[YouTube link for mobile viewing]

Supporting open standards and open source are keystones of the BlackBerry® platform. We are pleased to announce another repository of open source contributions through Github. Our 56th repository, jQuery-Mobile-Samples, will contain samples and tutorials using jQuery Mobile for building outstanding BlackBerry applications and mobile web experiences.

If you’ve done mobile web development, then jQuery will be familiar to you. It’s used by many organizations to make compelling websites and applications on the leading platforms. jQuery Mobile is a recent release focused on mobile devices with excellent cross-platform capabilities. With this repository we will be providing examples that detail some advanced features of the jQuery Mobile Framework which you will want to use in your next project.

Watch the repository on Github and you’ll see the first few tutorials with sample code appearing this month. Later in the roadmap are examples for using jQuery Mobile with other frameworks for even more opportunities to impress your users.

We’ve just updated the BlackBerry 10 Jam World Tour page with new cities and dates. Here’s the run down of where we’re heading:

May 29 – Milan, Italy
May 31 – Barcelona, Spain
June – California
June – New York
June 5 – Austin, TX, USA
June 12 – Paris, France
June 14 – London, UK [Updated to June 14]
June 21 – Toronto, ON, Canada
June 26 – Moscow, Russia
June 28 – Berlin, Germany
July 3 – Warsaw, Poland
July 4 – Delhi, India
July 6 – Beijing, China
July 9 – Singapore, Singapore
July 10 – Jakarta, Indonesia
July 12 – Sydney, Australia
August – Buenos Aires, Argentina
August – Mexico City, Mexico

A limited number of BlackBerry® 10 Dev Alpha devices will be available to qualified developers at each city in the World Tour. During the event registration process, apply to receive a BlackBerry 10 Dev Alpha device, available only to developers attending BlackBerry 10 Jam. If you received a BlackBerry 10 Dev Alpha device at a previous BlackBerry developer event, you do not qualify for this offer.

We’ll have more updates soon  - keep checking back here to the Inside BlackBerry Developers Blog.

From Kony Solutions’ press release:

“Kony Solutions, the leading mobile application development platform (MADP) provider, announced that it is one of the first mobile platform providers to support the new BlackBerry® 10 platform. Kony customers and partners can expand their mobile applications to support BlackBerry 10 users immediately, with just a few clicks of a button.
Kony’s flagship product is its KonyOne mobile enterprise application platform. Kony’s patent-pending “Write Once, Run Everywhere” technology enables developers to deploy their apps across more than 10,000 mobile smartphones/tablets/kiosks and operating systems from a single code base. All Kony applications can be delivered in native and mobile web (HTML5 and non-HTML5), across every mobile channel. Kony offers the mobile industry’s most comprehensive Service Level Agreement, ensuring support for new versions of existing platforms or OS within 30 days of code release, and within 90 days for any new device or OS.”

[ YouTube link for mobile viewing ]

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!

One of the true pleasures of my job is talking with developers. Creative, outspoken, funny, smart, artistic, genuine – they’re just some of the best people in the world to hang with. BlackBerry® 10 Jam was amazing last week. The code demos, AppCircus, the lunches and down time with people at the bar – these were the highlights for me.

As you know, I publish my email address everywhere (alec.saunders@rim.com), and people write to me. Nobex Chief Software Architect Jamie Julius wrote me the following last Friday, and gave me permission to share it with you all:

Hi Alec,

I wanted to thank you personally for such a great BB 10 Jam.

Last November, a letter that I had sent to someone at RIM was forwarded to you. In it I described my feelings after attending DevCon last fall in San Francisco.

Well, things have definitely changed. The difference between that DevCon and this Jam is like night and day.

Over the last three days, in keynotes and in sessions, the messages coming from RIM were very clear. Not only do we now see more clearly where RIM is going, but also what we should be doing as developers. As opposed to a vague range of technologies to be supported, it has now been made more clear which will work best for what.

For Nobex Radio, for example, all the RIM technical representatives made it very clear to me why Cascades is the way for us to go. The list of reasons is long. We never received such a clear message before.

I came away feeling that BB10 is now tangible. And I don’t just mean that I can hold the Dev Alpha device in my hand. I see real API’s! Even if some aren’t ready yet, I see them coming. I know what they will cover. That makes a really big difference. I also have an IDE with which to start writing real code. That makes a big difference too.

Back in November, games were over-emphasized. Not anymore. I think RIM has re-focused its identity. Games should definitely have an important place on BlackBerry smartphones, but not blown out of proportion.

So, a big congratulations to you and your team for doing such a great job putting together BB 10 Jam.

The enormous investment that RIM is making in dev relations has not gone unnoticed.

THANK YOU!

Jamie Julius
Chief Software Architect
Nobex Technologies

Thanks Jamie.

There are still lots of milestones to cross on the road to BlackBerry 10, but last week was a major step forward for RIM and the development community. We hope everyone who came to BlackBerry 10 Jam walked away with the same experience as Jamie, and we’re counting on you all, so let’s go write some code together!

Check out Patrick’s interview in the video:

[ YouTube link for mobile viewing ]

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.

1. Asynchronous Retrieval of Purchase History
2. The DigitalGood Class
3. Asynchronous Retrieval of Digital Goods Available for Purchase

Asynchronous Retrieval of Purchase History

In the previous Payment Service SDK version 1.5 (Version 1.5), only synchronous retrieval of purchase history was possible. This meant that when retrieval was occurring, the user interface would be unusable – a busy indicator would be displayed. This was acceptable for some situations but it could really impede usability of the application. With Version 1.8, you can now program your application to perform this pull request asynchronously using the following line of code:

PurchaseHistory.get(PurchaseHistoryListingListener purchaseHistoryListingListener);

The PurchaseHistoryListingListener interface has only 2 methods:

PurchaseHistoryListingListener(){
public void error(String message, int errorCode) {
}
public void success(Purchase[] goods) {
 }
};

The huge benefit here is that it is very easy to retrieve the purchase history of a user in the background without causing any impact to the user interface.

The DigitalGood Class

In Version 1.5, digital goods existed only in the BlackBerry App World™ storefront client. There are no actual classes in the Payment Service SDK to encapsulate what a digital good object actually is. Version 1.8 adds a DigitalGood class to do just this. The new DigitalGood class allows the application to retrieve information about the goods hosted on BlackBerry App World available for purchase by the user, where the Purchase class previously used only provides information about the actual purchase. The big benefit of this class: a developer can add new items to the Vendor Portal without needing to release a new version of their application. This new addition is also greeted with a way to retrieve all available digital goods asynchronously (continued in the next section).

Asynchronous Retrieval of Digital Goods Available for Purchase

The method to retrieve a list of digital goods available for purchase by the user is very similar to that used above to retrieve the PurchaseHistory. First, call the DigitalGoods#get() method passing in your DigitalGoodsListingListener:

DigitalGoods.get(DigitalGoodsListingListener digitalGoodsListingListener);

In your DigitalGoodsListingListener implement the 2 defined methods:

DigitalGoodsListingListener(){
public void error(String message, int errorCode) {
}
public void success(DigitalGood[] goods) {
}
};

This is virtually identical to the PurchaseHistoryListingListener implementation; however, the success() method receives an array of DigitalGood objects as opposed to Purchase.

The above three new features are easy to implement and should help simplify the development logic as well as improve the overall user experience of your application. You can find the new Payment Service SDK version 1.8 available for download here. The download includes full JavaDocs, and additional documentation (developer’s guide, release notes) can be viewed here.

Image By André Karwath (Own work) [CC-BY-SA-3.0 (www.creativecommons.org/licenses/by-sa/3.0)], via Wikimedia Commons

ZXing (pronounced “zebra crossing”) is an open-source, multi-format 1D/2D barcode image processing library implemented in Java, with ports to other languages. It decodes barcodes on the device without communicating with a server. ZXing currently support these formats:

The port of ZXing 2.0 for BlackBerry® 10 devices is available in our ZXing repository at GitHub; note that only the C++ source under zxing/cpp/core was ported. See the README.md for build instructions.

The ZXing unit test suite uses CppUnit, so a port of version 1.12.1 of this C++ unit testing framework was also done for BlackBerry 10 and it is available at the CppUnit repository. Build instructions are listed in the README.md.