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@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.
_______________________________________________
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
