For anyone new to analytics let me explain why I am so excited and why you should be as well. Analytics gives you the ability to know who is using your application as well as how they are using it. Sounds easy enough right? The Flurry SDK integrates with your application and allows it to log “events” when they occur. A simple example would be logging an event where a button is clicked. That data is recorded and then sent up to the dashboard where patterns start to emerge on how many people are clicking that button, how they got to it, and what users do after it gets pressed.

Analytics helps by telling you two very important pieces of information:

Who is using your application?

The Flurry Analytics service will report the following information about the user/user’s device by default:

• Locale set on the device
• Time Zone
• Approximate location
• Device name (ex “BlackBerry Z10”)
• Device OS version
• Carrier

And can also be configured by you to report:

• The version of the app being used
• The user’s geolocation (with permission from the user)
• The user’s gender (if supplied by the user)
• The user’s age (if supplied by the user)
• The user ID (if used by your application)

This will let you know where your application is being used, as well as provide you an idea for the type of people that are using it. This in turn gives you the ability to tailor content to various regions and locales based on demand, as well as determine which device models you may want to focus on in the future.

How are people using your application?

Of course after you know who is using your application you will definitely want to know how they are using it. Flurry lets you log events that occur within your application, letting you map out every step the user takes. This is helpful so you can see trends for where they may be getting stuck, areas for improvement, and features that are being used more than expected and can be prioritized for enhancement in future releases. This information is invaluable for making informed decision on where to take the direction of your application.

From the aspect of monetization, knowing user patterns can help you understand what will make your application and possibly digital goods for sale, more attractive/valuable to the end user. Events would also allow you to track the success of promotions within your application. If you happen to sell a limited edition digital good, or offer to unlock the premium features of the app at a reduced price, you have the ability to track the success of the promotion with a relatively short turnaround.

The idea of tracking everything your users do may sound like a scary concept, however all data is made anonymous by the service meaning there is no way of tracking specific actions back to one device/user. Keeping the data anonymous keeps users from compromising their privacy while still maintaining the integrity of the data.

If you’re ready to add some analytics to your application then getting started is easy. Simply go over to the Flurry home page and create an account. Then create an application to get the analytics SDK for BlackBerry 10.

I’ve also whipped up a sample app that you can take a look at to get a feel for the APIs that can be downloaded from the Community Samples Repo on GitHub.

JAM68 – Flurry Mobile Analytics on BlackBerry 10!!

If you’re lucky enough to be at BlackBerry Jam Americas this week, you can attend JAM68 where Anthony Watkins and Rich Brett from Flurry will be presenting with me on how to integrate the Analytics SDK into your BlackBerry applications. For those unable to make it, the recording should be posted a few days following the session and you can always send me a message on Twitter with your questions/comments: @garettBeuk

For more information you can also refer to our Analytics page on the forums:

http://developer.blackberry.com/devzone/develop/platform_services/platform_analytics.html
http://supportforums.blackberry.com/t5/BlackBerry-Analytics-Service/bd-p/analytics_serv

JAM36 – NFC development for BlackBerry 10: A whirlwind tour

Here we’ll look at all the tech that is available from you to create solutions. We’ll cover tag reading and writing, P2P and more.  Great to keep in mind that NFC is more than just payment!!!

JAM26 – Demystifying NFC Payment

But – if you’re thinking about getting into payment (or loyalty programs) – this is the session for you.

We’ll cover a few different approaches and talk about everything you need lined up. There are lots of moving pieces involved to make complete secure element / card emulation solution.

Send me an email or tweet @robbieDubya for all of your NFC needs.

Thinking of twitter – Martin @mdwrim and John @jcmrim are people you really should be following if you are into NFC and BlackBerry! #nfcguys

I hope you’ve enjoyed the series and we look forward to seeing you all at BlackBerry Jam Americas in Orlando. Please let us know what you thought of the videos to ensure that we can bring information to you in a way that’s educational, but entertaining as well.

This particular video will give you some information about the current opportunities and upcoming roadmap items that we’re looking at for extending connectivity for developers. In this video we’re joined by Rob Williams who talks about how you can connect BlackBerry 10 to the world around you to incorporate context into your apps.

So we’ve updated the socialinvocation sample to include examples of how to invoke Foursquare with all of the currently supported invocation parameters.

As you can see, Foursquare allows BlackBerry 10 developers to leverage their app in a number of different ways, both through Cards and the Invocation Framework.

Big thanks to Kyle from Foursquare who has also documented these features in his sample app:  https://github.com/foursquare/foursquare-bb10-sdk

If you want to learn more about Social Invocation and why you should be including it in your app, come to one of our sessions next week at BlackBerry Live!  We’ll be talking about the benefits of integrating with Foursquare and the rest of the Social apps in two sessions:

JAM37 - Building context-aware applications by leveraging the power of Foursquare APIs, Thursday, May 16

JAM52 - Get Social: Connecting your app to Facebook, Twitter, Foursquare, and more! Wednesday, May 15

Kyle from Foursquare will be there, and we will show a real world example of how Untappd found success by integrating with Foursquare.  Sample apps, best practices, and code snippets will also be presented that will show developers how to quickly get started in both the BlackBerry WebWorks SDK and the BlackBerry Native SDK.

We’ll be posting videos as part of this series leading up to BlackBerry Jam Americas in Orlando in order to give some more background surrounding the topics that we’ll be discussing in detail during the conference.

In this video we’re joined by Dale Ducharme (against his will) to talk about the cool features available for gaming developers on BlackBerry 10.

Next week is BlackBerry Jam Americas 2013 and as a member of the Developer Relations team, I’ll be stationed at various locations over the three days helping out developers when I can. Better yet, i’m also hosting a lab that I hope you will find a lot of fun and very informative on stereoscopic 3D and HDMI output for your apps. I’m also presenting a session on getting the most out of Momentics to help you build and package your apps in an efficient manner and streamline your development process. This is something all developers should care about since saving time during development often means you can take on more projects and earn more in the process.

JAM54 – Lab: Adding a new Dimension to your BlackBerry Apps – Stereoscopic 3D ( and other advanced applications for output to the HDMI display)

My first experience with stereoscopic 3D, like most people, was from playing with a ViewMaster as a child. In the years since, I have experimented with stereoscopic photography, utilizing stereoscopic 3D graphics in 3D modeling and rendering software I worked on in university and during the first few years of my career, and now I am reviving some of that early work in my spare time and applying that knowledge to develop stereoscopic software for the BlackBerry 10 platform.

Stereoscopic 3D represents another way your app can engage with its users and set it apart from the competition. Imagine users playing your game on the big screen with the game play literally in their face or taking a look at NASA rover stereoscopic photos with their smartphone and feeling like they are looking out the window at the Red Planet. That’s the kind of emotion and excitement that this technology brings to those who truly appreciate it.

The techniques we will review in the lab produce stereoscopic 3D output via the HDMI display in a manner that should be compatible with the majority of 3D TVs and monitors in the market today.  The diagram below provides an overview of what type of output is generated and I will have sample code on hand so that attendees can dive right in and integrate it into their applications.

Is that all we will cover? Absolutely not. The stereoscopic techniques rely on HDMI output. HDMI output can be useful in a number of other types of apps as well. We will review some other use cases and show how the existing sample code can be adapted for those purposes. If you want to incorporate stereoscopic 3D output into your app or if you just want to know how to output content to the HDMI display in general, join in on the fun. After the lab is over, the 3D TV will be moved into the Jam Space for attendees so you will have the rest of the event to access the TV and test the changes you make to your apps and demo your efforts to others.  I’m looking forward to seeing what our developers produce with this new tool in their arsenal.

 JAM39 – Build and Packaging for native apps

As your app portfolio grows, you are probably trying to come up with ways to reuse code you wrote in a different application or organize it better, turnaround changes faster. Maybe the app’s download time is a little slow and you want to improve on it but don’t know how? If any of these questions apply to you, you want to attend this session. We will run through some tips and tricks we use for internal apps and some little known options available in the Momentics IDE to help you develop a build system to be more efficient during the development process.  We will show you some tips on how to build a Qt or Cascades shared library. If you develop on multiple platforms, we will share some tips from our porting guides on how best to create a shared pool of code that you can build on multiple platforms. If you want to use a shared library developed by someone else, we’ll show you how to integrate that library with the IDE for seamless integration with your apps.

These sessions are just the tip of the iceberg of the session catalog at this year’s conference. Join us in Orlando and learn a lot about what you can do now and what’s coming in future versions of BlackBerry 10. I am looking forward to seeing some familiar faces and to meeting more developers again this year.

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.

Coding and deploying for the devices with 10.1 OS

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

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

What about my current applications for the Z10 devices?

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

Project Explorer View

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

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

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

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

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

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

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

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

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

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

Managing code base

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

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

To Sum Up

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

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

We’ll be posting videos as part of this series leading up to BlackBerry Jam Americas in Orlando in order to give some more background surrounding the topics that we’ll be discussing in detail during the conference.

This particular video will give you some information about the upcoming roadmap items that we’re looking at for extending BBM capabilities for developers. In this video we’re joined by Nick Kalkounis to talk about new APIs that are coming to better connect your application through BBM.

With the upcoming release of BlackBerry Q10, there’s never been a better time to bring over your BlackBerry Z10 game and start monetizing on the new form factor. In this post, I will be talking about various porting considerations and best practices to help you get started and ensure that your game runs the best on Q10.

Let’s start off with the hardware differences:

The BlackBerry Q10 uses the same chipset and GPU as BlackBerry Z10 variant B with Qualcomm Snapdragon MSM8960 and Adreno 225. The main differences that you need to consider are aspect ratio, screen size, orientation and physical keyboard.

Aspect Ratio

If you have designed your game around the 16:9 or 15:9 aspect ratio, you will need to evaluate how to layout your game content to adapt to the 1:1 aspect ratio. There are various approaches you can take to accomplish this. You might be tempted to take the easy approach of simply scaling your game screen to 1:1 aspect ratio by using letter boxing. This approach is not recommend as it could negatively impact user experience of your game.  Since The BlackBerry Q10 has a smaller screen compared to the BlackBerry Z10, you will significantly reduce the game interaction area and waste precious screen space that could otherwise be utilized for game content such as HUD or controls. For a landscape game, one approach you could take to solve this is to use a comprise aspect ratio such as 16:11.  For the BlackBerry Z10, display more content on the sides and for the BlackBerry Q10 display more content at the top and bottom.

Similarly for a portrait game (9:15 or 9:16), you can display more content at top and bottom on the BlackBerry Z10 and more content at the sides on the BlackBerry Q10. In the below example, Bejeweled 2 displays the time progress bar at the bottom on the BlackBerry Z10 and on the side on the BlackBerry Q10.

If you are using any aspect ratio specific static assets such as backgrounds, images and splash screen, they will need to be scaled accordingly. For the standard splash screen, the BlackBerry Native SDK allows you to manage multiple device specific splash screens in the same bar-descriptor. For the BlackBerry Q10 you can add a 720×720 splash screen by editing the bar-descriptor using the IDE or a text editor. Here’s an example:

<splashScreens>
        <image>splash_1280_768.png</image>
        <image>splash_720_720.png</image>
</splashScreens>
      <asset path="assets">assets</asset>
      <asset path="icon.png">icon.png</asset>
      <asset path="/Users/pratiksapra/assets/splash_1280_768.png">splash_1280_768.png</asset>
      <asset path="/Users/pratiksapra/assets/splash_720_720.png">splash_720_720.png</asset>

Once you do this, correct splash screen will be automatically chosen depending on the device your game is launched on.

Next, if your game uses overlay controls such as virtual joysticks, UI elements and menus, you will need to reposition them as needed. The best approach is to lay them out relative to screen width and height thus making them aspect ratio independent. Below is an example of a flexible UI layout used in Bard’s Tale that works on both aspect ratios.

Screen Size

The BlackBerry Q10 features a 3.1” screen surrounded by a gesture sensitive bezel. If your game uses on-screen controls, it’s important to place them away from the bottom edge of the screen to prevent accidental swipes. An accidental swipe-up gesture during game play will thumbnail your game and cause unnecessary interruption for the user.

Optimizing your game controls is also really important. For example, If your game uses dual virtual joystick control scheme, I would recommend reducing this to just one on-screen joystick.  Due to smaller screen size, the user might end up covering most of the screen when controlling both joysticks using two fingers. We will talk about a solution to this in the later part of this post.

Orientation

The BlackBerry Z10 supports portrait as the default orientation. If you are setting the orientation in the bar-descriptor for your game, you might be wondering whether this would work on the BlackBerry Q10 without the overhead of creating a separate binary with a different bar-descriptor. To make your life easy, we have made sure that both portrait and landscape orientation settings map to portrait orientation on the BlackBerry Q10. The below example shows how your game would be oriented on the BlackBerry Z10 and the BlackBerry Q10 based on the bar-descriptor orientation setting.

Input

The BlackBerry Q10 features a physical keyboard so your game needs to be aware of this. If your game contains any buttons to activate the virtual keyboard, you should make sure they are removed or disabled when the game is running on the BlackBerry Q10. Unlike the virtual keyboard, the physical keyboard is always there and can be utilized as an input mechanism.    You can combine keyboard input with touch screen to offer an intuitive and robust input scheme for your game. For example if you want to optimize the dual virtual joystick input mechanism for the BlackBerry Q10, you can substitute one of the joysticks with keyboard input. Or if your game only requires gamepad style input you can use the keyboard as a gamepad.

Integrating keyboard input in your game is super easy. To accomplish this, in your main event loop simply handle the SCREEN_EVENT_KEYBOARD event and check for the keydown value. Here’s a code snippet on how to do this:

if (screen_get_domain() == domain) {

        screen_event_t screen_event = screen_event_get_event(event);

        int screen_val;
        screen_get_event_property_iv(screen_event, SCREEN_PROPERTY_TYPE, &screen_val);

        switch (screen_val) {
        case SCREEN_EVENT_MTOUCH_TOUCH:
//handle touch events

        case SCREEN_EVENT_KEYBOARD:
            screen_get_event_property_iv(screen_event, SCREEN_PROPERTY_KEY_FLAGS, &screen_val);

            if (screen_val & KEY_DOWN) {
                screen_get_event_property_iv(screen_event, SCREEN_PROPERTY_KEY_SYM,&screen_val);

                fprintf(stderr, "The '%c' key was pressed\n", (char)screen_val);

                switch (screen_val) {
                case KEYCODE_W:
                    // Handle Up
                    break;
                case KEYCODE_A:
                    // Handle Left
                    break;
                case KEYCODE_Z:
                    // Handle Down
                    break;
                case KEYCODE_D:
                    // Handle Right 
                    break;
                case KEYCODE_L:
                    //Button A
                    break;
                case KEYCODE_P:
                    //Button B
                    break;
                case KEYCODE_K: 
                    //Button X
                    break;
                case KEYCODE_O:
                    // Button Y
                    break;
                default:
                    break;
                }
            }
            break;
        }

Tools & Deployment

To get started, you will need the latest BlackBerry Native SDK 10.1, which includes BlackBerry Q10 support. If you are running an older version please upgrade by visiting http://developer.blackberry.com/native.

To deploy your game on BlackBerry World, follow the regular process for creating a new release in the Vendor Portal. In the supported devices screen, make sure you select BlackBerry Q10.

Known Issues

There are two known issues with earlier versions of 10.1 device software that you need to be aware of.

• Audio – In-game audio playback results in complete loss of device audio and a reboot is required to restore audio.
• Orientation – If the orientation is set to landscape in the bar-descriptor, the app splash screen and system dialogs such as volume are incorrectly oriented.

Both of these issues have been fixed in the latest 10.1 device software posted at the below link so if you are running an older build please upgrade.

https://developer.blackberry.com/blackberry10devalpha/devalpha_update.html

I hope you found the information included in this post useful.  If you have any questions or feedback please leave a comment below or reach out to me directly on Twitter @pratiksapra.