I am still in the process of converting my iPhone project to Android. Main goal is to allow doctors to create cases out in the field and submit them to the back office for case workers to finish up and send off to insurance companies to get paid. All the rest of the software is written in Java and Ruby and has been operational for a number of years.
There are currently 24 of tables involved in the process with some containing over 17,000 records. I am storing as much of the data on the device as possible but some of it needs to be requested per login session as it can change on the back end - facilities, referring physicians, providers, etc.
The basics of getting the table data in XML format, converting it via SAX parsing to table rows and executing inserts to populate the tables is very similar between the platforms. Where the fun begins is displaying the data to the user.
The iPhone has a standard Table View but it is up to you to do all the work. You have to build out the rows, you have to get them displayed, you have to deal with rows that have different amounts of data. You have to convert clicks back into rows of your table. It appears one developer did the SQLite side and another did the Table View side but neither talked to each other. Doing all the work yourself is not fun. I have hundreds of lines of code to handle what I am doing trying to be generic as possible. Even showing a simple string when you have an empty table is a pain. Finally you have the fun of performing the SQL queries in a simulated background thread. You are responsible for disabling the UI, showing the busy spinner, positioning the busy spinner and if you feel really adventurous showing some status text.
Moving over to the Android has been a pleasure. Sure, I have the whole database schema in place giving me a big head start but that is not what is making it so easy. The Android team decided to do a lot of the hard work for me and provided a SimpleCursorAdapter. I can query the table, get a cursor back and pass it to this adapter and my table automatically populates. In a ton less code I actually have better functionality. The rows automatically size to the strings I provide. If my cursor has no rows a simple addition to the XML file shows the "No matches found" message. Background activities automatically take care of disabling the UI and I get to show status strings with ease.
Things are falling into place so quickly on the Android side I am able to add extra features as I go. This equals some pain as I will get to back port those to the iPhone before shipping.
This is not the only area where I have found Android to have a more complete API. I can quickly create two views, one for landscape, one for portrait and have them appear without any special code. Doing that on the iPhone is a major hassle. You can either shuffle the controls around in code, which is what I have done, or you can attempt to have to XIB files and do double control hookups which seems like a massive waste.
The code base I am generating on the Android side is massively smaller than on the iPhone. Pretty much anything I do takes less lines and much shorter lines of code to accomplish. Objective C is not a terse language. The less I have to type the faster I can get code done even with auto-complete available on both platforms. I also don't mind refactoring code in Eclipse where it is s crap shoot in Xcode. If I have to do anything massive I do it in AppCode which helps a lot. Not having two files for every class is also nice, cuts the size of the code tree in half.
It is going to be interesting to see what the doctors think. Many have iPhones but are thinking of getting Android tablets to do their case work. Why an Android tablet? Because you can get it in a 7" form factor and that size fits in a lab coat pocket where the 10" iPad does not. My job is to be cross platform and as feature equal as possible. This gives them a wide variety of device choice between iOS and Android.
Beta testing will be straight forward on the Android. I can send them the file and have them install it or they can stop by my cube, plug in the device to my USB cable and I can copy it right over after I kick the device into debug mode. iPhone, well buddy you better tell Apple about the device, wait for it to get provisioned, build the code with the provision in place then copy it on to the device. If you want them to install it they have to play funky monkey with iTunes. Can't go over a 100 device limit either without buying a second license.
The other area of fun will be release time. The initial version of the app just handled appointments and not completing the case. I was able to release the Android Market in 10 minutes. It took a full week for Apple to approve my app and have it hit the iPhone App Store. If I want to fix a bug on the Android I fix it and release it on my own. I have to restart the process on the iPhone side. With the current, very simple app, out there I have not had to do a bug release. The new version is much more complicated which increase the odds of nasty bugs.
If we update our back end we can easily sync that with an Android release. With the iPhone we are in the total dark even if I am really sure I have not used anything in the code that Apple with frown upon. It could take weeks to get something accepted. Can't even do a proper marketing campaign when you can't give a real release date. Apple is not really enterprise friendly and they are not really all that developer friendly either.
I am pretty happy with what I have been able to pull off on the iPhone. It looks good and according to QA is working nicely. I am very interested to see how the Android side turns out. So far it is matching the iPhone punch for punch and coming out better in a number of areas. Any time I have less code to write I know I will have less bugs and thus happier customers.
No comments:
Post a Comment