- Network connection is shaky at best
- Application run-time is never guaranteed, expect nothing to be there
- Users want the kitchen sink
- Phone processing power varies greatly (at least on Android)
- Pushing as much processing needs off to an external device (server, etc) helps performance
- Minimize data transferred over radio
Lesson 2: Android cleans up a lot behind the scenes. When users launched the external extent for barcode scanning, my app got killed sometimes. Handling this is tricky and I'm still not sure I got it right.
Lesson 3: I get so many feature requests it's not funny. Most of them make a lot of sense but would grow the application beyond what I think it should be. If you give the users the kitchen sink, its hard to keep the UI simple and performance good. Maybe I'll take all their suggestions and build a suite of applications some day when I'm 100% recovered...
Lesson 4/5/6: Parsing XML on the phone sucks. No simple way around it. Downloading a large XML document from Amazon and then making extra network calls based on what was in the document stinks. This is not enterprise programming... What I ended up doing was writing a REST service that returned a CSV file. XML is just to expensive over non-3G speeds which is still common for Android phones right now. The service I wrote checks Amazon and Google's GBase and parses the XML for the phone. It returns the results as a CSV file with a content type of plain text which is about as small as I can make the data transfer over the radio.
No comments:
Post a Comment