Em geral, toda a documentação (aqui) visa demonstrar o que acreditamos serem boas práticas de desenvolvimento para aplicativos e drivers Hubitat Elevation. Por exemplo, especialmente se você for novo no desenvolvimento da plataforma Hubitat Elevation, consulte:
No entanto, mesmo os desenvolvedores com experiência na plataforma Hubitat Elevation podem querer (re)ler esses documentos, particularmente as visões gerais do aplicativo e do driver e a documentação mais avançada à qual eles vinculam, pelo motivo acima.
No entanto, nem todos os aplicativos e códigos de driver Hubitat Elevation que você pode encontrar "em estado selvagem" seguem nossas práticas demonstradas. Isto não é necessariamente errado; há uma variedade de estilos e preferências de programação, e a programação em si é frequentemente descrita como uma ciência e uma arte. Ainda assim, ocasionalmente somos questionados sobre esse assunto, e há certos recursos do Hubitat que consideramos mais bem usados de determinadas maneiras, tanto para a experiência do usuário quanto para a eficiência no ambiente de execução de aplicativos e drivers.
Apresentamos aqui algumas dessas dicas, embora esta não seja de forma alguma uma lista completa. O fórum da comunidade é um ótimo lugar para se conectar com outros desenvolvedores (e funcionários!) para saber mais.
Aplicativos e drivers têm o objeto state disponível para persistir dados entre execuções (consulte, por exemplo, Visão geral do aplicativo: armazenamento de dados [estado]). Isso é conveniente e funciona bem para pequenas quantidades de dados. Mas observe que esses dados são serializados e desserializados de/para JSON durante ou após (ou para atomicState durante) a execução do aplicativo ou driver. Grandes quantidades de dados podem ser melhor armazenadas de forma mais eficiente usando outra técnica, incluindo:
static @groovy.transform.Field definida no nível superior do seu aplicativo ou código do driver
ConcurrentHashMap com uma chave exclusiva, como o ID do dispositivo, e então armazenar dados para essa instância específica dentro do valor dessa chave; e aplicativos que permitem múltiplas instâncias podem querer fazer algo semelhante – a menos que isso não seja uma preocupação para esse driver ou aplicativo)Os atributos do dispositivo (mostrados em "Estados Atuais" na página de detalhes do dispositivo) e state (ou atomicState) oferecem locais para armazenar valores. No entanto, em geral:
state (ou outro método de armazenamento) deve ser considerado para outros casos
Sugerimos seguir as convenções de registro conforme descrito nas visões gerais acima. A gravação de entradas de log, em geral, tem poucas chances de afetar o desempenho do hub. No entanto, muitos usuários preferem controlar se ou como os aplicativos e drivers criam entradas de log e para quais tipos de informações.
Embora muitos aplicativos e drivers sejam pequenos o suficiente ou executados com pouca frequência, o suficiente para que o uso de def como muitos desenvolvedores Groovy fazem não seja uma preocupação, alguns desenvolvedores de aplicativos maiores relataram possíveis melhorias na velocidade ou no uso de memória ao usar tipos específicos (ou void se apropriado) para variáveis, métodos, etc. Por exemplo,
void appButtonHandler(String nome do botão) {
// ...
}
pode ser preferível a:
def appButtonHandler(nomedobotão) {
// ...
}
Este documento não é uma lista exaustiva de todas as preocupações possíveis, nem é possível criar tal documento dada a vasta flexibilidade oferecida pelo Groovy e pelo ambiente de desenvolvimento Hubitat. No entanto, esperamos que as informações acima sejam úteis, pretendam adicioná-las ao documento ao longo do tempo e encorajem acessando o fórum da comunidade para se conectar com outros desenvolvedores e funcionários para continuar aprendendo mais.