Escolha o plano certo
- Antes de começar a criar uma aplicação no AppCreator, é importante entender o que a plataforma AppCreator pode oferecer e os detalhes de cada plano.
- Como regra geral, é ideal ter pelo menos 5-10% mais escopo do que o necessário. Isso irá garantir que sua a aplicação possa ser dimensionada caso haja um pico na atividade do usuário.
- Identifique quem irá utilizar a aplicação e o design de acordo com os respectivos requisitos. Por exemplo, você pode escolher um plano de portal do cliente para dar suporte às necessidades específicas de clientes, fornecedores e parceiros.
Melhores práticas de segurança
Usuários e permissões
- Apenas os usuários desejados devem ser adicionados à aplicação, e apenas os módulos necessários devem ser compartilhados.
- Os usuários ou desenvolvedores que não precisarem mais de acesso à aplicação devem ser removidos.
- Quando mais de um usuário estiver criando a aplicação, adicione os usuários desejados como desenvolvedores em vez de compartilhar as credenciais de administrador com eles.
- O acesso a dados com informações pessoais identificáveis (IPI) e informações de saúde protegidas por meio eletrônico (ePHI) pode ser fornecido apenas aos conjuntos de permissões necessários.
- As permissões Exportar, Excluir, Visualizar tudo e Editar em massa devem ser limitadas.
- Os conjuntos de permissões que não sejam obrigatórios para usuários e clientes podem ser excluídos.
Formulários e relatórios
- Os campos que coletam ou contêm dados IPI e ePHI devem ser criptografados.
- As informações confidenciais podem ser mascaradas nos relatórios, sempre que for aplicável.
- Os filtros e critérios podem ser adicionados aos relatórios para garantir que apenas as informações desejadas sejam exibidas aos usuários.
- Qualquer informação confidencial armazenada pode ser excluída quando ela não for mais necessária.
- As mensagens de confirmação podem ser associadas a botões de ação personalizados.
- Não é aconselhável coletar ou armazenar informações confidenciais, como números ou senhas da Previdência Social. Se coletadas, a finalidade deve ser claramente indicada no formulário.
- É melhor evitar armazenar credenciais API na aplicação.
- O texto de ajuda ou as dicas de ferramentas podem ser associados a campos para elaborar o motivo da coleta dos dados.
- Os campos de observação podem ser adicionados a formulários para especificar aos usuários a finalidade da coleta de dados.
- É aconselhável desativar os formulários publicados quando o acesso público não for mais necessário.
- Pode ser utilizada uma caixa de Decisão para obter o consentimento quanto à coleta de dados.
- A autenticação baseada em OAuth deve ser usada sempre que possível ao invocar APIs.
- Ao coletar o endereço IP, é aconselhável informar os usuários e obter o seu consentimento. O endereço IP também pode ser criptografado.
- As ações nos relatórios, como Adicionar, Excluir e Duplicar, devem ser revisadas e podem ser removidas caso elas não sejam mais necessárias.
- O histórico de alterações feitas nos relatórios também pode ser rastreado utilizando o recurso Trilha de auditoria.
Fluxos de trabalho e scripts
- As validações de entrada devem ser feitas para campos sempre que possível.
- Quaisquer hiperlinks usados na aplicação devem ser verificados.
- O conteúdo das tarefas de SMS e e-mail deve ser revisado.
- A lógica de negócios, como funções e fluxos de trabalho de Agendamento, pode ser executada dentro do próprio criador de fluxo de trabalho antes de ser incorporada ao fluxo principal.
Páginas
- HTML e código JavaScript devem ser revisados.
- Use comentários sempre que possível.
- Para páginas que funcionam com base em parâmetros, certifique-se de incluir seleções nulas para impedir que a página mostre erros ou dados irrelevantes.
- Evite duplicar estilos CSS.
Melhores práticas para aplicações
Práticas gerais
- Defina a estrutura da aplicação e identifique o modelo de dados: campos, relações, criptografia dos campos. Considere os pontos de tensão do processo atual antes de começar a criar a aplicação.
- Documente a estrutura da aplicação. Isso vai facilitar a realização de alterações posteriores.
- Atribua nomes significativos a todos os componentes: Formulários, Campos, Relatórios, Fluxos de trabalho, Páginas, Variáveis, Funções e Conjuntos de permissões.
- Use campos de pesquisa para estabelecer relações entre os formulários para evitar dados redundantes entre eles.
- Defina propriedades como Obrigatório e Sem valores duplicados para os campos a fim de manter a integridade dos dados.
- Exclua componentes da aplicação que não sejam necessários.
- Especifique o comportamento de exclusão de registros: o que acontecerá com quaisquer registros relacionados quando algum deles for excluído. Por exemplo, se um funcionário for excluído, o que acontecerá com as tarefas atribuídas a ele?
- Faça alterações na aplicação em um ambiente sandbox e teste-as antes de publicar.
- Utilize o recurso de backup de aplicação agendada para criar backups periódicos.
Melhores práticas do Deluge
O Deluge é a linguagem de script integrada do AppCreator. Ele é fácil de aprender e vem com um ambiente de desenvolvimento integrado que permite arrastar e soltar trechos de código Deluge durante a codificação.
Práticas gerais
- Declarações de depuração como "info" podem ser usadas onde for aplicável para eliminar erros.
- Evite o nesting pesado dos scripts e otimize os loops.
- Utilize a tarefa de registro agregado com eficácia. Obtenha todos os registros apenas quando for necessário.
- Utilize as funções incorporadas sempre que possível, que são otimizadas para desempenho.
- As declarações try catch podem ser usadas para lidar com exceções no código.
- As variáveis podem receber nomes significativos.
- Use variáveis do sistema, como zoho.appUri e zoho.appName, para que o nome do link da aplicação ou as alterações do nome do proprietário não afetem a sua funcionalidade.
- Isso é especialmente útil para um script Deluge usado dentro de páginas HTML para incorporar componentes.
- As funções podem ser utilizadas para criar blocos de código reutilizáveis a partir de códigos frequentemente utilizados ou duplicados.
- O código indesejado e comentado pode ser removido para manter a base de código limpa e facilitar a manutenção.
- Scripts podem ser recuados e comentários podem ser adicionados a eles para fornecer uma breve visão geral da lógica e da finalidade.
- Mantenha o código modular.
- O Assistente de sintaxe pode ser usado para ajudar a configurar tarefas.
- O controle de versão também está disponível para rastrear as várias versões e alterações de código.
- Ao usar a tarefa invocar do URL Deluge para fazer chamadas à API, a resposta não será armazenada ou processada nos dados mantidos pelo AppCreator, o que faz do Deluge seguro contra quaisquer vulnerabilidades.
- Quaisquer erros na execução de scripts Deluge afetarão apenas a lógica da aplicação e não causarão vulnerabilidades.
- Os erros de sintaxe que surgirem no Deluge serão exibidos quando um usuário tentar salvar o script. O código não será salvo nem executado até que o erro seja corrigido.
- Os erros lógicos que ocorrerem devido às más práticas de programação e as falhas devem ser rastreados e corrigidos.
- Qualquer código Deluge escrito deve ser otimizado para garantir que os limites das declarações Deluge não sejam atingidos. Eles foram criados para evitar o uso indevido e acidental de recursos.
- Para melhorar o desempenho, use as funções predefinidas do Deluge: equalsIgnoreCase, é igual para a comparação em vez de “==”.
SScripts a serem evitados
A seguir estão alguns scripts que podem ser evitados. São fornecidas alternativas a eles.
Exemplo 1:
Em vez de verificar a contagem a partir da declaração fetch, você pode usar diretamente a coleção fetch dentro do loop.
fetchInvoices = Invoice[Client == input.Client && Location.equalsIgnoreCase("Chennai") && Bill_Payment_Status == "Not Paid"];
if(fetchInvoices.count() > 0)
{
for each invoice in fetchInvoices
{
}
}
//------------------------------------------
//Instead use the below script
//------------------------------------------
for each invoice in Invoice[Client == input.Client && Location.equalsIgnoreCase("Chennai") && Bill_Payment_Status == "Not Paid"]{
}
if(fetchInvoices.count() > 0)
{
for each invoice in fetchInvoices
{
}
}
//------------------------------------------
//Instead use the below script
//------------------------------------------
for each invoice in Invoice[Client == input.Client && Location.equalsIgnoreCase("Chennai") && Bill_Payment_Status == "Not Paid"]{
}
Exemplo 2:
Você pode utilizar as funções integradas para evitar o loop.
paymentList=List();
para cada fatura em PaymentAgainstInvoice[ID == rushPayment]
{
paymentList.add(invoice.ID);
}
//------------------------------------------
//Instead use the below script
//------------------------------------------
paymentList = PaymentAgainstInvoice[ID == rushPayment].ID.getAll();
para cada fatura em PaymentAgainstInvoice[ID == rushPayment]
{
paymentList.add(invoice.ID);
}
//------------------------------------------
//Instead use the below script
//------------------------------------------
paymentList = PaymentAgainstInvoice[ID == rushPayment].ID.getAll();
Exemplo 3:
Esta é outra maneira de usar funções incorporadas para evitar o loop.
fethcInvoice = Invoice[ID == input.invoiceId];
for each lineitmcount in fethcfrominv.Line_Items
{
contlines = contlines + 1;
}
//--------------------------------------------
//instead use the below script
//------------------------------------------
count=fethcInvoice = Invoice[ID == input.invoiceId].count(ID);
for each lineitmcount in fethcfrominv.Line_Items
{
contlines = contlines + 1;
}
//--------------------------------------------
//instead use the below script
//------------------------------------------
count=fethcInvoice = Invoice[ID == input.invoiceId].count(ID);
Exemplo 4:
Este exemplo de código mostra como evitar operações de atualização desnecessárias.
billId = insert into Bill
[
Added_User=zoho.loginuser
Total_Price=Total_Price
Bill_Status=Bill_Status
];
fetchBill = Bill[ID == billId];
if(patient_Type == "Free")
{
fetchBill.Total_Price=0;
fetchBill.Bill_Status="Closed";
}
//--------------------------------------------
///Em vez de usar o código acima, podemos executar a verificação antes de inserir os dados no formulário “Bill”. Isso evitará uma operação de atualização desnecessária
//--------------------------------------------
if(patient_Type == "Free")
{
Total_Price=0;
Bill_Status="Closed";
}
billId = insert into Bill
[
Added_User=zoho.loginuser
Total_Price=Total_Price
Bill_Status=Bill_Status
];
[
Added_User=zoho.loginuser
Total_Price=Total_Price
Bill_Status=Bill_Status
];
fetchBill = Bill[ID == billId];
if(patient_Type == "Free")
{
fetchBill.Total_Price=0;
fetchBill.Bill_Status="Closed";
}
//--------------------------------------------
///Em vez de usar o código acima, podemos executar a verificação antes de inserir os dados no formulário “Bill”. Isso evitará uma operação de atualização desnecessária
//--------------------------------------------
if(patient_Type == "Free")
{
Total_Price=0;
Bill_Status="Closed";
}
billId = insert into Bill
[
Added_User=zoho.loginuser
Total_Price=Total_Price
Bill_Status=Bill_Status
];
Recursos
Melhores práticas para um app móvel
- É possível determinar e alterar ações e eventos acionados, como tocar em um registro, passar o dedo para a esquerda e passar o dedo para a direita.
- As colunas na exibição rápida e na exibição detalhada podem ser definidas de acordo com o contexto da aplicação.
- O logotipo personalizado pode ser enviado para as aplicações.
- As aplicações podem ser renovadas e publicadas separadamente, offline, para usuários e clientes.