Maximum field height?
alex at tweedly.net
Mon Apr 6 19:34:23 EDT 2020
Scott made many of the same good points as you did - so I won't
replicate my replies here.
On 06/04/2020 05:20, J. Landman Gay via use-livecode wrote:
> On April 5, 2020 8:39:15 PM Alex Tweedly via use-livecode
> <use-livecode at lists.runrev.com> wrote:
>> 1. xTalk features just don't work, or work totally inadequately (e.g.
>> scrolling fields).
> Somewhat true. LC made a start by adding widgets you can drop onto the
> stack to create native mobile buttons and fields, but I'd like to see
> regular LC controls magically change to native mobile controls much as
> the Mac, Windows, and (sort of) Linux appearances do. That would make
> a world of difference.
> But there are features on mobile that don't exist on desktop. LC has
> provided for things like Android toasts and iOS popups. These things
> are one reason the language can't be entirely universal; mobile
> requires a different feature set. But it would be great if a scrolling
> field would just be a scrolling field everywhere. On the other hand,
> mobile lets you scroll all sorts of things (images, carousels, etc.)
> so we'd still need our mobile scroller anyway.
Same response to that as I have to mobilePick, mobilePickDate, etc. Why
shouldn't they exist on desktop - if they're useful features for a good
UI, why would LC not want to add them for desktop.
> I agree it could be easier, but it isn't impossible. But parity
> wherever possible would be my first choice in what I'd like to see
>> 2. Failure in cross-platform equivalence.
> If you mean mobile equivalence, Android is catching up quickly, in
> part because of the FM initiative. I appreciate that. iOS is pretty
> well covered for the most part. Some folks mentioned the issue of
> branching for different mobile platforms but that doesn't bother me
> much. We have to do that sometimes for the three desktop platforms
> already. The features that both iOS and Android do have in common use
> the same code and syntax.
I mean that, but for all platforms. If there is a common piece of UI
functionality (e.g. pick a date) then abstract that out to a library
function (in the box - not one we each create separately and slightly
differently), and have it use the appropriate platform method. And if
that means we finally get a pickDate widget on desktop then I'd say
"about time" (and ask for a pickTime function as well :-)
>> The other two are, I suspect, not truly solvable.
>> 3. It's not "Live"Code. Developing for Mobile gets you back into the
>> horrible edit - compile (i.e. build a standalone) - test cycle.
> Yeah, this is a pain. I'm not sure there's any way around it but the
> addition of remote debugging has made it far easier. For a long time I
> felt like I was back in 1998 where I had to sprinkle "answer" dialogs
> all over the place just to know what my variable values were. There
> are some tricks though that help. I created a generic launcher app
> that loads my working stack so there's no actual compile required. I
> can't do this for complex apps, but I can do it for testing pieces and
> bits that will eventually go into the main app later. For simpler
> apps, the entire stack can be tested pretty easily this way.
Great. Now why didn't LC create a Launcher app like that so that
everyone (esp new users) can use it, one that runs in a standard way so
we can easily communicate about it - and is documented.
>> 4. You still need to deal with the ugly issues of the SDKs and the
>> app-store requirements.
> For me this is the hardest part, way worse than developing the app
> itself. It's also why I'd much rather deal with Android than Apple.
> Google is pretty easy to deal with. Apple is a constantly moving
> target with a rollercoaster of requirements, not to mention the
> profiles and certificates and what seems to me to be an unnecessarily
> complex review process.
Yes, but even getting the Android SDK seems to be (still) troublesome. I
know it took me (literally) days way back when - it does seem to be
better documented now, but apparently not quite straightforward.
> However, if you are just developing for yourself or a few other
> people, you don't have to mess with either app store. Android apps can
> be freely distributed to anyone by any method and you don't even need
> a Google account. iOS apps can be distributed to a few people as
> "testers" without going through their byzantine submission process,
> though you do still need to mess with their account, certificates and
> I'm thankful that the LC team keeps up with Apple's constantly
> changing requirements. Apple doesn't seem to value their developers much.
>> So, for me personally, even if LC Ltd. could fix (1) and (2), I would
>> still not even bother trying to build a mobile app; it's just not worth
>> the hassle or the learning curve.
> It isn't such a steep learning curve as you'd think. One test app will
> probably get you going. If I were starting over, I'd start with
> Android because it's so much more flexible. The hardest part there is
> just making sure you download the right SDK and Java version.
I did do a test app on Android. Hmmm- I've just checked and I'm
horrified to find it was in 2013.
So I really am basing my opinions on ancient history / versions.
I'll update (and probably apologize a bit) when I've retired with
something ore current.
More information about the use-livecode