Models organize and store data in App Maker. You can think of a model like a table in a database or a sheet in a spreadsheet. Spreadsheets organize data using named column headers, and store it in the sheet's rows. Similarly, models organize data into named fields, and store it in collections called records.
For example, imagine you work for a new startup, Weyland Corp, and are assigned to build an HR app that tracks employees' names, ID numbers, and dates of birth. In App Maker, you could make an
Employee model with four fields:
DateOfBirth. You'd then create a UI to populate that model with a record for each employee. Alternatively, here's how the data would be represented in a spreadsheet:
Types of models
There are five types of models:
Google Drive Tables—A model that stores data as files in your Google Drive. This model is the easiest to create, but it can't be used for large datasets or shared with multiple apps.
Calculated—A "virtual" model that uses scripts to produce data. This model lets you manipulate data from models or other sources, but requires significant server-side scripting to set up.
Google Cloud SQL—A traditional MySQL table that can be shared among multiple applications, and even integrated with existing Google Cloud SQL databases. This model supports a wide range of queries, but it requires more work to set up.
Calculated SQL—A query that is run against a Google Cloud SQL database.
Directory—A model that obtains information from your organization's directory, for example, email addresses and phone numbers.
The model editor
The model editor is where you define the structure and settings of your models. App Maker directs you to the editor after you create a model, and you can return there at any time by clicking your model's name in the left-hand nav bar. The editor has six tabs:
Fields—Add new fields to a model and adjust settings for existing fields. For example, you could add a
HireDatefield to the
Datasources—Define how a model retrieves and stores data when queried, including the subset of records it returns. For example, you could create a datasource for the
Employeemodel that only returns active employees when queried.
Events—Create server-side scripts that run when your app displays, creates, or deletes records. For example, you could write a script for the
Employeemodel that automatically populates the
HireDatefield when a user creates a new employee record.
Relations—Describe relationships between records within a model or across models. For example, you could establish relations in the
Employeemodel between a manager and their direct reports.
Security—Control which users can create, load, save, or delete records in a model. For example, you could restrict the
Employeemodel so that only employees could view the records in the model.
When a model is selected in the left sidebar, a dropdown for selecting the default display field appears in the action bar. Choose a display field specifies which field to use when
referring to a record of that model. A display field is commonly used for widgets that select a record like dropdowns. An alternative approach is to specify the display field by binding the
names property of a widget to the field you want to display.