Alex Tweedly wrote:
> On 06/04/2020 03:55, scott--- via use-livecode wrote:
>>> 1. xTalk features just don't work, or work totally inadequately
>>> (e.g. scrolling fields).
>> I feel this is overly harsh. Livecode fields (and the creation of
>> native UIText fields) do work on mobile. I think the issue is that
>> the use of some objects (like fields) on mobile is not as drag ’n'
>> drop simple as it is on desktop. No argument there.
>
> Yes, it was harsh - but sometimes a little bit of hyperbole helps, if
> only the mood of the speaker :-)
And for purposes of new-user advocacy. Which could (and arguably
should) be read as "conversion rates", or more directly, "making money".
Mobile fields are a subset of the excellent LiveCode-native field.
If things were the other way around that would pose a problem. But as
they are, the LC field object is so flippin' awesome it certainly
doesn't hurt us at all to simply use a subset of its rich features for
mobile development.
Of course mobile editing UI is not directly supported in the LC field
object. It does a wonderful job on the desktop, and it would be
super-awesome to see the object extended to support the other 55% of
where users spend time. But at least we have the option to script our
way to an OS-native mobile field.
But why would we do that? This is an xTalk. The benefit of The xTalk
Way is at the heart of all GUIs, direct manipulation of objects. It may
seem perfectly reasonable to a C++ programmer to type out every little
thing, but it doesn't reflect the charm, allure, and productivity
advantage of The xTalk Way.
Thankfully, LC is also super-flexible, so it's not all that hard to
write a library that on preOpenCard looks for all editable fields, hides
them, and creates matching OS-native fields over them.
Extra bonus points for re-routing messages for OS-native mobile fields
to traditional LC fields - even dispatching them directly to the field
object the library used as the basis for the mobile field.
This does two things:
1. We type less.
LC is a GUI app development tool, the world's most powerful
example of The xTalk Way. We type only when we need to.
And we don't need to type out definitions for something as
basic as a field.
2. We test on-device less.
The joy of The xTalk Way is that we code and run and
code and run interchangeably, interleaved, in a seamless
continuum of creative flow. "We don't need no stinking
compile-runtime cycle."
Sure, when you want to test OS-specific features, you need
to test on the specific OS. If you want to see how your
AppleScript works, you test on your Mac. If you want to
check your registry settings, you test on Windows. If you
want to see how incomplete the player object is, you test
on Linux. Same with mobile - test your OS-specific features
where they exclusively live.
But think about how much of a drag LC would be if every time
you changed one line of code you had to stop everything you're
doing, walk through a number of steps to move the app out of
where you can already see it right in front of you, to go
look at the same controls on a different screen.
So just don't do that.
Design the workflow to reflect the joyful productivity
which is the reason you're reading this now, the reason we
choose LiveCode. Code and run seamlessly interleaved right
where you are as much as possible.
When we maximize use of LC-native controls, and automate
instantiation of mobile-native controls based on those
LC-native controls, we get to spend more time where time
is best spent, right in the IDE.
Data entry, navigation, server connectivity, graphics
manipulation, and many other things apps do are equally
available on desktop and mobile OSes.
So if you set up a workflow that requires on-device testing
of things that can be tested in the IDE, you're choosing to
slow down development and reduce the joy of coding.
LiveCode is a wonderful environment, a rich thriving forest of
development treats. Let's spend as much time in that lush world as we
can, minimizing the sometimes-necessary ventures into the desert of a
handheld device foraging desperately for scraps of debugging info.
Let's live well. Let's live The xTalk Way.
This discussion on editable fields is just one way to streamline LC into
a joyful experience. Other controls can be similarly mapped, and even
moving the stack to the device for testing can be radically streamlined.
And the IDE itself is ripe for refinement of some of its GUI elements to
provide better guidance with a simpler appearance.
We can explore all of that after we resolve the question that gave rise
to this thread:
What is the simplest way Jacque can accomplish the most basic task of
gracefully displaying a block of scrolling text?
Money-making hint: if it requires creating a separate container object
just to handle a deficiency in field buffering, that would most wisely
be seen as a bug.
--
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
