Why I'm not using Android Market in-app billing

From a developer's standpoint, Android Market's in-app billing service is not that fun to use. It really doesn't give me any feeling of a well-designed API, like I've gotten from Twilio, and Stripe more recently. The whole in-app billing implementation pushes a lot more responsibility onto the app developer for what appears to be little gain.

The one benefit that I can see is that people will get to use Google Checkout without the extra login step. Android Market managed purchases are essentially useless in their current form, since the app developer has to store redundant info anyway in the case of doing content distribution.

Here are the reasons why it does make sense to have the app developer implement most of the in-app billing:

1. Security. One recurring theme in the in-app billing documentation is that for security, the developer should do things like implement a remote server, and rewrite the sample code so it's tougher to reverse-engineer.
2. Managed purchases. The way Android Market in-app billing works with managed purchases, is that it keeps track of a boolean yes/no whether you've bought a given product. However there is no mechanism to restrict content distribution from a remote server, so in that case it makes sense to have the app developer implement that piece.
3. Identifying the user. It's difficult to know anything about the user of an Android device, or any identifying features of the device itself, which is why in-app billing requires a Google account, via Android Market. If you want to do anything more sophisticated than just finding out if the user has paid, such as anything surrounding content distribution, then it's up to you as the app developer to come up with some identity management scheme. I.e., have a separate login, since Android Market isn't about to tell you the user's email.

As you can see, it all ties back in with security. It's great that the documentation suggests several best practices for billing, but Google didn't really go far enough this time to make things easy on the developer.

Things that would make the Android Market in-app billing API nicer:

1. A service to deliver content. (Maybe they don't have the infrastructure or business strategy for this service right now, in the context of Android Market at least.)
2. An online (non-cached) mode, letting the app developer require Internet connectivity to use a feature.
3. A way to create and distribute encryption keys. I'd love for Android Market to have a way to make callbacks to our web servers and help distribute encryption keys or other sensitive info, without unnaturally routing that info through the client app and then to our remote server.
4. Giving us unique identifiers for users. This would save a lot of trouble and help with many apps that wouldn't normally require accounts, but only need some identifier to make sure the user has paid.
5. Allowing more flexible payment models, like variable prices (good for donations) and managing numeric quantities of items (with an optional max limit) instead of just a boolean yes/no whether the user has purchased it before.

I'm sure Android Market in-app billing will evolve more in the future, but it's a shame that the initial release is so feature-constrained and not-nice for developers. It's because of the shortcomings described in this post--plus the fact that Android Market payments of course requires Android Market and therefore doesn't reach nearly the entire ecosystem of Android devices--that I may go with Paypal Mobile Payments as the main payment method for my next project.

First Impressions: Sencha Touch is faster than jQuery Mobile

Sencha Touch I have found to be a pretty sweet cross-browser HTML5 solution for building web apps. I was  looking for a good library to go along with PhoneGap.

At first I looked at jQuery Mobile 1.0rc1, but after checking out the examples on my phone, decided it's broken on Android. Specifically I have a Motorola Droid 1 running stock Android 2.2.2, and the examples ran quite choppily, with CSS page transition effects pretty much completely busted--I guess because they are relying on hardware accelerated CSS on newer phone models.

But even navigating the jQuery Mobile documentation site, which is naturally written with jQuery Mobile, showed some bugginess where the loading dialog would show off-center, the back button would flash the wrong page before finalizing the transition (a side effect of the broken CSS transitions, I guess), and just overall slowness. They even made some basic performance mistakes like binding to the "click" event instead of the "touchstart" event, adding some slowness--see this informative post from March 2011.

The Sencha Touch demos proved to be quite a lot snappier and look quite pretty. The button clicks are very responsive. I was impressed with the speed of the drag and drop, although there was a tiny bit of bugginess where the color might change differently depending if I drag quickly or slowly. In any case I'm pretty convinced  that Sencha Touch meets my needs for many use cases for current generation mobile devices. jQuery Mobile might serve me better in the future, when they speed up the library's performance or if I ever decide to cater to a small set of fast devices.

For some more opinions, check out this stackoverflow page: http://stackoverflow.com/questions/4066167/sencha-touch-or-jquery-mobile.

Android Market: Application Licensing vs In-app Billing

Licensing is the new way of doing Android Market copy protection. It requires the device to have the Android Market app, and the app must be associated to a Google account. The app that is licensed must be a paid app; free applications are considered licensed to all users. A down side is that many devices that are not licensed to use the official Google android apps won't be compatible with the licensing code. http://developer.android.com/guide/publishing/licensing.html

In-app purchases are also tied to Android Market. Here you are still locked down to the official Android Market app, but your application does not need to be a paid one, according to http://developer.android.com/guide/market/billing/billing_overview.html#billing-limitations. This is cool in that you can release an application for free, then charge for extra content.