DUAL mobile apps

[Thomas McGrath III]

Dear Listers,

I decided to build the Android push sample app in the same stack as the iOS sample I just built as a DUAL app and ran into a whole bunch of problems in trying to do so. I almost gave up. Ralph and others on the use list helped point to some of the problems with DUAL apps. Some of this may effect you if you decide to publish a dual app for iOS and Android. Ralph has posted a separate thread on the use list of other Gotchas to watch out for, but the list below mainly concerns resizing and positioning of controls.

1.) It turns out that front scripts from tmControls will silently block openCard from executing when run on Android. (I use tmControls on iOS because they work correctly on iOS and are very very easy to implement standard GUI controls. All GUI elements in tmControls match the HIG for iOS.)
2.) Without being able to use tmControls, I tried removing all traces of tmControl front scripts for Android and found I had to remove all custom properties from existing GUI elements as well, it also turns out that certain controls have behaviors and forgetting to remove the link between even just one will 'silently' block scripts from running.
3.) So without tmControls, all resizing schemes I've tried (including my own) that are used to handle 'ALL' different sized screens and also handle density on those displays will not handle the 'expected' resizing of the GUI elements like Nav Bars, Tool Bars, etc. as per HIG and Look and Feel for iOS and Android. Resizing schemes will also not look right below a certain size screen and will not look right above a certain size screen on either OS when building a DUAL app.
4.) All iOS extensions must also be removed from the copy files pane when building for Android in a DUAL app.

So, my take away is that for a DUAL app:
1.) The time saved using tmControls is lost in trying to disable it when run on Android. So NO tmControls for DUAL apps. (which is a real shame)
2.) 'All' current resizing schemes will not work for all DUAL apps - when the resizing goes below certain sizes and above certain sizes or for all GUI elements to match HIG requirements. This last seems to get over looked in most schemes.
-- For Android the mobilePixelDensity() is not a reliable way of scaling since the Display Metrics returned only report density and not width or height differences from the original development size and as such doesn't work correctly when resizing as the scale factor. Since the width or height is not doubled in most cases and yet MPD can return a 2 on a higher density device but the widths and heights of those devices may not be doubled etc. 
-- For iOS the iPhoneDeviceScale() works for Retina sizes since they ARE just doubled (except 4" where it does not take the extra height into account)
-- It is better to use the WidthRatio which is the ratio between the development size (generally easiest to use 768w as the "NORM") and the 'current' width when launched and using that as the ratio - the WidthRatio WORKS for all graphics but is difficult for Text and mostly WRONG for GUI elements when too small or too big a difference from the development size. So:
---- If you develop at iPad 768 width as the "NORM" and double it for 1536 iPad Retina it works well using iPhoneDeviceScale().
---- if you develop at 768w and resize to iPhone/iPod regular 320w the graphics will resize correctly but GUI will be too small as per the HIG. Text will also be too small in most cases. A redesign of the whole card is needed here.
---- if you develop at 768w and resize to iPhone Retina 640w (3.5 or 4 inch) the graphics will resize correctly but GUI elements will be too small as per the HIG. Most text is good except in GUI elements.
---- If you develop at 768w and resize to Android less than 768w the graphics will resize correctly using the WidthRatio but the GUI will be too small for accurate touch controls (don't know about any HIG expectations for Android).
---- If you develop at 768w and resize to all the different widths and heights for Android the graphics will mostly resize correctly (with proper design) using WidthRatio but again GUI elements just don't turn out right.
3.) Given this, two separate schemes need to be developed and used in a DUAL app. WidthRatio works for graphics (and a serious modification works for text) when using WidthRatio and a separate scheme needs to be developed for GUI elements since they have to match expected behaviors and expected Look and Feel.

Currently, I am using WidthRatio as my resize scheme for all app elements and I am looking into using a responsive scheme that both RESIZES GUI elements correctly for iOS HIG (which tmControls did do) and appropriately RESIZES GUI elements for Android, but that also REPOSITIONS GUI elements as appropriate for each device separately. Tagging a control for Repositioning based on a location based on width/height placement (distance from right, top etc.) and Resizing based on 4 generically specified device sizes S,M,L,XL or HDPI seems to be the only way. This also matches the web based approach of most mobile ready sites.

Tom
-- Tom McGrath III
http://lazyriver.on-rev.com
mcgrath3 at mac.com