20 articles about Studio apps, in reading order.
Studio apps
A Studio app is a screen you draw on a canvas and then tell what each part is. Saving turns the drawing into a real web page that reads and writes your records. Here's what that means, and when to draw a screen instead of laying out a form.
Studio apps
Create a Studio app, draw its one screen with a heading, a line of text and a button, give the button something to do, and open the app from the Platform Shell. About ten minutes, from nothing.
Studio apps
A Studio screen that greets whoever opened it by name and says which account they are signed in with, then gives them a link to each app they use. Two bindings and three links.
Studio apps
Draw a screen with the plain Frame and Text tools, then tell the platform what each part is: the screen, a heading, a paragraph, a text box, a dropdown, a date picker, a button. The role decides what each one becomes when the app runs.
Studio apps
Three things make a drawn screen do something: state it remembers, bindings that read the state, and handlers that run when something happens. The visitor sign-in screen gets all three: a line that follows what is typed, a button that stays off until the form is filled in, and a Pressed handler.
Studio apps
Two ways to put a table's records on a Studio screen: load them into the screen's state as it opens and draw one row that repeats per record, or place the table's own view as a Table view control. One screen, both side by side, over the Contact table every environment has.
Studio apps
A drawn list that shows ten records at a time: a page number in the screen's state, one query that skips to it and counts the whole table, and Previous and Next buttons that switch themselves off at either end.
Studio apps
An Add a contact form on a Studio screen: three text boxes bound to state, a line that says what is still missing, a Save button that stays off until the form can be saved, and a handler that creates the record and reloads the list beside it.
Studio apps
A second screen in the same Studio app: press a contact in the list and its details open on a screen of their own, handed the record's id with navigate; a Back button and the browser's own Back both return to the list.
Studio apps
Two overlays on the Contact screen: a modal that asks before a contact is deleted and can't be walked away from, and a drawer that slides in from the end of the line to change the job title. Each is a drawn card, ticked as an overlay card and opened by one line in a handler.
Studio apps
Four links on the Contact screen: an email that opens the mail app, the same contact in a model-driven app, a web search in a new tab, and another screen of this app. Each is a real link, so middle-click, right-click and a screen reader all treat it like one.
Studio apps
An image picker on the Contact screen holds the photo somebody chose, and a Save photo button stores it in the contact's Photo field with one updateRecord. The picker is the platform's own control, so it previews, it refuses a file that's too big, and the stored photo shows up beside the contact in every list.
Studio apps
The Contacts list reloads its page every five seconds, so a contact somebody adds in another app appears without anyone pressing anything. It's a timer on the list, a binding that says how often, and a tick box that pauses it.
Studio apps
An Overview screen for the Contact list app: three tiles that each count contacts with one query, a donut of where they are, and the Contact table's own grid underneath. The tiles are drawn boxes, the chart and the grid are the platform's own.
Studio apps
A Today screen for the Contact list app whose content is your own task list: every step any process has asked you to do, the same rows as the inbox in the top bar. One control, one setting, and the app opens on it.
Studio apps
The Contact list app had a link or two in a different place on each of its four screens. Now it has one top bar, drawn once beside the screens, placed on all four, and changed in one place.
Studio apps
A capital request raised on a phone, in a drawn app 390 wide, and approved by a budget holder at a desk, in a model-driven app over the same table. Two people, two screens, one record, and one process between them.
Studio apps
A model-driven app, Contact desk, with the Contact list screens and the Contact table side by side in its navigation. The drawn screens open as its home page, their own links stay inside it, and the task inbox comes with it.
Studio apps
Contact list opened from the Shell's app list, with nothing around it: every screen at its own address, a top bar that says who's signed in and signs them out, and the platform's own bar switched off so the drawing fills the window.
Studio apps
One sample that is a whole application: six tables, an approval process, two reports and a phone app, a year into use. A walk round it one rail group at a time, and what each piece is doing for the others.
