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!

[ YouTube link for mobile viewing ]

Since the launch of the Native SDK for BlackBerry® Tablet OS closed beta, game developers have been able to leverage rich tools to take advantage of the power within the BlackBerry® PlayBook™ tablet. With the general availability launch of the NDK, along with the Scoreloop NDK beta availability, leveraging the full capabilities of the BlackBerry PlayBook is now easier than ever.

The video above highlights some great examples of gaming experiences on the BlackBerry PlayBook, including apps like Dead Space for BlackBerry PlayBook, Asphalt 6: Adrenaline HD, and N.O.V.A. 2 HD (full list below).

Spacelings by HotGen Limited
BattleBallz Chaos by Pocketeers Limited
Raging Thunder by Polarbit
Bejeweled 2 for BlackBerry PlayBook by Electronic Arts Inc.
THE GAME OF LIFE for BlackBerry PlayBook by Electronic Arts Inc.
Dead Space for BlackBerry PlayBook by Electronic Arts Inc.
Asphalt 6: Adrenaline HD by Gameloft Inc.
N.O.V.A. 2 HD by Gameloft Inc.
Let’s Golf 2 HD by Gameloft Inc.
ToFu by HotGen Limited

[ YouTube link for mobile viewing ]

Here’s a guest post from our friend Anders at RIM TAT! – Ed.

Cascades is the user interface (“UI”) framework that TAT has been using for many years to create numerous advanced UIs and applications, such as Scrapbook for BlackBerry PlayBook. I’m happy to announce that it will soon be part of the BlackBerry Native SDK.

Here’s a short list of Cascades features:

• Great performance, including amazing transitions and animations
• Flexible UI layouts including free form lists.
• 3D support
• Support for mixing pre-packaged UI components with custom components
• Core UI feature support

Cascades was originally developed to enable development of really innovative and unique applications. This put hard requirements on the flexibility and extendibility of the UI framework. The need for designer/developer collaboration was also one of stronger driving factors when developing the framework. Let’s dig deeper into how Cascades will aid the development of rich and compelling UI.

The flexibility of Cascades enables UI innovation

Cascades has a unique level of UI building blocks. In other UI frameworks, when stepping beyond the set of standard UI components, developers must often resort to low level OpenGLES-commands. Cascades provides higher level building blocks for many of the tricky but application-defining UI scenarios. Features like Flexible List layouts, 2D/3D transformations, mixing of 2D UI and 3D objects are all made accessible to developers.

The Cascades workflow helps designers and developers collaborate

In Cascades, UI elements are exposed both programmatically and through mark-up. The mark-up also provides scripting support making it a suitable environment for more design-oriented developers to work with, allowing for quick turnaround times and prototyping to find best possible UI design.

The markup also enables strong tool support including a Photoshop plugin making it easy to take and .psd sketch to a working layout in an application.

Cascades has beautiful pre-packaged components

Not every developer is a designer, full of ideas around 3D layouts and crazy infographics. For developers who prefer pre-designed and pre-packaged components, Cascades provides a strong set of Core UI components with great look and feel. They come with a number of built in effects and interaction design that will risk making your app look prettier than you can take credit for.

Availability of Cascades

Cascades will be released as a Beta during the Fall of 2011, with more and more advance features coming in future releases.