This article will aim to explain how to build a native app from the command line, using the tools bundled in the BlackBerry 10 Native SDK and your favourite text editor.

Set up your environment

The Native SDK includes a script called bbndk-env.sh (or .bat on Windows) in the root folder that initialises the environment variables that the other tools depend on. I will refer to the install location of the Native SDK as $NDK_DIR.

Mac: source $NDK_DIR/bbndk-env.sh
Win: $NDK_DIR/bbndk-env.bat

So what does this script set?

The most important environment variables are:

QNX_TARGET: This directory contains all the configuration files and libraries for the BlackBerry 10 device, the target that we want our app to run on.  You can see all the libraries which can be linked against in $QNX_TARGET/armle-v7/lib and $QNX_TARGET/armle-v7/usr/lib.

QNX_HOST: This directory contains the tools and configuration files for our host system, ie Windows, Mac or Linux. It includes a compiler, linker and assembler for cross compiling to various architectures, as well as command line tools for packaging, signing and deploying your application.

Building for the ARM architecture

You may have noticed the use of armle-v7 in the above directory structure. This refers to the processor architecture on BlackBerry 10: ARM Little Endian Version 7. To build binaries that run on BlackBerry 10 you need to compile for this architecture.

Start by creating a folder to hold our app’s files, call it GoodbyeIDE. From now on I will refer to this as $PROJECT_DIR. Inside this folder create a file called main.c with the following content:

#include <stdio.h>
int main()
{
  fprintf(stdout, "Goodbye IDE!\n");
  return 0;
}

Now lets compile it. Change to $PROJECT_DIR and execute:

qcc -Vgcc_ntoarmv7le main.c -o main

Lets explain this command in a bit more detail. qcc stands for QNX C Compiler. BlackBerry 10 is built on top of QNX and uses many of its build tools.

qcc is essentially a wrapper for gcc  (GNU Compiler Collection). The -V switch tells qcc which version of gcc to use, in this case its the ntoarmv7le version which stands for QNX Neutrino ARM Version 7 Little Endian (a bit of a mouthful).

To build for the BlackBerry 10 simulator you need to use the gcc version for the x86 architecture.

qcc -Vgcc_ntox86 main.c -o main

To view a full list of the available gcc versions run:

qcc -V

The main.c -o main part of the command just specifies the input C filename and output binary filename.

OK, so now we should have a binary (called main) that will run on a BlackBerry 10 device. This binary won’t run on your host operating system since it’s not compiled for the same architecture. If you have a working gcc you can compile it by doing:

gcc main.c -o main2
./main2

When you execute main2 you should see “Goodbye IDE”.

Create the BAR descriptor XML

BlackBerry 10 apps are packaged as BAR (BlackBerry Application aRchive) files. To create a BAR file we need a descriptor file called bar-descriptor.xml. This file includes information about the app such as name, version, required permissions and a list of assets.

Create the bar-descriptor.xml file with the following content:

<qnx>
  <id>com.example.GoodbyeIDE</id>
  <versionNumber>1</versionNumber>
  <name>Goodbye IDE</name>
  <asset path="main" entry="true">main</asset>
</qnx>

From our point of view the most important line in bar-descriptor.xml is this one:

<asset path="main" entry="true">main</asset>

This specifies that the BAR contains a file called main which is the entry point for the app.

A full list of BAR application descriptor parameters is available here.

Packaging and deploying your app

Now that we have a binary and an application descriptor we are ready to create a BAR file.

A BAR file is essentially a zip file which contains all your app’s assets and the meta information from bar-descriptor.xml. In fact, if you rename a .bar file to .zip you will be able to extract it to see all the files in that app.

To create a BAR file run the following command:

blackberry-nativepackager -package GoodbyeIDE.bar bar-descriptor.xml -devMode -debugToken ~/Library/Research\ In\ Motion/debugtoken1.bar

Note that the -devMode and -debugToken flags are only required if you are deploying to a physical device. This is a handy feature that allows you to deploy your app without signing it, as long as your debug token is installed on the device.

To do this you’ll need to register with RIM to sign applications and create a debug token.

So now you have a BAR file called GoodbyeIDE.bar you can deploy it to the device using the following command:

blackberry-deploy -installApp 169.254.0.1 -password pass GoodbyeIDE.bar

169.254.0.1 is the IP of your target and pass is the device password.

If you take a look at your application icons, you should see a new one called Goodbye IDE (as specified in the <name> tag in bar-descriptor.xml).

If you tap on the icon your app should run! But…nothing happened, right?

Viewing log files over SSH

Actually the app did run, it’s just that all it did was print “Goodbye IDE!” to the stdout. The stdout on BlackBerry 10 is directed into a log file. We can view this log file by SSHing onto the device. Here’s how:

First we have to tell the device that we want to create a secure connection to it:

blackberry-connect 169.254.0.1 -password pass

Now open an SSH client (such as putty) and run:

ssh devuser@169.254.0.1

You should now be connected via SSH. Feel free to poke around! Apps are installed in /accounts/1000/appdata. Each app is given its own sandbox folder with a unique name based on its id (which we specified in bar-descriptor.xml).

Example sandbox folder name: com.example.GoodbyeIDE.testDev__GoodbyeIDEcf9b848

The log file can be found in the logs directory under the sandbox folder name. To view the file just run:

cat log

The log file is re-created each time the app is run. To test that the app is working delete the log file, tap on the app icon and run the above command again.

Summary

That’s it for now. The next article will focus on making your life easier by using Makefiles, the Qt build system and creating a more logical project folder structure.

What’s Count.ly? It is a real-time mobile analytics platform that shows information by using eye-catching visual elements. Görkem provided me with a test account and after logging in, I was very impressed by what I saw. The UI is gorgeus and the amount of useful and critical information a dev can get about their app is impressive.

Moreover, it’s an open-source project in which the team aims to discuss the future of Count.ly in an open, democratic environment. They offer the developers the opportunity to take part in the community, to send bug reports, feature requests, to provide fixes and best practices. It collects data from mobile phones, and visualizes this information to analyze mobile application usage and end-user behavior.

Having the ability to see how your users behave is critical for the success of an app. Developers can get a clear picture on what’s working well and what’s not working, what their users like the most, what the least/most used feature is and, last but not least, how much time people spend in your app and doing what.

When we met, BlackBerry 10 was not supported yet, but they were very interested in investing in our new upcoming platform (after the conference, even more!) and for that reason, twenty days after, they finally published their first SDKs for BlackBerry 10.

What’s so special with Count.ly?

• It has a dashboard
  • where you stay up to date
  • where you can easily monitor your data with graphics
  • which shows you everything at once with no need to dig in several pages
  • where you can track unlimited number of applications and switch between your apps, games and ebooks

• It has a special user behaviour stats experience in which;
  • you can track and visualize your users’ behaviours
  • you can see your application’s in-app performance
  • you can understand your customer’s behaviour and where user left off
  • you can observe your players closely to ensure success and maximize your online game revenue

• You can build better apps, games and ebooks;
  • by measuring and evaluating mobile app engagement as it enables optimization of mobile content
  • by exploring where a spike occurs and by personalizing and optimizing your app according to stats
  • by the help of the support that Countly offers for leading smartphones (iOS, Android, Windows Phone and BlackBerry)

• You can produce electronic reports with customizable charts and tables, showing how your application performed for a given period, add / remove pages through report generator.

Also, Count.ly is free. You can install Count.ly in-app analytics tool on your server to track unlimited number of mobile applications, if you want.

Here is what Onu Alp, Soner, co-founder of Count.ly, told me:

“The best feature of Count.ly is custom events: we help developers identify in-app purchase patterns, defining the best flow for payment. This is a crucial factor towards maximizing revenues in e-books and games. We are thrilled with what BlackBerry provides in their next-gen mobile OS, and decided to invest in BlackBerry 10 SDK. Being the most complete open source, real-time mobile analytics app in the world, we believe Count.ly will provide a lot of value for BlackBerry 10 developers”

If you are a BlackBerry 10 developer looking for a good option for in-app analytics, Count.ly is definitely a great choice. The team is also very accessible and happy to help if needed.

You can download the Countly WebWorks SDK from GitHub here, while the Cascades SDK can be download from here.

We spent part of last week at BlackBerry Jam Europe, which is generally a conference dedicated to those who already develop apps for BlackBerry. However, there are also many programs for beginners. Since I’ve never created an app, I decided to take a run at developing an app for the Inside BlackBerry Blog. As I have literally no experience developing apps, I asked Alex and Luke for some help.

We used the BlackBerry App Generator to automatically pull content from the Inside BlackBerry Blog, and the BlackBerry Facebook and BlackBerry YouTube pages. It took us only about 10 minutes from start to finish and it was absolutely free. The result is a great-looking app that pulls in all of our articles, posts and videos. Let’s have a look as Alex walks us through the process.

[ YouTube link for mobile viewing ]

See how easy it was? Using the BlackBerry App Generator you could have your own app up and running in just a few minutes, even with no development experience. Do you have a blog or content and think it would make a great app? Give the BlackBerry App Generator a try for yourself and let us know.

BlackBerry World 4.3 changes the BlackBerry World search algorithm to help make the discovery of your app or game easier for customers. To take advantage of these changes, we wanted to share with you how the following product attributes are prioritized to determine search results. The attributes are listed in order of importance to the algorithm:

1. Product Name
2. Keywords
3. Vendor Name
4. Short Description

It is important to note that the Long Description is no longer considered by the Search algorithm.

Product Name

The most important product attribute is the Product Name – the title of your application shown to the Consumer. Product Names can be specified by Platform and Language. This could allow you to have:

• ‘Awesome App” for BlackBerry 10
• “Awesome App HD” for BlackBerry PlayBook

Keywords

Keywords are the second most important attribute in determining search results and provide new flexibility and creativity to get your product noticed. Introduced to the BlackBerry World Vendor Portal in 2012, Keywords will now be used to determine search results. Keywords can be specified by Platform and Language.

Changing the Keywords from the Vendor Portal takes effect between one and nine hours after saving the changes.

• Number of Keywords.  There are up to ten (10) Keywords per Platform and Language pairing.
  • For example, the BBOS Platform for French has up to 10 Keywords and the BBOS Platform for English has up to 10 keywords
• Maximum Length of a Keyword: Each Keyword cannot be more than 100 characters or 3 words long.
  • For example, “Built For BlackBerry”
• Maximum Length of ALL Keywords for a Platform/Language Pair: There is a 1,000 character maximum length for all the Keywords per Platform and Language pair.
  • For example, the BBOS Platform for French has a 1,000 character maximum and the BBOS Platform for English has a 1,000 character limit.
• Term Frequency within Keywords – the number of times a term appears in the keywords increases the relevance.
  • For example, having “Black” 5 times within the Keywords gives more relevance than having “Black” only once.
• Term Proximity – for multiple search terms, say A and B, the keyword where A is closer to B has higher relevance over keywords where A is further from B. For example:
  • Given:
    • App #1 with Keyword = Built for BlackBerry
    • App #2 with Keyword = Built for the BlackBerry
    • Consumer search = “Built BlackBerry”

• WHY? The number of characters between Built and BlackBerry is less in App #1’s keyword than in App #2’s.
• Relevance – the keywords must be relevant to the product
  • Keywords cannot be competitive products or other product names.
  • Keywords cannot be popular terms for the sake of receiving a high hit rate.

Vendor Name

The third most important attribute is Vendor Name.

Short Description

The least important attribute is Short Description. It is also available by Platform and Language pairing.

Head over to BlackBerry World Vendor Portal and update your app today!

As many of you may be aware, there are essentially two main models for distributing applications through BlackBerry World: paid and free. With paid applications, the gap between a user seeing an application in BlackBerry World and actually purchasing that application can be a bit of a problem, especially for newer applications.

Free applications can spread quickly but don’t generate revenue when downloaded. So how do you get your applications into the hands of the masses without worrying about this gap and still make money? It’s not a trick question – the answer lies with a hybrid of the two models discussed above by use of the Payment Services SDK.

Enter the freemium (free + premium) business model. The freemium model uses the approach of providing free products/services with paid premium upgrades. Using this model, you would be able to provide a version of your application for free, allowing anyone to test your application without paying a cent, and then offer premium items for purchase using the APIs available in the Payment Services SDK to enhance the user experience. Of course, there are many options for how this could be achieved; the best way to proceed may be to use an example and evaluate a few strategies.

The simplest application to use this model that comes to mind would be a game. With a game, you can allow users have a feel for the gameplay, use the controls and get absorbed into the plot by distributing it for free. One great example where the freemium model is being used today is in the games created by the BlackBerry World vendor Ebscer, in particular Xploding Boxes. I will be using this example to draw parallels to a few concepts discussed in the remainder of this blog post.

To monetize, here are a few options which leverage the Payment Service SDK:

Upgrade

• The idea with the upgrade would be to provide a base or lite version of the application for free and provide the means for the user to pay to unlock the full version. In this scenario, you could present the user with an “Upgrade” button which, when clicked, uses the Payment Services SDK to purchase a Digital Good from BlackBerry World. Once this Digital Good is purchased, the full version of the application can be unlocked for the user.

Unlock Levels

• An alternate approach could be to create the application with 10 (to pick an arbitrary number) levels, but only allow the first 5 to be playable for free. The remaining 5 could be purchased in order to become playable and complete the game. For this you could use a single Digital Good to unlock all 5 levels, sell them individually or in bundles.

In the example of Xploding boxes, the first 25 levels are completely free to play when the application is first installed. As you work your way through the game and have exploded the first 25 levels worth of boxes you then have the option to complete an in-app payment to unlock all 360 levels! The first 25 levels do a great job of getting the player hooked with simple, fun and mind-bending puzzle gameplay, so once those are completed, the nominal fee to unlock an extra 335 levels is more than worth it.

Unlock Features

• Suppose the user would like to customize their game character, or access items for use in the game which will help them complete the game more easily. Why not offer the ability to purchase premium features such as clothing to customize character appearances or a charm to speed up character movements? These features could be as simple as a change to a variable value in the game, but could mean increasing the chances of returns and adoptions of your once-free application.

There are many more options to monetize your applications using the Payment Services SDK; the above three are just some ways this could be done. There is also no restriction to choosing one singular approach; you could use multiple approaches in the same application. As well, you can always release updated versions of your applications with new features and new options to enhance the application through paid premium upgrades.

A few minor suggestions when choosing to use the freemium business model: Make the application addictive/engaging and usable on its own without the user needing to purchase premium features. When selling premium features ensure that the end user receives a good return on their investment by making the features add good value to the application. Finally, premium features should be just that – “premium” – so it is important that they meet or exceed the caliber that users have come to expect from the rest of your application. Going back to the example of Xploding Boxes, all three of these criteria are met: the game is very fun and addictive, the extra 335 levels is a great return providing hours (if not days) of more fun, and as the additional levels extend the existing gameplay model, the user knows exactly what they are getting before making the purchase.

The Payment Service SDK is already supported in current BlackBerry smartphones (OS <=7.1) as well as the BlackBerry PlayBook OS and BlackBerry 10, so no matter what development approach you use (BlackBerry Java, WebWorks HTML5, Native, Cascades Framework, Adobe AIR, Android) there are APIs to support in-app purchases of Digital Goods.  The only thing left to do is implement the freemium model to your existing* or upcoming applications! Oh, and if you would like to have a good example of how this is done, then I would highly recommend giving Xploding Boxes a try on your BlackBerry PlayBook tablet as well as BlackBerrysmartphones (OS <=7.1 and BlackBerry 10) – it is free, after all.

Ready to get started? Here are some resources to help:

Cascades Framework
Native SDK
HTML5 WebWorks
Adobe AIR
Runtime for Android Apps
Java (BlackBerry OS <= 7.1)

BlackBerry World applications cannot change between paid and free models

Forget everything you know about working with maps and BlackBerry WebWorks. Mapping just got real, real easy!

We heard you ask for an easy way to integrate mapping services with your BlackBerry WebWorks applications, and today I’m happy to announce that on BlackBerry 10, the process has become much simpler.

We’ve put together a straight-forward sample application that will show you how to integrate with a few of the services out there:  Google Maps, Bing, Leaflet, and OpenLayers.

If you’ve been following the progression of the BlackBerry WebWorks framework, you’ve probably noticed an awesome amount of transparency. Open web standards are lovingly embraced and adopted here at RIM. Even the framework itself is staged publicly on GitHub.  Continuing this theme of openness and following web standards, the maps samples we’ve released are not platform specific.  Whether you’re writing an exclusive BlackBerry app, or planning on targeting multiple platforms using Cordova (previously known as PhoneGap), these samples are most definitely for you!

For each service, you’ll be able to learn how to:

-          Setup a mapping service to use to in your app

-          Find the users location with HTML5 Geolocation

-          Perform a search for nearby points of interest

-          Display push-pins on the map, showing the search results.

The goal of this sample is to show you how you can quickly integrate maps into your app and have it perform great in WebWorks for BlackBerry 10.

When it comes down to picking which service is right for your app, it’s completely up to you.  One of my teammates, Jim Ing, wrote a really in-depth article on maps, comparing services and much more.  I strongly recommend checking it out “Lightweight Maps For Mobile”.

Check out the sample, in action!

Download the source code.

Ready to add some maps to your app? Download the source code from our GitHub repository!

Calling all Native developers!

Have you been yearning to contribute to the BlackBerry 10 cause but weren’t sure how?  Why not take this WebWorks sample, and build a Native version?!  If you’re interested, get in touch with Shadid Haque (@ShadidHaque) on Twitter.

If you’ve got a success story, have a question, or just want to chat about apps, hit me up on Twitter @chadtatro!

As you will see below, there’s very little (usually just an icon change) required to transition you app from the BlackBerry® PlayBook™ to BlackBerry 10, or the other way around. So even if you haven’t submitted your Android app for distribution to BlackBerry App World™ yet, now is a great time to do so.

Icon size

The main difference to consider when you migrate your app from BlackBerry PlayBook to BlackBerry 10, is a change in the recommended icon size. Be sure to update your app’s icon to take advantage of the higher resolution and have your app stand out in the app grid. The suggested icon sizes are as follows:

BlackBerry PlayBook: 86x86px

BlackBerry 10 full touch devices: 114 x 114

BlackBerry 10 keyboard devices: 114 x 114

Fixed orientation

BlackBerry 10 smartphones are fixed to display content in the portrait position, unless your app uses the accelerometer to adjust the UI layout based on the portrait (vertical) or landscape (horizontal) positioning of the device.

API (sub) set

The good news on the API front is that once your app is functional on the BlackBerry PlayBook, than it will have no problems running on BlackBerry 10 smartphones. You can think of the supported APIs on BlackBerryPlayBook as a subset of the BlackBerry 10 APIs. Everything that is supported on PlayBook, will be supported on BlackBerry 10 and more. Feel free to reference our API support page, as well as our API roadmap.

Resolution Differences

If your application is drawing the UI directly, take note of the change in resolution for both the full touch and keyboard devices. Otherwise, the BlackBerry Runtime for Android apps will scale your app accordingly to fit on the screen.

BlackBerry PlayBook: 1024 x 600

BlackBerry 10 full touch devices: 1280 x 720 (16:9)

BlackBerry 10 keyboard devices: 720 x720 (1:1)

Vendor portal

BlackBerry App World has already opened its doors for you to submit your Android app for BlackBerry 10 full touch model.  To support BlackBerry 10 with an existing Approved/Up for Sale application, please submit it as a new release. Otherwise, when you’re creating a new release in the BlackBerry App World Vendor Portal, you will now see a new Family called “BlackBerry 10” and one new device “All Touch”. You can select “All Touch” to target your app for BlackBerry 10. The BlackBerry 10 Dev Alpha is also still available for targeting your app for testing purposes.

Now with 4500% more unique peaks and valleys.

On November 2nd, PeaksAndValleys 2.0 was uploaded to Github with a number of improvements. In the first release, we relied on a static map that was 150 by 150 vertices (22,500 total vertices.) When we’re talking about a map, we’re just referring to a grid of vertices where each vertex has a specific height.

Bird’s eye view of a 33 by 33 vertex grid (map); each vertex has a specific height associated with it.

These 22,500 vertices were all generated during startup with randomized heights. It was a good initial implementation, but subject to a number of limitations:

• Maybe we want a fixed / persistent world to traverse.
• We can’t expand the map much more due to performance reasons.
• If the player runs in any direction for long enough, they will hit the edge of the map.

Let’s take a look at each of these individually.

Fixed / Persistent World

One of the more common approaches to this problem is the use of a static source of data; in our case, a height map. This is the approach opted for in PeaksAndValleys 2.0. The following is an example of what a height map might look like:

Sample height map (originally 1024 by 1024 pixels).

Each pixel represents one vertex (or point) of the map, and the RGB colour of that pixel is used to determine the height of each vertex. In the case of PeaksAndValleys, the lowest height occurs at pure black (RGB = 0×000000) and the highest height at pure white (0xFFFFFF).

Though the height map is only 1024 by 1024 pixels, we can apply a scaling factor to extend the map across larger distances in our WebGL world.

Depending on how smooth the source image is, we may get areas where there is a very low region next to a very high region. To prevent drastic changes in terrain, a smoothing algorithm was implemented that averages the height of each pixel with that of its neighbours.

And with this, we address the fixed / persistent world by using a static data source. We can quickly see how multiple height maps and randomized starting locations can expand the versatility of this approach.

Performance

As noted, the first release of PeaksAndValleys contained a static 150 by 150 vertex area and expanding to a larger number of vertices would have an impact on performance; so then what good is a 1024 by 1024 height map?

In our case, we’re actually only loading a 121 by 121 region at any given time. As the player traverses the terrain, we are continuously reloading the surrounding region data (with the player at the center.) This means that as the player moves around, terrain in their vicinity is continually loaded from the height map.

There is a lot of processing that needs to go on in order to keep loading terrain — so much that if we do this processing on the main application thread, we’ll see a drop to roughly 30 frames per second. This is where Web Workers come in, for which the implementation can be seen in GLTerrainWorker.js.

A Web Worker allows a separate thread to perform actions without interfering with our main application thread. Our main application thread is where all of our interactions and rendering are performed, so if we can minimize the work being done there, we can improve our frames per second and responsiveness.

Web Workers aren’t without their limitations. Specifically affecting us, we cannot:

• Access the DOM. This eliminates WebGL rendering directly on the Web Worker.
• Pass objects with functions between the main application thread and Web Worker.

These two limitations mean that while we can perform our processing on a Web Worker, we actually need to pass the processed data back to our main application thread in order to update our rendering objects. We do this via the onMessage listener and postMessage initiator to initialize our Web Worker with the data it will need, and then pass subsets of that data at various intervals. You can see this initialization and rendering update performed in GLTerrain.js.

By offloading this processing to a Web Worker, we can continuously load more data off the main application thread, and only pass back the final data results to be assigned to our renderers. The end result is increasing our frames per second from roughly 30 to 50-60 frames per second; a huge win. To learn more about Web Workers, the following HTML5 Rocks tutorial is a great starting point.

Seamless Terrain

The final issue we had with our 150 by 150 static area was that when you run to the edge of the map, you hit the border. Loading data from a larger 1024 by 1024 area certainly extends the time before the player hits the border, but inevitably they will if they keep moving in one direction.

To counter this, the application continuously loads an area of pixels surrounding the player. As you reach any of the edges, data from the opposite side of the map will we used to populate that area. This produces a continuous terrain, even when travelling near the edges of the map.

Red cross represents the location of the player, white area represents the data we’ve loaded.

By wrapping the data that we load as we get close to the edges, we can in essence allow the player to run forever. You may notice that this image isn’t intended to be seamless (i.e. when wrapping around, the colours at the borders do not match up or flow together). This can be overcome by using a height map that is already seamless (i.e. it has already been processed to ensure that the pixels on the north side match those on the south, and those on the east match those on the west). In the case of PeaksAndValleys, our smoothing algorithm was implemented to wrap around the image when necessary (i.e. at the edges), thus turning non-seamless images into height map data that is seamless.

Preprocessing Data

To obtain usable height map data, we must:

• Read a source image; in our case 1024 by 1024 pixels.
• Perform height calculations.
• Calculate the normal (perpendicular vector) of each point.
• Calculate texture coordinates.

This involved quite a bit of math and processing power. Mathematical calculations are an area where JavaScript performance has historically suffered. Attempting to perform these actions while the application loads leads to a PC load time around 5 seconds and a mobile device load time around 20-25 seconds.

This also means that we are re-calculating data on every load just to get the same result as our previous run — a very inefficient approach.

To address this, a Node.js preprocessor tool was created that reads in an image, along with some parameters, and generates a json file with the resulting vertex, normal, and texture data required by our WebGL application. On a 1024 x 1024 image, the resulting file is roughly 50mb in size. Originally, this file was closer to 120mb, however by truncating decimal points to 5 significant digits the overall size was reduced.

As a result our application doesn’t actually process any data on load. Instead of feeding in an image, we are now feeding in the output json file with all calculations already in place. That being said, we are still loading a 50mb file which does take some time, but now we’ve managed to cut the loading time closer to 5 seconds on a mobile device.

Using preprocessed data also minimizes the amount of work the Web Worker has to do, as it will simply retrieve the appropriate data based on the user’s location and pass that data back to the main application thread.

Summary

Ultimately, PeaksAndValleys has seen a large number of improvements in the terrain implementation. From preprocessing / generating seamless height maps to leveraging Web Workers and minimizing strain on the main application thread, we now have a much more versatile world.

There are still some issues such as terrain popping into view as you move about. There is also room for optimization by only loading a cone of data in the player’s field of view (as opposed to a square in all directions around the player). These are topics that will be addressed in the next release.

For more information on this project, be sure to check out the Github release. Feel free to leave questions there, or reach out to me directly on Twitter® via @WaterlooErik.

With the upcoming launch of BlackBerry® 10, we’ve got a few new features on their way and we want you to be prepared for them.

We understand that the success of your app is based on marketing properly to as many customers as possible. With this in mind, we’ll be introducing a new Improved Relevance Marketing Meta-Data feature set.

So what does this mean for you? Well, a lot. When we launch this new feature set, you’ll be able to upload multiple sets of meta-data (this includes screenshots and descriptions) that will be platform and language-specific. That’s right — no need to spread your applications across multiple product SKUs.

For example, if you want to deploy an app supporting BlackBerry® OS, BlackBerry® PlayBook™ tablets and BlackBerry 10, you can do it all under a single application submission instead of three – all the while maintaining distinctive descriptions and screenshots for each platform.

What’s the benefit to you? Less SKUs in the store to manage – a single app supplies the binaries and meta-data for every platform you support. What’s the benefit to end-users? When they upgrade their BlackBerry smartphone to BlackBerry 10 or buy a BlackBerry PlayBook tablet, their apps can quickly and easily be reinstalled via My World. This also means that you keep your customer base when your users change platforms. Additionally, the user will see meta-data (description, screenshots, etc) that is optimized for his/her device platform.

Some updates to the BlackBerry App World™ storefront search will be made to further improve app discoverability. In January 2013, it will be updated to include searching on the following fields:

• Title
• Keywords
• Vendor Name
• Short Description

Long description will no longer be indexed for search.

Below you’ll find all the details currently available and how they compare to what will be available when these features launch shortly.

So, there you have it! Sound off in the comments and let us know what you think.

If you could promote your application on a rapidly growing social network with 60+ million active users – 70% of which use it daily – with just a few lines of code, would you do it? I think the more appropriate question is, why haven’t you done it yet?

Meet the BlackBerry® Messenger Social Platform (BBM™ SP), which you can use to enable your application to go viral with very little effort. Approximately 2% of applications in the BlackBerry App World™ storefront have connected to the BBM SP; however, that group accounts for over 20% of all downloads! Spending just half an hour to add this to your application can really pay off. With minimal development effort, Foursquare was able to integrate their application with the BBM SP, resulting in a doubling of downloads in a single day. Nobex Radio saw a 52% increase in downloads after they added support for the BBM SP.

Continue reading for a high level overview of what can be done using the BBM SP APIs. Today we’ll cover the “What” of the BBM SP. Future articles in this series will provide more technical “How To” for both Native and BlackBerry® WebWorks™ developers. The features discussed in this article exist both on BlackBerry® 10 and BlackBerry® OS 5 through 7.

Registration

Registration is the first step in connecting to the BBM Social Platform, which involves an application registering itself with the RIM®-hosted BBM infrastructure. Keep in mind that like most features on a BlackBerry device, the user can approve or deny this connection, allowing them to regulate which applications they allow to use the BBM SP. The application is also informed during this process whether or not the connection was a success. If it did fail, the application is given the reason why. Possible reasons include lack of network coverage, registration blocked by the user, or BBM Client not configured. Once this step is complete, the more interesting APIs of the BBM SP are available to your application.

Invite to Download

The invite to download feature allows users of your application to invite their BBM contacts to download your application from BlackBerry App World. The recipient receives the invitation through a BBM Chat session, which includes a message provided by the application and user sending the invitation. The chat session also contains buttons for the user to accept or decline the invitation. If they accept the invitation, BlackBerry App World is opened to show your application. This feature is ideal for multi-user applications or games, allowing the user to easily invite their contacts to participate.

Note that for this to work between BlackBerry 10 and BlackBerry OS 5-7 users, the SKU in BlackBerry App World for the two releases of the application (BAR and COD) must be the same.

Profile Integration

Updating personal message from BBMQtProfile Sample

BBM SP allows for both read and write access to the user’s BBM profile. This allows your application access to their profile message, status text, availability and avatar image. The screenshot above shows the confirmation prompt that appears when an application attempts to update a user’s personal message.

View from my contact’s device

Profile updates are visible from the devices of my contacts. They can see a list of recent updates made to my profile and provide yet another opportunity for viral growth. If an update to my personal message was made from an application other than the BBM Client, a tag is shown under the update stating the name of the application that performed the update. Note the “from BBM SDK Demo” tag beside the red arrow. Users can click on that tag to download the application from BlackBerry App World. This requires the sender to have installed the application from BlackBerry App World, so that tag won’t take you to BlackBerry App World if you side loaded your application for testing.

Profile Boxes

Profile Boxes provide yet another way for an application to promote itself to a user’s BBM contacts. They appear within the Apps area of a user’s profile and are ideal for sharing what a user is doing within an application. Every application that is connected to BBM SP appears in the list. Applications can create profile box items that appear under their application header. You can supply a custom image and string, which is used to create the profile box item. The user’s contacts can also use this to download the application from BlackBerry App World.

Contacts

An application can retrieve a list of BBM Contacts who have the same application installed. This list can be used as selection criteria for connecting to create a multi-user experience. Events are also fired for changes to this contact list, allowing your application to keep track of both the addition and deletion of contacts in the contact list itself and/or changes to individual contacts. An application could pick up on changes to individual contacts to trigger some event. For example, if someone gets a new high score, a game may broadcast it to the user’s BBM contacts by changing their BBM personal message. An application could listen for this update and use it to trigger an in-game challenge to beat their friend’s new high score.

You could also use this to trigger in game connections. A user could enter a game and indicate they want to play against their friends. The game could update the user’s BBM status to something like, “Mark wants to play Slingshot 5000 with someone.” By listening to BBM status updates, my contacts who are also in game could be prompted to join for some head-to-head action.

Wrapping It Up

This list covers the core BlackBerry Messenger Social Profile features that will be available for your application to use upon the launch of BlackBerry 10. The SDKs and APIs are available to use now — start today so you can be ready for launch. If you have an existing application that targets BlackBerry OS 5-7, you can roll out these features right away.

Keep an eye here on the blog for follow-up articles that’ll provide some technical information on how to code these features into your application. We also have further information available on the BBM SP website. Also, watch this blog for additional blog posts in the BBM series that cover how to use these features in a Cascades™ application and BlackBerry WebWorks application, as well as how to invoke BBM using the invocation framework.