Developing first on android

Richard Gaskin ambassador at
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 
script-only stacks?

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 

  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  Ambassador at      

More information about the Use-livecode mailing list