Developing first on android
ambassador at fourthworld.com
Fri Aug 18 10:56:00 EDT 2017
Mike Kerner wrote:
> There might be another way to skin this cat. I liked what Pomegranate
> said, which would also be a way to make apps even more levure/git-
> friendly, and would, I think, solve some of the Android layout issues
> that she was discussing - every object is created by a script, instead
> of using the LC IDE to do it.
Who is "Pomegranate" and where was this message? In a quick search of
recent posts here I was unable to turn up anything from that user.
Was Jonathan's issue specific to layout? I had thought it was a
reflection of a somewhat general sense that LC's feature set for Android
is in some ways a subset of features found in LC's iOS engine. To the
degree that's true, Jacque's suggestion is a great one, since the range
of things we can do in Android that aren't available on LC's iOS engine
does seem smaller than the other way around.
If not limited to layout, how would the storage format of the objects
affect that? Whether rebuilt on the fly each time from script or
instantiated from op codes in the binary stack file, an object is an object.
Even for layout, it seems the benefit of using Git-based workflows is
for the benefits of using Git, in development, and would not seem to
alter runtime behavior. Have I missed some feature unique to
The only downside I can think of to using any single OS for the majority
of one's multi-platform development is to make sure you periodically run
in each of the target OSes to ensure things look as they should.
For example on mobile, a menu button row/widget appears at the top of
the layour in Android (not a bad choice, given that people tend to
perceive layouts in reading order, left to right and top to bottom), but
on iOS that main navigation control is placed below the region it
affects, at the bottom of the card.
There aren't many things like that which differ so starkly, unless you
get deeply into Android's Material Design. But if we want to avoid
having our apps look like something that was obviously designed for some
other OS and hastily ported we want to learn those differences and
support them in our layout code.
> I've been thinking of developing a deconstructor to use with Levure.
> The idea is that you would lay out the objects, but then the
> deconstructor would pull all the properties of each object, put them
> in a YML, JSON, or other similar file, and then they would be built in
> the app by script, when needed.
That would be handy. I've considered making one, but the cost/benefit
relative to other commitments here has prevented me from diving in. I
appreciate your interest in this, and know you'll do a fine job with it.
While it's understandable that Git can't handle LC's binary files, one
of the strongest benefits of "The xTalk Way" is visual design.
This is why so many of us have written libraries to automatically
instantiate mobile-specific controls for us from LC-native objects,
because it lets us enjoy the fluid development workflow that
characterizes xTalks, rather than defining objects by typing long blocks
of object definitions in scripts, which is a very C way of doing things.
Automating use of Git through binary->script decomposers allows
developers the full benefit of the best of both xTalk and lower-level
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and the Web
Ambassador at FourthWorld.com http://www.FourthWorld.com
More information about the Use-livecode