An Droid Stuff

I was frustrated when texting friends because the phone I was using at that time required that I press keys multiple times to get to the letter that I wanted to type.  I saw in a Costco ad that there were Blackberries on sale.  I stopped at the phone kiosk and tried to get info from the gentelman there.  It was a waste of time, the man wasn't really into his job.  When discussing it later with a colleague at work I was told that The Google G1, the first Android phone was due out soon.  I checked it out.  I preordered. I waited to get my phone.

It arrived some time in early November.  Way cool! I dorked with the preinstalled apps and waited for the app store to open.  I downloaded and critiqued apps, and said I can do better.  Finally some time the following spring I bought a book. 

The book was a WROX publication entitled Android Application Development.  In it, I learned about Eclipse.  I downloaded and installed Eclipse.  I downloaded and installed the Android SDK.  I struggled to get things properly configured to actually work together.  I built, mostly just following the instruction in the text, the Hello Android app.  It complied! It ran in the Emulator! Woo-hoo. 

That was as far as I got.  I never actually loaded it into a phone.  Time went by....

Many month later I got the bug again.  I needed to be an Android Programmer.  I went to town.  Every waking moment that I wasn't working, or playing TeeVee junkie, I was reading about Android development.  When there was a slow running task on my computer at work I was reading about application development or the Android API.  Then it hit me.  FIPSit was conceived. 

I work in a company that sells a highly specialzed GIS product for territory design.  I had learned about FIPS code in a GIS class years earlier.  We used them in our product.  I thought a handy pocket reference was something no one else had published before. One of the problems with SmartPhone applications is that there are dozens, if not more, of pretty much the same application already. What would induce someone to try my my app? Make one that on one else has made! So I did.  So far no one else has.  Why would they? FIPS codes are so esoteric I was amazed that people discovered and downloaded my app. (I've been at 499 downloads for a week I have an active count of 117 or about 23%, I was really tempted to type aboot (as if I were Cana dian), what can I say, eh?)

FIPSit uses a database that I got from the NIST, that is, the National Institute of Standards and Technology.  I had to learn about SQLite and reformated the information to load into an SQLite database. I wanted the data to be self contained so that the app would work in the absence of internet. I didn't want to have to maintain a website so that people could download the data on first run.  I read about a way to include the data in the installer and on first run copy from a resource file to a database file. But I'm jumping ahead.  First I copied the database into the emulator so that it would just work while I was developing the rest of the system. Later that became a problem.  When I actually got around to pubishing my app and testing it after download & install, it crashed on first run because of bugs in my on first run code.  I scambled to get it fixed before actual users tried it.  I didn't want any bad reviews!

It ends up that I was the all 5 of the firstdownloaders and hence the reason for version 1.5.  I had to increment something for every iteration while I was getting the on first run code "fixed".  Later I realized there were other ways.  It was a learning experience. 

Another hurdle was actually getting the code loaded into the phone for testing before publishing.  It seems all of my computers had already "seen" the phone as a mass storage device.  This meant the SDK was unable to write to the phone in the way it needed to, since the wrong drivers were already installed.  It took a while to find the right tool to "fix" this problem too.  "Pulling teeth" is a term I use in describing Android development.  Finding the right information online can be challenging.  There are plenty of bad examples and out right misinformation on the web.  Seemingly "good" sources publish examples that don't actually work.  Finding a solution to a problem is like finding a needle in a haystack.  Try a bunch of stuff and figure out what acutally works, or why the supposed good sample doesn't. 

After many trials and tribulations I did actually get a product that I published and works. I received one superlative review from an early downloader and one 4 out of 5 review recently because I didn't include a feature the reviewer wanted. Zip codes change so frequently that it would be a nightmare and rather expensive to include a Zip Code to FIPS code translater. This means I really don't care about the second reviewers 4 rating. 

After I got the FIPSit published and people were downloading it I thought of additional features that might be nice to have, such as: to add locational awareness via coarse or fine precision, show location on a moving map and add speech. Applications were developed to do each of these things but I never intgratedthe snippets of code into a complete application.

Later I installed Tomcat, developed java servlet, installed and debugged in a shared hosting environment (GoDaddy). The servlet services 2 requests. The first reports the available database versions and the second returns a copy of the requested database from an online MySQL database. This was part of learning how to supply database updates.  It too was never implemented. with only ~500 downloads and 117 active users I really can't see investing the effort.  I will take the experience and put it into another product later.

I recently broke my ankle.  This meant a cast for 5 weeks and not much moving around.  The aftermath of the cast was a DVT, fancy short hand for Deep Vein Thrombossis.  In other words, a blood clot.  Once one has a blood clot they are in a group that are far more likely to get another.  I would really like to see the raw data! But the current medical thinking is to put such people on "blood thinners" or anti-coagulants.  I am in that set.  I found out that Vitamin K has an adverse effect on Coumadin effectiveness. So my second app is a Vitamin K intake monitor.  Again using a database published by a government entity, this time the USDA.  This time I decided to download on first install and developed code to do that.  Later I decided that maybe to be "nice", since it is a 4.5MB database I should make it access an online database rather than lugg around a bunch of unneede info abut foodes the user doesn't care about.  The goal is to download info as the user looks it up and if the tag it as food they have eaten add it to a local in-phone database.  Over time all of the food the eat regularly will be include in the in-phone db and internet access will no longer be necessary. 

Still in the early phases I hope to have the app completed before I get off the Coumadin.  Once completed I hope to add additional code to support Weight Watchers users.  The db contains info about Fat and Calories and Protien for all of the foods in addition to the Vitamin K info.  The source data also contains info on all kinds of Vitamins and Minerals that I chose not to include.