Recently I was asked how a developer can use an ALX file to make sure that the touch-aware version of their app only gets deployed on touchscreen devices. It occurred to me that a lot of apps are still set up with separate touch and non-touch builds. Certainly there have been good reasons to do that in the past – but is it still the case today? Let’s take a look at some of the past reasons why a developer might have set up separate builds, and explain why a separate approach isn’t necessary today.
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.