Update your BlackBerry WebWorks application without Recompiling

Tips and Tricks

I’d like to share a useful practice that can help to improve the efficiency of your BlackBerry® WebWorks™ development: how to get around recompiling your BlackBerry WebWorks application after small edits are made.

Web developers have the ability of being able to make quick changes to their applications, such as tweaks to verbiage, style or layout of content, without the need for recompiling the application to see the changes. The changes can be made directly on a development server, and previewed immediately in a browser.

With the introduction of the BlackBerry WebWorks SDK, web developers may be faced with BlackBerry applications that require a more formal compilation and deployment process. Using the BlackBerry WebWorks SDK and a configuration file (XML), web resources (HTML, JavaScript, Image files) are embedded into a compiled BlackBerry application (COD file). This COD file is your BlackBerry WebWorks application that is then deployed to a BlackBerry® smartphone (or simulator).

The authoring process looks like this:

  • Make content changes
  • Build BlackBerry WebWorks application
  • Deploy to BlackBerry smartphone (or simulator)
  • Preview & test the changes

Wouldn’t it be great if, for the purposes of development, this process could be simplified to the following?

  • Make content changes
  • Preview & test the changes

That sure would save a lot of time, while you are developing your content, wouldn’t it?

Well, with the BlackBerry WebWorks SDK, you can do this – here’s how.

When creating a BlackBerry WebWorks application, you tend to define a statement in your configuration file to load your web content as embedded resources. This means that each time a content change is made, you would need to recompile the application. Instead, you can deploy this content to an external location such as a shared network domain or even the device SD Card. Next, configure your widget to load the content from this location. Separating this remote content from the compiled BlackBerry COD file means that the widget does not need to be recompiled and re-deployed when small changes are made to this content.

So how do you do it?

Update the content element in your configuration file to load your primary index.html file from a different location. Change the content element in your config.xml file from

<?xml version="1.0" encoding="UTF-8"?>
<widget xmlns=" http://www.w3.org/ns/widgets"
            xmlns:rim="http://www.blackberry.com/ns/widgets" 
            version="1.0.0.1">
      <name>Test<?/name>
      <content src="index.html"/>   
</widget>

to the following if your web resources are deployed to a remote location:

<?xml version="1.0" encoding="UTF-8"?>
<widget xmlns=" http://www.w3.org/ns/widgets"
            xmlns:rim="http://www.blackberry.com/ns/widgets" 
            version="1.0.0.1">
      <name>Test</name>
      <content src="http://mytestsite.com/index.html"/>     
</widget>

or the following if your web resources are deployed to a SD card:

<?xml version="1.0" encoding="UTF-8"?>
<widget xmlns=" http://www.w3.org/ns/widgets"
            xmlns:rim="http://www.blackberry.com/ns/widgets" 
            version="1.0.0.1">
      <name>Test</name>
      <content src="file:///SDCard/myTestFolder/index.html"/>     
</widget>

Next, add the following access element to your config.xml file. This element will grant permission to your application to access resources from the specified URI. Without this declaration, any requests for resources from this URI would be denied.

<?xml version="1.0" encoding="UTF-8"?>
<widget xmlns=" http://www.w3.org/ns/widgets"
            xmlns:rim="http://www.blackberry.com/ns/widgets" 
            version="1.0.0.1">
      <name>Test</name>
      <content src="http://mytestsite.com/index.html"/>   
      <access uri="*" subdomains="true"/>
</widget>

When you build your application, you would normally include your web resources in the ZIP file that you provide to the BlackBerry WebWorks Packager. You don’t need to include these files in the ZIP file at this point as they are not being referenced as embedded resources and do not need to be compiled into the BlackBerry COD file. Instead, make sure these files are deployed to the location specified in the content element of your config.xml file.

The BlackBerry application that is created can now be built and deployed. When launched it will retrieve the content from your index.html file from the location you specified in your config.xml file.

While you are developing the content for your BlackBerry WebWorks application, you can make changes to the web resources without having to rebuild and/or redeploy your application.

Before you go…

Following this practice, it’s important to remember that your config.xml file needs to be updated whenever your widget content references elements from the BlackBerry JavaScript API collection. For instance, if you add content to your remote web resources that use elements from the blackberry.system namespace you would need to add a feature element to your config.xml file for this namespace. This change would require a recompile and redeployment of the BlackBerry WebWorks application for this any changes to be reflected.

Finally, please keep in mind that this practice is only recommended for development of your content. In most cases, you would not want your web resources publicly exposed, as this would introduce a risk of unwanted content changes. When you are confident your content is complete, update your config.xml file to reference them as internal resources, then include these web resources in the ZIP file used to build your BlackBerry WebWorks application.

I hope this practice helps reduce your development time. Enjoy and good luck!

About Adam S.

Adam is a Team Lead on the Developer Relations Team at BlackBerry. He manages technical relationships with ISVs as well as incubating the developing community ecosystem. Adam specializes in producing applications based on web and native technologies.

Join the conversation

Show comments Hide comments
+ -
blog comments powered by Disqus