Mobile Wondering <was Maximum field height?>

[Richard Gaskin]

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
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com