When we released our first Betas of the BlackBerry® 10 WebWorks™ SDK and Ripple Emulator at the BlackBerry 10 Jam conference in May, we spoke about our desire to bring frequent updates of these tools to you, our dedicated developer community. We want to keep fueling your creativity and desire to build the best BlackBerry 10 applications leading up to the official release. So, here is your next BlackBerry WebWorks and Ripple fix.
This update brings a few new APIs (and emulation thereof in Ripple) along with a host of fixes and a slight change to how we handle whitelisting of events.
First up is the addition of the blackberry.ui.dialog APIs that will be very familiar to existing BlackBerry WebWorks developers. This API provides two methods that allow you to launch asynchronous dialogs requesting feedback from the user. These dialogs leverage the standard system level dialogs so you can get a consistent look and feel for your application with the rest of the system. standardAskAsync provides a predefined set of buttons for your dialog, whereas customAskAsync allows you to customize the dialog buttons.
We have also added an API that, in conjunction with the standard HTML5 onLine API, will let you know just how connected you really are. The standard navigator.onLine property and online/offline events are supported to let you know if your application has connectivity in general. If you would like to know what type of connection you have and when the type of connection changes, check out our blackberry.connection.type property, and listen for the connectionchange event. This will tell you if you are on VPN, BlackBerry® Bridge™, WiFi®, etc.
Speaking of events, we have adjusted how these work slightly from the first release. In the initial beta, all events were defined in the blackberry.event namespace. Without getting into gory details, this proved to be somewhat inefficient on the final code size, so we have moved the event definitions into the namespace that contains the functionality related to that event – i.e. the battery events are now defined in the blackberry.system namespace. Note that you no longer need to whitelist blackberry.event, since it only has the add and remove listener functions (these will always be available to call), but you will have to whitelist any namespace that has an event you are specifically interested in. Please check out the API reference.
In terms of bug fixes, there are a couple of key ones that I want to call out. If you use a module loader, you can now also use BlackBerry WebWorks, hooray! In the first release, the last one included into your app would work but break the first. Now webworks.js and module loaders play nicely together.
In the first release, you also could not sign your application at the same time as enabling remote web inspector. You can now do this so you can test your application on secure devices without needing to worry about debug tokens. That said, be sure to turn off web inspector before you submit your application to the BlackBerry App World™ storefront. 😉
The team here at Research In Motion® (RIM®) is hard at work on the next Beta refresh, currently slated to land in early July. If you are really eager/curious/have lots of free time, feel free to check out our progress in GitHub, and let us know whether we are heading in the right direction on new features and APIs.
For BlackBerry WebWorks SDK work, check out:
Ripple? Check out:
Looking forward to a great summer of BlackBerry 10 and BlackBerry WebWorks coding!