Instalar a Skomi numa aplicação Electron: principal, preload, apresentação

Uma aplicação Electron não é uma página web ainda que seja construída a partir de uma, portanto não há etiqueta de script nenhuma aqui: há um pacote e uma chamada por processo. Vê medir uma aplicação para saberes o que isso te dá. O pacote Electron da Skomi não depende de nada a não ser do próprio Electron.

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

Três processos, três linhas

// main.js — arranca-a uma vez
const skomi = require('@skomi/electron').init({
    appId: 'your-app-id',
});

skomi.screen('launch');

// preload.js — expõe-na à janela
require('@skomi/electron/preload');

// apresentação — onde quer que viva o teu encaminhamento
window.skomi.screen('checkout/review', { tier: 'gold' });

A integração é isto. 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.

⚠ Não deites a mão ao fragmento web no teu processo de apresentação. Ele mede um sítio: quer um nome de anfitrião, um documento para vigiar e uma rede em que possa confiar, e uma janela do Electron não tem nada disso da maneira que ele espera. O SDK existe porque os problemas de uma aplicação de secretária são outros.

Dá nome aos teus ecrãs

Não há recolha automática, e é de propósito: um caminho de rota é 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 ou booleanos.

O que o SDK trata e que de outra forma terias de escrever

Funciona sem rede. Os ecrãs ficam em fila no disco, na pasta de dados da própria aplicação, e sobrevivem a sair da aplicação, a estoirar e a quinze dias sem rede. Uma aplicação de secretária que só reportasse quando estivesse ligada perderia exatamente as sessões que interessam.

Não conta a dobrar. Todos os ecrãs trazem um identificador cunhado uma só vez e reenviado sem alterações, portanto um lote reenviado é reconhecido em vez de contado outra vez. Uma fila para quando não há rede sem isso transforma a coisa que salva os teus dados na coisa que os inventa.

Sobrevive a um relógio errado. Cada lote grava quando foi despejado, portanto o servidor consegue perceber quão desacertado está o relógio da máquina e corrigir o lote. Um portátil acertado para a próxima terça-feira reportaria, sem isso, a próxima terça-feira.

Nunca lança para dentro do teu código. Argumentos maus, um servidor inalcançável, uma pasta de perfil onde não se pode escrever; tudo tratado por dentro e reportado através do onError se quiseres saber. A analítica é a coisa menos importante que a tua aplicação faz.

À espera do consentimento

const skomi = require('@skomi/electron').init({ appId: '…', enabled: false });

// mais tarde, depois de o utilizador concordar
skomi.setEnabled(true);

Não se grava nada enquanto estiver desligada, nem sequer em fila para depois. Um ecrã visto antes de alguém concordar não é um ecrã que devesses estar a enviar a seguir.

Erros e falhas

skomi.captureError(err, { screenName: 'checkout', fatal: false });

Postos em fila, guardados e reenviados como um ecrã, e desduplicados pela mesma regra, o que aqui importa mais, porque uma falha costuma ser enviada da fila no arranque seguinte.

⚠ O captureUncaught está desligado por omissão, e pensa antes de o ligares. Ligar um escutador ao uncaughtException é o que impede o Node de sair, portanto um relator de falhas instalado por omissão transformaria uma falha fatal num processo que continua a correr sobre estado corrompido. Com a opção ligada, a semântica é reposta: o relatório é escrito em disco de forma síncrona, o escutador é removido, e o erro é relançado.

Opções

init({
    appId: '…',                     // obrigatório
    appVersion: app.getVersion(),   // de origem: perguntado ao Electron
    origin: 'https://t.skomi.com',  // substituição para alojamento próprio
    enabled: true,                  // começa a false, liga depois do consentimento
    flushIntervalMs: 10000,
    onError(error, context) { },    // 'screen' | 'flush' | 'transport' | 'rejected' | 'queue'
});

O init liga o canal do processo de apresentação e despeja ao sair. Se quiseres um cliente cuja vida seja tua (sem IPC, sem gancho de saída), usa antes o createClient.

O que uma aplicação não recebe

⚠ Só a analítica lê uma aplicação. Os mapas de calor, as gravações de sessão e o widget de opiniões são produtos de sítio: precisam de uma página num navegador, e não há nada a que se agarrarem numa janela de secretária. Uma aplicação reporta ecrãs, sessões, versões, plataformas e erros, e é isso tudo.

Vê medir uma aplicação para saberes o que o painel faz com eles, e instalar no MAUI ou no Flutter se entregas também o mesmo produto por lá.

Instalar no Electron