Uma aplicação não tem etiqueta de script, portanto o equivalente é um pacote e uma chamada; vê medir uma aplicação para saberes o que isso te dá. O pacote Flutter da Skomi não depende de nada a não ser do próprio Flutter.

O código-fonte, e uma aplicação de demonstração que se reporta a si mesma, estão em skomi-sdk-flutter.

Arranca-a uma vez

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

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

  runApp(const MyApp());
}

O identificador de aplicação vem de As minhas aplicações na Skomi. Não é um segredo e pertence ao teu código-fonte: identifica uma aplicação em vez de a autenticar, tal como um identificador de sítio faz.

Dá nome aos teus ecrãs

// onde quer que um ecrã fique visível
Skomi.screen('checkout/review', props: {'tier': 'gold'});

Não há recolha automática de nomes de rota, e é de propósito: o nome da classe de um widget é como o teu código chama a um ecrã, não como lhe chamarias num relatório. Até 20 propriedades por ecrã: texto, números, booleanos.

Duas coisas que o Flutter não lhe consegue dizer

A versão da tua aplicação. O Flutter não tem API de framework para isso, portanto passa-lha:

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

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

Deixa-a de fora e todos os ecrãs reportam sem versão, e o painel de versões da aplicação diz então isso mesmo em vez de adivinhar, o que é honesto e pouco útil.

Onde vive a fila para quando não há rede. Sem um caminho, vai para a pasta temporária da aplicação. Isso é privado da aplicação e sobrevive a um reinício, mas o sistema pode reclamá-la quando o armazenamento aperta; dá-lhe um caminho de documentos se perder uma sessão em fila te importar.

O que ficas a ter sem pedir

Sessões, ecrãs, versões da aplicação, desagregações por plataforma, dispositivo e sistema operativo, e uma taxa sem falhas. A fila sobrevive a estar sem rede, a sair da aplicação e a estoirar, e todos os ecrãs trazem um identificador cunhado uma só vez, para que um lote reenviado seja reconhecido em vez de contado duas vezes.

Corre em Android, iOS, macOS, Windows e Linux. Uma versão web compila e não recolhe nada, de propósito: uma aplicação Flutter web é um sítio, e um sítio leva o script.

Erros - o que apanha, e o que não consegue

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

O start encadeia-se ao FlutterError.onError e ao PlatformDispatcher.instance.onError, portanto o que já tinhas instalado continua a funcionar. Apanha erros levantados dentro da framework Flutter e erros não tratados no isolate de raiz.

Não é um relator de falhas e não deve ser usado como tal. Uma falha nativa (um segfault no C++ de um plugin, uma morte por falta de memória, uma NSException vinda de um canal de plataforma) mata o isolate que a teria reportado. Fica com o Crashlytics, o Sentry ou o relatório da própria loja para essas. O que a Skomi acrescenta é a metade em Dart, na mesma página que os erros que reportas tu, e uma taxa sem falhas que consegues ler ao lado dos números das tuas versões.

As faltas são agrupadas por tipo, nunca por mensagem: uma mensagem transporta identificadores, caminhos e valores, portanto agrupar por ela dá uma linha por ocorrência e um relatório que não diz nada.

Confirma que está a funcionar

Corre a aplicação, muda entre dois ecrãs, e olha para o teu painel. Se não chegar nada, as causas habituais são um identificador de aplicação da aplicação errada e um start que nunca foi esperado com await.