Monday, May 27, 2013

To glass or not to glass.

So I attended Google IO 2012 and like many others, signed up to receive a Google glass.  I received the "your glass is available" email a few weeks ago and and have been sitting on the fence trying to make up my mind.  Apparently the offer isn't indefinite, as I just received a voicemail that I had until June 1st to get glass or forfeit my opportunity.

My original intent was to get the glass and try to build something really cool with it, just like I did when Android first hit the scene.  Unfortunately after looking into the mirror SDK and learning about the devices capabilities, I'm just not all that excited about developing for glass.  It seems like it's a glorified feed reader (timelines) that requires a web-api, and wasn't designed to run apps natively.  It's basically just a nice (useful) extension of your smartphone.

I've still got a dozen ideas for smart phone apps rattling around in my brain that I will never have time to build.  But with regards to glass, the best idea I've heard about from another developer was a shopping list app.  

As a consumer I'm excited about using a glass, but I'm not sure  that I want to pay $1500 for one.  I think it's going to be a fantastic way to do video conferencing, a navigation aid, an easy way to capture spontaneous videos/photos, to keep on top of important alerts ( incoming calls / emails / tweets / facebook posts / whatever).  All of this stuff is going to be very cool, but the infrastructure is already there, glass just presents another interface for it. 

Glass is going to make a lot of things we already do easier and more convenient. And  perhaps it will make some semi-good ideas just practical enough to become good ideas.  The innovation spurred by this hardware won't be driven by software, but by how people will discover interesting ways to use the device.

So to the title of my post, any comments?  Should I or shouldn't I, what would you do in my situation?  Keep in mind that while I can afford the $1500 pricetag, I don't consider it a trivial sum of money.  I look forward to any comments (hopefully I'll get a couple).

Friday, March 1, 2013

Encrypting string resources when using Android library projects.

When you're using an Android library project as the base code for multiple projects, it's handy to rely on resource overrides for configuration parameters.  For example, you could use a strings resource file that points to different URLS, etc.  While doing this is quite handy, you must also consider that resource files are very easy to extract using apktool, so if you are concerned about keeping any of this configuration data secure, you're going to have to take some extra precautions.

For a very basic obfuscation method you can just base64 the content and put it in a string resource.   I wouldn't recommend this alone, as any reasonably competent person can decode the string.  The nice thing about base64 is that it's output charset doesn't contain apostrophes or double-quotes (by design).  Because of this, base64 encoded data does not need to be escaped when used in a string resource.

For a better real-world scenario, let's assume that we have an application where we want to enable in-app billing, and to do so we need to be able to store the license key from our application in a reasonably secure fashion.  At the same time, we'd still like to leverage the convenience of resource overrides to store the license keys in our sub-projects that rely on a core android library project.

Our high level strategy will be to do the following.
  1. Encrypt our application license key (obtained via the Google Developer Console) using a hardcoded encryption key (think password).
  2. Base64 the encrypted 'cipher' text.
  3. Use this encrypted/base64 encoded value in our strings resource file.
Here's some sample code to help accomplish these tasks, just note that we will only use this code to generate our encrypted and base64 encoded license key before storing it in a resources file.  This is a one time activity.  And this should go without saying, but REMEMBER TO CHANGE THE VALUES IN keyBytes

Once you have the string encrypted/encoded as such and placed in your strings file, you simply need to decrypt it when needed.  Here's some example code :

Making it even more secure.

Since it's hard to get around hardcoding your secret key (the keyBytes in our sample code) using this strategy, it would be naive to assume this is 100% foolproof.  A persistent minded individual could still decompile your app, discover the byte array you used for encryption, and then reverse the entire process.  Your job is to make this as difficult as you can reasonably make it. You could store your key in multiple byte arrays and combine them when needed, for instance.  I won't go into specific methods here, but the point is to be creative. Using a code obfuscation tool such as proguard will help, or at the very least use non-obvious/misleading method names to perform these operations.

Wednesday, March 2, 2011

Google, please stop giving away hardware at your events!

I just read via engadget that Google is giving away Xoom tablets to attendees at the GDC. Originally, giving away free hardware was a great way to get devs to play around and build cool apps, but this cute gimmick has run it's course.  People now expect to get free hardware from Google, and since the value of the hardware tends to exceed the ticket price of the conference, everyone and their mother are signing up.

I had planned on going to Google IO this year, and was patiently waiting for registration to open.  I made the mistake of walking across the street to Panera for lunch with some co-workers, and by the time I got back registration had already opened and closed.  Who cares you say? Maybe I'm just bitter because I wasn't one of the lucky few that made it.

Sorry, but there is more too it than that, dev conferences are supposed to be for developers. It's a chance to learn new stuff and get some important networking done. The job I have now at TuneWiki, in fact, came from a random encounter I had during a lunch break at a previous Google IO.  Signing up for a Google IO event, should not be the online equivalent of going to Walmart on Black Friday.

   Yes, I'm also aware of the Google IO Pre-Sale VIP list, which supposedly was to give deserving developers a guaranteed spot at the conference.  Except that it failed, miserably, imo.  Using myself as an example, I attended the very first Android event on the Google campus.  I worked on two android projects that won top 10 placement in the first ADC (find someone else who can claim that).  I attended the first device readiness event before the G1 was released.  I sat front row at the G1 announcement press-conference as a special guest of T-mobile.  My current work efforts not only include TuneWiki, but also the media player that's baked into every motorola device (before US carriers replace it with their crapware).  Despite all this, I did not receive a VIP pre-sale invite.  And if I didn't get an invite, you can bet your ass there are plenty of other deserving developers who didn't either.

In short, Google, I am disappoint.

UPDATE: For the record, I already have stacks of android devices on my desk, including unreleased evaluation devices, so anyone who thinks that I'm butthurt over not getting a tablet is only re-enforcing my point. People are now assuming getting a device is the reason I want to go to these events.

Sunday, May 30, 2010

The limitations of AsyncTask

AsyncTask is a fine API, it's been said that it "holds your hand", and makes performing background operations painless. It pulls this off so well in fact, that I see people overusing it in situations where it's not really appropriate.

It's particularly unsuited for situations when you have a multiple tasks to perform concurrently. Imagine an Activity that needs to download about 30 small images from a remote server, and update the UI as these become available. AsyncTask uses a static internal work queue with a hard-coded limit of 10 elements. That means if you were to create an AsyncTask instance for each image, the work queue would quickly overflow and many of your tasks would get rejected. The best solution in this case is to create your own ThreadPoolExecutor instance that uses a queue that's large enough to hold all your tasks, if you need an unbounded queue, a LinkedBlockingQueue will work just fine.

Another severe limitation is that an AsyncTask can't survive your Activity being torn down and recreated on the other side.  Even if you pass it to the new instance via onRetainNonConfigurationState, the internal Handler inside the AsyncTask is still going to be stale and it's not going to behave correctly.  This is important to consider, and the Android documentation makes no mention of it all.  I've already blogged this scenario in detail, so I won't flog a dead horse here.

There are a few other minor issues, such as the fact that you can't change the background threads execution priority. It's hard-coded to a low priority, which granted, is the sensible default.  Also, exception handling is not very well supported.

So just to reiterate, AsyncTask is a nice API, but you should understand it's limitations and apply it appropriately.  If you're serious about writing mobile apps, then you're going to need a few more tools in the toolbox to get the job done.

Saturday, May 22, 2010

Android 2.2 Highlights, A developer's perspective

Android 2.2 is the most significant upgrade to the Android OS that I can remember. Chock full of new goodies for both users and developers.

I thought I'd just do a quickie post to highlight the features for developers I'm most interested in.

1) Android Cloud to Device Messaging - this is one feature that's been sorely lacking from the Android platform and it's a welcomed addition. The demo at Google IO demonstrated how you can push a message to a device in real time, and have it fire off an Intent which can kick off any number of interesting and yet to be dreamed of services. This also opens up a new way for devices to communicate with each other in real time over the internet, I expect interesting things to come of this.

2) Android Application Error Reports - logging exceptions remotely that occur on a users device is a very useful thing and every mobile company I've worked at has done this in some form or another. The typically way to do it is to override the default exception handler and replace it with something that will log the exception. I myself just started building a new  GAE project for this a few weeks ago The initial usefulness of this will be somewhat limited, due to the fact that many devices are going to be running older versions of android for the foreseeable future.

3) Stagefright media framework - I don't know much about Stagefright, I'll admit that right off the bat, what I do know is that I'm dreadfully tired with the limitations of the current MediaPlayer framework, and I'm really hopeful this can serve as an improvement / replacement for the API's we've been using up til now.

And lastly, I'd also like to mention the new support for Android Library Projects that are available in the newest SDK tools (SDK Tools r6). We will finally be able to share common resources between multiple projects, and since it's just build time magic, these new library projects are going to be backwards compatible with older platform versions.

Wrapping up, I'm really excited about android 2.2.  Google has really raised the bar with this release, and it's going to be interesting to see how other mobile technologies evolve in response to this.

Wednesday, March 31, 2010

A Simple ProgressBar Tutorial

I came across another ProgressBar tutorial a few days back posted on, and while it's certainly good enough to get someone started, it doesn't really go into any detail about how your non-ui thread should work, and how it should gracefully handle Activity restarts and what not. It uses a message handler to send notifications to the ui thread, but what if the Activity is paused and the message handler becomes stale?

So I'm taking this as a good opportunity to follow up on my previous Rebel Without A Context post.

The code is fairly short, so I won't go into a line-by-line explanation of it, but the general idea is that you have your own Thread implementation that maintains state, and you pass it from the old activity to the new activity via onRetainNonConfigurationInstance(). Also rather than updating the UI directly by sending a message from the background thread, the UI thread actively polls the background thread every 50 milliseconds with a handler loop, which updates the progress bar as necessary.

With this kind of approach, you can for example, flip orientations back and forth gracefully with no stale handlers or leaky window exceptions.

Saturday, March 20, 2010

HTTP Connections revisited

In a previous post entitled, HTTP connection reuse in android, I tossed out a code snippet for an HttpClientFactory that would spit out a DefaulHttpClient implementation suitably configured for re-using already open HTTP connections to serve multiple requests across multiple threads.

My hasty implementation from that post leaves a few things to be desired. Primarily, it's a singleton implementation which can lead to some problems. Since it's effectively a global resource, doing things like modifying the time out value, or forcibly closing the connection manager (as one commenter pointed out), could lead to the HttpClient to be in an invalid or undesired state when reused at a different time or a different part of your application.

So here's a simplified version without the singleton garbage:

The ideal place to use something like this is when you want to download multiple items from a single remote source, for example, if I needed to download a bunch of thumbnails to be displayed in a ListView, I could have a thread pool downloading images concurrently and all sharing this one HttpClient instance, reusing HTTP connections as they became available (all managed inside the HttpClient)