Controls on mobile apps - am I missing something?

[Ben Rubinstein]

Richard,

Thanks for your reply (and thanks Mike for the tmControls recommendation). I'm 
aware that we can make our own controls; and can use some native ones.

But surely the point of LiveCode being cross platform is that we shouldn't 
need to?

A checkbox on each desktop platform takes on something at least approximately 
akin to the native appearance.  In some cases in years gone by we used to see 
that the Mac controls at least started to look dated; because the engine drew 
approximations of the native controls, when Apple updated the OS they didn't 
look as modern. But they still looked like Mac; and something similar happened 
on Windows when that OS refreshed the UI, but again our software was 
recognisably Windows like.

But on iOS there's not the slightest attempt, which seems odd considering how 
much effort has gone into supporting the mobile platforms.

And yes, you don't see often see a checkbox as such on iOS (apologies for 
concentrating on iOS but I'm not as familiar with Android). But given that 
RunRev have made a switch widget and shipped it with the system, why not 
bundle it into the core and use that to render a 'checkbox'?  The native Mac 
display for a progress bar would look entirely suitable on iOS; if that's 
actually invoked by API (is it?) it still wouldn't take much work to draw it 
directly, and then again we'd get 'native' appearance that 'just worked' on 
each platform.

As for radio buttons, using the pick control is really not a replacement; one 
is an interface element which permanently displays the status (and clearly 
indicates that the user can only make a single choice), and can be interacted 
with along with any other controls; whereas the mobile list picker appears 
temporarily only when the user explicitly decides to change this setting, and 
then can't do anything else until they make their choice and dismiss it. (I'm 
glad to have it, of course - I just don't think it's very close match for 
radio buttons.)

Your library sounds very impressive; and tmControls look great too. When 
RunRev first made the product work on mobile platforms, it was a triumph, and 
we willingly put up with all the workarounds and emulations that were 
necessary to make the apps not look shit.

But it's been six years now.

I accept that native desktop elements won't always be appropriate on mobile; I 
don't expect that apps trying to use 'standard' interfaces will just be write 
once, run anywhere.

But after six years, I was just genuinely surprised to find that the standard 
controls still look shit, when they don't need to. I thought I must have 
missed a setting for theme or something like it.

Ben

On 27/06/2016 19:41, Richard Gaskin wrote:
> Ben Rubinstein wrote:
>
>> My previous mobile app dabbling had involved entirely custom
>> interfaces. Now I'm trying to create a more straightforward app
>> with a more conventional interface - and I'm getting a horrible
>> dichotomy between the widgets (header bar, navigation bar, switch
>> control, segmented control) and the traditional controls (radio
>> buttons, sliders, progress bars, etc).  The latter look fine
>> on Mac; but on iOS, they've gone back to Motif, which is to say
>> several decades.
>
> iOS does not contain the APIs to render Mac controls, so LC defaults to its
> built-in Motif emulation.
>
> Most desktop controls are unsuitable for use on mobile anyway, so using the
> types of mobile controls users are accustomed to is a better bet.
>
> Buttons are buttons, of course, and you can get very good appearances by just
> changing the style to rectangle or roundRect, with whatever background and
> hilite colors compliment your app's appearance.
>
> Radio control take up too much space on small devices.  More commonly pick
> lists are used, and LC provides commands to instantiate OS-native pick lists
> on mobile.
>
> The closest fit for a radio control on mobile might be an option control,
> which is what I use as the on-screen control the user clicks to bring up the
> pick list.
>
> For those, and editable fields and scrollers, it took me about 10 minutes to
> find the process of scripting the instantiation of their mobile-native
> counterparts tedious to the point of feeling silly.  So instead I wrote a
> backscript that catches preOpenCard to do my instantiation for me.
>
> My lib examines the controls on the card and then calls mobileControlCreate as
> needed, making editable text fields, scroll interaction overlays, etc. as needed.
>
> Once I figured out that scrollers for fields are actually MUCH simpler than
> the LC Lesson for that suggests, getting the basic functionality in place took
> just a couple hours.  In fact, given how liberating it is to be able to use
> LiveCode objects on the desktop and have a lib automatically take care of
> replacing them with their mobile-native counterparts, even mapping relevant
> messages between them so I don't need to write as much platform-forked code,
> I've been surprised this isn't included with LC itself.
>
> I'm still making lots of changes to my lib as I work toward deployment, so
> it's not yet in a sharable state.  When it is I mkay dual-license it, but I
> hope by then LC will just have something like this in the install; most devs
> I've talked to have already written their own variants of this, and like most
> things the code isn't the hard parts, it's designing how it should work.
> Maybe one of the many others in our community is already shared and usable....