Table of Contents
Once your application project has been created the next step is to start adding new model elements, screens, layers, and controls that reflect the display and organization of the user interface you want to build. You can add much of this new model content through the Storyboard Designer editor or via the Application Model View using the menu item. This will generally add the selected item as a child of whatever the current selection is.
Storyboard provides a flexible model for you to organize your application, however there are some general guidelines that you should follow. Applications should have screens that represent the different modalities of the application. For example, a thermostat application may have a main screen, a separate screen for managing settings, and another for a manual override behavior. Having all of the screens of the application line up with the different operating modes that a user might encounter with the product means that a new developer can immediately engage with a new project. When compared to a traditional code-based approach this visual roadmap allows for faster iteration and development.
Similar to using multiple screens to provide immediate visual guidance on how an application operates, layers can be used to consolidate common visual experiences. For example, an application may have a common navigation or feedback interface that should be represented in all modes of operation. This common visual presentation can be placed into one or more layers and those layers used on multiple screens of the application. When a layer is shared in Storyboard, it is truly shared. The control content on the layer is not replicated or copied, but is a single reference. For this reason it can be an efficient design approach to segment content to multiple different layers that can be reused across multiple different screen contexts.
Using multiple screens and layers in a Storyboard application does not impose a significant memory or CPU overhead cost. Similarly, due to resource references, all image and font resources in Storyboard are pooled and centrally managed. Once an image (or font) is referenced you can use it in a different visual context without incurring any additional memory overhead. This can be an important consideration for deeply embedded applications that may want to offer a compelling user interface but have a limited amount of storage Flash or dynamic RAM. With a judicious selection of common images, or by using techniques such as nine-patch images, it is possible to have a rich and engaging experience with minimal resources.
As you create your application you will encounter a number of situations where you will need to determine the name of an object. This might be the name of a screen, layer or control if you aren't importing from Photoshop or this might be name of an event or event a Lua file or function. Begin consistent with your names will help your application stay organized and avoid conflict.
Storyboard establishes and reserves several namespaces to ensure that system events and actions do not conflict with user defined functionality.
This prefix is reserved for all of the Storyboard internal variables. These are the variables that are associated with specific properties of model objects and are generally manipulated from Lua scripts.
This prefix is reserved for all of the Storyboard
standard events. You will see this prefix when you are picking events to trigger your
actions. When you create your own events, you should avoid the gre. prefix.
This prefix is reserved for all of the Storyboard defined actions. This action is the runtime identifier and is something that you would encounter if you were creating your own actions using the Storyboard SDK product.
In addition to the reserved namespaces, Storyboard Designer enforces a number of naming rules:
Starts with a character a-z/A-Z not a digit or special character. Only _ (underscore) is supported as a special character and there can be no spaces in names.
Screens and layers must be uniquely named. Controls and groups can use the same names as long as they have different parent containers. Two controls within the same layer can't have the same name.
Variables can not have the same name as model objects in their parent container.
For example you can't declare a layer variable button and have a control
on the same layer named button.