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. _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
