Appwin Core

Appwin Core est le socle de chaque module : identité d'appareil, session authentifiée, client réseau. Une personne reste la même dans Community, Support et les autres, et chaque requête atteint ton projet à partir de ton seul App ID.

Tu ne l'installes jamais à part : il vient avec le premier module, et c'est toujours la première ligne du code généré.

Ce qu'il fait au démarrage

• configure(projectAppId:) : synchrone, appelé une fois. Prépare l'identité d'appareil et le client réseau, et route chaque requête vers ton projet.
• Il démarre le pipeline d'événements et le cycle de vie de l'app, quels que soient les modules installés : les sessions et les événements automatiques commencent ici.
• Il ouvre ensuite la session seul, en tâche de fond, au premier appel qui en a besoin. Rien à appeler.

D'où un SDK à une URL et un configure plutôt que quatre : le initialize() de chaque module s'appuie sur la session de Core.

Envoyer un événement

track() est la seule façon de décrire ce qui s'est passé dans ton app, quels que soient les modules installés. L'événement arrive dans Analytics, peut démarrer un parcours dans Notifications et part chez tes régies, selon le consentement du client. Tu n'appelles plus AppwinAnalytics.track ni AppwinNotifications.trackEvent (dépréciés, voir plus bas).

AppwinCore.track("onboarding_completed", props: [
  "steps_count": 4,
  "notifications_enabled": true,
])

Les propriétés n'acceptent que des chaînes, des nombres et des booléens. Les noms suivent les règles d'Analytics.

Core envoie aussi les événements que personne ne doit écrire à la main, dès que configure a rendu la main : app_install, app_update, app_open, app_background, session_start, session_end, screen_view, install_referrer (Android), push_opt_in et push_opened. Voir les événements automatiques. Une app qui n'a que Notifications ou Support a donc aussi ses sessions et ces événements.

Consentement

Le consentement se donne par finalité :

Les trois sont granted par défaut : une app sans bannière n'a rien à faire. Un état vaut granted, denied ou unknown (ConsentState). unknown garde les événements sur l'appareil en attendant la réponse.

AppwinCore.setConsent(.unknown)

AppwinCore.setConsent(.granted) // envoie les événements en attente
AppwinCore.setConsent(.denied)  // purge la file et arrête la collecte

AppwinCore.setConsent(.denied, for: .marketing) // seulement le marketing

Sans finalité, setConsent(state) règle les trois d'un coup. Le tri se fait dans le SDK : si aucune finalité n'est accordée, rien n'est envoyé et la file locale est vidée ; sinon chaque événement part une fois, avec les finalités accordées à cet instant. Un refus purge aussi le replay déjà enregistré. Un consentement refusé avant la mise à jour en 0.16 reste refusé sur les trois finalités.

advertising n'est pas AppwinAttribution.setAdvertisingConsent : la finalité trie les événements du flux, tandis que l'IDFA, le GAID et les régies restent en opt-in par setAdvertisingConsent, inchangé.

:::note ConsentState remplace AnalyticsConsent (AppwinAnalyticsConsent sur Flutter et React Native), gardé en alias déprécié le temps de la transition. Sur Android, l'alias est un typealias Kotlin : le code Java, et les bibliothèques compilées contre la 0.15, doivent passer à ConsentState. :::

Une identité, tous les modules

Core reconnaît l'appareil sans inscription. Rattache ton utilisateur avec identify à la connexion (l'id est gardé d'un lancement à l'autre), pousse ses attributs avec updateUser, appelle logout à la déconnexion. Il devient la même personne dans tous les modules et sur tous ses appareils : les modules n'ont pas d'identité à eux.

Passe toujours ton id utilisateur, jamais un id de session ou d'appareil : deux identifiants font deux personnes. Détail dans Identité.

L'environnement visé

Par défaut, Core parle à https://api.appwin.io, routé vers ton projet par ton App ID. Le paramètre baseUrl de configure ne sert qu'à un autre point d'entrée fourni (un staging, par exemple).

Suite