Controls on mobile apps - am I missing something?

[Mark Waddingham]

On 2016-07-01 12:33, Ben Rubinstein wrote:
> That's why I think "it would be better if" the existing basic controls
> worked reasonably well on mobile platforms, and the existence of the
> various libraries, widgets, and mobileControlxxx functions - while all
> of them being extremely valuable - does not, for me, negate that
> ambition.

If by 'works well' you mean 'look less like they come from the age of 
the dinosaurs' then I cannot agree more.

The main issue here is that of rendering the iOS/Android 'native 
themes'. There are no APIs for this on either platform (unlike for Mac, 
Windows and Linux) so they have to be written by hand using drawing APIs 
(just as we only had emulated Motif, Mac Classic and Win95 themes before 
Tuviah added the hooks to use 'native OS API based themes').

Fraser has done some experimentation here to see how this might work - 
basically it would be a library of LCB handlers which render the 
different parts of each control using its rich 2D canvas syntax. 
However, there is a still quite a lot of work to do it before it becomes 
a feature we can employ.

> In my ideal future there would be no more "mobileXXX" terms in the
> dictionary; just as most of the "iphoneXXX" terms were generalised to
> be "mobileXXX", my dream would be for as many as possible of the
> 
> camera (again with functions to tell me which features are available).
>  After all most 'desktops' are now laptops, many of which have
> cameras, accelerometers, various density screens, idle timers, etc...

Indeed, that is my ideal future too. We need english-like syntax for all 
these things, and as many as possible should work across all the 
platforms we support (or at least allow implementations for specific 
platforms to be added easily when/if such functionality is made 
available).

The english-like syntax will have to wait until the Open Language 
project is completed, but the restructuring to allow the functionality 
to be iterated across all platforms can start with the Infinite LiveCode 
project.

> I'm really hoping (though I'm not clear if this is true or not) that
> the Native Field Object is not implemented as another new widget but
> as a new presentation of the LiveCode field object. A new widget would
> obviously be better than the using the mobileControlxxx functions
> (themselves a welcome addition); but even better if we can drag a
> field onto a stack, and have it work appropriately and according to
> expectation on all platforms.

Well, unfortunately, you will be disappointed in the first instance, but 
only because there is a logical and obvious path to achieving what you 
are talking about, and what everybody would really like.

Whilst it is easy to talk about 'an iOS field object' and a 'Windows 
field object'; the fact is that there is no universal idea of 'field' 
which is implemented across all the platforms we support. All platforms 
have things which accept text input, for sure, but they all work in 
slightly different ways with (in many cases *largely*) varying feature 
set.

So, if the goal is to have a "field control which uses the native 
'field' control on all the platforms we support" then you start with the 
first logical step: you wrap each OSes 'field control' as faithfully as 
you can giving rise to an 'native ios field', a 'native android field', 
a 'native windows field' etc.

This first step means that if you are writing an app *for only one 
platform* (which is not that rare, I know a number of significant 
commercial users of LiveCode who use it to write apps for only one 
platform as that is where the app has purpose) you can do so using 
specific native controls which give you full access to the features that 
specific platform presents.

The next step is that you right a 'native field control' which exposes 
the features which *can* be implemented across all the platforms. This 
would essentially be a wrapper around the actual platform-specific 
widget - it would contain one as a child widget and its main concern 
(code-wise) would be mapping a 'universal' set of properties, commands 
and messages to the specific idiosyncrasies of the specific platform 
implementations.

The icing 'on the cake', of course, would be that 'field' would be a 
'native' field on all platforms. However, I'm not sure that is in any 
way practical. The LiveCode field's functionality is not a subset of any 
of the native field controls on any of the platforms - it has various 
specific features and ways of working which are heavily relied upon in 
people's scripts - therefore it is very unlikely you could just switch 
your fields to native fields without changing code. Which, in the first 
instance at least, suggests that having a separate control for 
'nativeness' makes a good deal of sense - you only have to use it in 
projects it is explicitly designed for.

(Although the news isn't all bad here - by introducing more specific, 
'simpler' controls for specific purposes it should eventually make the 
'automatic switching to use native controls' possible. For example, 
fields are used as labels, lists, rich text editing fields, single line 
entry fields, password fields, multi line entry fields and they are used 
in this way by adding script and setting various different properties in 
various different ways. By giving developers the option of using 
*specific* kinds of field control which are limited to doing precisely 
what they are meant to, and no more, it means they can be mapped to the 
platform specific controls which exist without loss of functionality, or 
lots of 'if the platform is' type constructs to deal with variant 
feature-set on each platform).

I think it is important for me to point out that the use of 'native 
controls' is subject to hefty restrictions at the moment (they all 
'float above' the card) - simply because the architecture of the engine 
was never designed to really work with them. Now, we do have a plan and 
an good understanding of how to change this (it will require 
restructuring the way the engine renders / manages its control tree), 
but even when we do there are a fair few features that will be lost - 
for example, on all but Mac you cannot composite together (via 'inks') 
native controls with anything other than 'blendSrcOver' mode. Similarly 
bitmap effects cannot be supported beyond simple drop-shadows, and even 
then on only some platforms. However, at the end of the day, this is 
something you just have to accept - if you want a truly native UI, then 
you can only do that within the remit of the platform the native UI is 
running on; otherwise it isn't really a native UI anymore, is it?

Warmest Regards,

Mark.

-- 
Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps