When you imagine how a typical mobile application appears, it would be somewhat along these lines:

Sometimes, applications are entirely code-driven where every screen you see is created using code at the time that it's needed. Perhaps, it would already lay out the elements that are saved as resources and then the code would load these resources. In either case, the whole application could take place on the equivalent of one LiveCode card.

Another approach would be to lay out every possible screen combination as different cards or even stacks and to go to the card or stack that looks like how the app appears at that moment.

In the first case, you would need to run the application and go through the user actions in order to check whether the layout was correct. Then, you would need to go back and change the code or resources and try again. In the second case, you may face a lot of combinations of layout.

As we start making apps here, we'll try to find a middle ground where we'll use cards to set up the main screens we'll need and then we'll use code to show and hide other elements. Our goal is to try and be efficient and not create complex code to lay out items that could be laid out quickly by hand. We also don't want to use a lot of images when a small amount of code could get us the same results.

LiveCode is extremely flexible in terms of how you structure things that you make with it. In addition to a dozen different kinds of controls that could contain code, you can also control front scripts, groups, the current card, a mainstack, stacks in use, back script, and LiveCode itself. The following diagram shows you only a few example controls, but gives you the sense of how many levels there are to the hierarchy of LiveCode:

You can also have sub stacks that are often used to show dialog windows, the ability to add front and back scripts, and you can put stacks in and out of use too. Overall, it can get quite confusing!

It is largely a case of personal style as to where you put your scripts and often, you may have a reasonable argument why you did it in a certain way. You could argue that all the actions that take place should be in the script of the button you clicked on. It would make it easy to edit all the handlers involved and if you need the same features in another stack, you would only have to copy the button across. However, if you had a number of those buttons on the screen and needed to make changes, you would have to do so for all of them.

Another valid argument would be to say that all handlers are at the stack level. You would then have one central place to make changes, but you would have to make lots of if statements to check which control has been operated on.

You might want to reuse routines that you have developed over time and would have a set of stacks that you could put into use, where each stack just handles a particular aspect of the task at hand. In the world of Object-oriented Programming (OOP), it's quite common to extend this approach to a crazy degree with hundreds or even thousands of small files where each file handles a tiny portion of the overall application.

We won't go to any of these extremes. Instead, we will try to put code at the lowest level that it needs to be without duplicating the code, as you make additional controls that need the same code. While doing this, we will try to think ahead and spot efficiencies that we can use. Let's look at an example.

Suppose you have a main menu button and its function is to take the user back to the card named main. Having this as the button's script would make sense:

on mouseUp
  go card "main"
end mouseUp

It would appear to be the lowest level the code can be at and we're not going to duplicate it, as there's just one main menu button. However, suppose we want to track the user's progress, the main menu button won't know anything about that. So, we could do this instead:

on mouseUp
  navTo "main"
end mouseUp

In the card script, there would be this handler:

on navTo aCard
  saveNavState
  go card aCard
end navTo

The saveNavState function would be somewhere, saving the user's state. The only problem is that for each of the cards we make, which includes the main menu button, we will have to have this navTo handler in each of their scripts. Therefore, we'll put the handler in the mainstack stack script. With it being at this level, it can handle calls from any button on any card. The help button's script could be this:

on mouseUp
  navTo "help"
end mouseUp

Going to the help card would also save the user's state. Later, we could also add a visual effect as you jump from place to place and make that change in navTo instead of going around the various buttons that make use of the navTo handler.

There is a common term used to describe the LiveCode hierarchy that helps convey how information is passed up and down the hierarchy. What is that term called?

Answer: 2

For further reading, RunRev has an online lesson that describes the message path, which you can find at:

http://lessons.runrev.com/s/lessons/m/4603/l/44036-the-livecode-message-path