Android Mobiles

There’s this little bookstore, up around Seattle, called Amazon.com. You might have heard of them. They sell an ebook reader called the Kindle, now in its second generation. Now, the Kindle is turning into a mobile platform, with the introduction of “active content”, complete with an SDK and “app store”. Here’s my take on what they are offering. Note that this is based solely on materials presently available at public URLs, as I have not yet elected to agree to the beta terms and conditions.

From a programming standpoint, the Kindle embeds JavaME, specifically the Personal Basis Profile. Hence, instead of Android widgets, you’re using AWT for containers and drawing and some Kindle-specific widgets, like KButton and KTextField. However, it is still Java from a programming language standpoint, a plus for Android developers looking to dip their toes in the Kindly waters.

The equivalent of an Android activity is the “kindlet”. It is unclear if the Kindle will support any sort of multiprocessing (e.g., playing music while the user reads), but preliminary indications suggest it will not. Notably, you cannot keep your “kindlet” running while the device is idle (screensaver mode) or when the Kindle is mounted as a USB device.

Also, bear in mind that the Kindle is not a touch-screen device. Instead, you use what amounts to a D-pad to navigate. It also has a fairly slow screen refresh rate, courtesy of e-ink technology. The combination of these means fast-twitch games (e.g., first-person shooters) seem unlikely apps for Kindle. Displays are also monochrome, with only a few shades of gray. However, the Kindle does sport a QWERTY keyboard.

The SDK comes with simulators for both sizes of Kindle, supported on Linux, OS X, and Windows. You can also associate up to three real Kindles as test devices — apparently, these are then also eligible for you to use for testing applications.

Once we get out of the realm of programming and into the realm of the “app store”, though, things start to radically depart from the Android model.

It would appear the only way to deliver “active content” to the Kindle is through Amazon.com. This is not surprising, considering it follows the iPhone App Store model and fits with Amazon’s strong preference for you to get your Kindle books through Amazon.com. Also, like the iPhone App Store, Amazon must approve all applications (“We recommend that you test your application on a Kindle before submitting it to us for approval.”). Their current terms notably prevent one from creating a VOIP app, an alternative reader (e.g., for EPUB), or display advertising.

Applications will be protected by Amazon’s DRM system. Since this was broken some time ago for ebooks, it will be interesting to see how long this lasts, and whether people are able to “root” or “jailbreak” their Kindles for use with apps distributed outside Amazon with removed DRM.

Their “active content” pricing rules are…interesting. Developers get a 70/30 split (less a 15-cent delivery fee), much like the Android Market and iPhone App Store. However, your choice of pricing model depends on how much bandwidth you consume. Kindle users get free 3G service (Whispernet), and Amazon clearly does not want to bankroll ridiculous bandwidth charges. Hence, you can only distribute an app for free if it is smaller than 1MB to begin with and uses less than 100KB/user/month. If you want to offer a one-time charge (a la Android Market and iPhone App Store), you can, and you can then have a larger app (10MB for Whispernet, 100MB for USB-based installation), but you still are subject to the 100KB/user/month bandwidth budget. If you want more bandwidth, it appears you have to charge a monthly fee, and it is unclear what bandwidth limits you are subject to under that model.

Perhaps the biggest thing that the Kindle has going for it is the possibility of a “land rush”. Many Kindles have sold, though Amazon has been mum on actual figures. Some estimates peg it at around 1.5 million as of the end of 2009, though many of those were first-generation Kindles that will not support active content. The iPhone app land rush was caused by many more iPhones, and it is unclear how popular “active content” will be among Kindle users. However, the Kindle is popular enough that there may be first-mover opportunities to make some money, if you have an app that is small, has modest bandwidth requirements, fits the display and user input constraints of the device, and might prove popular among Kindle users.

Android already dwarfs Kindle’s market size, and Android would appear to have a far better growth curve. Hence, Android is a better bet overall, if you are not in position to support too many platforms. But, Kindle will still have its share of winners, and since it is Java-based, Android developers may want to check it out.

The One From the Stack series will highlight some interesting questions and answers from StackOverflow’s #android tag, a fine place to get your Android application development questions answered.

Today’s one from the Stack is from a developer trying to figure out how to attain a look and feel similar to one that is already in Android. In this case, the poster is looking for the gray box behind the Done and Revert buttons in the Edit Contact activity in the built-in “Dialtacts” application.

If you poke through the source code, you would eventually stumble upon this layout file, showing that the button bar has a style=”@android:style/ButtonBar”. Tugging on that thread via Google Code Search will give you this styles.xml snippet, indicating that the background for that style is @android:drawable/bottom_bar.

At this point, you can turn to your local SDK. All resources are stored in $SDK/platforms/$PLATFORM/data/res, where $SDK is wherever you installed your SDK and $PLATFORM is the specific Android version you are interested in (e.g., android-2.1). If you go in there, you will see that bottom_bar refers to a pair of PNG files, one in data/res/drawable-hdpi and one in data/res/drawable-mdpi.

You might be tempted to just plop the same style or background image reference in your own code. While simple, this leads to somewhat fragile code, as you are now dependent upon things that are not truly part of the SDK. Part of the reason for making all these resources available to you in your SDK installation is so you can copy them into your project, so you are now independent of any changes Android makes to its names or looks of these images.

Note that the answer I provided on the question itself is a bit off. I thought that hierarchyviewer would be another possibility, rather than poking through the source code. Unfortunately, I didn’t think that all of the way through — hierarchyviewer does not report background resource values.

The One From the Stack series will highlight some interesting questions and answers from StackOverflow’s #android tag, a fine place to get your Android application development questions answered.

Today’s one from the Stack is from a developer trying to figure out how to attain a look and feel similar to one that is already in Android. In this case, the poster is looking for the gray box behind the Done and Revert buttons in the Edit Contact activity in the built-in “Dialtacts” application.

If you poke through the source code, you would eventually stumble upon this layout file, showing that the button bar has a style=”@android:style/ButtonBar”. Tugging on that thread via Google Code Search will give you this styles.xml snippet, indicating that the background for that style is @android:drawable/bottom_bar.

At this point, you can turn to your local SDK. All resources are stored in $SDK/platforms/$PLATFORM/data/res, where $SDK is wherever you installed your SDK and $PLATFORM is the specific Android version you are interested in (e.g., android-2.1). If you go in there, you will see that bottom_bar refers to a pair of PNG files, one in data/res/drawable-hdpi and one in data/res/drawable-mdpi.

You might be tempted to just plop the same style or background image reference in your own code. While simple, this leads to somewhat fragile code, as you are now dependent upon things that are not truly part of the SDK. Part of the reason for making all these resources available to you in your SDK installation is so you can copy them into your project, so you are now independent of any changes Android makes to its names or looks of these images.

Note that the answer I provided on the question itself is a bit off. I thought that hierarchyviewer would be another possibility, rather than poking through the source code. Unfortunately, I didn’t think that all of the way through — hierarchyviewer does not report background resource values.

It seems that Mozilla has begun work in earnest on building Firefox for the Android platform.  Citing sources from the German Firefox community, Softpedia says that Mozilla is working with developers to make a build available that will at least display webpages in February, with a usable Alpha coming months down the road from that.

This is great news for those Android users looking for the Firefox experience on the their handsets. With Mozilla announcing in late 2009 that they were considering moving towards the Android OS, it appears they are going make good on that statement.

It is safe to say however that we will not see something usable for most likely another 6 months if there are any development delays (and there always are).  Still, the idea that there is a Firefox Browser build in the pipes coming our way is exciting and something to look forward to!

If you want to track the progress of the Android flavor of Firefox, and you can read German, check out the Firefox forums by clicking here.