Aplicativos: comandos da CLI

Empacote um diretório estático em um arquivo determinístico sem enviá-lo.

app pack <directory> [--output FILE]

screenrig app pack ./lobby-board --output ./lobby-board.tgz

O envelope informa sha256, compressed_bytes, expanded_bytes, file_count, a lista de entradas, e se o tempo de execução do SDK foi injetado. app upload empacota o diretório em si, então use este comando apenas quando quiser inspecionar o arquivo primeiro. Ele roda localmente e não exige login.

Um pacote tem no máximo 5000 arquivos, 250 MiB descompactados e 100 MiB compactados, cada arquivo com no máximo 32 MiB, com caminhos de no máximo 16 níveis e 255 bytes. O empacotamento deixa de fora nomes que começam com ., node_modules/, bower_components/, jspm_packages/, vendor/, venv/, __pycache__/, CVS/, source maps *.map, arquivos de chaves e credenciais (*.pem, *.key, *.p12, *.pfx, *.crt, *.cer, id_rsa, id_dsa, id_ecdsa, id_ed25519, credentials.json, secrets.json), arquivos temporários e de backup de editores, Thumbs.db e desktop.ini. Um arquivo .screenrigignore na raiz do diretório acrescenta padrões no estilo gitignore, um por linha, e não pode restaurar uma exclusão embutida. Links simbólicos, hardlinks, arquivos esparsos, dispositivos, caminhos duplicados (comparados também sem diferenciar maiúsculas de minúsculas), arquivos que mudam durante o empacotamento e um diretório sem index.html na raiz são recusados com o caminho indicado: o comando termina com o código 2 e não envia nada.

Aplicativos rodam sob política de segurança de conteúdo que bloqueia código inline. Empacotamento move blocos de estilo e script inline para arquivos _screenrig-inline-* ao lado de cada documento HTML e os vincula. Handlers de evento inline como onclick= e URLs javascript: não podem ser movidos; empacotamento os recusa e nomeia arquivo e linha.

Grave os tipos TypeScript de window.screenrig em um diretório.

app types [directory]

screenrig app types ./src

O envelope informa path, bytes, sha256 e written, que é false quando o arquivo já continha os tipos atuais. O arquivo corresponde ao tempo de execução que app pack e app upload injetam, então execute o comando de novo depois de atualizar a CLI. Um screenrig.d.ts existente é substituído por inteiro; um diretório ou um link simbólico nesse caminho é recusado, e o comando termina com o código 2. Ele roda localmente e não exige login. TypeScript descreve o que os tipos declaram.

Sirva um diretório em um ambiente de teste local do Player para experimentar um aplicativo antes de enviá-lo.

app dev <directory> [--port PORT] [--open] [--no-reload] [--kv FILE | --kv-from APP_ID]

screenrig app dev ./lobby-board --open

O comando serve o ambiente de teste em http://play.screenrig.localhost:18890 e roda até você interrompê-lo. Ele injeta o runtime como app pack faz e informa o que o empacotamento recusa, indicando o arquivo e a linha, conforme você edita. O ambiente de teste simula as capacidades, a viewport, o nome da tela, o fuso horário e os params, o temporizador da página, a pausa, a tela e a saída, os eventos do dispositivo, e portas seriais, linhas GPIO, periféricos Bluetooth LE e impressoras. As linhas emit e log são impressas no terminal. Desenvolver localmente descreve os controles.

Empacote um diretório, publique-o como uma nova versão do aplicativo e aguarde a publicação ser bem-sucedida.

app upload <directory> [--name NAME] [--no-wait] [--poll-ms MS] [--timeout MS]

screenrig app upload ./lobby-board --name "Lobby board"

Ler três campos: data.operation.state é succeeded, data.application.release_id é o id rel_ um primitivo application fixa, e data.application.id é o id app_ que os comandos kv usam. Uma operação bem-sucedida, não um id de release sozinho, significa que a release é utilizável.

Cada app upload cria um novo aplicativo e uma primeira versão imutável. Para publicar uma versão posterior do mesmo app, use app update. Uma playlist continua servindo a versão que já fixa até você editar esse primitivo.

Uma transferência para o armazenamento que for interrompida é tentada até 4 vezes enquanto a URL de upload for válida. Se ainda falhar, execute o mesmo comando novamente para retomar o mesmo upload.

Publicar uma nova versão de um aplicativo existente, preservando identidade, nome e K/V do aplicativo.

app update <id> <directory> [--expect-rev REVISION] [--no-wait] [--poll-ms MS] [--timeout MS]

screenrig app update app_01EXAMPLEAPP00000000000 ./lobby-board

O nome permanece; altere-o com app rename. Aguarde data.operation.state: "succeeded", depois use playlist replace-release para revisar a página exata, primitivo, nova versão e telas afetadas. Aplique com o token de impacto retornado e um controle de revisão opcional conforme descrito no fluxo de trabalho da playlist. Os pins existentes da playlist permanecem inalterados até a aplicação. Em caso de conflito de revisão, leia o app novamente antes de decidir se deve tentar novamente; não crie um aplicativo substituto apenas para contornar o conflito.

Listar os aplicativos do projeto.

app list

Sem parâmetros.

screenrig app list

Alterar o nome de exibição de um aplicativo.

app rename <id> --name NAME [--expect-rev REVISION]

screenrig app rename app_01EXAMPLEAPP00000000000 --name "Lobby welcome"

Só o nome de exibição muda. O ID do aplicativo, seus lançamentos, seus dados chave/valor e as playlists que fixam seus lançamentos permanecem como estão, e nenhum diretório é enviado. Renomear para o nome atual deixa a revisão inalterada. Os nomes podem se repetir; identifique um aplicativo pelo ID.

Leia um aplicativo.

app show <id>

screenrig app show app_01EXAMPLEAPP00000000000

latest_ready_release está ausente até que uma primeira publicação fique pronta. O estado da publicação vive na operação e no lançamento, não no aplicativo. last_used_at está ausente até que uma tela reproduza o aplicativo pela primeira vez.

Excluir um aplicativo e todas as suas versões.

app delete <id> [--expect-rev REVISION]

screenrig app delete app_01EXAMPLEAPP00000000000

Não há exclusão por lançamento. Enquanto uma tela mostra um dos lançamentos da aplicação, a exclusão responde application_in_use: dê a essas telas outro conteúdo primeiro. A exclusão não verifica playlists que fixam um lançamento sem mostrá-lo, então atualize ou exclua essas playlists também.

Listar as chaves armazenadas para um aplicativo.

kv list --app-id ID

screenrig kv list --app-id app_01EXAMPLEAPP00000000000

Leia uma chave.

kv get --app-id ID <key>

screenrig kv get --app-id app_01EXAMPLEAPP00000000000 menu

A resposta traz o valor em data.value_base64, inclusive valores JSON: decodifique-o e interprete JSON somente quando data.content_type indicar JSON. kv list omite os valores.

Escreva uma chave do JSON, um arquivo ou bytes base64.

kv set --app-id ID <key> --json-value JSON [--expect-rev REVISION]
kv set --app-id ID <key> --file FILE [--content-type TYPE] [--expect-rev REVISION]
kv set --app-id ID <key> --value-base64 BASE64 [--content-type TYPE] [--expect-rev REVISION]

screenrig kv set --app-id app_01EXAMPLEAPP00000000000 menu --json-value '{"soup":"lentil"}'

Excluir uma chave.

kv delete --app-id ID <key> [--expect-rev REVISION]

screenrig kv delete --app-id app_01EXAMPLEAPP00000000000 menu

Criar um webhook que grava uma chave de uma aplicação ou, com --card, o documento de dados de um cartão, e receber sua URL e segredo uma vez.

kv webhook create <key> --app-id ID [--description TEXT]
kv webhook create --card CARD_ID [--description TEXT] [--map FILE|-] [--key-template TEMPLATE] [--signing]
                  [--verify VENDOR [--verify-secret-file FILE|-] [--verify-header NAME] [--verify-encoding hex|base64]
                   [--verify-timestamp-header NAME] [--verify-tolerance SECONDS]] [--handshake VENDOR]

screenrig kv webhook create menu --app-id app_01EXAMPLEAPP00000000000 --description "Point of sale menu feed"
screenrig kv webhook create --card crd_01EXAMPLEBOARD0000000000 --map alert-map.json --description "CMS alerts"

--map, --key-template, --signing, --verify com suas opções e --handshake se aplicam apenas a um webhook de cartão.

O envelope é o webhook: data.id (kvw_…), data.key ou, para um cartão, data.card_id, data.url (https://api.screenrig.ai/api/applications/<app_id>/kv-webhooks/<id>/write ou https://api.screenrig.ai/api/cards/<card_id>/kv-webhooks/<id>/write) e data.secret (srkw_…). Um webhook de cartão que assina também traz data.signing_secret (whsec_…). Informe agora a URL e os segredos no sistema remetente. Nenhum comando posterior os mostra de novo. Após uma criação interrompida ou ambígua, execute novamente o comando idêntico dentro de 24 horas: ele reutiliza a chave de idempotência salva, e o servidor retorna o mesmo webhook e os mesmos segredos em vez de criar outro.

Listar os webhooks de uma aplicação ou de um cartão, os mais antigos primeiro.

kv webhook list (--app-id ID | --card CARD_ID)

screenrig kv webhook list --app-id app_01EXAMPLEAPP00000000000
screenrig kv webhook list --card crd_01EXAMPLEBOARD0000000000

Cada item possui id, key, description, url, created_at e, após ser gravado, last_used_at. O item de um webhook de cartão tem card_id no lugar de key, mais mapping (null quando o objeto postado é o documento), enabled, signing e, quando definidos, key_template, verify e handshake. Uma lista nunca carrega um segredo.

Excluir um webhook. Sua URL para de funcionar imediatamente, e a chave ou o documento do cartão mantém seu valor.

kv webhook delete <webhook_id> (--app-id ID | --card CARD_ID)

screenrig kv webhook delete kvw_01EXAMPLEWEBHOOK00000 --app-id app_01EXAMPLEAPP00000000000
screenrig kv webhook delete kvw_01EXAMPLEWEBHOOK00000 --card crd_01EXAMPLEBOARD0000000000

Substituir o segredo de um webhook e receber o novo uma vez.

kv webhook rotate-secret <webhook_id> (--app-id ID | --card CARD_ID) [--signing]

screenrig kv webhook rotate-secret kvw_01EXAMPLEWEBHOOK00000 --app-id app_01EXAMPLEAPP00000000000
screenrig kv webhook rotate-secret kvw_01EXAMPLEWEBHOOK00000 --card crd_01EXAMPLEBOARD0000000000 --signing

O envelope traz o novo segredo em data.secret. O segredo antigo para de funcionar imediatamente, então informe o novo no sistema remetente. Com --signing, o envelope traz no lugar o novo segredo de assinatura em data.signing_secret, e o segredo srkw_ do webhook permanece. Após uma rotação interrompida ou ambígua, execute novamente o comando idêntico: ele reutiliza a chave de idempotência salva, e o servidor retorna a rotação que já aconteceu em vez de rotacionar de novo.