Une application n'a pas de balise script : l'équivalent est un paquet et un appel ; voir mesurer une application pour ce que cela vous apporte. Le paquet Flutter de Skomi ne dépend de rien d'autre que de Flutter lui-même.

Le code source, et une application de démonstration qui se mesure elle-même, sont sur skomi-sdk-flutter.

Démarrez-le une fois

void main() async {
  WidgetsFlutterBinding.ensureInitialized();

  await Skomi.start(SkomiOptions(appId: 'your-app-id'));

  runApp(const MyApp());
}

L'identifiant de l'application vient de My Apps dans Skomi. Ce n'est pas un secret et il a sa place dans votre code source : il identifie une application plutôt qu'il ne l'authentifie, comme le fait un identifiant de site.

Nommez vos écrans

// là où un écran devient visible
Skomi.screen('checkout/review', props: {'tier': 'gold'});

Il n'y a pas de capture automatique des noms de routes, et c'est délibéré : un nom de classe de widget est ce que votre code appelle un écran, pas ce que vous appelleriez ainsi dans un rapport. Jusqu'à 20 propriétés par écran : chaînes, nombres, booléens.

Deux choses que Flutter ne peut pas lui dire

La version de votre application. Flutter n'a pas d'API de framework pour cela : passez-la.

final info = await PackageInfo.fromPlatform();   // package_info_plus

await Skomi.start(SkomiOptions(appId: '…', appVersion: info.version));

Omettez-la et chaque écran remonte sans version, et le panneau Version de l'application le dit alors plutôt que de deviner, ce qui est honnête et pas très utile.

Où vit la file hors ligne. Sans chemin, elle va dans le répertoire temporaire de l'application. Il est privé à l'application et survit à un redémarrage, mais le système peut le récupérer sous pression de stockage ; donnez-lui un chemin de documents si perdre une session en file vous importe.

Ce que vous obtenez sans rien demander

Sessions, écrans, versions de l'application, répartitions par plateforme, appareil et OS, et un taux sans plantage. La file survit au hors-ligne, à la fermeture et au plantage, et chaque écran porte un identifiant émis une fois pour qu'un lot réessayé soit reconnu plutôt que compté deux fois.

Fonctionne sur Android, iOS, macOS, Windows et Linux. Une compilation web se compile et ne collecte rien, exprès : une application Flutter web est un site, et un site reçoit le script.

Erreurs - ce qu'il attrape, et ce qu'il ne peut pas

try {
  await checkout();
} catch (error, stack) {
  Skomi.captureError(error, stack: stack);
  showRetry();
}

start s'enchaîne à FlutterError.onError et à PlatformDispatcher.instance.onError : ce que vous aviez déjà installé continue donc de fonctionner. Il attrape les erreurs levées dans le framework Flutter et les erreurs non gérées de l'isolat racine.

⚠ Ce n'est pas un rapporteur de plantages et il ne doit pas servir de tel. Un plantage natif (un segfault dans le C++ d'un plugin, un arrêt pour manque de mémoire, une NSException venue d'un canal de plateforme) tue l'isolat qui aurait fait le rapport. Gardez Crashlytics, Sentry ou le rapport du store pour ceux-là. Ce que Skomi ajoute, c'est la moitié Dart, sur la même page que les erreurs que vous rapportez vous-même, et un taux sans plantage lisible à côté de vos chiffres de version.

Les défauts sont regroupés par type, jamais par message : un message porte des identifiants, des chemins et des montants, regrouper dessus donne donc une ligne par occurrence et un rapport qui ne dit rien.

Vérifier que cela fonctionne

Lancez l'application, passez d'un écran à l'autre, et regardez votre tableau de bord. Si rien n'arrive, les causes habituelles sont un identifiant d'application venu de la mauvaise application et un start qui n'a jamais été attendu.