Controls on mobile apps - am I missing something?
benr_mc at cogapp.com
Tue Jun 28 18:12:55 EDT 2016
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
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
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
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.
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....
More information about the Use-livecode