Begriffserklärung

App-Repository

Der Ort, wo Apps hochgeladen werden. Aktuell: Der FTP-Ordner einer App.

Runtime-Ordner

Ein Ordner auf dem AppServer, worin sich eine Kopie aller Dateien einer App aus dem App-Repository befindet. Beim Start der App werden alle Dateien der App aus dem App-Repository in den Runtime-Ordner kopiert.

Shared-Ordner

Ordner im App-Repository, mit denen Code zwischen allen Apps geteilt werden kann.

Nutzerlöschung

Für den Fall, dass eine App deaktiviert war, während relevante User gelöscht wurden, werden die Aufrufe des Hooks (und anschließende Löschung) gedrosselt nach dem App-Start nachgeholt. Dies gilt auch für den Release des Features. Alle bisher gelöschten User werden dann einmalig durch den Hook durchlaufen und danach gelöscht werden. Für zukünfitge Löschungen funktioniert es so, dass diese sofort nach der Löschung des Users bei allen laufenden Apps den Hook und die Löschung auslösen. Weitere Details in der Doku von App.onUserDeleted().

2-Phasen Release:

Die Löschung der Persistenz-Daten und Accessibility gelöschter User wird vorerst nur dann aktiviert werden, wenn die App den onUserDeleted-Hook implementiert. Diese Übergangsphase gibt euch die Möglichkeit euch zu überlegen, ob ihr den Hook benötigt und ihn ggf. zu implementieren. Nach der Übergangsphase (mindestens 2 Monate) wird das System umgestellt werden, sodass die Persistenz-Daten und Accessibility stets sofort nach der Löschung eines Users gelöscht werden.

Shared-Ordner für Source-Code und www

Wenn man mehr als eine App hat, kommt es vor, dass man den gleichen Source-Code gerne für mehrere Apps verwenden möchte. Die App-Server bieten nun folgende Funktion an um dies zu vereinfachen:Man kann nun im App-Repository (FTP-Ordner) zwei Ordner anlegen, welche automatisch beim App-Start (für alle Apps) kopiert werden: ftp/shared/ – wird nach /shared/ kopiert. ftp/wwwShared/ – wird nach /www/shared/ kopiert und ist, wie alles in www, in der App-UI verfügbar.

Beispiel: (Datei-Struktur im FTP)

ftp/shared/script1.js

ftp/wwwShared/script2.js

ftp/wwwShared/style.css

ftp/app1/main.js

ftp/app1/www/index.html

ftp/app2/main.js

ftp/app2/www/index.html

Wenn nun app1 oder app2 startet, werden folgende Dateien im jeweiligen Runtime-Ordner verfügbar sein:

app1:

main.js

shared/script1.js

www/index.html

www/shared/script2.js

www/shared/style.css

app2:

main.js

shared/script1.js

www/index.html

www/shared/script2.js

www/shared/style.css

Wissenswerte Details

Copy-Channel verbessert

Die Test-Funktion /apps openCopyChannel kann nun mehrfach ausgeführt werden und erzeugt bei jedem Aufruf einen weiteren Sub-Channel (bis zum Limit von 9 Sub-Channels).

Verkürzung der www Resource-URLs

Die API bietet Funktionen um öffentliche URLs zu den Dateien im www-Ordner zu bekommen. Diese URLs waren bisher sehr lang und kompliziert, was verschiedene Probleme verursachte. Nun sind sie kurz und einfach.

Verbesserung für Multi-(Sub-)Channel-Apps

Bisher war es so, dass beim Start einer Sub-Channel App diese die App-Sourcen komplett neu aus dem App-Repository gezogen hat. Mit anderen Worten: Es konnte passieren, dass die App-Instanz im Sub-Channel neuer war als die im Haupt-Channel (bzw. in anderen Sub-Channeln). Durch die Änderung wird nun für Sub-Channel-Apps der gleiche Runtime-Ordner verwendet wie für den Haupt-Channel.

Als Nebeneffekt davon können Sub-Channel-Instanzen nun nur noch starten, wenn die Haupt-Instanz bereits läuft. Ausserdem sind nun auch die www-Resource-URLs für alle Sub-Instanzen die gleichen. Bisher hatte jede Sub-Instanz eine eigene Kopie der Dateien mit einer eigenen URL.

Hinweise bezgl. Headerbar

Die Breite bei setSize() wird ignoriert. Die Höhe ist auf 20 – 500 limitiert.

Client.getHostFrame().setSize(0, 200);
Im HTMLChat scheint per default der Channel-Hintergrund durch die Headerbar durch. Um dies zu unterbinden muss man lediglich dem <body> eine Hintergrund-Farbe geben.

Wiki

User Apps / Development