Applications at their core are all about:
- gathering data from users (e.g. the user picks a day for a weather forecast) and other applications (e.g. the weather channel)
- processing that data
- returning the results in various forms to the user and other applications
In this article, we will discuss the facilities provided by the platform for exchanging data between pages and components. This is essential for different kinds of mechanisms including navigating through pages, updating parts of the user interface, and triggering functions such as sending a text message.
All related Blockly blocks can be found in "Actions"/"project data" section.
There are two channels of data exchange:
- Session. All data in this channel are lost once the app is closed
- Local (Storage). All data in this channel are preserved in the specific browser (for web apps) or device (for mobile apps) and available the next time the app opens.
In both channels you can save data behind a key, load (retrieve) that data using their key and register for listening to any changes at a specific key. Depending on your background you can consider those channels as a set of global variables, a HashMap or just a block of lockers where you store different kinds of stuff and use a key to open them and get that stuff out.
Let's focus on the locker metaphor for the moment. Student A (a component or page) gets a locker and its key. Student A shares a copy of the key with student B (another component or page). Student B informs student A that she is interesting to get notified whenever the contents of the locker change ("on change" block). At some point, student A opens the locker with the key and puts a book in it ("save" block). Then she sends a text message to student B to notify her on the change. Then student B opens the locker and gets the book ("load" block).
Apart from the differentiation in terms of data persistence mention previously, both channels work in the same way. So let's elaborate more on the "Session" channel.
Save to Session
What we can store behind a session key can be anything from simple text (strings of characters) to complex data structures. In the latter case, we can directly access a part or field of those structures directly. Let's suppose we want to store data about the current user of our app. Example fields could be name, email, and age. In that case, we can use the dot notation. So if the key is "current_user" then the key "current_user.name" would refer to the "name" field in the data structure.
Load from Session
The "load" block just reads and returns whatever was stored behind the specified key. We can "save" in one page or component and "load" in the same or any other page or component. The dot notation can be also used here to retrieve a field of a complex data structure directly.
Delete from Session
The "delete" block is apparently for deleting the contents behind a specific key.
On Session changed
This is a very important block as it expresses the interest of a page or component in getting notified regarding any changes behind a specific key. A function name is given to specify the function to be called once a change occurs. Again the data behind a specific key can be saved or loaded in the same or any other page and component where the "on changed" block is used. Additionally, more than one pages and components can register for change notifications.
Example of page navigation
A useful pattern for implementing page navigation using Session is the following:
In this example, we create a main component (not a page) that has no UI and server as the "switchboard" of the application. Based on changes in the session value behind the key "current_page" and an IF statement it replaces the contents of the app window with the page specified. Each page need code similar to that at the bottom of the screenshot to set the current page and trigger the logic in the main component.