I have for some reason been acquiring touch screen devices like they were ukuleles.
I have been wanting to do a very brief comparison. They are listed below in the order they're depicted above. I do not actually own the iPad.
|Apple iPad 2||Google Nexus 7||BlackBerry PlayBook||Motorola Droid RAZR MAXX||HTC Droid Incredible|
|Currently installed OS||Apple iOS 5.1.1||Google Android 4.1.1||BlackBerry Tablet OS 220.127.116.118||Verizon Android 4.0.4||Cyanogenmod Android 2.3.7|
|Acceptable battery life||x||x||x||x||x|
|Home screen rotates||x||x||x|
|Physical buttons||Power, Volume, Home, Rotate/Mute Switch||Power, Volume||Power, Volume, Play/Pause||Power, Volume||Power, Volume, Home|
|Official means of developing for it are free||x||x||x||x|
|Best thing||Lauren likes DragonVale.||Running ScummVM.||Easily closing apps.||4G LTE.||GPS data logging.|
|Worst thing||Having to scroll to the top of my inbox.||Too big to fit in my pocket.||Finicky power button.||An OS release behind.||Home button lights don't turn off, even when watching videos.|
That's about it.
I have two free apps in the BlackBerry app world for BlackBerry PlayBooks, now:
"Ukulele Chords" was just posted today. I applied what little music theory I learned from my previous ukulele chord webapp to what little I could learn in a day about QML.
I added both to my project list.
Several months ago, a coworker alerted me to a promotion Research in Motion was having. I believe the original description was essentially, "port an Android app to BlackBerry and receive a free PlayBook tablet." I spent about a day setting up the development environment and configuring Winter Simulator to run on the PlayBook simulator and submitted it for approval. My app was approved quickly, but I had basically given up on the promotion until about a month later, when I received the request for a shipping address which preceded me receiving free hardware.
There are two particular points I find interesting that I want to explore here. BlackBerry development is sort of in an unfortunate transitional state right now, but it looks as though it is quickly improving. Qt Quick, which is the foundation for BlackBerry's Cascades, seems fantastic.
The State of BlackBerry Development
The following is all based on my personal experience in going from zero knowledge of what BlackBerry development is like to picking a path and releasing a few apps. Things are changing quickly, and that is part of the point.
There Are Many Options
The BlackBerry development site highlights choice, in big letters, right up front. My assessment of the choices follows.
- C/C++ Native SDK
- This is how I ported Winter Simulator. The C API I assume is adopted from previous BlackBerry platforms. This is entirely adequate except for the fact that it provides no facilities for UI. It is delightful to, unlike on Android or iOS, write a simple C program without any surprises.
- C++/Qt Cascades
- More on Cascades below. This looks like a great approach to UI, but it's not ready to be used until BB10 is released.
- HTML5 WebWorks
- In combination with something like Apache Cordova, this seems like the best bet for actually making cross-platform iOS+Android+BlackBerry UI-heavy applications. I have CSS nightmares and so I shied away from it.
- ActionScript Adobe AIR
- I don't know anything about this and don't really care.
- Java Android Runtime
- The BlackBerry tablet OS includes a runtime for Java Android applications. Many applications can run after just being repackaged. At the time, I only had native applications which this doesn't support. Applications run this way currently run in a shell application which makes them appear slightly as second-class citizens, but the next OS release will apparently improve this situation.
- This isn't really documented, but the bbndk includes a script for packaging python scripts as applications. I didn't try more than a "hello world" application, but with the appropriate wrappers, either of BlackBerry's C API or Qt, this would be wonderful.
- Qt already includes BlackBerry support. I tried making a C++ Qt PlayBook application, but it seemed like it would take substantial work to make it look and feel right on a tablet.
- If you're making a game, use the native SDK.
- If you're making a UI-heavy application, either use WebWorks or wait for BB10.
- If you already have Android applications, why haven't you already repackaged and published them?
I ended up using QML in Qt, and it make me excited for Cascades. I think the main downside is that I've had to include the Qt libs, which amount to 36M, while my application is honestly just a few k of QML. When BB10 is released, I expect I will be able to convert and republish my app, and its size will shrink appropriately.
A few months ago I wrote my first real pyqt application, for work, mostly on a whim. It's all procedural code, because that's how I knew to make and manage UI, and I was already embracing enough risk by using Python, Qt, and writing the app I was writing. The first time I got frustrated with the mess I was making, I started to look at my options, got confused, and decided it was correct to return to the path I was taking.
It seems Qt presents three options.
- Generate UI in code
- It's really not a bad option. For simple UI, I like having things in one place, where "things" include UI layout, declarations and appearance of widgets, application logic, and event handling. This only becomes a mess if there are a lot of things.
- Qt Designer
- This looks like a great WYSIWYG GUI editor. I didn't see the need for that at the time, so I skipped it. I may go back and convert some UIs to encourage other people to meddle with them visually.
- Qt Quick
- This appears to be intended for mobile UIs. The most concrete indication of this is that it lacks standard widgets.
When I wanted to make a UI-heavy BlackBerry application, I tried out Qt Quick.
I found that the answer to my first concern, that there are no standard widgets, is mitigated several ways:
- BlackBerry provides standard widgets in Cascades.
- Many mobile applications prefer to use their own widgets. This annoys me, but it is the way things are.
- Qt Quick provides enough to create basic widget types without too much hassle. Scrolling lists are a fundamental type.
A few more thoughts:
- QML is a declarative language. More things should be declarative. I don't know how put this plainly. It is the Right WayTM.
- QML is part of Qt. Qt signals, types, and the ability to interact seamlessly with C++ code seal the deal.
Much to my surprise, I ended up writing my whole application in QML, rather than following my original plan of writing most of the logic in C++ and only presenting the UI in Qt Quick.
So All Is Great?
Well, Research in Motion has to find a way to be relevant again, but I like their development tools. :)