Controls on mobile apps - am I missing something?

[Richard Gaskin]

Ben Rubinstein wrote:

 > A checkbox on each desktop platform takes on something at least
 > approximately akin to the native appearance.
...
 > 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).

People do all sorts of things.  Some might even have a 45-degree angled 
progress bar.  Not everything folks might want comes in the tin. :)

The HIGs for both iOS and Android suggest using a slider switch instead, 
which LC provides with a widget in v8.

Personally I think the checkbox is not only arguably less ambiguous, but 
a definite space-saver as well.  But alas it's not what either OS 
suggests we use for Boolean selectors.


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

Fixed-length progress bars are definitely problematic.  Long processes 
for which we'd use a progress bar on the desktop should be extremely 
rare in a mobile app. With a handheld device there's a premium on the 
user's time, and any lengthy process may merit reconsideration, perhaps 
refactored to something that could be chunked in the background, or 
handled through some other means.  I suppose there may be cases where 
it's unavoidable, but IMO those should be the last resort when all other 
options have been tried.  Users really demand responsiveness in handheld 
devices, and apps that feel sluggish won't live long on the device.

That said, indeterminate progress indicators are frequently used on 
desktop and mobile, often for syncing and are almost always short-lived. 
  And unfortunately they're currently not possible to implement well in 
LiveCode at all.  These would require threaded GIFs, or threaded OS API 
hooks, neither of which we have.  Indeed, we're reminded of this each 
time we build a standalone, watching LC's progress indicator stutter 
frequently as it goes through its steps.

Now that LC Builder has been funded to include support for addressing 
APIs other than those based in C, I'm hoping we can get a crew together 
to have either OS-driven indeterminate progress indicators or 
separately-threaded GIF playback (or maybe both, since each is useful in 
its own right).


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

Yes, which is why I mentioned that the on-screen element I use is an 
option control.  On mobile this renders as a button, and if I set its 
border and colors properly to compliment my app's appearance it can look 
quite nice.  If I find a case where I don't like the look I can have my 
library change its style to anything else on the fly.  The reason I use 
an option control is primarily because it lets me build rapidly in the 
IDE, providing the closest behavioral match for the mobile conventions 
to be invoked later at runtime.

I agree that hand-writing the code to tie it into the picker is tedious, 
which is why I only wrote it only once in a bit more generalized way and 
now my library does that for me.  I never think about that anymore.


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

Whether an app looks like merde or not is more a function of the 
developer than of the engine.  I've seen many apps on the desktop that 
look completely horrible, even though it's not that hard to make a good 
looking app in LC.

On mobile we need to work a bit harder, but it's still doable.

Given the many years since scriptable mobile-native controls first 
premiered, it is a bit of a head-scratcher that I'm writing a version of 
the same library that Chipp, Ken, and so many others I've spoken to has 
written, nearly everyone except the vendor. :)

But I don't get paid to wait for others to make my work even easier.  I 
appreciate it when they do, but I've looked around for an even simpler 
solution as flexible as LC with the same platform coverage and I just 
can't find it.

So warts and all, I do what I can with what's available and for the most 
part I like it.  As the great bard Donald Rumsfeld once said, "You go to 
war with the army you have."

LC continues to get better with each version, and hopefully one day the 
core team will also include one of these auto-instantiation libraries to 
tide us over until they have a more perfect solution.

In the meantime nothing stops me from enjoying an uncommon level of 
productivity across a nearly unmatched scope of platforms given the raw 
materials we have 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.

What you missed is a moment of feature incompleteness, understandably 
missed because the moment is now more than half a decade long. :)

LC offers pretty good support for mobile-native controls.  It's just 
that, unlike everything else in LC or any other xTalk, they must be 
instantiated through script rather than by drawing on screen.

Fortunately mobile apps are, but their nature, often less complex in UI 
than desktop apps, and the properties and messages provided for 
mobile-native scripted controls are a subset of those we've been 
enjoying for the desktop.

This makes it relatively straightforward to use the subset of controls 
that make sense on mobile where useful in development, and have a script 
walk through them on preOpenCard and replace those that need to be 
mobile-native with their mobile-native counterparts.   Add a resizeStack 
handler to handle orientation changes, and a few dispatches to map 
mobile-native messages to your LC-native objects, and you can enjoy a 
workflow very much like the desktop with your focus on your app's 
business logic when in the IDE and smooth deployment on the device.

It'll be nice when LC Ltd provides for those two platforms the 
xTalk-like workflow that is the reason we love this family of tools. 
They may find an uptick in sales as well as new users will find mobile 
work as enjoyable as making desktop apps.

But in the meantime the distance between what we have in hand and what 
we need to enjoy a smoother workflow for at least ourselves is less than 
a day's work.  I'd easily spend an order of magnitude more time porting 
even the simplest app to anything else.

-- 
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com