Web Development for the Android Browser

Description: This presentation will cover the lessons learned from a web project that targeted the Android default browser. We will discuss gesture and device limitations and approaches for screen size fragmentation.

About me: Mitch Hunt has been developing software since the 80's for both government and private industry. Since 2006 he has been involved in multiple web projects at places like NASA and AT&T.

Below is my initial pass of items of "lessons learned" from my recent android html5 project for AT&T. The project could probably be categorized as a very rapid prototype except that we were going into production (to the public) with it. Most of the items are things which gave us some trouble. I guess the theme of the talk would be "Here are some things which gave us problems, our solution, and a recommendation".

ground rules a high profile proje= ct looking to go into production on a very aggressive schedule designed for android devices run in native browser using html5, css3 no view fragmentation (no media queries) Urchin Rails, Mong= oDB, capistrano, puppet, nginx, phusion, solr (lucene) Agile dev team in Atl, StLouis, Dallas, Huston, India test team in = Redmond customers in Redmond, Plano, Atl development environme= nt Macs - trouble free Windows - unbelievably difficult= (rmagic created by mac fans to torture windows users... minimagic is great= ) Ubuntu32 - ran in VMs on Win7-32 boxes (db difficulties) Re= dhat64 (in production) RubyMine, Sublime git -> svn<= /li> Rackspace -> corp network MongoDB - on the whole, it= performed well.=A0 replication is still a touchy area devices different screen sizes, very difficult to= keep things looking good everywhere slow connection speeds html5 lessons css3 lessons browsers customized by the manufacturer limited processing power (just amazing ho= w well angry birds works) load css then html then js testing clear c= ache frequently reboot frequently (minimum of daily) test w= ith more than one device (a small, medium and a large is best) chrome is best then firefox > safari > opera > ie adb is better than nothing but chrome is preferred (it is like you intr= oduced yet another device called 'adb' into the mix) screen= shot trick hard back vs. browser back keeping page size= small is extremely important behavior orientation gestures (swipes) hidi= ng the addr bar agile almost everyone on the team was new to= agile 2 week iteration 15 min stand-up story e= stimation updating the underlying utils (ruby, jQuery, etc) praise for new features, none for fixing problems face= book mobile is still immature minimal to no support difficulties of "like"ing something behind a firewall developer accounts are difficult lessons learned penny-wise and pound-foolish <= li>dev machines phone devices networking (wireless access f= or testing devices) svn -> git -> svn expensive = consultants their advice is hard to remove (paid a lot for it, so it must be go= od) off-shore consultants language and cultural ba= rriers timezone differences no ruby or rails experience a fair bit of js experience very difficult to effectively task = (maybe my limitation) use something like phonegap or trigger.io do not b= e afraid of jQuery Mobile media queries a fast moving project does not allow for much tim= e to "come up to speed" just like editors, agile is not a= one size fits all