I’m working on getting up to speed with the BlackBerry PlayBook. The best way to do this is to build some apps. For my first pass at this, I wanted to see how it would be to build apps with Flex Hero for both BlackBerry and Android at the same time. I figured it would be a good chance to get a feel for what multiscreen development really is like.
To start with I set up a few devices to test with:
- Nexus One
- Galaxy Tab
- PlayBook Emulator
This is my go-to application for trying out new things. It’s an approximate clock. If you’ve seen my “Holy Crap I’m a Mobile Developer” Series, then you’ve seen it before. It will tell you, for example, that it’s “Just after Ten” instead of “10:02.”
I like it because it is more than a Hello World, works with date/time formatting (which is usually just different enough between different systems to be annoying to learn), and it doesn’t have any external dependencies to start with like my other go-to learning app, the Twitter Search App.
That being said, I wanted to add a little pizzazz to this one:
- It has four states: dawn, day, dusk, and night
- There are transitions between the states
- It uses geolocation and a web service to get sunrise/sunset times
- It uses those times to set the correct state
As this is a pretty simple app consisting of just one screen, it was extremely simple. The only real challenge I had was laying out images. It works and looks acceptable on all three tested environments.
The simpler the application, the easier it is to handle multiscreen. This app has no input, and very few moving parts. Getting it to work on many screens in both landscape and portrait was very easy.
This may sound like I’m saying “AIR makes it easy to do multiscreen development.” I’m not; I’m saying “Multiscreen development is easy if your application does nothing.” The app I’m going to blog about next confirms that once you add actual interaction to your UIs it gets much tougher.
If you’re going to target both Android and BlackBerry Tablet OS with your application then Hero is the way to go. There’s no way to selectively swap in QNX for pieces here and there. If you want cross platform without writing for each platform you have to acknowledge that your app won’t look quite like a native BlackBerry application. It won’t quite look like a native Android Application either. There are certainly pros and cons to this.
- One code base for all of your target platforms
- Might be consciously or unconsciously confusing or troubling to the user.
- Might be jarring.
- Might look cheap, or somehow wrong.
There are certainly more pros and cons than this, but this is what really slaps me in the face. For me, there’s no question, the ability to write applications once and trivially tweak builds to get them onto other platforms outweighs the other issues. However, your mileage will vary. Your applications might need that extra performance, or abilities. I have not run into these as limitations yet, for my use cases the performance hit of AIR as an abstraction layer have been very overblown. That being said, I’m not writing a complex app for mobile devices.
But how complex should your mobile applications be? From my vantage point, with slower processors, and less user attention, mobile apps should do less than their desktop counterparts. Most of my experience with mobile apps tells me that my fellow developers agree. Which again is not to say you shouldn’t write complex applications, merely that the types of applications I am disposed to writing on mobile devices are simpler, and require less capabilities and performance.
Also visually, I think the Flex team is doing a good job making visually pleasing interfaces. For comparison, I hated Halo, and mildly like Spark. Hero’s mobile components are visually better than both, in my opinion.
Also as I have posted before, I learned how to publish both apk (Android) and bar (BlackBerry Tablet OS) versions of AIR applications at the same time.
AboutTimeHero on github
I can’t include the APK as it requires an as-of-now unreleased version of AIR.