Why Are BlackBerry Widgets Repackaged?

Editorials

With the great reception of BlackBerry® Widgets on the BlackBerry® 5.0 operating system – and all the talk around mobile widgets in general – we are often asked, “Why do we have to repackage our widget archives for the BlackBerry® smartphone?” After recently explaining the reasons behind this to one of the attendees at Mobile World Congress, they pointed out that the information would make for a great blog article.

There are many emerging standards around mobile widgets such as W3C, JIL, BONDI and others. In all of these different technologies, a widget application is simply a ZIP archive that is loaded into a widget runtime and executed on a smartphone. Those who are working with these emerging standards – and are now working with BlackBerry Widgets – usually question why Research In Motion (RIM) repackages a BlackBerry Widget instead of leaving it as a ZIP archive. Wonder no more – the answer lies below the jump.

How are BlackBerry Widgets Repackaged?

To give a little bit of background, I thought I would first describe how BlackBerry Widgets are repackaged.

The process of using the BlackBerry Widget Packager is to bundle a widget as a native BlackBerry application, which utilizes a Browser Field Java® control to render the content and run the JavaScript.

When the widget archive is processed by the BlackBerry Widget Packager, all the web assets (HTML, CSS, JavaScript®, Images etc.) of the widget are left untouched and are encapsulated as embedded resources. The JavaScript BlackBerry Widget APIs are then added to the nested Browser Field control.

Security

The number one reason for repackaging is based on security. Standards for a mobile widget security model are still in the developing stage; some widget frameworks such as JIL (Joint Innovation Labs) have a defined security model already, while others such as a standard W3C widget don’t quite have the security topic ironed out. The W3C is looking to standardize a security framework for widgets, but that work isn’t quite ready yet.

By packaging a BlackBerry Widget, it inherits the same BlackBerry security that has been built into the operating system since day one. This allows the user or system administrator to manage and set security permissions for a widget the same way they would for any other application on the smartphone. This also means that users don’t have to figure out where to go to configure the security for a widget versus a Java application. It is all configured the same way.

Intellectual Property

One of the complaints I occasionally hear from widget developers is that normally, the entire source code and assets of their application are quickly extractable from the zip archive. By repackaging a BlackBerry Widget and processing the archive, it provides an opportunity to better protect the assets of your application.

Application Management

A BlackBerry Widget installs and uninstalls the exact same way as any other application on the BlackBerry smartphone. It appears in the same application list for viewing application details and leverages the same menu items from the Home Screen to delete an application. This provides a consistent user experience for those looking to manage their installed applications on a BlackBerry smartphone. In contrast, having a separate runtime manager and installation model for widgets did not provide the desired user experience.

Distribution Model

The ability to distribute a BlackBerry Widget was another big influence in the repackaging approach. There are already many supported mechanisms for distributing and selling your BlackBerry applications, such as:

  • BlackBerry App World™
  • BlackBerry® Desktop Manager
  • Pushed Over the Air installation
  • Install via a hyperlink in the BlackBerry® Browser
  • Deployment through the BlackBerry® Enterprise Server
  • Third party application stores

By packaging a BlackBerry Widget the same way as all other existing BlackBerry applications, it gives developers many different immediate options for distribution of their widgets.

Chicken vs. Egg

One of the tricky challenges when providing a runtime-based technology is to make sure that the desired version of the runtime is available for the developer wanting to install their application. For BlackBerry Widgets, we took the approach of making sure all the needed pieces for building a runtime were part of the BlackBerry Operating System v5.0. We then essentially created a lightweight runtime around each and every widget packaged.

This approach gives the freedom to add new JavaScript APIs and widget functionality without upgrading a runtime, and also allows a developer to create their own custom JavaScript extensions. It essentially removes the need for upgrading a runtime.

One thing that a lot of people don’t realize is that we actually distribute the full source code of the lightweight wrapper used for repackaging, found in the “device_templates” directory, as part of the BlackBerry Widget SDK. You can even make changes to this source code to better tailor it to your needs.

In Summary

The decision to repackage a standard widget archive into a BlackBerry Widget was based on many different factors, including the ability to provide the most flexible architecture for developers, the addition of security protocols, and enabling the most distribution methods possible.

I really encourage those out there who have not yet tried BlackBerry Widget development to download the tools. Give it a try and let us know what you think.

About Tim W.

Tim works on the Developer Relations team at BlackBerry, focusing on WebWorks, HTML5, and Open Source.

Join the conversation

Show comments Hide comments
+ -
blog comments powered by Disqus