Creating LiveCode applications that play well with git

[jim1001]

Try moving your Levure project to the local drive on Windows and try again. It should work.

Thanks. Yes it did. apk created fine.

The rename command doesn't work with network folders

You can use the Windows xcopy command with network folders then remove the source after copying - that any use?

[trevordevore]

Yes, xcopy could be used. I am filing a bug report, however, as `rename` really needs to work in this situation.

[trevordevore]

`rename folder` bug: http://quality.livecode.com/show_bug.cgi?id=19954

[jim1001]

The Wiki documentation is really a great help. I've started using Levure with Git for my main (Android) project and all the signs are that it's a big leap forward from the disorganized way I was working before. I feel like I'm now developing on solid foundations.

I've just come across https://github.com/trevordevore/levure/ ... oid-device. Very clear description and works like a charm.

Thanks to all involved.

[trevordevore]

Glad to hear it Jim.

I've been working on the "rename" issue. Turns out that not being able to rename folders across volumes is in the docs. I've reworked the code to use revMoveFolder and rename. I will be posting an update to Levure so that you can build on network drives attached to Windows within the next few days.

[jim1001]

Does anyone have any advice / recommendations on Git workflow with a LiveCode Levure project?

I’m working alone on a LiveCode Levure project and thinking of using git-flow to further organize my work. A general question seems to be: How do you fit the binary UIs produced with LiveCode into the Git workflow?

Specifically, the app I'm currently producing has to function in two languages, Swedish and English. As well as the UI language difference there will also be language specific audio and video files.

I’ve just started developing in English and at the moment am only using a master branch and backing this up to GitHub. I was thinking to develop one app with a user controlled language switch but maybe with Git could have two separate branches and therefore two separate apps for Swedish & English.

Thanks,
Jim

[Mikey]

The binary stacks (which, if you like, could be limited to the UI pieces, and no code), are put in the UI folder of a Levure project. Once you get the UI set, they may not change very frequently, and therefore they may not be very problematic.

Git will handle binary files the same as text-only files. It's just that unless you speak binary, you won't be able to look at the changes in the binary file and see what those changes mean.

[trevordevore]

Does anyone have any advice / recommendations on Git workflow with a LiveCode Levure project?

Yes I will be giving a presentation on git workflow at the LiveCode Global conference next week: https://livecode.com/global/#schedule

I’m working alone on a LiveCode Levure project and thinking of using git-flow to further organize my work. A general question seems to be: How do you fit the binary UIs produced with LiveCode into the Git workflow?

As @mikey said, you will still use Git with your binary `ui` stacks. You just won't be able to see granular changes in the ui stacks like you do with the script files. A couple of things:

1. Rather than use substacks, move all ui stacks into individual `ui` components. The more granular your organization the better idea you have of what changed when you make changes to a part of the UI.
2. Make sure you move your scripts out of the binary stack file and into script only stack behaviors.
3. When you do change the UI and make changes to a binary stack file provide a detailed description of what changed in the git commit message.

If you haven't watched the screencast or read the wiki page on `ui` components then make sure you review that as well:

https://github.com/trevordevore/levure/ ... -and-above

Specifically, the app I'm currently producing has to function in two languages, Swedish and English. As well as the UI language difference there will also be language specific audio and video files.

I’ve just started developing in English and at the moment am only using a master branch and backing this up to GitHub. I was thinking to develop one app with a user controlled language switch but maybe with Git could have two separate branches and therefore two separate apps for Swedish & English.

I would not recommend using different branches to manage the languages. I think you can manage the languages using the build profiles in Levure and a translation library. This will be easier than continually merging changes to the main app between the two branches. Here is one idea on how to set things up so that you have a dedicated english app and a dedicated swedish app. This is just an example. I'm not saying that this is the right solution. It may be better to have one app with both languages.

1. Add two new build profiles to the `app.yml` file. One for english and the other for swedish. Each build profile will have a copy files section that copies the relevant files for the target language.

Code: Select all

build profiles:
 ...
  release-en:
   copy files:
      all platforms:
        - filename: english folder
  release-sv:
   copy files:
      all platforms:
        - filename: swedish folder

2. Add a library to handle translations. I have a very basic Helper available here:

https://github.com/trevordevore/levurehelper-translate

The helper allows you to store your translation strings in a YAML file located in a `locales` folder. The YAML file consists of keys and values. The key is the identifier used in the `_t()` function. The value is the translation for the currently active locale. The `app.yml` file would be updated like this in order to make sue the proper YAML files are included with the packaged application:

Code: Select all

build profiles:
 ...
  release-en:
   copy files:
      all platforms:
        - filename: ./english assets
        - filename: locales/en.yml
  release-sv:
   copy files:
      all platforms:
        - filename: ./swedish assets
        - filename: locales/sv.yml

3. In `app.livecodescript` set the appropriate locale when the application starts up. You can do that in the `InitializeApplication` handler. The following example sets the language to english unless the version of the app that was packaged using the `release-sv` build profile:

Code: Select all

command InitializeApplication
  if levureBuildProfile() is "release-sv" then
    translateSetLocale "sv"
  else
    translateSetLocale "en"
  end if
end InitializeApplication

[jim1001]

Mikey, Trevor, thanks for the helpful advice.

The binary stacks (which, if you like, could be limited to the UI pieces, and no code), are put in the UI folder of a Levure project. Once you get the UI set, they may not change very frequently, and therefore they may not be very problematic

I think I should modify the way I’m working a bit then. I’ve been creating bits of the UI as I’m going along and writing code to go with those bits. Maybe I should try & create the whole app UI from the start and once that's done only then start writing code to make it functional.

Make sure you move your scripts out of the binary stack file and into script only stack behaviors.

Yes - I’ve been doing this from the start of using Levure with Git. The benefits are great.

When you do change the UI and make changes to a binary stack file provide a detailed description of what changed in the git commit message.

Yes, something you have touched on before & I’ve been doing this from the start

Rather than use substacks, move all ui stacks into individual `ui` components

I currently have one UI stack with many cards and am creating numerous behavior script files for objects in that stack. Are you talking about splitting the graphical UI stack into many components? Are your components still LiveCode stacks? I’ve seen creating UIs 1) from a single stack with substacks and /or 2) a single stack with many cards but haven’t seen one split into many UI stacks...

Here is one idea on how to set things up so that you have a dedicated english app and a dedicated swedish app. This is just an example. I'm not saying that this is the right solution. It may be better to have one app with both languages.

Thanks for the idea which I’ll look into.

I will be giving a presentation on git workflow at the LiveCode Global conference next week

Thanks - will make sure I get to see that

[trevordevore]

I think I should modify the way I’m working a bit then. I’ve been creating bits of the UI as I’m going along and writing code to go with those bits. Maybe I should try & create the whole app UI from the start and once that's done only then start writing code to make it functional.

I think you can work either way. When I'm working on my own or exploring ideas I typically do what you are doing. When I have a designer working on the UI then the whole UI is created first and then I hook it up.

I currently have one UI stack with many cards and am creating numerous behavior script files for objects in that stack. Are you talking about splitting the graphical UI stack into many components? Are your components still LiveCode stacks? I’ve seen creating UIs 1) from a single stack with substacks and /or 2) a single stack with many cards but haven’t seen one split into many UI stacks...

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

You can see a basic example of this in a github repo for a mobile app I converted to Levure. Here is the `ui` folder contents:

https://github.com/trevordevore/bell-co ... ter/app/ui

The "configuration" and "playback" `ui` components are the ones that are displayed to the user on the mobile device. In `app.livecodescript` the `OpenApplication` handler opens the configuration screen using `go stack "configuration"`:

https://github.com/trevordevore/bell-co ... script#L43

When it is time to play the song I use `go stack "Playback" in window (the short name of this stack)`:

https://github.com/trevordevore/bell-co ... script#L68

[jim1001]

You can see a basic example of this in a github repo for a mobile app I converted to Levure.

Very helpful to see an example - thanks. I was going to ask how you communicate between two cards that belong to two different stacks if you split like this but then I found that you use the current_session.livecode script as a library to set, get & store data between the stacks. I’m learning...

This may be a daft question but do you ever split the UI into stacks that contain something you want that’s smaller than a single card? I know every stack has to have at least one card but perhaps you can use dummy cards…

ps: might get onto Kidsplay for some colored bells. Strictly for app testing you understand!

[trevordevore]

This may be a daft question but do you ever split the UI into stacks that contain something you want that’s smaller than a single card? I know every stack has to have at least one card but perhaps you can use dummy cards…

It sounds like you are talking about templates that can be inserted into another stack. I've been experimenting with that. Depending on your project it may or may not be worth the effort.

ps: might get onto Kidsplay for some colored bells. Strictly for app testing you understand!

The bells are lots of fun. When used with the app I've had a group of 4 year olds play songs that sounded pretty good.

[jim1001]

I think you can manage the languages using the build profiles in Levure and a translation library.

I had a closer look at what you'd written and it looks like a very elegant solution. I'll going to give it a go.

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?

In the "traditional" way of LiveCode working the app I'm developing now would have one stack with many cards and each card sharing many design elements with the others, e.g. size, text size, navigation bars etc. Would having each card in its own stack mean having to specify these multiple times, once for every card-stack and overheads at run-time? It looks like you did this for the stack size of each UI stack in the bellConductor app.

Perhaps all the set up could be put into library functions / commands shared by all?

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

[Mikey]

Jim,
I'm doing what you do.

[jim1001]

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?

ps: I'm using Levure commit e96eb49

Thanks.