Mobile Cross Platform was==>Android openCard not firing

Fri Apr 19 13:56:44 EDT 2013

2 more gotchas.

1) Native input==>On Android it is on a layer above an LC field control. On
iOS it is below the LC field control layer. I set the appropriate field
control colors when I'm not in development mode to hide the LC field
control(thanks to Jacque for the dev function) except for the border in my
case. Don't need to do it for Android but I wanted one code base so I do it
for both Android and iOS. I also put the native input control's data into
the LC field object and use the field control for examining/processing the
inputted data. This makes testing in development easy. I make the native
control name the same as the LC field control. This makes handlers in either
a library or a behavior generic.

2) LC 6.0. When entering a return in a native input control on Android the "
inputReturnKey" handler is getting 2 messages. I had to put a timer in to
ignore the second if it comes with 1,000 milliseconds of the first. This
might be too much time for some apps. For my app 1,000 ms is OK so I did not
see what minimum wait time is needed. I present a pick list when the user
hits enter and 2 pickers appear on top of each other if I don't filter out
the second message.

As for the tmControls issue... I'm glad I spent winter 2012 creating my own
resolution/aspect ratio independence library. It's clunky to set up but work
like a charm. I can't wait to use Monte's release version.

Ralph DiMola
IT Director
Evergreen Information Services
rdimola at evergreeninfo.net

-----Original Message-----
From: use-livecode [mailto:use-livecode-bounces at lists.runrev.com] On Behalf
Of Thomas McGrath III
Sent: Friday, April 19, 2013 1:25 PM
To: How to use LiveCode
Subject: DUAL mobile apps

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

_______________________________________________
use-livecode mailing list
use-livecode at lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode