> 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. And the fact that mobile-specific commands each need to be 
wrapped inside an environment-check to keep from throwing an error in the IDE.

> 3. It's not "Live"Code. Developing for Mobile gets you back into the horrible 
> edit - compile (i.e. build a standalone) - test cycle.

I agree that there is much more of this needed for mobile since the IDE doesn’t 
allow us to build directly on mobile (I’m not sure that is a bad thing.) I have 
found simulators to be a good intermediary but it absolutely does require this 
frequent build cycle for some aspects of development.

> 4. You still need to deal with the ugly issues of the SDKs and the app-store  
> requirements.

I suspect that jumping the security hoops like certificates and store portals 
are a big reasons why even if "everyone can code” not everyone can see their 
mobile creation made available to others. Learning how to navigate these added 
security restrictions is time consuming and confusing (at least to me). Several 
people like Trevore DeVore and Matthias Rebbe have been helping ease these 
complications for desktop. I’m not sure what the answer is for mobile, though.

—
Scott Morrow

Elementary Software
(Now with 20% less chalk dust!)
web       https://elementarysoftware.com/
email     sc...@elementarysoftware.com
booth    1-800-615-0867
------------------------------------------------------
> On Apr 5, 2020, at 6:37 PM, Alex Tweedly via use-livecode 
> <use-livecode@lists.runrev.com> wrote:
> 
> As I see it, there are 4 broad areas of problem for LC on mobile OSes.
> 
> The first two have been well described earlier in the thread and should just 
> be fixed.
> 
> 1. xTalk features just don't work, or work totally inadequately (e.g. 
> scrolling fields).
> 
> 2. Failure in cross-platform equivalence.
> 
> 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.
> 
> 4. You still need to deal with the ugly issues of the SDKs and the app-store  
> requirements.
> 
> 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.
> 
> OK - that's an easy decision for me - I don't do this for a living, I do it 
> for fun. And right now Mobile development is no fun.
> 
> The downside is, I've all but run out of reasons to develop in LC. I used to 
> write little (but useful) apps/games/utilities for myself, or my family, or 
> sometimes for friends. I don't think my wife's laptop has been switched on 
> this year - she uses her tablet and/or phone almost exclusively. And others 
> in the family are much the same.
> 
> So I think the right solution is for LC Ltd is to add *another* target 
> platform - PWAs. (This has the advantage that it also tackles the inadequacy 
> of the HTML platform).
> 
> LC Ltd should just pick a set of PWA components (I don't know which - maybe 
> Angular, Polymer, etc. I *really* don't know which - but just pick one for me 
> !!). Then they should identify a *subset* of LC script/UI features that can 
> be readily mapped to JS and a LC/JS library, and implement that.
> 
> Given the ability to re-load JS it should be feasible to be (fairly) 
> "Live"Code, without a full stand-alone build step.  It should produce 
> fast-loading, small "apps" that would allow many fairly straightforward apps 
> to be developed easily - bringing Mobile development back into the realm 
> where new / naive users (that includes me) can readily develop apps and run 
> them on the devices we all use these days.
> 
> And I'd get to stick to LC :-)
> 
> Alex.
> 
> On 05/04/2020 21:53, Curry Kenworthy via use-livecode wrote:
>> 
>> Agreed!!! I had grown weary of endless arguments previously pushing back 
>> against most LC critiques while the wagons were circled, so very glad to see 
>> this frankly discussed now.
>> 
>> "Live" Code. Meaning: WYSIWYG between dev and runtime, no edit-compile-run 
>> cycle, much more efficient. Remember the marketing? For us the Users, it 
>> wasn't just marketing. It was real, and it was the reason and the 
>> empowerment. We lived it and used it. Still do on desktop.
>> 
>> But LC has never been "Live" Code on mobile platforms. A big fail. Not just 
>> the UI, but also the mobileBlahBlah keywords that must be placed in if/then 
>> branches to avoid runtime errors on desktop whereas they should have been 
>> designed pan-platform. When these first appeared I was hoping they were 
>> temporary. Instead they've grown and multiplied, setting an arguably bad 
>> trend for the future.
>> 
>> That was a huge design flaw or design mistake/bad decision for a product 
>> called "Live" Code. LC Ltd needs to understand and embrace some key 
>> characteristics of its own product. It's not just marketing, and it's not a 
>> HyperCard "Boomer" fad that will (or should) die out demographically with 
>> younger coders. It's valid, there's a reason, and it's so important.
>> 
>> How's that for a "second"? :)
>> 
>> Best wishes,
>> 
>> Curry Kenworthy
>> 
>> Custom Software Development
>> "Better Methods, Better Results"
>> LiveCode Training and Consulting
>> http://livecodeconsulting.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

Reply via email to