The latest BlackBerry® 10 Beta SDKs are now available for download! They bring a whole lot more functionality, along with a software upgrade for the BlackBerry 10 Dev Alpha testing device for those who have received one at our BlackBerry Jam World Tour events or BlackBerry 10 Jam in Orlando this past May. This new device update now includes the BlackBerry App World™ storefront client application (the same version that is on the BlackBerry® PlayBook™ tablet). Yes, this means you can start to submit your BlackBerry 10 applications to BlackBerry App World and share it with fellow BlackBerry 10 developers to get early feedback.

So what’s next?

To keep the ball rolling for our developer community, we’ve scheduled a series of tooling and SDK releases that will be rolled out over the next few months. Each runtime (Native, HTML5, Adobe® AIR®, and Android™) will have incremental updates to functionality. Each runtime’s functionality won’t necessarily be in sync, as they each have different developer audiences where APIs are prioritized based on what each of these communities are asking for.

Each release is named Rn where R stands for “Release” and n stands for “number”. So for the first BlackBerry 10 Dev Alpha release, the SDK was R4 to match with 10.0.4.xyz version. We also sometimes do internal-only releases, which is why you’ll see some numbers skipped.

The BlackBerry 10 SDK Beta schedule looks like the following:

• R4: May SDK Beta Release (first beta)
• R6: July SDK Beta Release (just launched)
• R8: September SDK Beta Release (API Freeze, Binary Compatible with Gold)
• R9: October SDK Beta Release (bug fixes)
• R10: November Gold SDK Release (bug fixes)

But what’s coming in these releases?

We’re going to step out of the box and do something that we’ve never done before and quite frankly, something that I’ve rarely seen any tech company do in this industry. We’re going to share with you our feature release plan for each of the runtimes. We’ll be providing a list the top level line item deliverables — but not getting into the details of each feature, or else the list will turn into something as long as a DVD’s extended director’s-cut limited edition!

The beta roadmaps will be posted in the form of flight arrival boards so that you can see the feature, the flight/release it is on, the scheduled arrival time and the current status. These roadmaps should be available in a couple of weeks.

Now I’m going to give the usual disclaimer: These are “targets” and the usual laws of software delivery apply around priorities, dependencies and customer issue firefighting that can impact delivery schedules and scope. We’re being transparent as we can with you, our developer community, to help you better plan your app development leading up to the BlackBerry 10 launch. We want to ensure that we are releasing updates to the SDKs as frequently as possible leading up to gold. Once you have finished digesting and implementing what has been made available in one Beta update, there will be another one waiting for you with more goodies.

Reason #1: Touch isn’t supported in that OS

When the BlackBerry® Storm™ 9530 smartphone launched with OS 4.7, it was necessary to have a special touch-only version compiled against OS 4.7 in order to take full advantage of the touch functionality. If you were using the standard BlackBerry UI components, an app compiled for an older OS would probably work fine – but if you wanted to actually capture and use touch events, those methods didn’t even exist until OS 4.7. In this case, not only did it make sense to have a separate touch-only version optimized for the BlackBerry Storm smartphone, it was really the only way to go.

Fast forward a few years, and devices running BlackBerry® Device Software 5.0 and higher are 93% of the market share worldwide for free apps. With paid apps, it’s up to 97%! Since the touch APIs are present in newer OS versions regardless of whether the device supports touch or not, any app compiled for BlackBerry Device Software version 5.0+ (or really 4.7+) can be made touch-aware.

Reason #2: Touch isn’t supported in that form factor

Regardless of if it was even possible to make an app touch aware when targeting OS 4.7+, for a while the BlackBerry® Storm™ smartphones and BlackBerry® Storm2™ smartphones were our only touch-enabled devices. They had a totally different form factor and no trackpad. It made a lot of sense to have a separate version of your app to target those devices. Even with the BlackBerry® Torch™ 9800 smartphone, it was likely just a matter of adding trackpad navigation to your BlackBerry Storm build.

But now with the BlackBerry® Bold™ 9900 and 9790 smartphones, builds targeting the standard 4:3 aspect ratio/full QWERTY form factor need to be touch-aware too. Make that touch aware but not reliant, and now you don’t need a non-touch build.

Reason #3: I want to optimize my UI for Touch-only devices

This is good. The fact is, devices like the BlackBerry® Curve™ 9380 smartphone and BlackBerry Torch family of smartphones have lots of screen real estate in order for you to make buttons nice and big. It’s totally reasonable to have a different UI for those devices compared to something like the BlackBerry Bold 9900 smartphone, where the user might only want to use touch for certain things.
Do you really need a separate build to do it though? Maybe, but it will be easier in the end if you can avoid or minimize that. For example, if you check the VirtualKeyboard.isSupported() method, a return of true would indicate one of the long, touch-based form factors.

What might get you though are resources. If you have different ones you want to deploy to different aspect ratios and you don’t want to just include them all, your only choices are: a) separate builds, or b) downloading them at runtime. Either way, it doesn’t leave much room for a non-touch version.

Deploying to Touch Only

In answer to the original question, unlike GPS, you can’t determine whether or not a device is touch capable in an ALX file. But as I’ve said, I don’t think there is much point. What you can do is use the KeyboardType property, similar to how you’d use the VirtualKeyBoard.isSupported() method in Java™. If it’s “Virtual” or “QWERTYVirtual” (for the sliders), then you can give it that special build with the different resources. But touch itself is easy to implement and present on many devices, so you may as well take advantage of it.

Got questions about implementing touchscreen functionality? Let me know in the comments.