Bitcoins are currently being traded at Bitcoin exchanges, like MtGox and others. Because the phenomenon is relatively new, the exchange rates can fluctuate fast and heavily (e.g. from 13 USD to 30 USD over a couple of days, as happened in beginning of June). This creates a demand for rapid information, as traders need to make decisions based on accurate and valid information.

This demand has spawned the creation of a handful of Android applications and widgets for the Android platform, informing users of current BTC exchange index values. However, all of the available apps rely on polling for information. While this is easy to implement it requires the application to run in the background, or use of the Android AlarmManager API. This basically wakens the phone (Android devices enter a state called "deep sleep" to preserve battery power) e.g every 30 minutes, polls for the current BTC index, and presents it to the user. This approach is sub-optimal however, as it both drains battery and may present information which is up to 30 minutes delayed. The obvious approach is a true push-based approach, and for my weekend projcect, I made an app utilizing Google's "Android Cloud 2 Device Messaging API" (AC2DM or C2DM).

To test the Android application: https://market.android.com/details?id=no.skjervold

By removing the burden of polling a BTC exchange from the device and placing it on a third party server, a battery power consumption vs Information delay compromise was avoided. My web server can poll the exchange as often as I'd like (e.g every 10 seconds). I decided to go with the folling experimental and unusual software stack for my project:

-A web application using ASP.NET -HTML, JavaScript and CSS -DB4O for persistance (Object Oriented Database) -IIS (Internet Information Services) hosting environment -A thin Android client wrapping the web application

Since I was going to need a web server anyhow, I thought why not make the application a web application, presented inside a thin Android application? By making the real Android app very thin, I could place all business logic in the web app, allowing me to make updates and feature add-ons without re-deploying to Android Market, -instead I would simply re-deploy my web application. Additionally, I could design the UI using HTML, JavaScript and CSS, which allowed me to reuse existing know-how (and VisualStudio 2010), avoiding delving into the unfamiliar Android UI API. Initially, I was worried about the communication between the thin Android client and the web app. Fortunately, and I really love Google for implementing this feature, the Android WebView offers the "addJavascriptInterface()"-method, allowing me to create and specify an object that effectively bridges the web app's javascript and the Android app's Java code. This enabled me to make calls from the web app into the Android app, by creating javacript on the server side, which was then run inside the Android Webview, and finally handled by the Android app itself. While this can be used for web app to Android communication, I couldn't use this for push functionality, since the Android app would need to run in the background draining the battery. For true push based notifications, I used Google's Android Cloud 2 Device Messaging API (C2DM).

Integrating an .NET Ajax web application and an Android app with Google's C2DM wasn't trivial, and took a lot of experimentation, trial and error, and web searching. The first and easiest part was making the Android app register with google servers to receive noticiation messages. This required some special permissions in the AndroidManifest.xml file, -

<permission android:name="no.skjervold.permission.C2D_MESSAGE" android:protectionLevel="signature" /> uses-permission android:name="no.skjervold.permission.C2D_MESSAGE" />

To register for notifications, the Android app then had to create an intent (com.google.android.c2dm.intent.REGISTER-intent), and a BroadcastReceiver had to be created to receive the registration ID. Upon receiving the registration ID, the Android app would now send it to my own web server (construcing a HttpGET), pairing it with a custom application ID, which I would then store in a database (DB4O).

The next step would be to make my web application Authenticate with Google's C2DM server. Google requires a two-step authentication process, where my web app makes a request, receives a special token, and then creates another request including this token. This can be a little tricky, and doing it from .NET probably made it a bit harder. The fact that Google requires SSL-connections resulted in issues connecting from .NET, which was finally solved with a hack requiring me to create my own System.Net.ICertificatePolicy, which basically overrides the CheckValidationResult()-method, always returning true. Once authenticated, my application would access my database, retrieve notification subcriptions and determine their C2DM registration IDs and the users' specified BTC index threshold values, and send notifications via Google's notification servers.

The result was an Anroid application downloadable from Android Market, allowing users to specify high and low BTC index values, and showing status bar notifications on Android devics only seconds after the index changes. No polling or background running required.

The application can be downloaded here for free: https://market.android.com/details?id=no.skjervold

The technology stack I chose seemed to work quite well, and the merger between a native Android app and a web application is surprisingly smooth. And this makes me wonder: Are application store specific technologies really the best way forward for mobile device applications? With the emergence of HTML5 and CSS3, wouldn't it be a lot cooler if I could create a web application that could run on both Android, IOS, WhinPhone and Blackberry systems? As of today, sure, one would only need to create a thin device client wrapper application to indeed run my app on all platforms, but with HTML5's support for local storage and stuff, this could probably be avoided all together. If device-specific API's was made accessible for the different platforms, web applicastions could access OS specific resources, such as status bar notifications. While HTML5 might not provide all the functionality needed to this, device OS providers could provide interfaces between OS resources and javascript, as Google has done with its Android WebView, effectively bridging web apps and device resources.

While I believe this approach would be great for both developers and consumers, less open device OS makers (I'm not going to name names here), probably don't want this to happen. I suspect that they want full control of their application stores and what's run on their platforms. Let's hope I'm wrong, and that the OS makers come to their senses in the future :)

Dr. Heisenberg