/home/jeff/blog

Archive for September, 2009

I’ve been in the process of teaching myself the Google Android platform over the last few weeks, as my work has had a contest devoted to creating a mobile phone app, with a prize attached. I’m the only entrant who doesn’t work in the Engineering department, so this is a bit of a professional stretch for me as far as my job is concerned.

I have found quite a few caveats in the development process which are worth noting, as I have spent a fair amount of time researching them to figure them out. (I should also note at this point that this is in no way downplaying the important role Android plays in the future of mobile phone platforms, and is definitely *not* advocating either WinMo, which is a horrible abortion of a platform, or iPhone, which is not only locked to a single vendor, but *requires* purchasing a Crapitosh for development as well as a minimum 99$ development license to get going …)

1) Camera Access – It took some digging to find that you have to allow permission android.permission.CAMERA, or else it’ll throw out of memory errors and crash the app. I think it’s a running bug that in Android 1.6 it isn’t throwing a proper “PermissionDeniedException” or whatever else they feel like calling it. Otherwise the Camera API is pretty powerful.

2) Getting your own phone number – This is very interesting, as Android just moved to using something called “TelephonyManager” to deal with all of this. Unfortunately documentation hasn’t quite caught up to it. An example:

TelephonyManager mTelephonyMgr = (TelephonyManager)context.getSystemService(Context.TELEPHONY_SERVICE);
String imei = mTelephonyMgr.getDeviceId();
String phoneNumber=mTelephonyMgr.getLine1Number();
String country = mTelephonyMgr.getNetworkCountryISO(); 

3) Saving state – If you want to save state for your app, it makes no sense to go any further than SharedPreferences. It keeps you from having to create a content provider to deal with keeping that information stored somewhere else …

4) AppWidgets are awesome — The idea of a “home screen” applet is really easy to implement simply by extending AppWidgetProvider and add a <receiver> XML element to the AndroidManifest.xml file corresponding with the class.

5) Opening an intent from a menu item – The documentation says to use *a* Context, but doesn’t mention that you should be passing the Activity subclass that you’re coding to use as the Context.

For those who don’t know much about my life or daily habits, I have to commute into Framingham, Massachussets most days for work, which is about an hour drive from Northeast Connecticut, where I live. Unfortunately, this means spending a fair amount of time in traffic, as well as on the Mass Pike, which is the sorry excuse for mass transit across Massachussets. Americans think of mass transit as highways instead of rail and its compatriots, for one reason or another.

Getting on or off that road is a little dangerous — drivers in Massachussetts, less-than affectionately referred to as ‘Massholes‘ by drivers in other states, seem to have some hideous mental block which keeps them from being able to merge into traffic. A single lane merge on the Mass Pike can backup traffic for miles on some days. Instead of following the customary turn-taking merge technique which has become so commonplace in other parts of the country, drivers in the “Make it yours” state just slam their heavy feet down on the accelerator and attempt to cut off every other driver on the road.

It struck me that this is a pretty decent metaphor for the issues with the illusion of “pure capitalism” mentality that has become so prevalent in this country. Common sense dictates that by not being rude to your countrymen and displaying common courtesy, everyone does better. You may get to work a few minutes later, or possibly everyone could get to work on time. People don’t need to step on other people to get ahead — they can still get where they’re going, but it’s far better for everyone involved to not be such a dick about it.

And the second part of the metaphor is that if we just went with mass transit, we’d probably be better off, but no one is going to do it because we can’t show anyone our large shiny chrome and plastic wangs. Sadly, that might be the more apropos part of the metaphor.

As I have been delving deeper into the J2EE Servlet specification during the rewrite of REMITT, I have been learning some very interesting, and sometimes very painful, lessons about trying to package something without requiring complicated installations.

To get authentication working in Tomcat, the normal way is to define a Context and Realm in TOMCAT_HOME/conf/server.xml. A relatively undocumented file called META-INF/context.xml allows fragments to be distributed with war files. This would be a great solution if it didn’t mean that authentication was now deeply dependent on editing a file in the web archive, which kind of takes the advantage completely out of having one. D’oh!

Next up was the idea of using JAAS, which is a way of setting all of the security information in a single configuration file, and using a custom security module. Which would work very well, if I wanted to pre-extract the war file and pass an archaic system property file through JAVA_OPTS. This seems, again, too difficult to make any sort of sense.

I eventually found a solution by creating my own Filter and LoginModule, then setting the system property for the JAAS configuration manually in the init() portion of the Filter. A little filter and realm information in WEB-INF/web.xml, and everything seems to work somehow. I understand that the Servlet guys wanted to make sure that the J2EE server context and app context were at two different levels (hence the reason a DataSource in META-INF/context.xml or tomcat’s conf/server.xml isn’t writeable at all), but it makes it a mess for clean deployment.

As it stands now, I can run the server with an override file like like:
JAVA_OPTS="-Dproperties=/my/remitt.properties" ./bin/catalina.sh start

And I think that’s worth the hassle to set up, since it makes deployment a breeze.