Das Manifest

Das Manifest ist die einzige verbindliche Beschreibung einer App: defineAppManifest im SDK, die Prüfung beim Laden und die Ablage im Katalog lesen exakt dieselbe Form. Die Tabellen nennen jedes Feld mit Pflicht, Format und Wirkung; Beispiele stehen darunter.

Die Felder#

unlocks und connects werden ausgelassen statt leer gesetzt: Ein leeres Feld verschöbe den kanonischen Hash jeder bestehenden Fassung, ohne dass sich etwas geändert hat.

Der Block compatibility#

defineAppManifest verlangt den Block im Typ und zur Laufzeit: Ohne ihn wirft es mit einem Satz, der die drei Felder nennt. Jede Liste nennt einen Wert höchstens einmal.

Der Block translations#

Die Texte des Manifests stehen auf Deutsch, der Pflichtsprache. Jede weitere Sprache steht unter translations als eigener Block, der nur Texte trägt: displayName und description, store (Einzeiler, Langtext, Funktionen und Einrichtungsschritte in der Reihenfolge der deutschen), widgets je Kennung mit Name, Beschreibung und variants je Ansicht, resources je Kennung, permissions je Schlüssel, dataAccess.external in der Reihenfolge der Dienste und legal.disclaimerSummary. Kennungen, Werte und Regeln stehen nie in einem Block.

Ein Block ist vollständig oder gar nicht da: defineAppManifest prüft ihn mit appManifestTranslationIssues() und wirft beim Bauen, mit der Stelle beim Namen. Der Store antwortet in der Sprache, die das Portal erbittet, und fällt auf Deutsch zurück. Englische Begriffe folgen den Portalen: display, nie screen, die Leinwand heißt video wall. pnpm app:check <id> prüft die Texte beider Sprachen nach der Hausregel, in der Zeile Texte.

Der legal-Block#

Ein neuer disclaimerKey macht ein Release zustimmungspflichtig: Sobald die neue Fassung als stable veröffentlicht ist, steht die Installation auf Update wartet. Wer den Hinweis inhaltlich ändert, hebt deshalb den Schlüssel, im selben Arbeitsgang wie Kurzfassung, Volltext und Fassung der App. Eine neu formulierte Kurzfassung bei gleichem Schlüssel übernimmt die Plattform still. Eine Manifest-Änderung ohne Versionssprung erreicht bestehende Installationen nicht.

Was nicht im Manifest steht#

• Fetcher und Jobs. Sie deklariert eine App als Decorator an Klassen ihres Server-Teils (@Fetcher, @JobHandler, @WidgetResolver); die Plattform entdeckt sie beim Start. Das Manifest bleibt reines Datenformat.
• Ob ein Ladefehler den Start abbricht. Das ist eine Eigenschaft der Installation und steht in der Server-Konfiguration des Betriebs; critical im Manifest ist nur Bericht.

Beispiel: das Manifest der Notdienst-App (gekürzt)#

import { defineAppManifest, RENDERER_HOST_RANGE } from '@szenera/apps-sdk/manifest';

export const manifest = defineAppManifest({
  id: 'pharmacies-on-duty',
  version: '1.3.0',
  displayName: 'Notdienst',
  description:
    'Zeigt die Apotheken im Notdienst rund um Ihren Standort, regelmäßig aktualisiert für ganz Deutschland.',
  tier: 'pro',
  category: 'geschaeft',
  vertical: 'pharmacy',
  schemaName: 'apps_pharmacies_on_duty',
  apiCompatibility: { appsSdk: '^0.2.0', rendererHost: RENDERER_HOST_RANGE },
  widgets: [PharmaciesOnDutyDisplayWidget],
  resources: [
    { ...PharmaciesOnDutyLocationResource, slug: 'locations' },
    { ...PharmaciesOnDutyScheduleResource, slug: 'schedules' },
  ],
  permissions: {
    tenant: [
      {
        key: 'pharmacies-on-duty.location.read',
        label: 'Standorte lesen',
        description: 'Hinterlegte Apotheken-Standorte ansehen, für die Notdienstpläne geladen werden.',
        defaultRoles: ['OWNER', 'MANAGER', 'MEMBER'],
      },
      // … weitere Rechte für das Team …
    ],
    platform: [
      {
        key: 'pharmacies-on-duty.crawler.config',
        label: 'Crawler konfigurieren',
        description: 'Betreiber-Recht: Quellen, Abrufintervalle und Parser des Notdienst-Crawlers einstellen.',
        defaultRoles: [],
      },
    ],
  },
  publisher: { name: 'Szenera' },
  signing: 'required',
  legal: {
    disclaimerKey: 'notdienst.bedingungen.v1',
    disclaimerSummary: 'Notdienstangaben stammen aus öffentlichen Verzeichnissen … und werden ohne Gewähr angezeigt …',
    termsPath: '/app-bedingungen/notdienst',
    requireAcceptanceAt: 'install',
  },
  preview: { iconUrl: '/apps/pharmacies-on-duty/icon.svg' },
  dataAccess: {
    external: [
      {
        name: 'Öffentliche Notdienst-Verzeichnisse (u. a. aponet.de)',
        purpose: 'Wir rufen die Dienstpläne für Ihre Standorte ab und halten sie aktuell.',
        sends: 'Postleitzahl und Umkreis der Standorte, die Sie angelegt haben.',
      },
    ],
  },
  // Die Dienstpläne holt der Server, das Display behält den letzten Stand im Schnappschuss.
  compatibility: {
    hosts: ['szenera-os', 'fire-tv', 'tizen', 'webos', 'web-display'],
    orientations: ['landscape', 'portrait'],
    offline: 'last-known',
  },
});

Formprüfung und Querregeln#

defineAppManifest prüft die Form gegen das Schema, wendet Vorgabewerte an (tier, critical, criticalForTenant, signing), verlangt den Block compatibility und wirft bei jedem Formfehler. Drei Regeln, die sich aus mehreren Feldern zugleich ergeben, prüft erst die Plattform beim Laden: Das appId jedes Widgets muss der id des Manifests gleichen, jede Ressource muss das Präfix der App tragen, und keine zwei Widgets dürfen dieselbe Kennung haben. Ein Manifest, das dem Schema widerspricht, weist die Release-Anlage mit Manifest.ValidationFailed (HTTP 422) ab.

Weiterführendes#

• Widget, Konfiguration und Vorschau — die Widget-Definition im Feld widgets.
• Datenzugriff, Rechte und Bedingungen — dataAccess, permissions, unlocks, connects und legal im Detail.
• Signieren und der Weg in den Katalog — was aus signing beim Release und am Gerät folgt.