Logs do Framework no aplicativo cliente

5

No momento, estamos criando uma estrutura (biblioteca estática de fonte fechada) que se comunica com alguns dispositivos domésticos inteligentes via Wi-Fi. Essa estrutura será usada por desenvolvedores de terceiros para criar seus próprios aplicativos (principalmente aplicativos móveis) para se comunicar com esses dispositivos.

Atualmente, dividimos as opiniões sobre se a estrutura deve gerar logs visíveis (digamos, um arquivo de registro ou um registrador de eventos) em uma versão de lançamento (forneceremos uma versão de depuração e de lançamento para desenvolvedores de terceiros).

Razões para ter registros:

  • Os registros são sempre úteis se precisarmos descobrir a causa raiz do erro inesperado.
  • Qualquer forma de logs é sempre boa
  • Obter as informações dos registros do celular deve ser fácil. (Por usuário do aplicativo ou técnico de suporte)
  • Podemos provar que é culpa dos desenvolvedores de aplicativos se eles nos culparem.
  • Alguns problemas só podem acontecer na produção que não podem ser reproduzidos no ambiente de teste.
  • Os arquivos de log não são grandes de qualquer maneira. Um pequeno arquivo de log que usa parte do armazenamento do dispositivo não deve ser um problema.
  • Todos os aplicativos / API dos servidores sempre têm registros.
  • A engenharia reversa é sempre possível por meio de descompilação, por isso não importa.

Razões para não ter registros:

  • O Framework não possui o aplicativo.
  • A maioria dos usuários não tem idéia de como obter os arquivos de log do armazenamento do aplicativo (portanto, é menos provável que consiga obtê-los), portanto, não adicione algo que não será usado
  • O desenvolvedor de aplicativos deve ser capaz de identificar o problema pelo seu próprio método de registro / depuração antes de chegar até nós
  • Risco de expor muitas informações aos usuários finais.
  • Nenhum outro framework parece fazer isso (por exemplo, SDK do Facebook / Google SDK)
  • Ativando o armazenamento do dispositivo. Cada contagem de bytes.
  • É o responsável do usuário do framework (desenvolvedor) ter seus próprios relatórios de logs / falhas se quiserem.
  • A versão de depuração com logs de console / depurador deve ser suficiente para desenvolvedores.

Então, basicamente, não podemos entrar em um acordo. Basta saber o que a comunidade mais ampla pensa sobre isso, se você é o desenvolvedor que usa uma biblioteca estática de fonte fechada em um aplicativo cliente.

    
por CHey 19.01.2017 / 07:15
fonte

1 resposta

4

Você não pode torná-lo configurável? Praticamente qualquer biblioteca do Android que faz solicitações de rede que conheço faz o seguinte:

  1. Ter um arquivo de configuração e / ou setter em alguma classe onde você possa ativar o log e definir o nível de log
  2. Leia se o aplicativo é compilado como depurável e faça o login de acordo

Como desenvolvedor, eu ficaria muito aborrecido se uma biblioteca viesse em dois tipos (debug e release) ou apenas decidisse por mim. Além disso, o login na produção em dispositivos móveis não é permitido, pois pode ser lido por qualquer pessoa que tenha acesso ao dispositivo.

    
por 24.01.2017 / 21:23
fonte