Para comparar orçamentos de desenvolvimento de aplicações Bluetooth, forneça a cada fornecedor os mesmos detalhes do dispositivo e do firmware, o fluxo de ligação, a lista de telemóveis e sistemas operativos alvo e os testes de aceitação. Uma proposta que abrange um dispositivo numa sessão em primeiro plano não é diretamente comparável com outra que também inclua recuperação de ligação, utilização em segundo plano e várias versões de plataformas.
Documente o dispositivo, o protocolo e o firmware
Comece pelo modelo exato do dispositivo e pela revisão de hardware. Indique se utiliza Bluetooth de baixa energia (BLE), Bluetooth Clássico ou outro perfil especificado e partilhe a documentação do protocolo ou da integração. Para BLE, inclua os UUIDs dos serviços e das características relevantes, o comportamento de leitura/escrita/notificação e os requisitos de segurança ou de criação de vínculo. Se utilizar um SDK do fabricante, forneça a respetiva versão, as plataformas suportadas, as condições da licença e as instruções de configuração.
Inclua as versões de firmware abrangidas e explique como são identificadas ou atualizadas. Anexe exemplos de payloads, definições de comandos, códigos de erro e quaisquer limitações conhecidas do dispositivo. Se a documentação estiver incompleta, assinale o que não é conhecido, em vez de deixar os fornecedores fazerem suposições diferentes. Peça-lhes que identifiquem separadamente quaisquer alterações necessárias ao hardware ou ao firmware, distintas do trabalho na aplicação.
Mapeie os fluxos de ligação e de dados
Descreva o percurso do utilizador desde a primeira abertura até ao funcionamento correto: detetar um dispositivo, selecioná-lo, emparelhar ou criar um vínculo, estabelecer ligação e chegar a um estado pronto. Em seguida, enumere cada ação da aplicação e a resposta do dispositivo, incluindo os dados que são lidos, escritos ou enviados como notificações. Uma lista de ecrãs, por si só, não define o comportamento Bluetooth.
Especifique o que deve acontecer quando o utilizador recusa uma permissão, seleciona o dispositivo errado, deixa o Bluetooth desligado, se afasta do alcance ou fecha e volta a abrir a aplicação. Indique quais as funções que têm de funcionar em primeiro ou segundo plano, se a aplicação deve manter a seleção do dispositivo e que estado ou instrução de recuperação deve ser apresentado ao utilizador. Peça aos fornecedores que identifiquem as suposições sobre o funcionamento em segundo plano para cada plataforma.
| Requisito a fornecer | Elementos comprovativos ou detalhes a anexar | Como verificar na proposta |
|---|---|---|
| Dispositivo e protocolo | Modelo, revisão de hardware, documentação do protocolo, versões de firmware, detalhes do SDK | Confirme que estão indicadas as combinações exatas de dispositivos e firmware suportadas |
| Emparelhamento e dados | Diagrama do fluxo, exemplos de comandos e respostas, comportamento de segurança e criação de vínculo | Verifique se cada ação da aplicação tem uma resposta esperada do dispositivo ou um estado de erro correspondente |
| Âmbito das plataformas | Modelos de telemóvel e versões do sistema operativo necessários para o lançamento | Peça uma lista das combinações incluídas, excluídas e testadas fisicamente |
| Comportamento de recuperação | Resultado esperado para uma desconexão, perda do vínculo, reinício da aplicação ou substituição do dispositivo | Associe cada caso a uma condição de aprovação definida e a evidências de teste |
| Entrega | Código-fonte, instruções de compilação, registos de testes e documentos de integração necessários | Confirme que cada entrega e o respetivo responsável estão identificados no orçamento |
Defina os telemóveis e os sistemas operativos
Forneça aos fornecedores a lista das plataformas alvo, incluindo os modelos de telemóvel e as versões do sistema operativo que os seus clientes ou colaboradores irão utilizar. Inclua suporte para tablets apenas se for necessário. Indique se a aplicação se destina apenas a Android, apenas a iOS ou a ambos; não parta do princípio de que uma base de código partilhada significa que o comportamento Bluetooth será idêntico em todas as plataformas.
Peça ao fornecedor que indique se a camada Bluetooth será nativa, partilhada ou uma combinação das duas e que explique como a opção será testada com o seu dispositivo. O desenvolvimento de aplicações Android e o desenvolvimento de aplicações iOS são opções relevantes quando está a definir o âmbito de uma plataforma de cada vez. Para um produto conectado que exija trabalho específico para cada plataforma no dispositivo, o desenvolvimento de aplicações nativas inclui integrações com dispositivos e testes entre as áreas do seu âmbito.
Defina os testes de desconexão e perda do vínculo
Trate a recuperação da ligação como uma área identificada dos testes de aceitação, não como uma expectativa informal. Peça casos de teste que abranjam o primeiro emparelhamento, uma desconexão normal, a perda de alimentação do dispositivo, a desativação e reativação do Bluetooth do telemóvel, o reinício da aplicação e a remoção ou perda do vínculo. Para cada caso, especifique o estado visível para o utilizador que se espera, se é esperada a reconexão automática e que ação o utilizador deve realizar se a recuperação não ocorrer. Defina o tempo aceitável para cada resultado como um requisito do projeto, em vez de presumir um valor.
Uma nota sobre alterações de comportamento do Android 17, datada de 1 de outubro de 2026, descreve o novo emparelhamento autónomo por Bluetooth após a perda do vínculo e recomenda que as equipas da aplicação e do hardware verifiquem as transições de vínculo e simulem a sua perda. Consulte a documentação atual do Android e confirme se se aplica às versões alvo antes de a adotar como requisito de aceitação.
Peça evidências de teste que identifiquem o dispositivo e o firmware, o telemóvel e a versão do sistema operativo, os passos executados, o resultado esperado, o resultado obtido e quaisquer limitações conhecidas. Pergunte quais os testes realizados em dispositivos físicos e quais foram simulados. Para uma aplicação existente, inclua nos materiais de briefing o acesso ao repositório ou à compilação, os problemas conhecidos atualmente e quaisquer resultados de testes anteriores com dispositivos.
Compare o âmbito do orçamento e a entrega
Compare as propostas linha a linha. Verifique se cada uma abrange as mesmas variantes de dispositivos, os mesmos fluxos de ligação e recuperação, as mesmas combinações de plataformas, os mesmos estados da interface, o trabalho de back-end, se necessário, e os mesmos casos de teste. Peça a cada fornecedor que enumere as exclusões, as dependências das equipas do dispositivo ou do firmware, as suposições sobre o acesso ao SDK e quaisquer elementos que exijam que a sua equipa forneça hardware ou credenciais.
Esclareça o que conta como aceitação, como serão registados os defeitos não resolvidos do dispositivo e qual o código-fonte, as instruções de compilação, os registos de testes e os documentos técnicos que serão entregues. Se forem necessários o envio para lojas de aplicações, serviços de back-end, análises ou manutenção contínua, indique-os explicitamente, em vez de os tratar como incluídos implicitamente.
Perguntas frequentes
Devo escolher desenvolvimento nativo ou multiplataforma para uma aplicação Bluetooth?
Decida depois de documentar o protocolo do dispositivo, o comportamento necessário em segundo plano e a matriz de plataformas alvo. Peça aos fornecedores que expliquem como a implementação proposta será testada no seu dispositivo real em cada plataforma e, em seguida, compare o âmbito e as evidências, em vez de escolher apenas com base no nome da framework.
E se o firmware do dispositivo ainda estiver a mudar?
Identifique as versões de firmware disponíveis atualmente, as versões previstas para o lançamento e quem controla as alterações ao firmware. Peça ao fornecedor que indique qual a versão assumida no orçamento e de que forma as alterações a comandos, segurança ou comportamento da ligação afetarão o âmbito.
Quantos dispositivos devo disponibilizar para os testes?
Pergunte ao fornecedor de quantas unidades físicas precisa para o plano de testes acordado e quais as revisões de hardware ou versões de firmware que têm de estar representadas. Indique o número de unidades que pode disponibilizar e assinale quaisquer limitações antes de comparar os orçamentos.
Para um briefing de aprovisionamento, partilhe as especificações do dispositivo, a documentação do protocolo e do firmware, a quantidade de unidades de teste, o destino para onde pretende enviar qualquer hardware, os telemóveis e as versões do sistema operativo alvo e os detalhes da aplicação, API ou repositório existentes. Os serviços de aplicações do Manboo Studio podem ser definidos com base nesses requisitos; discuta os requisitos para definir o âmbito do projeto.