Our rationale for providing these target OS updates to our developer community is twofold. First, we want to provide you with the ability to debug your apps on the latest OS targets that you download on your Dev Alpha devices. These debug targets contain the new symbol tables that will allow you to line up the target with the IDE. Second, as we release production devices, we expect that many of our developers will be purchasing this production hardware for development and testing purposes. We plan on making the latest libraries available for our production devices so you can debug and test your apps. You can use the IDE’s built-in update manager to get these targets.

The purpose of this blog post is to explain and clarify how the update mechanism will work for both Dev Alpha testing devices and production devices. I’ll assume you are already familiar with the update manager. If not, I urge you to read my previous blog post prior to reading this one.

First, let’s start with the simple case of updating the target OS for the BlackBerry Dev Alpha testing devices. To keep things simple, we will only provide the latest and most recent target OS update for these devices so you will only find one dev alpha update at a given point in time via the update manager. So as an example, let’s say 10.0.9.2318 is the latest version of software you can download for our Dev Alpha test devices through our update manager. Once we release the next target OS, we will remove 10.0.9.2318 and place the new one on the update server. We will also add the Dev Alpha keyword in the update site target string to clearly indicate that this is a Dev Alpha load. When you bring up your update manager UI, you will see the new build tagged with the ‘Dev Alpha’ keyword as shown below. Note that 2318 is no longer available through the update site now that we have refreshed it with a newer version.

I hope you found that straightforward, since on production hardware things get a little more complicated – though we are trying our very best to simplify this. As we release the different revisions of BlackBerry 10 production hardware, you will see multiple versions of production software based on device type and carrier. Once again, I should reiterate that from an API perspective this software is identical, and there should be no difference in app behavior between these various versions. These versions are only there so if you have a device from a carrier with that build number on it, you can match up your debugging target with it to perform on device debugging. The way you find your build number is by accessing the Settings screen (slide down gesture from the top bezel), and once you get in to this screen you select the About menu. Once you click on this, you will see a screen that provides various pieces of information about your device such as Model Name, Number, OS Version etc. The field you are interested in is OS Version. You should see something like the following under OS version. In the figure, the OS version is 10.0.10.401:

If you now go to the update manager, you should find a version of software that you can update to that matches your OS version. For target OS updates that correspond to production hardware, we will not have the Dev Alpha keyword in the update string, so you will just see BlackBerry 10 Native SDK 10.0.10.401.

Last but not least, if you are developing using the simulator, you can find the latest version of the simulator on our native site. We will also be providing earlier revisions of our simulator on our site in case you need to acquire a previous copy. Once you have the simulator, you can get an updated target for it via the IDE by using the same mechanism as described above. You can determine your simulator build in two ways. First, when you see the simulator download on our developer site, it will also specify the simulator version you are downloading – for example, it is 10.0.10.261 in the example below:

You can also determine your simulator build using the swipe down gesture to access the Settings screen, similar to how you would do this on the device as described above. Once you know your simulator version, you can download the appropriate target libraries using the update manager. In this case, it’s the Dev Alpha build 10.0.10.261.

My hope is that this clarifies things for you and makes it easy to keep up with target OS’s. One thing I need to reiterate though is that you don’t have to keep downloading newer device side updates. Our APIs are complete and other than a few minor exceptions, we don’t plan on adding in new APIs. More importantly, though, backwards compatibility is being enforced – if your app works as of our Gold 10.0 SDK, you should be fine. We are making sure that the new targets don’t break backwards compatibility. So you only have to worry about downloading these new targets if there is a specific issue you are trying to debug on a target that is running a newer version of software. In addition to this, in the future we plan to simplify the process of keeping up with targets so that you don’t have to worry about matching target numbers with SDK numbers – the IDE will automatically select the right debug symbols for you based on what target is loaded on the device you connect to.

I hope you have found this useful – as before I will continue to provide important snippets of information on a regular basis to assist you with your development via my blogs and through Twitter @russell_andrade.

Our SDKs (both API and tooling) remain gold as of the previous release and we have not introduced any new API or tooling changes in this release.  However, that being said, we continue to build new versions of the BlackBerry 10 device software that contain various bug fixes and stability improvements.  Our BlackBerry 10 software is being tested by over 150 carriers around the world and as they provide feedback we continue to release software incorporating this feedback.

What this means is that even though our API signatures and tooling are not changing; the underlying device software will go through a continuous improvement cycle. As an app developer you will want to upgrade to the latest software on your BlackBerry 10 Dev Alpha testing device in order to get the latest fixes as well as perform some sanity testing with your app to make sure there are no unexpected issues.  If you are trying to debug your app on the latest and greatest device release, you will likely want to pick up the latest Native SDK target OS so that you can get the right libraries and symbols for debugging on the latest version of device software that you are working with.

The good news is that you can download the the latest Native SDK target OS via the Update Manager that we provide as part of our Momentics IDE suite. If you click on Help in the menu bar, you will see an item that says ‘Update Native SDK’.

Once you click on Update Native SDK, you will see a dialog pop up that provides a list of Native SDK targets OS releases you can download. The latest Native SDK target OS as of the time of writing of this blog article is BlackBerry 10 Native SDK 10.0.9.2318. You should see this in the list.  Select it via the checkbox, click Next and follow the steps to download the latest Native SDK target OS.

As we get closer to the launch date of our device and the gold release of our BlackBerry 10 device software we want to make sure that you have the latest BlackBerry 10 Native SDK target to test and debug with on your BlackBerry 10 Dev Alpha testing devices.  As we build new iterations of our OS software, we will continue to release these to you via our Update Manager so you can keep up with the most recent versions.

In many ways, this release is rather uneventful since we had achieved most of what we set out to do from an SDK perspective for BlackBerry® 10 in the last release. But as they say, “no news is good news” and the reason for this release is primarily performance enhancements – we delivered all the key APIs you need in earlier releases.

Our main focus at this time is to stabilize the Native SDK and make sure to get rid of those nagging bugs and issues that can make the lives of our developers difficult. We also want to avoid feature creep and churn, especially with our BlackBerry 10 launch not that far away. That being said, there are still a few key features that I would like to talk about in this release.

At the core Native layer, we introduced a few new APIs and fixed a whole bunch of bugs. There are too many fixes to list, and you should refer to our release notes if you need a comprehensive overview. However, I thought I should point out a couple of important ones.

We added functions to support a Proxy auto config (PAC) and URL exclusion list to the BPS netstatus API. We also fixed the netstatus availability API, and added a last known location request to the BPS Geolocation API. Several fixes and minor enhancements were also made to our Scoreloop SDK.

For many of you these will likely not be a big deal, but for those of you who have been blocked waiting for some of these fixes and enhancements, I hope they help address your issues and concerns.

On the Cascades™ platform side of things, we added in an API to determine device orientation along with a camera specific API to query the preview frame orientation. Another API that might be of interest to our audio developers is the ability to provide an external audio manager handle into the AudioRecorder object.

Many app developers have also expressed the need for APIs that allow them to query the device for information, either for diagnostic purposes or for optimization and fine tuning based on what the system is capable of. With that in mind, we have added a device information API that provides the ability to query device-related information, as well as a memory info API that allows you to query memory related parameters such as total RAM and flash. We have also addressed a bug in our dialogs and toast API that will allow Cascades developers to access the finished signal in their qml code. Speaking of dialogs and toasts, we also enhanced our BPS dialog service to add support for recursive mutexes.

There are also some exciting developments to report on in the tooling front. We are releasing a new beta of the Visual Studio™ Plugin that addresses several of the bugs and issues with the earlier beta. One useful improvement that we addressed is support for variable expansion via the debugger. For performance reasons, we were only able to support up to five levels deep in our last release. We managed to optimize the way we perform variable evaluation so we can loosen this restriction. Developers who have significant nested structures in their games will now have no issues expanding their structures as deep down as possible, as you can see in this screenshot:

Another important usability issue that we addressed in this release is the ability to stop a build that is in progress. Many game developers have large projects that can take some time to build, and it was important to provide the ability to stop a build midway in case the developer decided to cancel it. There was no easy way to do this in our previous beta release, so you would have to wait until the build finished, which could be painful if you had a large project.

As always, please continue to provide your feedback on our forums as you use the Visual Studio plugin. All your feedback so far has been incredibly valuable in helping us understand the issues that cause you the biggest headaches.

Our BlackBerry 10 IDE has also not stood still, and we have a few important new developments to point out. We have added support for Apple’s OSX Mountain Lion so you should be able to develop with our IDE on OSX. Unfortunately, our installers are dependent on the Flexera Install Anywhere which does not fully support Mountain Lion as yet. In the meantime, you can still use the IDE on Mountain Lion but you will have to do a couple of simple workarounds after installation in order to create an icon and deploy the IDE — please see our release notes for details. We continue to be on top of this and once full support is provided in the Install Anywhere software, you will be able to install our IDE without the workarounds. We are also actively testing our Windows 8 version which is progressing to come out in the next release. In case you were not aware, you can view our roadmap information online on our developer site.

If you are actively using our Native SDK to develop BlackBerry 10 applications, I hope you are finding the development experience to be easy and seamless. If you still haven’t gotten your feet wet, I encourage you to do so. You can download our Native SDK and tooling from our developer website. Best of all, it’s free – you do not even need a device to test out your apps. You can just download our device simulator that you can use for developing and testing your apps just as you would on an actual device.

While these earlier betas offered significant improvements over previous editions, they were still a work in progress. We are finally at a stage where we can truly say that with Beta 3 of our Native SDK, our young child has finally come of age. Our APIs have evolved to a point where they are stable and functional enough to advertise backwards compatibility. We also support a full feature set of APIs in the Native SDK – from connectivity APIs such as email and calendar to APIs that support deeper integration such as invocation to social APIs such as BlackBerry® Messenger™ (BBM).

Beta 3 of the Native SDK contains numerous new and important APIs that many of you have been anxiously waiting for. Some of the highlights include:

Cards

If you attended some of our other conferences, the BlackBerry Jam 10 World Tour or BlackBerry Jam Sessions, you have probably heard us talk about the flow and deep integration that the BlackBerry 10 platform provides. The invocation framework provides a facility via cards through which you can incorporate some of this flow and integration in your app. With cards, you will be able to expose discrete functionality within your app to other apps as well as incorporate functionality provided by your other apps within your own. As an example, if you are developing a picture viewer app, you might expose a simple picture previewer card to the invocation framework. Any app that registers with the invocation framework can invoke your card to preview a picture. Likewise, your app can leverage existing cards on the platform to access various pieces of functionality, whether it is a simple preview of a video or other discrete functions like picking a contact or composing an email.

Visually, a card typically appears as a previewer that takes up most of the screen. However, it appears as part of the application on which it is stacked. Essentially, you can use a gesture to slide the card in, partially or fully into your app as seen in the picture below:

A Card is considered part of the application that invokes it and does not appear as a separate entity in the running applications grid. In addition, when the card’s function is complete, the user is automatically returned to its parent. In this way, a card “feels” like part of the application.

BBM Social Platform

BBM has always been core to the Blackberry platform and it still remains a critical piece of our BlackBerry 10 portfolio. The BBM Social Platform APIs allow you to leverage the social features and functionality of BlackBerry Messenger from within your app. For example, you can initiate a BBM chat and share files such as pictures, voice notes, and music between users who are running your app. You can also stream data between users of your app for real-time applications such as communication, gaming and location tracking. As part of the BBM social platform, you will be able to harness BBM features such as BBM user profile, contact list, messaging and application profile box.

Email, Calendar and Contacts

There is a significant amount of interest from our third party developers for Calendar, Email and Contact APIs, and we are excited to announce their availability in this beta. The Message Center is a signature feature of the BlackBerry experience, and we are adding support on the API side for it as well. The Message Center APIs provide the ability to launch the unified inbox, send emails and receive task notifications. You can use our calendar functionality to create new calendar events, edit existing events, delete existing events and view existing calendar events. We also have the ability to notify third parties when events are being created, modified and deleted. Finally, our contact API allows you to create, edit, delete and view contacts as well as add additional meta information to a contact.

Advertising

In this competitive world of app development, you likely care about creative ways in which you can make money off your apps and we want to help bring you the tools to do just this. After all, the success of our platform depends on your success. To facilitate that, we are adding an Advertising Service along with APIs that allow you to display banner and splash ads in your application or game. You can also create hot links to keyword advertising. Under the scenes, our Advertising service launches a Browser webview to display the advertisements. Along with our Payment and Scoreloop APIs that we introduced in earlier Betas, we believe that we have some powerful tools that can help you monetize your application.

Push

At RIM®, we are proud of our Push technology, and we are now making our powerful Push framework available through the NDK. Through the APIs we provide, your app will be able to register with the Push service and receive push data. When the Push service receives incoming Push messages, it will invoke the application registered for the message using the addressing information provided during the registration. Any app that needs to be responsive to incoming data streams should strongly consider taking a look at our Push framework and associated events.

…and many others

On the ‘Core Native’ front, we’ve introduced a Bluetooth® API which supports Bluetooth on/off, power status, and retrieving paired and found devices. It also provides several Bluetooth profiles such as Serial Port Profile (SPP), Bluetooth Low Energy (LE) and Generic Attribute Profile (GATT). Other core native APIs include APIs for Holster detection, retrieving application info and for querying Wi-Fi® and battery status.
Our spell check engine now exposes APIs at both the C and C++ layer to allow apps to perform spell check functionality in their own customized UI.

At the Cascades™ layer, we have introduced a WallPaper API that allows users to set an image as the wallpaper. We have also introduced APIs for sensors, including support for rotation, orientation, magnetometer, gyroscope and accelerometer. The geocoding API allows the user to perform geocoding and reverse geocoding while the radio info API includes the ability to query available radios, their status, ESN/IMSI, Sim card info, Mobile Country Code and Mobile Network code.

We hope you find enough content in this release to satisfy your needs. As we continue to evolve our platform, we intend to be as open and transparent with you about what’s coming down the pipe. I want to point you to our really cool-looking Native & Cascades flight boards where you can get an up-to-date status on our roadmap items. We have also added a section to our site that highlights the key features of our Core Native and Cascades frameworks. It should be useful for those of you who are trying to decide whether Core Native or Cascades is the right framework to use for developing your app.

As always, we want to continue to hear from you about your needs and receive feedback on our Native SDK.

The first fix addresses an issue with the Invocation API. The invocation framework does not launch the target on the simulator. For all practical purposes, this means that if you create an invocation target application and install it on the simulator, no app will be able to invoke it. This functionality does already works on the device, so if you are developing your BlackBerry 10 app on the BlackBerry 10 Dev Alpha testing device, you should be fine. But for all those developers who are using the simulator for development, we felt it was necessary to provide a fix to this as soon as we could.

The other noteworthy fix is with regards to the Notifications API. When you develop an app with the capability of posting notifications, it gets vibrate set to ON and Badge set to OFF by default in the Notification Settings. It should actually be the other way around – vibrate should be set to OFF and Badge should be set to ON by default. Oops, reminds me of something Dr. Nick would do.

Other than that, there are no new features included in this patch. If these fixes are not important to your development, you can continue to use the Beta 2 version of the BlackBerry 10 Native SDK that you currently have installed.

You can download the latest BlackBerry 10 Native SDK here.

At the C API layer, we have introduced some important new functionality such as the Invocation Framework API, NFC, Geocoding, Cryptography, Audio Manager, Slogger2 and Notifications Manager. As you can tell, the teams have been working hard since the release of Beta 1 to bring all this functionality to you.

Invocation

The invocation framework enables the delivery of invocations between end points. It describes how end points can be addressed, and provides a mechanism for registering and brokering event handlers such that invocation sources may be loosely coupled to the handler. The invocation framework provides an advanced brokering scheme that allows it to address many different service scenarios, and also to easily be extended to cover new cases.

Your app can register as either a source or a handler. A good example of a source app is an app that supports nested URI’s, and requires a URI handler to handle the URI request. Your app can leverage the invocation framework to broker and determine the best handler for this URI – the assumption here is that there are handlers registered for this on the system. Alternatively you can develop an app that registers as an invocation target – for example, an NFC handler that registers interest in certain NDEF tags. When the NFC service reads a tag, it will leverage the invocation framework to find the best fit handler for that tag and invoke your app. We also support the Invoke API at the Qt layer, so if you are developing a Cascades™-based app, you may want to use the Qt-based invoke API as opposed to the C-based API. We also have built-in support for invoking the Cascades Action Bar and Context Menu. This support is now integrated in our Cascades UI Framework. Please refer to the following Knowledge Base article for details on some known issues which will be addressed in an upcoming patch

NFC

NFC (Near Field Communications) is a short range protocol that is used for contactless communication between devices and tags. Our NFC API will support multiple NFC use cases such as Bluetooth®/Wi-Fi® pairing, NFC contact exchange, reading and writing tags, contactless payment and so on. The possibilities here are endless and I look forward to some really innovative NFC apps for BlackBerry 10 smartphones.

Cryptography

If you care about cryptography, you are in luck as we now expose our Certicom APIs for encryption and decryption of data streams. Those of you who have worked on our Java-based BlackBerry platforms might have some familiarity with what these APIs are capable of. They provide a whole slew of symmetric and asymmetric encryption algorithms such as AES, DES, RSA, ECIES and many more. Along with this, we provide various algorithms for key agreement and transport such as DH, ECDH, ECMQV, RSA, a variety of digital signatures, numerous SHA, MD and HMAC hash functions and random number generation.

Audio Manager

For developers working on apps with audio content, we have introduced a new audio manager API that provides audio concurrency services. The audio manager allows you to choose which microphone and speaker to use. It also provides APIs to get information about different microphones and speakers so if you need that degree of control this API should provide what you need.

Native SDK Logging with slogger2

With slogger2, the most important thing that you gain as a developer is speed. Slogger2 will have minimal system overhead and will be several times faster than the original slogger. Slogger2 will also log when interrupts are disabled, which might be of use to those hardcore low-level developers who require this type of capability. If you have code that uses the slogger APIs, don’t worry — we will continue to support it. Our slogger2 APIs will happily co-exist alongside the legacy slogger.

Notifications Manager

Some apps may want to send notifications to the user – for example, say an app that communicates with the cloud wants to inform the user when new data has been uploaded. The app can register with the notification service to send such a notification. We support simple LED notifications, sound and vibration, toast messages, dialogs, and Inbox notifications. Apps that want to leverage this service need to indicate this by specifying the post_notification action in their bar descriptor. The user will have the ability to customize the notification through the notification settings dialog.

Cascades Platform (C++) APIs

I’ve already used up so many words and haven’t even touched upon the C++ APIs yet! On the C++/Qt side of things, we’ve introduced a whole set of new APIs such as invocation API, Barcode processing, vibration control, copy and paste, and video capture (plus I already described the invoke API earlier). The C++ invoke API is similar in scope to the C layer API and is geared towards folks writing Cascades apps who would naturally be working with the Qt paradigm and would benefit from a Qt API.

Barcode Processing

Barcode Processing is a new API that was developed for encoding and decoding QR codes. While we’ve made the basic encoding and decoding functionality available to non -Cascades apps, the real interesting use cases would occur in conjunction with Cascades apps. The barcode-extended APIs in the Cascades namespace that will allow apps to create and display a barcode scanning control, which will in turn trigger the camera API to show a viewfinder surface as a Cascades foreign window. The app can then scan the QR code and use the provided APIs to encode it as a string and display it on screen.

In addition to this, you will also have APIs that allow your app to customize properties of the Viewfinder surface such as size and location.

Video and Camera

Speaking of camera, we now provide APIs to control camera settings and capture pictures within an application. This allows you to develop apps that interact with the camera, as well as ones that programmatically request a still image from the camera and start a video stream recording.

Location

For developers creating location-based apps, we have added a subset of the QtMobility location APIs. We have introduced APIs for querying current location such as latitude, longitude and altitude. We expect to continue to evolve this API in subsequent releases and plan to provide APIs for geocoding shortly. However, I should mention that we will likely not end up supporting the entire QtLocation API – certain functionality such as maps will be covered by Cascades-specific APIs in upcoming releases.

Vibration Control and Clipboard

Last but not least, we provide a C++ API for vibration control and a clipboard API, both of which are similar in scope to the C layer APIs we already provide. There have also been a myriad number of bug fixes, enhancements to existing APIs and optimizations, which are too many to list in this blog. The best way to explore all these changes is by downloading the NDK and taking a look at the headers, documentation and samples.

Tooling

On the tooling front, we’ve introduced some neat features such as invocation framework tooling, an option for faster bar deployment time, and pretty printing of objects in the debugger. More importantly, we also allow you to specify multiple icons and splash screens in your bar file. This is important for when we start releasing new devices based on the BlackBerry 10 platform, such as the BlackBerry® PlayBook™ tablet. To make it as easy as possible for you, Beta 2 of our IDE will allow you to package multiple icons and splash screens in your bar so that the bar can be deployed on multiple targets.

One of the challenges in writing a blog post like this is that there is a lot of content to present, and unfortunately I can’t do justice in describing all the functionality being released. My colleagues on the Developer Relations side and I are hoping to deep-dive into some of these technologies in dedicated blog posts that we plan to publish in the near future. Meanwhile, I hope this blog post provides at the very least a map of what’s available in Beta 2.

For more information, you should download our NDK on our website and take a look at the new headers. You can also navigate to our NDK documentation and API reference to get more information on each of the APIs. If you still aren’t satisfied, please do not hesitate to consult our developer forums if you have questions or need support. API requests and feedback about our APIs are also very much welcomed — if there is an API you need on our platform, we want to hear about it so we can help unblock you. Happy coding!

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!