Why Are BlackBerry Widgets Repackaged?


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.


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 is an Open Source Technical Lead at BlackBerry, focusing on WebWorks, HTML5, and Open Source.

Join the conversation

Show comments Hide comments
+ -
  • iamtony

    A good read Tim.

    Will there be changes made to our BlackBerry Widgets in the future if for example W3C does manage to standardize a security framework? Or will our current BlackBerry Widgets still be the same?


  • Tim Neil

    Hi Tony,

    We are carefully watching W3C, BONDI, JIL etc. to see where they head around security and other aspects. With most of these initiatives it is still a “lowest common denominator” approach where we will still want to have the freedom of providing BlackBerry specific APIs not found on other platforms which makes applications on BlackBerry Super Apps. We also want to continue to provide the flexibility for a Widget developer to get down to Native calls where they see the need.

    How mobile widgets evolve will be quite interesting, and expect us to play a role in this field. We are already participating with the W3C on driving a security standard as well as other areas. We are also playing a lead role on the evolution of WebKit on mobile.

    Whether or not we continue to re-package a BlackBerry Widget in the future will depend on the flexibility of these evolving standards as well as our evolving BlackBerry Platform.

  • Dominic Aquilina

    It seems like a well-thought-out and intuitive approach to distribution. I'm glad that RIM has put in the effort to standardize all of their software.

  • http://twitter.com/johnsin John Drefahl

    As the JIL Developer Support Lead for the United States I can guarantee you that things will be moving along a lot fast once the WAC/JIL merger has been completed. JIL initially was only 4 carriers, but now with the merger taking place there is a good possibility of over 22+ OpCos from around the world adopting the JIL Widget Runtime Platform. But don't let that statement trick you into thinking that the JIL Runtime and the JIL Distribution Platform are at all dependent on each other. Newer versions of the JIL/WAC AppStore Distribution Platform are being re-engineered to be Application Runtime agnostic. The .WGT file format that was invented by JIL will continue to build of itself through iterations of updates, but in order to meet the expectations of what a Mobile Application Distribution Platform is for all the players in WAC.. The distribution platform's back-end is trending to be app agnostic, and will be used to deliver many types of mobile apps. Remember, this isn't about a runtime.. Its about the OpCo's regaining a foot hold in market share they are loosing to Apple and Google. Imagine how embarrassing it is that you can't make a single dollar off Apps when you are the consumer facing piece of the entire value chain? Another reality people seldom realize is that a majority of the market is not the Smart Phone demographic. Pre-paid and throw-away phones are the bread and butter of the industry. Unfortunately, that demographic (unless it's kids) is not a very “sexy” group to market to…Draw your own social/economic conclusions of why carriers do what they do. But one this is for sure, and Verizon realizes this. There is a hell of a lot more revenue to be made selling low cost “slimapps” at 0.50usd to 1.00usd through their own VZ Store… then there is with the Droid. Remember.. Most people don't care about smart phones, but they do expect their Boost mobile to do a couple things besides phone calls, sms, and navigation. They expect that their is an “Atomic Fart App” just like all the rich hipster kids that are invading their neighborhood have. You know what.. They are on the verge of getting it, and a lot more of it.. and the affluent smart phone (iphone bloatware loving crowd) is going to once again realize that if they would have just waited a little.. That they may have saved 20grand in contract/fone fees. Just something to ponder.. Big things to come.. When you can create apps that rival Iphone/Android native apps coded in Java and Objective C with apps coded using only HTML 4 (hopefully 5), CSS 2 (hopefully 3), and a little bit of JavaScript to access handset/apis.. it's a game changer.. and the whole hot as balls Android/Iphone developer market is going to cool off really fast.

    Just be patient.. learn from your mistakes from the past.. :) It's all coming!

  • http://twitter.com/johnsin John Drefahl

    I can't say too much, but as the JIL Developer Support Lead for the United States I can tell you a couple things.

    1. Once the JIL/WAC merger is completed.. there will be over 22 OpCos around the world using the JIL Appstore Platform for mobile application distribution through the phone.

    2. JIL's ..WGT file format and widget runtime is not dependent on they actual JIL AppStores. Sure at this moment.. the various Vodafone Appstores that are deployed only serve JIL .wgt applications. With 22 carriers now coming aboard I think its safe to say that we have come to a fork in the road. .WGT will continue to develop it's specs, but I think its very safe to say that the actual Mobile Application Distribution Appstore Platform will no longer be JIL dependent, but APP agnostic. Watch for the first .WGT roll-outs to happen with Verizon through the VZ Stores by Q1 2011. When it comes to security.. We use Trustcenter Developer ID's to sign applications. If we find an application to be malicious.. we pull the certificate from the system, and the “Widget Runtime on the Handset” does the dirty work of deleting it. Google prefers to view security on mobile devices as scaled down Linux User Privs.. and sandboxing.. Eventually there will be industry consensus on the best practice… But there will be consensus.. Why? Because with every App that comes out for a mobile device.. that is one less need for a website. This time they can actually charge us for it first!

    Welcome to Web 3.0.. The Mobile Web, the web you actually will pay for. :) Not a bad thing if you ask me.. I never liked the scumbagness of being a contractor in the industry to begin with. Knowing their is a revenue stream only means now that a lot of 19 year old kids who are going to work for pennies on the dollar will actually get that check they deserve, and not have to run after some silicon valley douche bag in his Audi T3 just to pay his rent.

  • Thomas Kraemer

    I don’t get the “Intellectual Property” part. Just open the signed cod file with any text editor and you will see all the HTML, JS and CSS. Looks like I have to write my own content encrypter as on all the other mobile platforms.

blog comments powered by Disqus