Mobile Wondering <was Maximum field height?>
J. Landman Gay
jacque at hyperactivesw.com
Mon Apr 6 13:53:45 EDT 2020
On 4/6/20 10:12 AM, Alex Tweedly via use-livecode wrote:
> But, afaik, it's not just scrolling fields; aren't there also issues with keyboard input
> requiring you to scroll / move the field to remain visible,
That was fixed recently with mobileSetKeyboardDisplay.
Also, besides mouse events working on both mobile and desktop, there is automatic conversion of
option buttons to native mobile equivalents and cross-platform equivalence for browser widgets.
Other widgets like navigation bars and segmented controls can change between mobile platforms
by altering some of their properties, and the switch button has a handy "theme" property that
lets you do that with a single property setting. I wish they all had that.
We also have Android native fields, and iOS native fields and buttons (where's my Android
button?) which can be dropped onto the stack, though on desktop they are placeholders.
> And the fact that mobile-specific commands each need to be wrapped inside an environment-check to keep from throwing an error in the IDE.
That's easy to fix. I have standard library handlers that create scrollers, input fields, etc.
and at the top of each one I put "if the environment <> "mobile" then exit thisHandler". That
way I can script everything normally and if I'm not on mobile the command is ignored so the
scripts don't need to branch for things like that.
On the other hand, a frequent request has been for the LC engine to ignore mobile commands if
we're in the IDE. So there's that.
> 4A. SDKs and the build environment. Just horrible; when I tried this a few years ago (for Android) it took me days of frustration and guesswork to get a working SDK, and get it connected to LC, and to try to get a simulator to work properly. Including choosing (I think it "device type") from a long drop-down list of devices I didn't own. I picked at random - and was told either that it was "unavailable" or "will be slow - suggest you try a different device". Well - they were right about that - the simulator was S...L...O...W.
You're right, the Android emulator is horrible. I stopped using it early on. LC recently added
support for x86-64bit specifically so we could use the faster version, but I found it much
easier to just cable my phone to my Mac and use the real thing. It's quick and painless.
>> I never did get round to trying for IOS, because everyone said how much harder it was than Android :-)
I've found the iOS simulator to be very good, on the other hand. It accurately represents what
will happen on a real device, including all the bugs I introduce. It does require a bit of
setup -- downloading gigabytes of XCode is a time suck -- but once set up it performs well.
However, I've found switching between different versions of XCode/LC to be cumbersome. I'd like
it if LC could make the process easier, maybe by issuing shell commands behind the scenes so I
don't have to.
> 4B. App store issues. Never got that far - though it sounds like it's pretty annoying.
> Build for a few people (and sidestep the store) - seems to be possible, but not clear how easy it is.
Apple makes it painful to submit to their store, but if all you want is to generate some
certificates and profiles so you can distribute to a few people, more than half the pain is
Private Android distribution is a piece of cake. Build the app, send it to someone. The only
caveat is that the user must enable a setting on their phone that allows them to accept apps
that are not downloaded from the Play Store. Newer Android devices will ask the user if they
want to do that, older ones require the user to go into Settings to flip a switch.
> Thanks for the reply - it has stiffened my resolve to have another go !!
I'm so glad to hear that. :) Ask us if you get stuck.
Jacqueline Landman Gay | jacque at hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
More information about the use-livecode