Maximum field height?

[Alex Tweedly]

Hi Jacque,

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.
Yes !!
>
> 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 
> improved.
>
>>
>> 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 
> profiles.
>
> 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.

Alex.