In honor of 10/10 and the opening of BlackBerry App World™ for BlackBerry 10 app submissions, we’ve put together a list of the 10 most viewed blog posts in the developer blog about BlackBerry 10. It’s been an eventful couple of months! Check out how far we’ve come:

1. BlackBerry 10 Cascades™ is here!
2. Introducing Built for BlackBerry and the $10K Developer Commitment
3. Standardizing on Screen Resolutions for BlackBerry 10 devices
4. The BlackBerry 10 Native SDK Experience
5. BlackBerry 10 WebWorks™ SDK Released!
6. BlackBerry 10 – The Evolution from Beta to Gold
7. Flight Arrival Boards have been posted!
8. The BlackBerry 10 User Agent String Has Arrived!
9. BlackBerry 10 Samples Galore
10. Creating Outstanding Apps with bbUI.js – Community Tutorial

Now, you can submit your app to the BlackBerry App World for BlackBerry 10.

What was your favorite BlackBerry 10 related blog post? Share with us in the comments below!

Many great APIs and features have been delivered to our BlackBerry® WebWorks™ developer community with the recent updates to the BlackBerry WebWorks SDK. The Ripple Emulator is a key part of our tooling story for our web developers, and Ripple just got richer. Today we have released Ripple 0.9.8 with some excellent new features. If you already have our Ripple Emulator installed, then you should be updated automatically the next time you start Google Chrome. If you haven’t yet installed Ripple, then don’t hesitate — get on your (virtual) scooter and head over to the Ripple download page to get the latest version. Please pay careful attention to the install instructions, as with the latest versions of Chrome, you can only install the Extension by dragging it right into the chrome://extensions page.

In this update to Ripple, you will find a new area in the Chrome Extension panel for Ripple that will allow you to start and stop the build and deploy services from within the tool itself. You will no longer need to start and stop the services manually. You can even set the services to start and stop each time your start Chrome if you like. This should be welcome relief compared to previous versions where you needed to start the services from the command line.

Also in this release is emulation for a number of APIs delivered in recent BlackBerry WebWorks SDK releases:

• Blackberry.app.exit
• Software version and hardwareId
• Support for the swipedown event
• Support for the Invoke framework, both invoking other applications and being invoked

Further, enhanced support for Apache Cordova emulation is included. A bunch of work has been done here, including:

• Navigator.camera
• The media APIs
• The File APIs
• Events
• Navigator.contacts
• Partial support for the navigator.device.capture API

We are really excited about how Ripple is evolving, and look forward to hearing your feedback on the latest additions. Fire up Google Chrome if you already have Ripple installed and start playing with the new features. Otherwise, head over to the Ripple download page to get the latest version and get started!

Hopefully you aren’t getting tired of me yet, and I’m sure you are not tired of the updates to the BlackBerry® WebWorks™ SDK. We’ve just posted a new release, and it squarely falls in the high-value realm. While incremental, it empowers a significant feature of the BlackBerry WebWorks platform: custom API extensions. That’s right, like previous BlackBerry WebWorks platforms, you can now write your own extensions to enable native capabilities not yet exposed by the pre-packaged BlackBerry WebWorks APIs!

First, let’s quickly mention the other major item in this release: Now, when you build your application, you can pass a configuration file to bbwp.exe – the main command line tool for BlackBerry WebWorks – which will pass parameters on to the other downstream command line tools that bbwp.exe leverages. bbwp.exe is your main command line tool to create your applications for BlackBerry WebWorks: it will give you your .BAR file and even sign it for you. However, under the covers, it uses a couple of other command line tools that are part of the BlackBerry tool chain to perform these actions such as creating the .BAR and signing it. These other tools sometimes have parameters that are not exposed by bbwp.exe. With this release, we have provided a parameter (-p or –param) on bbwp.exe to provide a file on the bbwp.exe command line that you can use to pass on to the downstream tools any additional parameters you choose. It is a simple json structure that you can mark up. The main use case we hear quite often is providing the signing tool with proxy settings. Check out the params-example.json file in the root of your BlackBerry® 10 WebWorks SDK installation for an example. It contains the framework for providing parameters to the other two tools, the native packager that creates the .BAR, and the signing tool which signs the .BAR.

OK, now back to custom extensions. As a quick recap, BlackBerry WebWorks APIs are conceptually comprised of two different things: an API or service in the native platform, and a JavaScript® front-end to this native service. All of the APIs that are part of the official BlackBerry WebWorks SDK take advantage of this architecture and a system called jNext. jNext is what binds the JavaScript layer to the native layer. You can now build your own API extensions in exactly the same way we do.

To get started, you will first need to download our BlackBerry 10 Native SDK and configure it. This will give you access to all that the native environment offers. Go do that now and come back here for the next step.

All right, you’re back. Next step is to visit our GitHub Community API repo and download the sample BlackBerry 10 Native SDK project we have provided. This sample project is a working example of an extension that monitors memory usage on the device. Everything you need to create your own extension is modeled here. A full walk-through of the project and its components can be found in the README associated with the project in the GitHub repository, so check that out next, and get working on your extension.

Once you are done, I highly recommend that you check out our Community API repository, and seriously consider contributing your extension to the repository so that others can take advantage of your awesome work. To contribute the extension you will need to apply the ASL 2.0 license, and complete a few other administrative things, but then the whole BlackBerry WebWorks community can benefit.

One thing to bear in mind with your extension: we really didn’t want to hold back on releasing this feature to our community, but we do know that one thing will change in our next BlackBerry WebWorks SDK release. When you completed your extension, you would have had to create/modify a file called manifest.json. This file provided metadata regarding your extension. Moving forward, we will very likely model the format of this file after the CommonJS package.json file format (used by npm modules). This should not constitute very much refactoring, as the current file format is very concise, and the community alignment is valuable in itself.

OK, that’s it for this release. As always the team is working on some exciting stuff for the next release. I can’t wait for the next release! Until then, head over to our download page and our GitHub repo to start working on your custom extensions!

One of our priorities is to make sure that apps written with the BlackBerry Native SDK for Tablet OS will transition with minimal hassle to our BlackBerry 10 platform. We don’t want you, our developer community, to have to reinvent the wheel or tweak significant amounts of code. We also want to make sure that our developers are aware of changes coming to the platform that may impact them so they can prepare accordingly. With that in mind, I want to talk about two important upcoming changes to the BlackBerry 10 Native SDK in order to help developers prepare for upcoming releases. The motivation for both changes is to help developers scale their apps from tablets to phones.

The first change has to do with multi-icon support. We want to create a seamless way for developers to port their BlackBerry PlayBook tablet applications to the BlackBerry 10 smartphone. As we support two device screen sizes, applications may need to provide more than one icon size depending on the device they are being installed on. Developers will now be able to specify a list of icons and splash screens per locale and per resolution in the bar descriptor. These would be of various sizes to suit the different target displays. The runtime will then choose the icon and splash screen that matches the given display. We will be maintaining backwards compatibility, so existing apps written for the BlackBerry PlayBook tablet should not have to modify anything. However, if you are moving your app to a BlackBerry 10 device, you will have to specify icons and splash screens with alternate sizes.

The second important change is with respect to orientation. On BlackBerry 10, native applications will not be able to get the width and height values that they need for sizing their windows and determining orientation by querying the ‘WIDTH’ and ‘HEIGHT’ environment variables. If the width is greater than the height, the application will know it is running in landscape mode and vice versa. This behaviour has changed from BlackBerry PlayBook OS 2.0. On BlackBerry PlayBook OS 2.0, an application would query the screen APIs to get its width and height. For applications running on BlackBerry PlayBook OS 2.0, they can continue to rely on this behaviour as this is now going to change. On BlackBerry 10, however, applications are discouraged from querying for their width and height using the screen APIs. The following code snippet illustrates how an app can query for its width and height:

int screen_resolution[2];
screen_resolution[0] = atoi(getenv("WIDTH")); //get width
screen_resolution[1] = atoi(getenv("HEIGHT")); //get height

Once the application gets these values (which it can and should do at startup), the application can proceed to create and set up its window.

screen_create_window(&window, context);
rc = screen_set_window_property_iv(window,
SCREEN_PROPERTY_SIZE, screen_resolution);
if (rc) {
//handle error …
}

rc = screen_set_window_property_iv(screen_win,
SCREEN_PROPERTY_BUFFER_SIZE, screen_resolution);
if (rc) {
//handle error …
}

Applications written for BlackBerry 10 should not set the SCREEN_PROPERTY_ROTATION value, as Navigator will set this for the application automatically when it posts its window.

Furthermore, if you were writing native apps on BlackBerry PlayBook OS 2.0, you would have had to write extra logic to rotate your window based on what you read out from the “ORIENTATION” environment variable. The box below shows an example of how orientation was set up in the BlackBerry PlayBook OS 2.0 setup. This code can now be removed, thereby simplifying your setup logic.

//THIS CODE CAN NOW BE DELETED

int angle = atoi(getenv(“ORIENTATION”));
int buffer_size[2] = {screen_resolution[0], screen_resolution[1]};
int flip = false;

if ((orientation == LANDSCAPE) && (buffer_size[0] <
buffer_size[1])) {
//In landscape, rotate to portrait
buffer_size[0] = screen_resolution[1];
buffer_size[1] = screen_resolution[0];

if ((angle == 0) || (angle == 180)) {
//Landscape device in landscape mode
angle = 90;
} else if ((angle == 90) || (angle == 270)) {
//Portrait device in landscape mode
angle = 0;
}

flip = true;
}

if (flip) {
rc = screen_set_window_property_iv(screen_win, SCREEN_PROPERTY_ROTATION,
&angle);
if (rc) {
//handle error …
}

rc = screen_set_window_property_iv(screen_win,
SCREEN_PROPERTY_BUFFER_SIZE, buffer_size);
if (rc) {
//handle error …
}
}

When it comes to determining current orientation, applications should always rely on the navigator to present current orientation. You should never use the accelerometer to determine orientation. The navigator will also inform the application when it needs to rotate and will initiate the rotation sequence by sending the application a rotate (PORTRAIT or LANDSCAPE) message. These new “rotate” messages are replacing the “orientation” messages on the current 2.0 Navigator. It is to be noted as well that the old orientation messages used to specify rotation in angles, while rotation will be specified as Landscape or Portrait in the new messages. These new units are much more intuitive in my opinion and map more closely with how we think of orientation on the device.

As a native app developer, there are several things you need to consider:

• Continuing to support your application on BlackBerry PlayBook OS 2.0 won’t require any change – things will continue to work as before.
• If you are developing a native app only for BlackBerry 10, you should make sure to use the new method of getting width and height parameters from navigator as well as using the new rotate messages.
• If you already have an app on BlackBerry PlayBook OS 2.0 and want to move it to BlackBerry 10, you will have some minor changes to make to port your app over. Your code on BlackBerry PlayBook OS 2.0 will not be able to get the width/height parameters via environment variables, so you will continue to use the old methods. On BlackBerry 10, you should use the parameters you receive from navigator for this.

These changes are not drastic, and our hope is that you will be able to migrate from BlackBerry PlayBook OS 2.0 to BlackBerry 10 with minimal fuss. In passing, I should also point out that these changes target developers who are writing applications right on top of our low-level windowing framework, so these changes mainly impact game developers. If you are writing a Cascades™-based application, you should also be abstracted from most of these changes and should consult your Cascades documentation.

I am personally excited about these changes as they will enhance the development capabilities of the BlackBerry 10 Native SDK when it comes to supporting multiple resolutions and orientation. When the time comes for you to start developing or moving your app or game over to the BlackBerry 10 platform, you should definitely consult the developer documentation for more details on these two features and how they will impact your application.

Happy developing!

Desktop web development is like this…	Mobile web can feel like this…	But mobile should and can be like this…
fairly standard	frustrating	compact, elegant, and functional

So where do we start? Well, when it comes to mobile web apps, file and transfer size matters — the smaller, the better. So the first thing I wanted to do was survey the landscape and compare the size of some of the different APIs that are available. (If I missed some that are lightweight, please let me know.) Although Google Maps is the most popular API out there (and deservedly so), it’s JavaScript API and tile images are quite large. In my tests below, I created basic map pages for a 1024×768 screen using each of the APIs, and I found that Google Maps transfers about 950 KB of data! This can be a problem for smartphones since they have limited memory. Besides causing an application to crash, a memory-intensive app can also chew up precious kilobytes from a user’s data plan, and it can drain their battery faster than they want. Thankfully, we have some choices…

Bing

As we can see from the results, Microsoft’s Bing Maps is a good alternative that has improved a lot since version 6.3. In version 6.3, Bing quietly introduced a “core” version for mobile that stripped out features like drawing lines and polygons. This reduced their JavaScript library from 230 KB to 47 KB! Unfortunately, if you needed some of those features, you were out of luck. But in version 7.0, they cleaned up their API and reduced it to 87 KB (without stripping features). So when you combine that savings with Bing’s smaller tile size, the Bing test map transferred 432 KB — that’s less than half of Google Maps! So I could stop here and just tell you to use Bing instead, but (as you’ll see) it’s always good to look at other options…

Modest Maps

Especially if we look at the API with the smallest library, Modest Maps, is a new library that weighs in at only 40 KB! It was designed to be simple, extensible, and it even works in older browsers like IE7. However, it’s tile size was the largest at 861 KB!

MapQuest

MapQuest is a provider that has been around for a while. Their version 7.0 is the second-smallest library at only 47 KB, but their tile size is the third largest at 852 KB.

Nokia Ovi

So if we’re also looking for an API that has the smallest tile size, Bing looks like the best choice. Nokia’s Ovi tiles are also lightweight at 373 KB, but their JavaScript library is the largest at 151 KB! It’s too bad we couldn’t use Modest Map’s compact library with Bing’s lightweight tiles…or can we? Well, in a way we can…

OpenLayers

OpenLayers, as the name suggests, is a completely free and Open Source library that allows you to switch between different base layers like Google Maps, Virtual Earth (Bing), Yahoo, etc. From a business model, this approach makes a lot of sense because it means you’re not tied to one mapping provider and you’re not as restricted by licensing or forced-API changes. With this approach, you can switch providers without having to completely change your code.

However, OpenLayers supports other maps by creating their own API layer on top of the other mapping APIs. So to use OpenLayers with Google or Bing, you’d have to include their libraries as well! This approach is fine for desktop, but it doesn’t make sense for mobile. Also, OpenLayers is not as well-documented as some of the others, and its API can be harder to learn. But, if you’re doing some serious GIS work, this is an API you’ll want to consider.

Leaflet

Fortunately, a new lightweight library called Leaflet has been gaining popularity because it is a modern Open Source library that uses HTML5 and CSS3. It was designed from the ground up to work in modern and mobile browsers. Since CSS3 is hardware-accelerated on many mobile devices, visuals like zooming and fading will be much faster than JavaScript-based animations.

Also, Leaflet has an easy-to-use API. So just how easy is it to add a map? First, we include the CSS and JavaScript:

                 <link rel="stylesheet" href="leaflet.css"> <script type="text/javascript" src="leaflet.js"></script> 

Then we create a new tile layer specifying the format of the tile URL with some options like maximum zoom level:

                 var tileUrl = "http://{s}.tile.cloudmade.com/BC9A493B41014CAABB98F0471D759707/997/256/{z}/{x}/{y}.png", tileAttr = "Map data © 2011 OpenStreetMap contributors, Imagery © 2011 CloudMade", tileLayer = new L.TileLayer(tileUrl, { maxZoom: 18, attribution: tileAttr }); 

Then we create the map and add the tile layer to it:

                 var map = new L.Map("map", { center: new L.LatLng(43.6425778753, -79.3870621920), // Toronto zoom: 14 }); map.addLayer(tileLayer); 

That’s it! Like OpenLayers, Leaflet allows you to easily switch between tile providers, but it does this in a much cleaner way — all you have to do is change the tile URL. So you don’t even need to include a vendor’s API to use their tiles. Of course, if you do use another tile provider, make sure you contact them about licensing and include the proper attribution.

                 var tileUrl = "http://{s}.googleapis.com/vt?lyrs=m@174225136&src=apiv3&hl=en-US&x={x}&y={y}&z={z}&s=Galile&style=api%7Csmartmaps", tileAttr = "Map data © 2012 Google", tileLayer = new L.TileLayer(tileUrl, { maxZoom: 22, subdomains: ['mt0', 'mt1'], attribution: tileAttr }); 

So with this simple approach, you can change the base tile layer to almost any provider as long as they are using OpenStreetMap’s “Slippy” tile naming convention, which is pretty much every provider, except for Bing because Microsoft uses a different “Quadkey” convention.

Tile Naming Conventions

Basically, Slippy uses a straight-forward naming convention that looks like this (“mustache-style” URL template):

http://{s}.tile.cloudmade.com/YOUR-API-KEY/997/256/{z}/{x}/{y}.png

where,

• {s} = subdomain
• {x} = x-coordinate
• {y} = y-coordinate
• {z} = zoom level

Here’s an example of an actual tile (near the CN Tower):

http://b.tile.cloudmade.com/BC9A493B41014CAABB98F0471D759707/997/256/14/4578/5980.png

But if we compare Slippy to the Quadkey format, you’ll notice it’s different enough that we can’t easily use it (at least not with Leaflet — we can with Modest Maps):

http://ecn.{s}.tiles.virtualearth.net/tiles/{style}{quadkey}?g=914&mkt=en-us&lbl=l1&stl=h&shading=hill&n=z

http://ecn.t0.tiles.virtualearth.net/tiles/r03022313122210?g=914&mkt=en-us&lbl=l1&stl=h&shading=hill&n=z

because the Quadkey format works like this:

• At zoom level 1 (of the entire world), there are only 4 tiles (or quadrants) numbered from 0 to 3. At the next zoom level, each tile is sub-divided into “quads”, and so on.
• So the length of the quadkey represents the number of zoom levels.
• The quadkey of any tile starts with the quadkey of its parent tile.
• The first letter (which is not really part of the quadkey) specifies the base map style (r = Road, a = Aerial (Satellite), h = Hybrid (Aerial + Labels)

Although it might be tempting to complain about Microsoft being different, from a database perspective, quadkeys makes indexing and storage really efficient.

Hybrid Approach

Hopefully, that gives you a better understanding of tile structures. Do you see the possibilities? This is AWESOME! This means we can easily interchange libraries and tiles to suit our needs. Essentially, we can build our own “hybrid” API or “mashup” from the best pieces available. So now we can have an API that uses Bing’s tiles, but is even lighter than Bing itself (which was already light to begin with at 432 KB)!

Here are some other combinations that are under 450 KB that you may want to consider:

Since we were able to make Bing lighter, I was curious to see if we could do the same with Google, and the result really surprised me! As you may recall, Google Maps transferred 950 KB, but when I combined Leaflet with Google’s tiles, it only transferred 498 KB! That’s half the size, which is great! But why such a difference?! Well, if we look at the number of requests, it gives us a big clue — Google’s API is loading twice the number of tiles!

At first, I thought it might be pre-fetching or “lazy loading” tiles for areas outside the bounding box in case a user pans or zooms. But when I inspected the extra tiles, I found it’s actually loading another set of tiles for the same area, which I haven’t been able to figure out why — the extra tiles don’t seem to be displayed anywhere. It’s still a map view tile, but it has slightly different labels. Notice the one on the right has “Corktown” and the other one doesn’t?

Tile Set 1 (displayed)	Tile Set 2 (not displayed)
m@174232040&src=apiv3&hl=en-US&x=4580&y=5979 &z=14 &s=Galileo &style=api%7Csmartmaps	m@174000000&src=apiv3&hl=en-US&x=4580&y=5979 &z=14 &s=Galileo &style=api%7Csmartmaps

I’m sure there’s a good reason for this, but I’d be curious if there’s an option to disable that? Either way, the good news is Google’s tiles are not as heavy as I first thought so we can use them with Modest Maps or Leaflet to build familiar-looking mapping applications that will be more lightweight especially for mobile.

Besides being able to switch between providers, this hybrid approach has other advantages:

1. For packaged applications like BlackBerry® WebWorks™, you can locally include the required API files (JavaScript, CSS, and images) with your application so you don’t need to fetch them from a remote server. This makes loading an app faster and reduces bandwidth charges.
2. Another advantage of having local files is you don’t have to worry as much about a provider forcing an API change that can break your customizations. Although, you can usually reference an older API, sometimes a provider will force an upgrade even if you try to reference an older version.
3. In the case of Yahoo! Maps, which discontinued its map service in September 2011, a local version means your app can still work. For example, Leaflet provides a layer control so you can select from different base layers.

These advantages are important especially for enterprise or mission-critical applications that need to minimize risk and downtime. So in the next post, I’ll cover some techniques for adding offline capabilities to your map. Hopefully, with this “best of breed” approach, you’ll be ready to build a map-based app that will feel more like a paper airplane than a paper ball.

The BlackBerry 10 WebWorks SDK allows web developers to create first class BlackBerry applications using familiar web technologies such as HTML5, CSS, and JavaScript®, and extend their application with deep integration into the full device platform. It is the evolution of the BlackBerry WebWorks SDK, built on the foundations of the BlackBerry WebWorks SDK for smartphones and the BlackBerry WebWorks SDK for Tablet OS.

First introduced on the BlackBerry® 5 OS and supported on all OS versions and devices since, BlackBerry WebWorks allows a developer to package their web content into the native application format, leveraging all the benefits of the BlackBerry platform including security and distribution through the BlackBerry App World™ storefront. With the WebKit-based HTML5 browser environment provided by the platform, BlackBerry WebWorks developers have full access to many powerful HTML5 APIs and CSS3. Further, BlackBerry WebWorks provides a set of JavaScript APIs that allow the developer to extend their web content out of the browser with platform functionality such as BlackBerry® Messenger SDK, Payment Service, PIM (email, contacts, and calendars), file access, and so on.

For the BlackBerry smartphone, the BlackBerry WebWorks APIs were built on the native Java platform, and for Tablet OS, on top of the Adobe® AIR® SDK. With BlackBerry 10, it was obvious that BlackBerry WebWorks needed to leverage the full power of the new BlackBerry 10 Native platform built on C/C++ and Cascades™. This gave us an opportunity to look at BlackBerry WebWorks with fresh eyes and determine the best route forward. Let’s take a look at the different pieces that make up BlackBerry WebWorks and how we have been able to improve on the platform with the power of BlackBerry 10.

The Packager

This is the piece of the SDK that takes you application content and packages it up into a .BAR file for distribution in BlackBerry App World™, and is the file that is installed onto the device. For BlackBerry OS and Tablet OS, the packager was implemented in Java, which required the developer to have the JDK installed on their machine. For BlackBerry 10 WebWorks SDK, we have re-implemented the packager in pure JavaScript, which runs in an instance of Node.js included with the SDK. BlackBerry WebWorks developers have minimal external dependencies required to get their development environment setup.

One thing to note is that the packager now creates two binary outputs, one for the device and one to be used in the BlackBerry 10 simulator. This is because the BlackBerry WebWorks runtime is now backed by the native platform, and there are different instruction sets for the OS on desktop environments versus the device platform.

The Framework

The framework is the code that wraps around your web content, and is run on the device in order to orchestrate the platform and provide your runtime environment. For BlackBerry OS, the framework was in Java, and for Tablet OS it was Adobe AIR. Similar to the packager, and enabled by the underlying platform providing in essence a JavaScript runtime environment, we have re-written the framework in JavaScript.

Since the framework is in JavaScript, developers will need to include this JavaScript code into their web content for their application. Just add a very simple script tag to all your pages:

<script type=”text/javascript” src=”webworks.js”></script>

Webworks.js is the framework code that handles all of the BlackBerry WebWorks whitelisting logic and injection of allowed APIs for the current domain into the current page. The webworks.js file is included in the BlackBerry WebWorks SDK in the framework\clientfiles directory and should be copied into your application content.

Since script loading can occur asynchronously, we have provided an event that you must listen to before accessing any BlackBerry WebWorks APIs. The framework will trigger this event once it is done initializing the BlackBerry WebWorks framework and APIs. Here is an example of the webworks script file definition and webworksready event in action:

<html>
<head>
<script type=”text/javascript” src=”webworks.js”></script>
<script type=”text/javascript”>

window.addEventListener(“load”,
function() {
document.addEventListener(“webworksready”, start);
}, false);

function start() {…}

While the webworks.js file did not exist and is not required for BlackBerry OS or Tablet OS WebWorks SDKs, you can leave the script inclusion line in your application even on these platforms. If your application is not running on the BlackBerry 10 platform, the webworksready event will fire almost right away, and none of the rest of the BlackBerry 10 framework logic will execute; your app will run in the context of the standard BlackBerry OS and Tablet OS WebWorks frameworks.

Config.xml

For this first Beta of the BlackBerry 10 WebWorks SDK, we have implemented most of the existing elements of the configuration document. There are a few elements that will come in the future along with some new additions required to support some new BlackBerry 10 features. Not to worry if you use new elements or have elements that are not yet supported in BlackBerry 10 WebWorks, as the packagers for all platforms will ignore elements they don’t recognize. Please check the documentation for details on the config document.

APIs

APIs for BlackBerry WebWorks have two components to them: JavaScript that runs in the browser environment, and a “native” component that interfaces with the rest of the platform, allowing for the deep integration that provides the full power of BlackBerry WebWorks. Again: Java for smartphones, Adobe AIR for BlackBerry® PlayBook™ tablets. For BlackBerry 10, of course, native is C/C++. So we have to re-implement all the APIs, and will be delivering them incrementally with Beta refreshes over the summer.

In this initial Beta release, we have been able to provide a core sub-set of the full WebWorks API, which is documented on the BlackBerry HTML 5 site, including Identity, Application and App events, System and system events. On a monthly cadence, we will be releasing new Beta bundles of BlackBerry WebWorks with net new APIs, such as Push, File and File Transfer, Audio/Video Capture, etc.

Apache Cordova

The nature of HTML5 is that it is prevalent on most platforms and devices. Apache Cordova (which is the basis of the well-known PhoneGap) is an industry-leading cross-platform framework very similar to BlackBerry WebWorks. We are striving to bring BlackBerry WebWorks and Cordova closer together, and are actively part of the Cordova open source project providing contributions. To begin down this road, we are aligning some of our BlackBerry 10 WebWorks API signatures with Cordova API signatures. Existing WebWorks applications may require some refactoring to target BlackBerry 10, but Cordova/PhoneGap is supported on BlackBerry OS and Tablet OS, so you can take advantage of these APIs on older operating systems.

For example, event APIs have changed. For BlackBerry smartphones or Tablet OS, if you wanted to listen for battery level changes, you would do something like this:

function onBatteryLevelChange(level) {
alert("Battery Level: " + level);
}
blackberry.system.event.deviceBatteryLevelChange(
onBatteryLevelChange);

For BlackBerry 10 WebWorks SDK, we have introduced an Event API with a signature like your typical add/removeEventListener:

function onBatteryStatus(status) {
alert("Battery Level: " + status.level +
“ isPlugged: “ + status.isPlugged);
}
blackberry.event.addEventListener(“batterystatus”, onBatteryStatus);

The “blackberry.event” feature id would be used in your config.xml file for whitelisting purposes. You will notice that, if you replaced “blackberry.event” with “document” or “window”, you have the Cordova/PhoneGap API signature.

Please check out the BlackBerry WebWorks development site to learn more about how you can be part of the first wave of applications for the BlackBerry 10 OS by leveraging your web technology skills, while continuing to target our over 75 million smartphone subscribers and BlackBerry PlayBook tablet users.

The Research In Motion® (RIM®) Developer Relations team recently hosted a BBM™ Hackathon event in NYC. Developers were invited to apply for a chance to participate in the event, getting one-on-one time with BlackBerry® platform experts and network with other developers while working on integrating social elements into apps using the BlackBerry® Messenger (BBM) APIs.

Attendees told us that they found the direct contact with our social platform experts to be invaluable – and we liked hearing that so much that we’ve decided to host more of these hackathon events across the globe in the coming weeks.

The first of these events happened yesterday in our company hometown of Waterloo, Ontario, Canada, with the second event happening today, September 29th. Following this, we’ll be hosting BBM Apps Hackathons in Toronto, Chicago, San Francisco, Boston, Jakarta, Amsterdam, London and more. Here are the scheduled dates:

Updated Dates!

• Toronto: October 6th and 7th
• Chicago: October 10th and 11th
• San Francisco: October 16th and 17th (just in time for BlackBerry DevCon Americas 2011!)
• Boston: November 3rd and 4th
• Jakarta: November 14th and 15th
• Bangkok: November 17th and 18th
• Amsterdam: November 24th and 25th (updated)
• London, England: November 28th and 29th (updated)

To enter for your chance to attend one of the BBM Apps Hackathon events, follow this simple process to apply: Visit the site bbmappshackathon.com and fill out an application, outlining among other things (i) why you feel social platform integration adds value to mobile applications; and (ii) give an example of previous mobile apps you have developed.

Developers who are selected to attend a BBM Apps Hackathon event will also receive a BlackBerry gift bag, which includes a BlackBerry® 7 OS device. In addition, those selected to attend the Toronto, Chicago and San Francisco Hackathon events will also receive a pass to attend BlackBerry DevCon Americas 2011 and three night accommodation at the San Francisco Marriott Marquis for the duration of the conference.

We definitely recommend that developers of any level apply to attend these collaborative events. The BlackBerry Social Platform gives developers a way to tie existing apps to BBM, or to build social apps from the ground up. One of the benefits to these social aspects is the added viral buzz that an app can gain from integrating with BBM. At these hackathons, developers will discover valuable strategies that will help them add social aspects to their apps.

Would you be interested in this type of event? Let us know which hackathons you’ll be applying to attend!

Research In Motion® (RIM®) and Telefonica have teamed up to host a webcast happening on Thursday, March 17, 2011. This webcast is for developers to learn how to take advantage of new features introduced in the BlackBerry® 6 platform and BlueVia network APIs to build Super Apps.

Date: Thursday, March 17, 2011
Event Start Time: 4:00 PM GMT
Duration: 1 hour
Presenters:
Sanyu Kiruluta, Team Lead, Developer Relations EMEA (RIM)
Andres-Leonardo Martinez-Ortiz, BlueVia Developer Programs Engineer (Telefonica)

Topics that will be covered include:

• BlackBerry 6 overview – learn about improvements to the UI and new APIs that you can take advantage of when creating your applications
• Learn about BlackBerry® platform commercialization services
• Learn how to use BlueVia SMS APIs

Register for this event and find out more information today!

In the course of this series on running in the background, we’ve covered how to run a process in the background (Part One), how to move your application from foreground to background and vice versa (Part Two), and some of the reasons why you would want to (Part Three). The previous articles have shown Super App features that enable both the “Always-on Experience” and “Tight Integration with the Native Apps”, as well as a “Proactive and Notification-driven Application”. Today, the focus will be on “Designing for Efficiency”.

In some ways, the mobile environment is constrained much more significantly than the desktop environment, with limits to battery life, wireless bandwidth, memory, and CPU cycles, among others. These constraints become even more important when running processes in the background. The last thing the user wants is a massive data bill, or a dead device due to a poorly behaved background application that they weren’t even aware of. With that said, let’s look at the “dos and don’ts” of running in the background.

Stop Painting

If you have any looped painting, animations, or other UI processes on your screen, stop them when your application moves to the background. Verify that you don’t have UI threads running needlessly by using the Profiler view in the BlackBerry® Java® Plug-in for Eclipse®.

Minimize Processing

As in checking for painting threads, use the Profiler to ensure that you don’t have threads running that aren’t actually necessary. A careful balance must be maintained here; if you perform an action in your application that may take some time, the application will expect it to continue even if you go to another application in the meantime. Similarly, if your application is expected to do tasks in the background – such as downloading music or tracking GPS coordinates – then processing can’t be avoided. However, battery life will be greatly enhanced if your application does this processing all at once, with periods of full idleness in between processing blocks. Ensure that your processing is not spread out over a long period of time, and the device will be able to go to a low-power sleep mode.

Be Aware of the Device Context

Before your application runs a background process, check the status of the device to determine if it is an appropriate time, or to optimize the task itself. Check the Idle Time using DeviceInfo.getIdleTime() and Backlight.isEnabled() to determine if you are currently using the device. Heavy processing should be done when the device is idle in order to avoid an impact to the user.

If the task your application intends to do is lengthy, ensure that there is adequate battery power available, or wait until the device is connected to a charging source. The DeviceInfo.getBatteryLevel() API will return the percentage of remaining battery, while DeviceInfo.getBatteryStatus() & DeviceInfo.BSTAT_CHARGING >0 will determine if the battery is currently charging. Applications should not keep the backlight on unless the device is connected to a charger, or if the screen display is critical to the application. For example, navigation apps should shut off the backlight when not powered by a car charger, while a video player should enable the backlight while the video is playing but not when it finishes.

Finally, check the network coverage available if you need to make a network connection, or the GPS satellite coverage if you intend to use GPS. If coverage is poor, then it will take more power to use the radio, or it may be more effective to wait until coverage is better. In the case of network communication, it may be more effective to download a smaller, lower quality set of data immediately and wait until WiFi® coverage is available, or to sideload large data through USB. For GPS, cell site location will provide approximate location with very low power use almost instantaneously while waiting for a more accurate GPS satellite fix to occur. The BlackBerry location object can provide information on the number of satellites visible to determine the effectiveness of getting a satellite fix. Likewise, the RadioInfo.getSignalLevel() API will tell you how strong the signal is, and the CoverageInfo.isCoverageSufficient() or TransportInfo.hasSufficientCoverage() methods will tell you if a connection is possible through the transport that you require.

Free Memory

Dropping references to stale objects is important when your application is long-lived. Objects should be released when no longer needed, but not too aggressively. Since object creation is costly, you don’t want to churn through objects if you will need them again, so there is a balance to find here. For example, your application should not usually release screens it has on the stack immediately upon going to the background. If you switch back to your application, you do not want to wait for the screen to be recreated. However, if the screen contains information from an external source, that data structure could be released when it’s no longer current and refreshed when you return.

Running in the background is a pillar of the Super Apps concept, and with so many Super App features enabled by background processing, it’s critical to remember to “Design for Efficiency”. You’ll earn the gratitude of your users – and they will enthusiastically recommend your app to their friends and colleagues!

Have you tried integrating any of these tips into your Super Apps designs? Let us know in the comments.

There’s been no shortage of excitement about BlackBerry® 6 lately – I am thrilled by the response to our latestBlackBerry 6 video and Inside BlackBerry blog posts. We wanted to find a way to outline for you, our developer community, some of the opportunities that BlackBerry 6 will bring.

One thing we want to do is differentiate the way BlackBerry 6 will affect Java® development versus Web development. Over the coming weeks, we will share tips, tricks and more information about developing for BlackBerry 6 through two separate paths. For our Java developers, we’ll work to highlight the new APIs being introduced, including a new powerful set of new User Interface controls, Universal Search integration, and a Barcode Capture API. For our web developers, we’ll start to redefine BlackBerry® Widgets and talk about the completely revamped BlackBerry Browser powered by a Webkit engine. We will cover HTML5, CSS3, and concrete steps for how you can bring your mobile site to BlackBerry® smartphones.

On top of that, we are going to continue our series covering Super Apps and how you can create an amazing user experience on the BlackBerry platform. We are now less than eight weeks away from the final deadline for the BlackBerry Partners Fund Super Apps Developer Challenge. With over $1.5 million in prizing, this is a challenge you don’t want to watch from the sidelines.

So bookmark the Inside BlackBerry Developer’s Blog (if you haven’t already!) and be sure to check back frequently for all the latest content!