Eine Studio-App erstellen
Ziel
Eine Studio-App erstellen – eine Anwendung, die Sie zeichnen, statt sie aus den Feldern einer Tabelle aufzubauen.
Wenn dies Ihre erste ist, führt Ihre erste Studio-App bauen Sie den ganzen Weg – eine Tabelle, ein Bildschirm, eine Liste, die daraus stammt, eine Symbolleiste und ein Seitenbereich, der einen Datensatz zurückschreibt – in etwa vierzig Minuten.
Was eine Studio-App ist
Die Plattform hat drei Dinge, die Sie zeichnen, und sie sind nicht dasselbe.
- Ein Bericht ist Papier. Er hat Seiten, er wird jedes Mal gleich gedruckt, und was er erzeugt, ist ein Bild eines Dokuments.
- Ein Dashboard sind Zahlen. Sie zeichnen die Bereiche und markieren, wohin jedes Widget kommt, und die Plattform füllt diese Stellen mit ihren eigenen Live-Diagrammen und -Rastern.
- Ein Bildschirm ist die Anwendung selbst. Alles, was Sie zeichnen, wird ein echter Teil der Seite – ihr Text lässt sich markieren, ihre Kästen sind echte Kästen, und später nehmen ihre Eingabefelder einen Cursor auf und ihre Schaltflächen tun etwas.
Zu einem Bildschirm greifen Sie also, wenn Sie weder ein Formular über einer Tabelle noch eine Seite voller Zahlen wollen, sondern ein Stück Anwendung, das so angeordnet ist, wie Sie es möchten.
Was Sie zeichnen, läuft wirklich, und es gibt zwei Wege, es zu erreichen. Es erscheint eigenständig in der App-Liste der Shell, neben Ihren modellgesteuerten Apps, mit nichts drumherum außer der eigenen oberen Leiste der Plattform – siehe Eine Studio-App eigenständig ausführen. Und es kann in der Navigation einer modellgesteuerten App platziert werden – so steht eine gestaltete Landingpage über einer Liste von Datensätzen –, siehe Eine Studio-App aus einer modellgesteuerten App öffnen.
Voraussetzungen
- Sie sind als Ersteller angemeldet, mit ausgewählter Umgebung und Lösung.
Schritte
- Öffnen Sie Ihre Lösung, und wählen Sie Bildschirme.
- Drücken Sie Neu.
- Geben Sie einen Anzeigenamen ein – das, was Sie in dieser Liste sehen werden. Der logische Name füllt sich während der Eingabe selbst aus; er beginnt mit dem Präfix Ihres Herausgebers.
- Beschreiben Sie optional, wofür der Bildschirm da ist. Das liest jemand anderes, wenn er entscheidet, ob dies der Bildschirm ist, den er sucht.
- Wählen Sie, was diese App ist – siehe die drei Arten unten. Lassen Sie es auf Anwendung, es sei denn, Sie zeichnen eine Seite einer modellgesteuerten App oder ein Portal.
- Wählen Sie optional ein Symbol. Es ist das Bild auf der Kachel dieser App in der App-Liste, aus demselben Satz, aus dem jedes Symbol der Plattform stammt. Lassen Sie es weg, zeigt die Kachel ein Fenster – so sieht eine gezeichnete App überall sonst aus –, aber eine Reihe von Kacheln, die alle dasselbe Fenster zeigen, ist eine Reihe, in der man nichts findet; die zehn Sekunden lohnen sich also.
- Drücken Sie Speichern.
- Drücken Sie bei ausgewähltem Bildschirm Entwerfen, um die Zeichenfläche zu öffnen – siehe Eine Studio-App zeichnen.
Die drei Arten von Apps
Jede App sagt, wofür sie da ist, und das entscheidet, wo sie verwendet werden kann. Das müssen Sie als Erstes richtig machen, denn die beiden anderen Einstellungen hängen davon ab.
| Was sie ist | Wo sie erscheint | |
|---|---|---|
| Anwendung | Etwas, das Personen öffnen. Der Standard. | Die App-Liste – und sie kann auch eine Seite innerhalb einer modellgesteuerten App sein |
| Seite einer App | Ein Bildschirm, der in eine modellgesteuerte App gehört | Die Navigation dieser App und sonst nirgends. Sie bekommt keine eigene Kachel |
| Portal | Ein Bildschirm, der unter einer Webadresse für Personen veröffentlicht wird, die nicht angemeldet sind | Die Adresse seines Portals und sonst nirgends |
Ein Portal ist das eine, das wirklich nirgendwo anders laufen kann, und deshalb wird die Wahl
abgelehnt und nicht nur davon abgeraten. Ein Portalbildschirm liest seine Daten über benutzerdefinierte
APIs (api:…) – so liest ein Portal, und genau das lässt die Plattform-Shell bewusst nicht zu –, eine
Portalzeichnung in einer modellgesteuerten App wäre also eine Seite, die jedes Mal fehlschlägt, wenn
jemand sie öffnet. Wählen Sie Portal, und die App wird modellgesteuerten Apps nicht mehr angeboten,
sondern auf der Seite Portale; wählen Sie etwas anderes, und kein Portal veröffentlicht sie.
Die Art einer App später zu ändern, ist erlaubt, und es wird gegen das geprüft, was bereits auf sie verweist: Sie können die eigene Zeichnung eines Portals nicht in eine gewöhnliche App umwandeln, solange dieses Portal sie veröffentlicht.
Die zwei Kontrollkästchen
Der Dialog Neu (und Bearbeiten) hat zwei Kästchen, und ihre Standardwerte zeigen absichtlich in entgegengesetzte Richtungen. Sie werden nur bei einer Anwendung angezeigt: Eine Seite lebt in einer modellgesteuerten App, und ein Portal antwortet unter seiner eigenen Adresse, sodass keines von beiden eine Kachel in der App-Liste oder eine Plattformleiste zum Ausblenden hat.
| Beginnt | Was es bewirkt | |
|---|---|---|
| Komponenten dieser App teilen | aus | Jede andere App in dieser Umgebung kann die hier gezeichneten Komponenten platzieren – siehe Eine Komponente in einer anderen App verwenden |
| In der App-Liste anzeigen | an | Personen, die diese Umgebung verwenden, sehen diese App in der App-Liste der Plattform-Shell |
Bei den meisten Apps soll keines davon geändert werden: Eine App ist etwas, das jemand öffnet, und sie behält ihre Komponenten für sich.
Das Teilen von Komponenten ist absichtlich keine der Arten: Eine gewöhnliche App kann einer anderen
ihre Teile leihen, ohne eine Bibliothek zu sein – das Beispiel Studio — Shared Components besteht aus
zwei Apps, die genau das tun.
Drehen Sie beide um, und Sie haben eine Komponentenbibliothek – eine App, deren Aufgabe es ist, die
Teile zu enthalten, aus denen Ihre anderen Apps gebaut sind, und für die niemand, der das Produkt
benutzt, eine Kachel bekommen sollte. Das Beispiel Studio — Component Library ist genau das.
Das Deaktivieren von In der App-Liste anzeigen verbirgt die Kachel, nicht die App. Sie ist weiterhin hier im Erstellerportal – dorthin gehen Sie, um sie wieder einzublenden –, und alles, was auf einen ihrer Bildschirme verlinkt, öffnet sie weiterhin: die Navigation einer modellgesteuerten App, ein Link auf einem anderen Bildschirm, eine Adresse, die sich jemand gemerkt hat. Was eine Person öffnen darf, ist eine Frage der Berechtigungen, und dies ist keine.
Was Sie nachträglich nicht ändern können
Den logischen Namen. Alles, was einen Bildschirm erreicht, nennt ihn, eine Umbenennung würde also jeden dieser Verweise auf einmal und ohne Hinweis unterbrechen. Anzeigename und Beschreibung können Sie jederzeit ändern.
Wo ein Bildschirm lebt
Ein Bildschirm ist eine Komponente Ihrer Lösung, wie ein Formular oder eine Ansicht. Er ist also versioniert, reist mit, wenn Sie die Lösung exportieren und in eine andere Umgebung importieren, und wird wieder entfernt, wenn die verwaltete Lösung, die ihn mitgebracht hat, deinstalliert wird.
Einen Export eines einzelnen Bildschirms in eine Datei gibt es absichtlich nicht: Ein Bildschirm, der außerhalb einer Lösung herumgetragen werden könnte, ist ein Bildschirm, dessen Umgebung niemand nachbilden kann.
Fehlerbehebung
- „…must be lower snake-case and start with the publisher prefix.“ – Der logische Name muss mit dem Präfix Ihres Herausgebers beginnen und Kleinbuchstaben, Ziffern und Unterstriche verwenden. Geben Sie zuerst den Anzeigenamen ein, und lassen Sie den logischen Namen sich selbst ausfüllen.
- „A screen named … already exists in this environment.“ – Dieser Name ist vergeben. Bildschirme werden über ihren Namen erreicht, daher können sich zwei keinen teilen.
- Jeder Bildschirm zeigt „Nur Zeichnung“. – Das ist in diesem Release zu erwarten. Siehe den Hinweis oben.