Lessons learned on my Mobile Journey

[Chipp Walters]

Hey all,

So, I've been immersed in mobile dev for about a month now. Just finished
my 4th product in 3 weeks. Including an Android Sesame Street app which
plays Flash, m4v video, embedded browser-- the works. Comes with 2 weeks of
teaching content and uses a sweet caching system to download the data so
the app can run un-tethered to the Internet.

And I just shipped off to the iOS AppStore and neat little portable CMS
Symposium app which retrieves all it's updates from Google Spreadsheets--
which is great as now I can let my customers edit their content live. This
app was built for iPhone (both Retina and reg), and all Androids, including
tablets (though a bit LARGE type for them!)

I've learned a ton and thought I'd share some of this for posterities sake.
As those of you who saw me at RunRevLive, you'll know I just about asked
*everyone* how they handle multiple resolutions for mobile app development.
I talked at length with *Tom, Jacque, Andre, Ken, Mark Waddingham, Scott
Rossi, and many others* about this subject. Here are a few of the
highlights I learned.


   - *Jacque told me right off the bat to consider scaling everything.* My
   early image scaling tests told me that resizeQuality=BEST was way too slow
   and =NORMAL was too ugly. *But, it turns out =GOOD works pretty darn
   good!* Generate the graphic at Retina resolution and it should look good
   on all iPhones and Androids no matter what the scaling. BTW, both Mark W
   and Scott R also mentioned the same trick.

   - Tom mentioned *having Square cards and keeping different layouts on
   each card for Portrait vs Landscape*. I really like this idea and think
   it's one way to create a 'responsive-like' approach to layout management.
   Thanks Tom!

   - *I created a test harness* which auto scaled to the screen size. I
   then provisioned it ad hoc on iOS and apk on Android and installed it on
   both devices. With this took, I could create buttons to launch stacks I was
   working on which were loaded on the Internet. A simple "go stack URL" and
   the stack was there running on my device to debug-- no provisioning
   necessary.

   I then created file management stacks which could look into the sandbox
   and move, delete or download files there, along with test debug stacks, and
   my production stack. The beauty of it all is I just kept my local work
   folder inside DropBox's PUBLIC folder and every save was uploaded to the
   Internet automatically in a matter of seconds. Then off to my mobile
   harness app, *a press of the "Reload and Run" button- and voila--
   testing the app directly*.

   - The *easiest and best auto-update mechanism for mobile apps is to have
   a splashscreen app which copies (or SPITOUT) the actual app in a sandboxed
   directory*. No check for updates or anything-- it just checks to see if
   the stack is there and if not decompresses and decodes the custom prop to
   create it. Then, THAT stack can check for updates to itself, and download
   them if needed. This can all be quite complex, and should only be done with
   Android as Apple's TOS doesn't allow for it (AFAIK).

   - Did you know *Google Spreadsheets are a great way to allow your
   customers to manage their content?* I wrote a small bit of Javascript
   which increments the version number on a hidden sheet when any cell is
   modified. And Gsheets provides a very easy way to *grab this data via a
   URL as CSV for each sheet independently!*

   Richard Gaskin (and Alex Tweedly) has a nice CSV library on his site
   which parses this stuff great.
   http://www.fourthworld.com/embassy/articles/csv-must-die.html

   Here's an example sheet:
   https://docs.google.com/spreadsheet/pub?key=0AiQYsJmyjjz8dE5BekpOYUF3RnlxWWV2dEZTY291Z0E&output=html

   - Trevor gave a GREAT talk at RevLive on *grabbing data off the web and
   caching it locally*. If you didn't see it, I'd suggest trying to get a
   look. It's for sure the way mobile apps need to work. All the apps I
   created store caches of the data and update only when needed so that they
   work when not connected.

   - My *biggest issue in mobile development was how to do all the resizing
   of ALL the objects*. I've built Layout Manager tools before in Rev but
   knew they wouldn't work too well. I contacted Ken Ray and he sent me a not
   yet ready for prime time resizeStack library. After studying it, I realized
   it could do a ton of cool stuff, but was missing a couple parts.

   In particular, it needed a way to automatically resize images
   proportionally. I also needed a way to proportionally resize text in
   objects as well. I added some handlers to his library, then went about
   building my own library on top of it along with an altPlugin Inspector so
   that I now could easily apply properties to objects, which would be
   controlled by the libraries.

   A quick modification to my altButton DropTool and now I can resize it as
   well as all the other rev objects with a simple click of a button on the
   inspector. *Then, the revelation.....*

   It turns out, *for MOST all layout management in mobile, you are only
   scaling things-- not offsetting them* (this is especially true if you're
   using Tom method with different cards for Portrait and Landscape).
   Furthermore, you typically only *do this ONCE per launch*, not every
   millisecond during a resize window drag. So, you can take more time-- and
   do it for each card at the beginning OR when going to the card. All of the
   tricky offsets and moving isn't necessary for mobile.

   So, now *laying out a mobile app is pretty damn simple*. Just *resize
   the stack to it's minWidth and minHeight (320,480)* then layout your
   objects (altButtons work great for this as they can be any color and have
   any text-- icons DON'T resize because they use a button, not an image--
   need to fix that), then use the stsResize Inspector to set the correct
   properties *AND it JUST WORKS*. On both Android and iOS devices -- no
   matter the resolution. *No coding necessary.* Here are a couple of
   images of it at work. The first is the stack at minWidthHeight while the
   second is at Retina resolution. You can see the layout is virtually
   identical.


   http://dl.dropbox.com/u/3788438/revTests/Screen%20Shot%202012-07-13%20at%2011.29.44%20PM.png


   http://dl.dropbox.com/u/3788438/revTests/Screen%20Shot%202012-07-13%20at%2011.35.40%20PM.png


I've talked with Ken and we think it may be a good idea to release this as
a free library and plugin, but it needs some cleaning up. Perhaps this
library could be something Scott's products could tie into, as well as
others? Anyway, I thought I'd share some of this stuff while I'm coming up
for air.