Global application state, such as permissions, Bluetooth and connectivity state, and others, brings an interesting set of challenges. Whenever one of these global states changes, for example, the network connectivity drops, then different parts of the app might need to react differently.
With global state, the challenge becomes deciding which component owns listening to these state changes. At one end of the spectrum, application screens or components could listen to global state changes they care about; resulting in lots of code duplication, but components handling all of the global state concerns. At the other end, a component could listen to certain global state changes and forward these on to specific parts of the application. This might result in less complex code, but now there is a tight coupling between the global state handler and the components it knows.
App launch points like deeplinks or internal shortcut navigation points within the app also add complexity to state management.
With deeplinks, the application state might need to be set up after the deeplink is activated. We will go into more detail in the Deeplinks chapter.
O estado global do aplicativo, como permissões, estado de conectividade e Bluetooth, entre outros, traz um conjunto interessante de desafios. Sempre que um desses estados globais muda, por exemplo, a conectividade de rede cai, diferentes partes do aplicativo podem precisar reagir de maneira diferente.
Com o estado global, o desafio é decidir qual componente é o responsável por ouvir essas mudanças de estado. Em uma extremidade do espectro, as telas ou componentes do aplicativo podem ouvir as mudanças de estado globais com as quais se preocupam; resultando em muita duplicação de código, mas componentes lidando com todas as questões de estado global. Na outra extremidade, um componente pode ouvir certas mudanças de estado global e encaminhá-las para partes específicas do aplicativo. Isso pode resultar em um código menos complexo, mas agora há um forte acoplamento entre o manipulador de estado global e os componentes que ele conhece.
Os pontos de inicialização do aplicativo, como deeplinks ou pontos de navegação de atalho internos no aplicativo, também adicionam complexidade ao gerenciamento de estado.
Com deeplinks, o estado do aplicativo pode precisar ser configurado após a ativação do deeplink. Entraremos em mais detalhes no capítulo Deeplinks.
Old versions of the app will stay around for a long time, up to several years. This time frame is only shorter if you are one of the few teams that put strict force app upgrade policies in place. Apps that have a rolling window of force upgrades include Whatsapp and Messenger. Several others use force upgrades frequently, like banking apps Monzo or American Express.
While most users will update to new app versions in a matter of days, there will be a long tail of users who are several versions behind. Some users disable automatic updates on purpose, but many who do not update are blocked because of old phones or OSes. At the same time, old app versions are unlikely to be regularly tested by the mobile team because it is a lot of effort, with little payoff.
Even a non-breaking backend change can break an older version of the app - such as changing the content of a specific response. A few practices you can do to avoid this breakage:
Build sturdy network response handling and parsing, using dedicated tooling that solves these problems. I prefer strongly typed, generated contracts between client and backend like Thrift, GraphQL, or other solutions with code generation, over REST interfaces that you need to validate manually, which is bound to break when someone forgets to update the parsing logic on mobile.
Plan well in advance for breaking backend changes. Have an open communications channel with the backend team. Have a way to test old app versions. Consider building new endpoints and not retiring old ones until a forced upgrade moves all current app users off the old endpoint.
Version your backend endpoints and create new versions to accommodate breaking changes.
Versões antigas do aplicativo permanecerão por muito tempo, até vários anos. Esse período de tempo é menor apenas se você for uma das poucas equipes que implementam políticas rígidas de atualização forçada de aplicativos. Os aplicativos que têm uma janela contínua de atualizações forçadas incluem o Whatsapp e o Messenger. Vários outros usam atualizações forçadas com frequência, como aplicativos bancários Monzo ou American Express.
Embora a maioria dos usuários atualize para novas versões de aplicativos em questão de dias, haverá uma longa cauda de usuários com várias versões atrasadas. Alguns usuários desativam as atualizações automáticas de propósito, mas muitos que não atualizam são bloqueados por causa de telefones ou sistemas operacionais antigos. Ao mesmo tempo, é improvável que as versões antigas do aplicativo sejam testadas regularmente pela equipe de aplicativo porque é um grande esforço, com pouco retorno.
Mesmo uma alteração de back-end ininterrupta pode interromper uma versão mais antiga do aplicativo - como alterar o conteúdo de uma resposta específica. Algumas práticas que você pode fazer para evitar essa quebra:
Construa manipulação e análise robustas de resposta de rede, usando ferramentas dedicadas para resolver estes problemas. Prefiro contratos fortemente digitados e gerados entre cliente e back-end, como Thrift, GraphQL ou outras soluções com geração de código, sobre interfaces REST que você precisa validar manualmente, que está prestes a quebrar quando alguém se esquece de atualizar a lógica de análise em móvel.
Planeje com antecedência para interromper as alterações de back-end. Tenha um canal de comunicação aberto com a equipe de back-end. Tenha uma maneira de testar versões antigas de aplicativos.
Considere criar novos endpoints e não aposentar os antigos até que uma atualização forçada mova todos os usuários atuais do aplicativo para fora do endpoint antigo. Versão dos endpoints de back-end e crie novas versões para acomodar as alterações mais recentes.
