No mundo dos especialistas em smartphones, a ideia de sandboxing - restringir o software a lidar apenas com os arquivos ou recursos de que ele absolutamente precisa - tende a ser um conceito polarizador. Por um lado, os usuários avançados se irritam com a maneira como isso limita sua capacidade de usar seus computadores e dispositivos móveis da maneira que desejam; por outro, é difícil argumentar contra o sucesso que a Apple teve com a filosofia - particularmente no mercado móvel, em que a empresa criou uma plataforma de computação segura e popular.
No entanto, o sandbox também está começando a mostrar sua idade. Enquanto os recursos dos dispositivos iOS estão se aproximando rapidamente do território de seus equivalentes de desktop, a capacidade dos aplicativos iOS de se comunicar uns com os outros está travada na era de 2007. É hora de mudar.
Castelos de areia e segurança
Sandboxing é mais frequentemente apresentado como uma tecnologia cujo trabalho principal é a segurança e o controle. Ao impor um conjunto muito rígido de regras sobre quais aplicativos podem ser instalados em um dispositivo e exatamente o que eles podem fazer, a Apple afirma - com razão, na maioria das vezes - que pode fornecer a seus usuários um ambiente de computação seguro no qual eles podem operar sem ter que se preocupar com seus dados e informações pessoais sendo roubado.
Em um nível mais profundo, no entanto, o sandbox também ajudou a empresa a cumprir sua promessa de uma experiência móvel inovadora que pode rivalizar com o desempenho fornecido pelos computadores desktop.
As primeiras gerações de iPhones e iPads eram, essencialmente, grandes telas amarradas a grandes baterias. Como tal, eles sofriam de severas limitações tanto de desempenho quanto de potência que, se não fossem controladas, teriam prejudicado severamente o tipo de interação que a Apple queria que seus usuários usufruíssem: É difícil fornecer rolagem suave consistente ou duração da bateria durante todo o dia quando o usuário pode estar executando dezenas de aplicativos em segundo plano, cada um dos quais está consumindo parasiticamente ciclos de CPU e poder.
Com o sandboxing instalado, a Apple foi capaz de estabelecer e aplicar um conjunto de compromissos por meio dos quais poderia garantir que todo usuário, por mais experiente ou ousado que seja, sempre desfrute do poder que a empresa prometido.
Graças ao sandbox, cada aplicativo em seu dispositivo iOS pode ver apenas seus próprios arquivos, com poucas formas de se comunicar com outros programas.
Tolos de todos nós
Os tempos, no entanto, mudam e o dispositivo móvel médio de hoje é muito menos limitado pelo hardware do que seus ancestrais. Os próprios materiais de marketing da Apple, que normalmente evitam conversas técnicas, agora dizem que iPhones e iPads “aula de desktop” hardware sob suas telas.
O sandbox, infelizmente, não conseguiu acompanhar essas mudanças. Claro, algumas das restrições anteriores foram levantadas: o software de terceiros agora pode ser executado em segundo plano sob alguns circunstâncias, por exemplo, e os aplicativos podem trocar arquivos diretamente, se solicitado pelo usuário, ou por meio de uma área de transferência do sistema.
Mas a capacidade dos aplicativos de se comunicarem diretamente uns com os outros ainda se limita à ideia de URLs personalizados. Este sistema permite que um aplicativo envie dados para outro pedindo ao sistema operacional para “abrir” um aplicativo especialmente criado. endereço - semelhante aos que usamos para acessar um site - que é registrado pelo segundo aplicativo quando é instalado. Mas, embora muito possa ser feito com esses esquemas de URL personalizados, eles ainda apenas arranham a superfície do que é possível.
Essa limitação na comunicação entre aplicativos é ainda mais irritante quando você considera a própria herança do iOS e seu mercado.
Um grande cachimbo
No mundo UNIX de terminais e linhas de comando, os usuários há muito desfrutam do poder do “piping”, uma técnica que torna possível encadear vários comandos de várias maneiras. Ao canalizar a saída de um comando para a entrada do próximo, o usuário experiente pode crie aplicativos surpreendentemente complexos simplesmente colando um conjunto de blocos de construção.
Um corolário dessa configuração é que aplicativos individuais neste mundo tendem a assumir um foco semelhante a uma navalha em um determinado tarefa, fornecendo um grau muito alto de especialização que de outra forma seria difícil de construir em grandes, monolíticos Programas. Sem surpresa, é mais fácil construir um muito bom app cujo único trabalho é classificar dados do que torná-lo um marcador adicional em um pacote de software que também oferece uma infinidade de outras funções.
Inesperadamente, talvez, o modo UNIX de desenvolvimento de software também tende a padronizar o software e permitir mais personalização do usuário ao mesmo tempo. Se você não gosta da maneira como um determinado aplicativo funciona, é provável que encontre outro que possa ser usado como um substituto para ele em suas expressões canalizadas com apenas alterações mínimas em seu fluxo de trabalho.
O conceito de canalização - muito popular no mundo UNIX de terminais e comandos de texto - é um bom exemplo de como permitir que os aplicativos se comuniquem torna possível criar fluxos de trabalho complexos a partir de um conjunto de aplicativos altamente focados.
Pequeno é bonito
No mundo das GUIs e interfaces de toque, terminais e pipes podem parecer o tipo de tecnologia esotérica que interessaria apenas a especialistas em computação sérios, mas sua conceitos subjacentes se aplicam muito bem ao mercado atual de iOS, onde a pressão para baixo aplicada ao preço do software tende a favorecer pequenos aplicativos que se concentram em um determinado tarefa.
Se você deixar de lado por um momento a ideia de que a tubulação tradicionalmente está ligada a uma interface de linha de comando, a ideia de a criação de fluxos de trabalho que envolvem uma cadeia de dados de um aplicativo para outro tem várias vantagens para usuários e desenvolvedores.
Dispositivos mais poderosos e um mercado implacável se traduzem em clientes que esperam que seu software seja mais produtivo mesmo enquanto continuam pagando preços baixíssimos por ele. Infelizmente, os desenvolvedores são sempre obrigados a construir programas que são quase completamente autossuficientes, o que significa ter que lidar com muito mais código do que simplesmente o que torna seus aplicativo específico exclusivo.
Concentre-se onde ele pertence
Veja, por exemplo, aplicativos de câmera; é uma categoria tão lotada que um dólar é praticamente o valor mais alto do que os desenvolvedores podem esperar cobrar pelos frutos de suas labutas.
O problema é que, mesmo que um aplicativo específico tenha algum gancho exclusivo, como, digamos, ser capaz de capturar várias fotos em sequência rápida ou tirar fotos panorâmicas, ele ainda precisa fornecer todas as outras funcionalidades que os usuários esperam de aplicativos desse tipo - filtragem, corte e edição, redução de olhos vermelhos e assim por diante adiante.
Embora o próprio iOS possa fornecer alguns desses recursos, os desenvolvedores têm pouca escolha a não ser investir seu tempo no código que não é realmente central para o aplicativo que eles criaram. construído, ou ignorar o problema completamente e esperar que os usuários de alguma forma consigam descobrir uma maneira de construir seu próprio fluxo de trabalho manual que se aproxime do mesmo nível de funcionalidade.
O resultado final é algo que não beneficia ninguém: os desenvolvedores perdem tempo com recursos que outros já implementaram e os usuários acabam com aplicativos abaixo da média que implementam a mesma funcionalidade, mas com interfaces de usuário inconsistentes e graus variados de qualidade. Sem mencionar os fluxos de trabalho que criam várias cópias inconsistentes dos mesmos documentos à medida que são embaralhados de um aplicativo para outro.
Por outro lado, se os aplicativos pudessem se comunicar entre si, o aplicativo de fotos em nosso exemplo poderia se concentrar em fornecer o melhor experiência de costura panorâmica e delegar a funcionalidade restante a outros aplicativos, que podem manipular o arquivo original por meio de sua própria interface e, em seguida, retorná-lo ao aplicativo original, oferecendo aos usuários o melhor de ambos os mundos.
Os desenvolvedores de aplicativos adoram se concentrar em um conjunto muito restrito de recursos, mas geralmente são forçados a replicar funcionalidades que não podem delegar facilmente a outro software.
De A a B a C
A presença de algum tipo de mecanismo de comunicação entre aplicativos também permitiria aos usuários unir os serviços oferecidos por vários aplicativos em conjuntos coesos de etapas que podem ser executados sem intervenção do usuário, talvez por meio de aplicativos que, como o Automator no OS X, facilitam a criação de fluxos de trabalho complexos com pouco ou nenhum conhecimento técnico.
Não estou necessariamente sugerindo que a Apple deva trazer o Automator para iOS, mas, se você considerar o quão útil um aplicativo como Launch Center Pro pode ser - mesmo com todas as limitações atualmente impostas pelo modelo de sandbox do iOS - não é difícil imaginar o que a melhor comunicação entre aplicativos pode significar para todos, independentemente de quão experientes eles sejam nas formas de Informática. Os usuários podem criar fluxos de trabalho complexos para tudo, desde enviar e-mails até definir lembretes, usando o tipo de interface simples que esperamos de nossos dispositivos móveis.