I am starting to realize that blog writing is similar to any other mental or physical exercise: it takes some time to knock the rust off if you take a break. Given how hard that first sentence was to write, I feel like red dust should be falling out of my ears. My robot vacuum cleaner needs to work harder to earn its keep anyway.

I do have a good excuse for my absence (I am not sure that Kinsella would agree). My first blog in a little while now comes to you from the sunny shores of Northern California. I have joined the (relatively) small but extremely dedicated contingent of BlackBerry employees fighting the good fight in the Bay Area. The relocation was no small task, let me tell you. Not the least of which was the four day drive from Toronto. I-80 is brutally efficient at getting you from A to B. But for some large segments, it is just brutal. Our dogs were also very efficient at letting us know when our travel day was (or should be) at its end.

But now I am setup here on the west coast, and fully in the middle of yet another move. If you missed BlackBerry Jam Americas in Orlando last month – nothing less than a cross-continent move will be accepted as excuse – you missed a very important BlackBerry 10 WebWorks roadmap session where we discussed the move of BlackBerry 10 WebWorks to use Apache Cordova at its core.

Fundamentally, the web is cross platform. While it is certainly not write-once/run-everywhere, the web does allow for a lot of reuse of code and assets. As mobile browser vendors continue to evolve and implement the various web technology standards, the amount of work to port an application becomes smaller and smaller. We are seeing web-based mobile applications become a much bigger piece of the total app pie. A large part of that is due to the success of Apache Cordova, which is the open source engine that powers Adobe’s Phonegap.

Our goal with BlackBerry 10 WebWorks is to ensure that we embrace the true philosophy of the open web, and empower our development community with the best tools and frameworks available to create rich web-based mobile applications. Moving BlackBerry 10 WebWorks to be based on Apache Cordova is a huge step in this direction and provides many benefits to our development community.

We are building support for BlackBerry 10 right into the core Apache Cordova project. This will allow Adobe PhoneGap developers to easily target BlackBerry 10 alongside other platforms for their mobile applications. BlackBerry 10 platform specific APIs will also be available as plugins for Apache Cordova (e.g. BBM, invocation, etc.)

As the center of gravity for packaged web applications, Apache Cordova garners a lot of attention from tooling and framework communities that will build their solutions to work with Apache Cordova. Having BlackBerry 10 as a core platform in Apache Cordova will help to ensure BlackBerry 10 WebWorks developers will be able utilize these tools as well.

To be clear, there are some differences in how you work with an Apache Cordova based application, specifically in terms of the command line tools, and some API signatures. All existing BlackBerry 10 WebWorks functionality does still exist, but the API signatures might be slightly different. Full documentation and porting guides will be available. The key thing to understand is that we have full compatibility built in. Applications built with an existing BlackBerry 10 WebWorks SDK WILL work on all 10.X code lines and new ones moving forward.  Similarly, apps built with the new Apache Cordova approach will ALSO work on all 10.X code lines.

I am really excited about being part of the Apache Cordova community, and about the benefits and opportunities this will bring for our dedicated BlackBerry 10 WebWorks developers. Stay tuned to this blog and the developer portal for news on how the move to Apache Cordova progresses.

Coding and deploying for the devices with 10.1 OS

Even if your older 10.0 Z10 version of the app runs “fine” on the newer 10.1 devices (Q10 and upcoming Z10 update) running the 10.1 OS version, you should try to use the latest 10.1 SDK. Why? Starting with the 10.1 SDK, you get access to some new features which will enhance your app’s experience on the Q10 devices significantly. This particular blog post here is a great source of information when you are converting your Z10 app for the upcoming Q10 devices. In terms of the UI elements that you can leverage as a developer, among others, you now have access to certain components like the auto hiding ActionBar, customizable/freeform and sticky TitleBar – these elements will allow you to maximize your screen real estate (for the smaller screen Q10 devices) and provide more room for actual content for the users.

Key shortcuts and listeners are some of the other slick new features; they make common tasks much easier for your users. The Q10 devices are definitely designed for the power users who love the physical keyboard and who value productivity greatly. You want to show them as much useful content as possible (even in the smaller screen) and require as few user input as possible to get to the primary features and content.

What about my current applications for the Z10 devices?

If there are any updates or bug fixes necessary for your currently public Z10 versions of the app (made using 10.0 SDK), you definitely don’t want to keep your users waiting. Until the in-market Z10 devices receive the 10.1 updates, you should continue posting updates and bug fixes as necessary. Going forward, the new 10.1 features that you will be using for Q10 devices (which you definitely should be) and upcoming Z10 updates; if they are mainly on the QML asset files, you can just continue to maintain just one BAR file. All the 10.1 specific QML code; those asset files can be placed in the folder called 720×720. For devices running lower 10.1 OS, that folder will just be ignored and only the QML files in the root folder would be considered. You can check out the github sample apps here to look at the code for projects like these. If you are using any new 10.1 C/C++ API then your application would need the latest 10.1.X.X SDK to compile against to bypass all the compile errors (the corresponding BAR file would also be a different one, since it would need the minimum 10.1 platform to run against).

Project Explorer View

The QML code under the 720×720 folder. It is using some new 10.1 specific features (e.g. customizable TitleBar).
If the same BAR file is run on the 10.0 devices, this code won’t be executed (the folder will be ignored).
Note: This is a modified sample code shown here just for demonstration

The QML file under the root assets folder; this will run by default. Note that there is no 10.1 specific code here

Note that you can install all the different SDK versions through the IDE update options and install the different OS versions. Re-iterating what is mentioned on the release notes:

• If you are developing using a BlackBerry 10 Dev Alpha device, you need to download the 10.0.10.263 target from the update site.
• If you are developing using the BlackBerry Z10 smartphone, you need to download a target from the update site that matches the device version that’s provided by your wireless service provider. You can verify the device version by opening the Settings app, tapping About, selecting OS in the Category drop-down list, and checking the version that’s listed in the OS Version field.
• For more information about developing apps that work on different versions of the BlackBerry 10 Native SDK, see Appropriate version of the BlackBerry Native SDK in the BlackBerry Support Community Forums.

How do I specify restrictions to BlackBerry World and BAR files?

When you are submitting the signed BAR files through your vendor portal account, you can choose the minimum OS version and the devices accordingly. These settings control whether or not your app will show up on the users’ BlackBerry World app (depending on the devices and the OS version they are currently running on).

Note that there is also a specific value that can be set through the bar-descriptor.xml file, which dictates the minimum required platform OS version required to install and run the app. This in turn gets reflected on the final signed BAR produced (MANIFEST.MF file). Do not modify this default value set unless you are absolutely certain which device OS versions you want to prevent the app from being installed (even if they are discovered through the BlackBerry World app). This value is checked by the OS itself when the app is installed and run using the BlackBerry World app. However, this is not something that the BlackBerry World looks at (currently) to filter what apps the user can see to download. This means, if you are playing around with this value, there could be instances where the user can see or buy the app through the BlackBerry World app but not be able to install it! The vendor portal filtering only gives you granularity between 10.0.0, 10.0.10 and 10.1.0 for now but if you are modifying the bar-descriptor.xml value for this, you can end up being really specific (10.0.9.X, 10.0.10.X, 10.1.X.X) which could prevent your users from installing the app (even if they are being able to see it or buy it).

The bar-descriptor.xml editor from the QNX Momentics IDE

Viewing the resulting signed BAR file through the IDE (MANIFST.MF file)

Viewing the resulting signed BAR file through the IDE (MANIFST.MF file)

Managing code base

Since there are newer API/libraries with 10.1 SDK, you might already be thinking about how to manage your code base better. Well, there are a few different options to choose from:

1. If you are already using a version control system like Github, just use the branching and merging technique for your code base
   • Create a new branch from your latest 10.0.X.X code version. Add all the new 10.1 features here and continue to use this one for devices running 10.1 (Q10 devices for now and soon to be Z10 as well)
2. If your 10.1 changes (e.g. using some of the newer UI elements and features) are mainly on the QML assets, you can make use of the static asset selector which is new with 10.1. Basically, your IDE will be pointing to the same project (code base) but based on which device you are targetting your app, it will select the respective .qml files
   • As mentioned before, the Z10 devices running lower than 10.1 OS, will just ignore the folders such as the 720×720
3. If you are using 10.1 specific API in your C++ code (only), you can use the NDK versioning macros to detect the OS versions. This forum post here talks about this in details

To Sum Up

• For devices running 10.1 OS, definitely use 10.1 SDK to compile and deploy your app; make use of all the useful features which will make the Q10 experience of your app significantly better
  • As soon as 10.1 OS is picked up by the Z10 devices, these app releases will be shown through BlackBerry World as well (provided you set the vendor portal filtering accordingly)
  • There is more than one way to manage your code base; you have to decide which one is best for you
• For posting updates and bug fixes to the 10.0 Z10 versions of your app, continue to use the respective 10.0 SDK to compile and deploy the app
• Sanity check: Don’t forget to test and try out the application on the OS versions that your users are expected to run the app

We hope at least some of this was helpful to you. If we have missed any particular cases, do bring them to our attention and we will try to advise accordingly. Hope to see all of your apps for the Q10 devices soon!

For both South Africa and India, the new pricing tiers reflect adjustments for updated foreign exchange rates, competitive benchmarking, consumer friendly price points, and taxes, where applicable.

The price change is completely automatic and will not impact the availability of your content items to customers. You are not required to take any action.

Should you like to adjust the price tier for your content items in a given country you can freely do so within the BlackBerry World vendor portal at any time.

Please note that if you make any changes to the pricing of your content items there will be a delay of up to 24 hours until the prices appear.

“Money” by PTMoney/CC/flickr

Most people like to be rewarded for hard work. There are of course many ways in which people derive reward. Fame. Adoration. Legions of followers on Twitter. Free cookies. But perhaps the most prevalent and obvious is cold, hard cash.

With BlackBerry World, there are a number of ways to get money out of your investment in your BlackBerry 10 application. Today’s refresh of the BlackBerry 10 WebWorks SDK brings support for ourPayment Service. The Payment Service allows you to implement in-app purchases, either one-time purchases or subscription-based services. Now you can choose your monetization strategy for your BlackBerry 10 WebWorks application: paid download, freemium, in-app purchases, digital goods, etc.

Check out the API reference to get started.  You will immediately notice that there are a few new additions to the API compared to previous implementations in BlackBerry WebWorks, such as cancel subscription.

While payment should be enough to get your excited on its own, we also were able to sneak in some of the final bits of the BBM Social Platform – namely support for the Profile Box.  The Profile Box is a customizable box for your app that appears in the current user’s BBM profile. You can use it to broadcast achievements or provide updates. The box contains a list of items, each composed of text and an optional icon. The Profile Box API allows you to manage the items in your app’s profile box. The API reference for this new API is here.

One final item that you should be aware of is how popup windows are handled. With this release, the popup blocker is disabled by default.  This means that popups will display in the Child Browser window.  If you wish to enable the popup blocker functionality there is a new parameter that you can pass in config.xml to the “blackberry.app” feature.  For information, see the <param> element.

<feature id="blackberry.app">
  <param name="popupBlocker" value="enable" />
</feature>

Be sure to download the latest SDK, and check out the Payment service to see how you can develop a richer monetization strategy for your application.

Car Polish / JMR_Photography / CC BY 2.0

Last month we delivered the Gold release of the BlackBerry 10 WebWorks SDK to our development community. This was a huge milestone on the road to launch for BlackBerry 10, allowing our developers to confidently develop, test, and submit their WebWorks applications to BlackBerry World, and to take part in the Built for BlackBerry program. I am sure all of you have already submitted your apps and are now relaxing by the pool.

Today we are launching a refresh to the WebWorks SDK that brings a number of fixes that, while not required for your application to run on BlackBerry 10, bring a few tweaks and stability improvements. There are two very specific updates addressing some underlying platform changes that COULD mean you will want to repackage an existing application. Let’s look at those first.

The concept of Cards in BlackBerry 10 is what really enables the Peek and Flow experience. There are many built-in cards that developers are able to leverage to complete common tasks or integrate with system services, and WebWorks has provided built-in APIs for some of these system cards. One of them is the File picker (blackberry.invoke.card.invokeFilePicker). In the gold release, you could provide a list of directories in the FilePickerOptions object, and the standard UI would present a selection list of those folders. This ability was removed from the standard UI. The API has not changed, but we only now look at and use the first entry in the array to seed the UI. So as long as you were not relying on this multi-directory functionality, or if you don’t mind that only the first is considered, then you have no need to repackage your application.

Another update relates to how Contacts are created, or more specifically, what happens when you save a newly created contact using the blackberry.pim.contacts API. In the Gold SDK, when you save a contact that you create using blackberry.pim.contacts.create(), it will always create a new entry in the device address book. The underlying native implementation changed slightly and will now attempt to merge it with an existing relevant contact entry if it finds one. If you are fine with this behavior, or if it is desirable, then you need to do nothing if you have already packaged with the Gold SDK. Otherwise, in order to preserve the behavior of creating a new contact, you will need to repackage with this latest WebWorks SDK refresh.

That’s it for compatibility concerns – not so bad. There is one other thing though that you will notice with the latest Dev Alpha update. If you are using the blackberry.invoke.card.invokeEmailComposer API, clicking the Send button actually does nothing. This has already been fixed on the native platform and will work at launch. You have no need to repackage your app, either now or later, as the fix is entirely on the device, but just something to be aware of if you use this API and are testing it on the latest Dev Alpha build.

Finally, let’s turn to a couple of the polish items that we have in this refresh. As most of you are probably aware, BlackBerry Balance allows the user to segment their device into multiple perimeters to separate work and personal. The enterprise perimeter can be locked if a password is enabled, and when locked, apps are “locked” as well. In order for you as the developer to know what the current state is, we have introduced events that you can listen for that will tell you when the perimeter locks while your application is open. Check out blackberry.system.perimeterlocked/perimeterunlocked.

We have also expanded the Contacts API to include the Accounts information for that contact. Check out the new field blackberry.pim.contacts.contact.sourceAccounts.

We recently added the ChildBrowser concept to WebWorks that allows you to support target=”_blank” and window.open in your web content. We also allowed you to disable it. With this release, if you disable the ChildBrowser and use target=”_blank” or window.open to display non-whitelisted content, the result will be opened in the system browser, rather than the user being presented with an access denied dialog.

Context menus and custom contexts have also seen a couple of improvements. When you add your own menu item to the context menu, the callback that is invoked when the menu item is clicked will be passed the id of the content element that the user long-pressed on. You can also now override existing menu items through the blackberry.ui.contextmenu.additem method. Just provide the platform action id in the additem call and you can provide your own text, image, and functionality for things like Copy, paste, and so on.

As you can see, unless you use one or two specific items, applications you have already packaged and built are still good to go. But if you do use the contacts API and wish to always create new items as oppose to merge, or if you used the file picker in a specific mode, you will want to repackage and resubmit your applications to BlackBerry World. And be sure to get your applications approved for sale prior to January 21st, and take advantage of the Built for BlackBerry program. Download the gold refresh of WebWorks today to polish up your applications before launch of BlackBerry 10!

DSC04801 / mat79 / CC BY 2.0

Months of planning. More months of development. Re-planning. Long hours. Trips around the world. Meeting with you, our BlackBerry WebWorks development community. It all culminates with this: the gold release of the BlackBerry 10 WebWorks SDK. The team here could not be more stoked to deliver this final developer milestone on the road to the launch of BlackBerry 10. I apologize for the use of the word “stoked” in the preceding sentence, but I could not help myself. We are REALLY excited.

We recently delivered the final Beta of the BlackBerry WebWorks SDK in conjunction with our recent BlackBerry Jam Asia conference. With that release we began guaranteeing compatibility of your applications, which was a major milestone. Hopefully you have already started submitting your apps to BlackBerry World for approval and preparing your application to the Built for BlackBerry program.

Of course, the team has continued to work days – and many nights – to ensure this gold release is rock solid. Of course, we also snuck a few new things in.

We now have a full house of cards that you can directly invoke from webworks. From the blackberry.invoke.card namespace, you can leverage the following new cards on top of the camera and file picker cards we already delivered: calendar picker, calendar composer, email composer, media player, contact picker, and ICS viewer card.

We have also now provided to you the means to leverage the built in invocation selection UI. If you choose to do your own invocation target queries and provide the user with the ability to select the target, you can use the API to present native look and feel selection UI.

Wallpaper: an interior decoration technique that has happily fallen out of favour (opinions my own and do not reflect those of my employer). But smartphone users love setting the wallpaper of their device. Allow the user to set the wallpaper from your BlackBerry WebWorks app:

blackberry.system.setWallpaper(pathToImage);

You can now also specify custom contexts in your applications that can be used as a target type for invocation request, and to put custom actions into the context menu.

<div align="left" data-webworks-context="myContext">>

   <h4>Local image link: with customContext</h4>
   <a href="http://www.blackberry.com">
      <img src="../../img/secretdeviceimage.jpg" width="150" height="350"/>
   </a>

</div>

If the user triggers an invocation – say, as a long-press on any element within the div in the code example above – the system will pass the “myContext” custom context in the invocation request rather than an image context.

In addition, you will often want the ability to know when your context has been the target of a user-triggered invocation, and do something before the system completes the invocation. In the example above, you might want to add to the invocation request additional relevant information for the “super secret device”. All you need to do is assign a function to the blackberry.invoke.interrupter property. This function will be given the invocation request object, and you can return a modified version of the object that will actually be sent on in the invocation request. You may also just want to allow the user to confirm they wish to take this action.

blackberry.invoke.interrupter = function (request) {          
	if(confirm("System would like to invoke: " + request + " would you like to continue?")) {
              return request;
        } else {
              alert("User canceled invocation");
        }
};

One of the key user experience items for BlackBerry 10 is the concept of Active Frames. When your application is no longer in the foreground but still running, it gets a placeholder window that by default displays a snapshot of the application when the user put it into the background. With this API, you can customize what is displayed. You can set a different image, as well as specify custom text that will be overlaid onto the image. If you wish, you can also periodically update the cover, or reset it to the snapshot originally taken by the system. Check out the documentation for more info.

function onEnterCover() {
    blackberry.ui.cover.setContent( blackberry.ui.TYPE_IMAGE,
        {path: "/path/to/an/image/windowCover.png"} );
    blackberry.ui.cover.labels.push({label: "Label 1",
                                 size: 15,
                                 wrap: false});
    blackberry.ui.cover.setTransition(blackberry.ui.cover.TRANSITION_FADE);
    blackberry.ui.cover.updateCover();
}

blackberry.event.addEventListener("entercover", onEnterCover);

Even though this is the gold release, we know there are a few things still missing that we are working hard to deliver. The nice thing about BlackBerry WebWorks is that we can expose existing native platform functionality outside of device OS and native SDK updates. Keep an eye on the flight boards as we are actively planning maintenance releases to deliver a few more things.

But the gold release is your cue to finish your BlackBerry WebWorks application so that you can leverage the first-mover advantage. Get out in front of the wave and be one of the first applications in BlackBerry World. And be sure to get your applications approved for sale prior to January 21st, and take advantage of the Built for BlackBerry program. Download the gold release of BlackBerry WebWorks and put that final luster on your applications!

As we promised a few weeks ago, a BlackBerry® WebWorks™ SDK would be released soon that would have compatibility of applications moving forward. That day has arrived with the latest update to the BlackBerry 10 WebWorks SDK! Applications that are built with this BlackBerry WebWorks SDK will run on the latest delivered BlackBerry® 10 OS beta version as well as future OS updates.

Note that this does not mean that APIs don’t have the potential to change in the future, and there will certainly be more APIs added – but an application binary compiled with this SDK will continue to run on future OSes. With this guarantee, you can now build your BlackBerry WebWorks applications and submit them to the BlackBerry App World™ storefront for approval. You can now also apply for the Built For BlackBerry program before January 21st 2013 to take advantage of our 10k Developer Commitment to developers.

However, no BlackBerry WebWorks release would be complete without some new API additions. We have a ton of great stuff so let’s dive in.

Perhaps our biggest addition is the ability to integrate with the Calendar on the device. Create, edit, delete – it’s all there. It also delivers access to all calendars available on the device while of course respecting the work/personal boundary provided by BlackBerry Balance™. Combine this with the Contacts API delivered in the previous release for some very compelling applications that integrate with the BlackBerry 10 integrated PIM story.

Everyone likes toast (well, they should), and BlackBerry 10 has brought a mobile flavor to this breakfast staple with the Toasts notification concept. Toasts are quick, non-blocking notifications to the user that your application has performed some action, which are displayed for a minimal amount of time and then disappear. You can also enhance your toast with butter a button that allows the user to take some action in relation to that toast (eg. a toast that notifies the user that an item was deleted, and provides an Undo action). Check out blackberry.ui.toast for more on this one.

blackberry.ui.toast.show(“Pass the jam!”, options);

Now, wouldn’t it be cool if you could have a sensor in your phone that would tell you that your toast is ready before it was burnt? Well, no, we can’t do that (yet). But with this release of BlackBerry WebWorks, you now have access to a whole host of new sensor APIs. Orientation, light, proximity, compass, space-time disturbances; okay, not space-time, but yes on the rest. Leverage these APIs to add some real value into your application based on the device environment.

// Create a callback to handle each sensor function compassCallback(sensor, data) {
     alert("Current azimuth: " + data.value); }

// Start listening to the compass sensor with a delay feedback of 1000  blackberry.sensors.setOptions("devicecompass", { delay : 1000 });

// Start the event listener for the sensors callback blackberry.event.addEventListener("devicecompass", compassCallback);

In the previous release of BlackBerry WebWorks, we provided a way to lock the orientation of your application by setting a flag in the config.xml. We have now provided a full JavaScript® API that allows you to lock/unlock your application dynamically based on your own logic. There are a few things to note with this change: To have a good JavaScript API signature, we are putting the orientation functionality right on the blackberry.app namespace, but this is out of line with the current config.xml approach of putting the parameter on the blackberry.app.orientation feature. So we have deprecated this, and now you should put orientation in config.xml on the blackberry.app feature. Also, if you do choose to set it in config.xml, that is a constant value that cannot be overwritten by the API – what you set in config.xml is what you get.

Speaking of config.xml, with this release we have all the pieces in place to allow for full localization of your application, including the display name of your application as well as the description. In the config.xml, you just need to put the localized text inside another element with the xml:lang attribute for the language. Furthermore, all of the built-in UI components are fully localized and reflect the current system language.

<widget xmlns="http://www.w3.org/ns/widgets">
<name>
    The Ultimate Weather Widget
</name>
<name xml:lang="fr">
     insérez Françaises ici
</name>
</widget>

Let’s now take a look at some enhancements made to the underlying BlackBerry WebWorks platform. With this release, we have delivered a number of different optimizations to the runtime initialization process. Lots of highly technical, egghead type stuff. Long story short – your apps should load a whole bunch faster for your end users. Be sure to get the latest BlackBerry 10 OS build to see the full benefit.

Perhaps even more interesting is the addition of a child web view control. If you have a link in your content with target=”_blank” or use the window.open function, the content will now be loaded in a child web view that looks much like a card and won’t overwrite your current content. The user can then cancel the view to return to the originating page. When you use window.open, you will receive a window object for the child web view. One of the more obvious use cases here is a more seamless method of supporting OAuth for authentication into social networks like Facebook®, foursquare, Twitter®, and so on.

We have also added a new attribute to the element in config.xml that allows you to specify a single HTTP header key-value pair. This HTTP header will be added to every HTTP request sent from your application. This allows your backend system to key off of this header and perform any required customized processing for your app.

<widget rim:header=”header:Goooallll!”>

If that wasn’t enough on its own, we have also added a few new tooling features that should make your life a lot easier. First on deck is the ability to pass your application’s root folder into the bbwp tool to package your application. No more requirement to first zip your application content and risk feeling silly when you forget to update your zip file with your latest changes. The packager also supports ignoring folders and files within your application folder hierarchy; just create a “.bbwpignore” file in the root folder and list the folders and files you don’t want to be part of your application packager. The format of this file is essentially the same as the .gitignore file, with one or two very small differences.

Another potential time saver and headache reliever is a new facility that will allow you to forget about ever needing to update the version of the webworks.js file you reference in your app. In your application files, reference the webworks.js file like so:

<script src=”local:///chrome/webworks.js”>

The packager tool will include the latest webworks.js into your package and put it at the appropriate location to be loaded.

So there you have it. It is worth reiterating that with this release you can now submit your apps to BlackBerry App World and be assured they will run properly come launch of BlackBerry 10! So submit early so you can get your application approved, and then apply for the Built For BlackBerry program before January 21st, 2013. No time to waste – grab the SDK today!

There has never been a better time to build for BlackBerry. If you are a web developer, building with the BlackBerry 10 WebWorks™ SDK is your path to the Built for BlackBerry program and the $10k commitment.

Now, while BlackBerry App World is accepting application submissions (as of 10/10/2012) for BlackBerry 10, you will want to hold off on submitting your BlackBerry 10 WebWorks applications for just a short while. Using the current publically available BlackBerry 10 WebWorks SDK, you can build, package, and test your application against the current BlackBerry 10 OS builds available in simulators and the BlackBerry 10 Dev Alpha testing device. However, those same applications will not work in upcoming builds of the BlackBerry 10 OS, so your application would be rejected by the BlackBerry App World team.

Unfortunately, unavoidable changes were made in the underlying web runtime that broke compatibility. Have no fear; the development team is hard at work ensuring that the next release of the BlackBerry 10 WebWorks SDK – due in November – will ensure compatibility moving forward. You will NOT have to change any of your code; this will simply be a repackaging exercise with the new SDK to create an application package that will run correctly on the latest BlackBerry 10 builds.

So hang tight for our next release of the BlackBerry WebWorks SDK – which in itself has some cool new features that you will love – and then get submitting to BlackBerry App World!

After a bunch of hard work, bbUI version 0.9.4 is finally here. The focus in this release has really been around bug fixes, optimizations and additional JavaScript® interfaces. The previous versions of bbUI have been VERY declarative and haven’t allowed for much manipulation after the fact via JavaScript. This release takes a step in the right direction to allow you to create more dynamic user interfaces via JavaScript. While there are some improvements in this department with v0.9.4, we’re not finished yet and have much more planned for v0.9.5.

One of the best things I’ve seen lately is the number of people participating in the project. It’s absolutely fantastic to see members of the community grab items from the roadmap, implement them and send them back as pull requests. These pull requests are full on feature creation as well as bug fixes. A gigantic THANK YOU goes out to all those who are helping to improve bbUI!

Be sure to check out the full change log for this release to know what kind of adjustments you may need to make to your JavaScript in order to run v0.9.4, and check out the closed issues for details on bugs that have been fixed and features that have been added. The v0.9.4 JavaScript changes are fairly minor and are meant to make your life easier as we continue to move forward.

Notable Improvements

• Updated coloring/styling to better match Cascades™
• New Title Bar styling which now allows images in the Title Bar
• New BlackBerry® PlayBook™ tablet 2.x styling for Activity Indicators, Text Input, Image Lists and Buttons
• Many new JavaScript interfaces to manipulate controls on-the-fly
• Native scrolling speed increases
• Screen stack bug fixes
• Control bug fixes

Changes to your code

I mentioned that there were a few changes that were made that will affect your applications JavaScript so let’s talk about those.

• bb.init()
  • bb10ActionBarDark renamed to actionBarDark
  • bb10ControlsDark renamed to controlsDark
  • bb10ListsDark renamed to listsDark
  • bb10HighlightColor renamed to highlightColor
• You no longer specify a viewport meta tag in your main index.htm. This is now supplied by the toolkit at runtime based on the OS version.
• BlackBerry® 10 title bars now take on the control coloring.
• You no longer need to specify a unique id for your script tags used with screens.
• Scroll Panel JavaScript interfaces have been modified.
• If you were calling bb.scroller.refresh() you will want to change your code to “if (bb.scroller) bb.scroller.refresh();”

More to Come

We’ve now created an additional v0.9.5 milestone for bbUI that contains additional BlackBerry 10 styling improvements, but also includes more JavaScript interfaces for dynamic screen creation and manipulation. If you’re interested in following the bbUI.js changes as they go, feel free to follow me on Twitter®.

We’ve updated our flight arrival boards to provide statuses on all of the feature functionality delivered with the September BlackBerry® 10 development tools update. Along with this, we’ve updated some milestones leading up to the Gold SDK releases.

In my previous blog post, I mentioned that we were still considering whether or not to do another set of SDK updates after our September release and before the final Gold SDK build. Based on feedback from our developer community, we’ve decided to add another SDK release on the road to Gold. We’ve updated the SDK release schedule to reflect these needs while ensuring that there’s no impact to the first BlackBerry 10 smartphone being delivered on-time in Q1 2013. The updated SDK schedule is as follows:

November: SDK Gold Candidate

• Updates to all SDKs
• Mainly bug fixes

December: SDK Gold

• Updates to all SDKs
• Mainly bug fixes

December: Keyboard device SDK Beta

• Updates to necessary SDKs targeted at compatibility testing for QWERTY devices
• User Experience tweaks to Cascades/Adobe AIR controls to account for screen resolution changes

The November release will be a gold candidate release which will contain mainly bug fixes and further stabilized SDKs for you to continue testing. This will be the SDK candidate that RIM® will continue to test and be finalized in December as the Gold SDK. Be sure to check-out the updated flight arrival boards for the details associated to the SDK of your choice.

Wait a second, you show a Keyboard device SDK Beta. What the heck is that?

In December 2012, we’ll also be releasing the necessary Beta SDKs to allow you to perform compatibility testing of your application for the first BlackBerry 10 QWERTY device. Since this new device will be a different screen resolution (720×720 vs 1280×768) than the first all-touch BlackBerry 10 device, we want to make sure you have simulators and updated SDKs to test your applications.

This SDK release will also include any UI tweaks for the Cascades™ and Adobe® AIR® controls to match the new Keyboard device screen resolution. The controls mainly affected are Action Bars, which are adjusted take up less screen real estate.

Why do I see some new items appearing in the upcoming November release?

With this current September release, we do consider the Native SDK, Adobe AIR and Android™ Runtime API complete. However, there are a few small additional items that will be coming into the November release. These are mainly small additions that will not affect the main APIs, which are now considered complete. BlackBerry® WebWorks™ is one of the exceptions that will be continuing to deliver new APIs both in the Gold Candidate and Gold release.

Where do I find these Flight Arrival Boards?

You can check out each of the Flight Arrival Boards by clicking on the “Roadmap” links on each of the websites or check out the links below:

Native SDK
Cascades Application Framework Roadmap
Core lower level API Roadmap
HTML5/BlackBerry WebWorks SDK Roadmap
Adobe AIR SDK Roadmap
Android Runtime Roadmap