Creating LiveCode applications that play well with git

[trevordevore]

After making a change to "version" and "build" in app.yaml, when should I expect to see those changes in
cRevStandaloneSettings: android,version name (same as LC IDE: Version Name) and cRevStandaloneSettings: android,version code (same as LC IDE: Version Code) of the LC IDE?

The changes won't ever show up in the cRevStandaloneSettings. They are only applied when you package up the application and the settings are applied to a temporary stack that is used to build the standalone.

[trevordevore]

My UI components are all livecode binary stacks. I only use one card per component,

I can see the advantages but are there any drawbacks in doing this or anything to watch out for?

It looks like you are already considering the major drawbacks - cards sharing a group and visual properties like font and colors that can be set at the stack level. You don't have to worry about stack size. If you use `go stack "Untitled 2" in window "Untitled 1"` then stack "Untitled 2" will appear at the current size of stack "Untitled 1".

My projects rarely have stacks with more than one card although my preferences stack does have two or three. I don't bother splitting that up into different stacks. It may be that for the design needs of your project keeping everything together is best. For my Bell Conductor application the configuration screen and playback screen are so different that it made sense to break them up into different stacks. How many cards are you dealing with?

Maybe another drawback would be that it's harder (& slower?) to communicate between cards if they are in different stacks.

This won't be a factor at all.

[jim1001]

The changes won't ever show up in the cRevStandaloneSettings. They are only applied when you package up the application and the settings are applied to a temporary stack that is used to build the standalone.

Maybe we're at cross-purposes here but I've found that the LevureStandalone stack android cRevStandaloneSettings (and hence Android Basic Application Settings) do change to the app.yaml values after a levurePackageApplication call. The changes are preserved even if I exit LC after the build and choose not to save changes to the stack...

[trevordevore]

I was mistaken. The packaging code in Levure does in fact store and save the version info prior to packaging the application. A temporary standalone stack is created during the packaging process but the standalone version information is updated and saved to the actual standalone stack before the temporary copy is made.

[jim1001]

You don't have to worry about stack size. If you use `go stack "Untitled 2" in window "Untitled 1"` then stack "Untitled 2" will appear at the current size of stack "Untitled 1".

Thanks - that's good to know as is that communication between stacks isn't a problem.

How many cards are you dealing with?

With the current design I estimate about 10 different card layouts are required. I've designed them to be as uncluttered as possible so their layout is not complicated - however they are all distinct. The app is a self-help guide and includes a lot of video footage. It also allows users to take photos, write responses to activity questions and link to further information PDFs on the device. The first version of the app to be trialed won't use the internet.

[jim1001]

It looks like you are already considering the major drawbacks - cards sharing a group and visual properties like font and colors that can be set at the stack level.

Using a single stack with many cards for my UI, I wanted the same widget.navbar on all the cards to move between different screens of the UI. I put the navbar into a group which is shared across all the cards so that any changes to the group are propagated to all cards using it. If want to break up the UI into multiple stacks with a single card per stack (so that it's easier to manage in version control) what would be the best way to implement the navbar to avoid duplication?

Thanks for any advice.

[trevordevore]

You wouldn't be able to get around the fact that you would have multiple instances of the widget. You would have to write your own code that stored the master version of the navigation in a template and then updated it everywhere it appears if you make a change.

If you use a behavior then the code would be shared and you would only update the code in one place.

[jim1001]

Thanks Trevor for continuing to reply. The things I'm asking are as a consequence of adopting Levure with Git but if you think they'd be better off in a new thread then please don't hesitate to say.

You would have to write your own code that stored the master version of the navigation in a template

You've mentioned that you were experimenting with templates before and I can see you have a NoteTemplates stack in bellConductor although I’m sketchy as to how it works. Is there a standard way of implementing templates in LiveCode? Is there any lesson / post you can point me to describing how to implement & use?

A web search for "livecode templates" didn't turn up much. I also looked in the LC dictionary but I don’t think the templates talked about there are the same as you mean - could be wrong of course!

[jim1001]

Is there a standard way of implementing templates in LiveCode? Is there any lesson / post you can point me to describing how to implement & use?

Are they also known as as Custom Controls? http://lessons.livecode.com/m/4071/l/22 ... m-controls

[trevordevore]

A custom control is a group that is intended to act as a single control. A data grid is an example of a custom control. Widgets can replace custom controls in many cases.

In LiveCode there is the concept of templateGroup, templateField, etc. This settings applied to these template objects affect the properties of new controls. The idea is similar to what I'm referring to but these are not the templates that are used.

The NoteTemplates stack in the Bell Conductor app contains the templates of each note that can be displayed during playback of a song. When playing a note in a song the code looks for the note in the NoteTemplates stack and copies it to the playback stack. These notes are created and deleted while the song is played. Any changes that are made to the template will then be used the next time a song is played.

The concept is somewhat similar to what I referred to in creating a template for your header. You would have a widget, standard control, or custom control somewhere that represents your navigation control. You would write code that copies it into all of the cards that use it, replacing an existing instance of the control. You would run this code anytime you made changes to the navigation.

I hope that makes sense.

[jim1001]

Trevor, thanks for the explanation. As I understand it then your notes templates are home-made & not part of core LiveCode.

Any changes that are made to the template will then be used the next time a song is played.

You've lost me there. I would have thought a template was fixed (at least in any one version of an app) but you make minor changes to the objects / instances which are created from it.

Anyhow, as a trial, instead of adding another card to my single UI stack I added a single card stack and managed to link it with the main UI stack. Made it look to user like they share the same navigation bar. Used a new instance of the nav bar widget but set its items for all cards of the UI with the same library command. Probably trivial to many but made me happy.

To include the navigation bar widget in the Android standalone I had to check it on the Inclusions pane of the LevureStandalone. Not sure if there's any other way with Levure.

[trevordevore]

As I understand it then your notes templates are home-made & not part of core LiveCode.

That is correct.

Any changes that are made to the template will then be used the next time a song is played.

You've lost me there. I would have thought a template was fixed (at least in any one version of an app) but you make minor changes to the objects / instances which are created from it.

In the Bell Conductor application that template is not modified after a new version of the app is packaged. What that means is that there is no code in the application that modifies the note templates while the application is running. Any modifications are made by hand in the IDE. The point I was trying to make was that changing properties of a note template control will change what the note looks like when you play a song the next time. It doesn't really matter whether that change is made in the IDE during development or in a packaged application. The properties of the template control affect what copies of the control will look like.

Anyhow, as a trial, instead of adding another card to my single UI stack I added a single card stack and managed to link it with the main UI stack. Made it look to user like they share the same navigation bar. Used a new instance of the nav bar widget but set its items for all cards of the UI with the same library command. Probably trivial to many but made me happy.

Great!

To include the navigation bar widget in the Android standalone I had to check it on the Inclusions pane of the LevureStandalone. Not sure if there's any other way with Levure.

That is the proper way to include widgets.

[jim1001]

The point I was trying to make was that changing properties of a note template control will change what the note looks like when you play a song the next time

OK - clear now, thanks.

Now I’ve found another problem that has led to deeper questions.

Navigation around my multiple stack UI works fine in the IDE. However not on an Android tablet. So I started to have a poke around at various things along the way.

One thing I was checking was the IDE stack files tab for one of my single card UI stacks, called say UI1. I had a card behavior and stack behavior stack listed. I noticed the file paths were pointing to the behaviors folder of a different UI stack, say UI2/behaviors. Now let’s say I clear out both leaving me with no listed stack files. Then first I add the stack behavior stack. It appears listed as “behaviors/UI1_stack_behavior.livecodescript”. (I assume that this path is relative to the folder of the UI1 stack). Then I add the card behavior stack. It appears listed as “behaviors/UI1_card_behavior.livecodescript”. But then I notice that the IDE has changed the File Path for the stack behavior stack I added first which now appears as “C:/…../UI2/behaviors/stack_behavior.livecodescript”.

Why has it changed and why is it pointing to the absolute path of UI2/behaviors when I chose the file from UI1/behaviors? I also think that if the app is going to be installed on a tablet I need relative paths not absolute ones.

Let’s leave it at that for this post - thanks!

[trevordevore]

One thing I was checking was the IDE stack files tab for one of my single card UI stacks, called say UI1. I had a card behavior and stack behavior stack listed. I noticed the file paths were pointing to the behaviors folder of a different UI stack, say UI2/behaviors. Now let’s say I clear out both leaving me with no listed stack files. Then first I add the stack behavior stack. It appears listed as “behaviors/UI1_stack_behavior.livecodescript”. (I assume that this path is relative to the folder of the UI1 stack). Then I add the card behavior stack. It appears listed as “behaviors/UI1_card_behavior.livecodescript”. But then I notice that the IDE has changed the File Path for the stack behavior stack I added first which now appears as “C:/…../UI2/behaviors/stack_behavior.livecodescript”.

Why has it changed and why is it pointing to the absolute path of UI2/behaviors when I chose the file from UI1/behaviors? I also think that if the app is going to be installed on a tablet I need relative paths not absolute ones.

By any chance do your behavior stack files use the same name in memory? If you have two behaviors that are both named "Stack Behavior" in memory then perhaps it could confuse the IDE.

[jim1001]

By any chance do your behavior stack files use the same name in memory? If you have two behaviors that are both named "Stack Behavior" in memory then perhaps it could confuse the IDE.

Don’t think that is the problem. Before I saw your post I had tried re-creating the behavior files with different file names and different (unique) script names but it didn’t make any difference. I think I may have put them in the wrong UI folder originally which the IDE seems to have memorised and I’m unable to erase that memory. I’ve tried to recreate the problem with a new Levure project but haven’t been able.

As a possible workaround and also because it may be better in long term for version control I’ve tried to set up a behavior by script.

I inserted the following lines in app.livecodescript:

Code: Select all

command InitializeApplication
# Called after script-only stacks, extensions, and externals in app.yml are loaded.
# Perform initialization operations before UI stack is opened.
local myPath, theStackFileIsLoaded
put levureAppFolder() & "/" & "ui/ui1/behaviors/stack_ui1_behavior.livecodescript" into myPath
set the stackFiles of stack "ui1" to myPath
put there is a stack myPath into theStackFileIsLoaded --checking existence of behavior stack loads it into memory if it exists
if theStackFileIsLoaded then
put "stack " & myPath & " is loaded"
set the behavior of stack "ui1" to stack "stack_ui1_behavior"
else
put "stack " & myPath & " not loaded"
end if

The put command tells me the behavior stack script is loaded but I get the error

Code: Select all

Type	Chunk: source is not a container
Object	app
Line	set the behavior of stack "ui1" to stack "stack_ui1_behavior"
Hint	InitializeApplication

stack_ui1_behavior.livecodescript currently contains only one line:

Code: Select all

script "stack_ui1_behavior"

Any idea what I’m doing wrong?

Thank you.