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
____________________________________________________________________
ambassa...@fourthworld.com http://www.FourthWorld.com
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
