Mobile Wondering <was Maximum field height?>

[J. Landman Gay]

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 
avoided.

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