BlackBerry 10 Native SDK – Racing to the Finish Line

Native SDK Development

In my previous blog post, I talked about how the BlackBerry 10 Native SDK had finally come of age, and how we had released a whole set of important APIs in Beta3 that was launched in September. The notable ones in our last release included Email, Calendar, BBM, Cards, Advertising, Push, Bluetooth and several others. I had a chance to meet with many of our developers at the BlackBerry® Jam Americas conference in September and there was quite a bit of excitement about all the new APIs and tooling features we had added in.

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.

Join the conversation

Show comments Hide comments
+ -