61
Pós-graduação MIT em Desenvolvimento Mobile A WEB COMO UNIFICAÇÃO DAS PLATAFORMAS MOBILE Allan Marques Baptista Coordenador: Thiago Cortat Rio de Janeiro, maio de 2015

A web como unificação das plataformas mobile

Embed Size (px)

Citation preview

Pós-graduação MIT em Desenvolvimento Mobile

A WEB COMO UNIFICAÇÃO DAS PLATAFORMAS MOBILE

Allan Marques Baptista Coordenador: Thiago Cortat

Rio de Janeiro, maio de 2015

2

RESUMO

Este trabalho tem como objetivo fazer uma análise da atual situação das

plataformas móveis do ponto de vista tanto do desenvolvedor, quanto de negócios,

trazendo uma comparação técnica sobre cada uma das plataformas mais populares,

listando os benefícios e malefícios de cada abordagem e sugerindo uma opção mais

viável em termos de custo e tempo de desenvolvimento, utilizando a WEB e suas

tecnologias como uma interface de alto nível para os recursos nativos das

plataformas mobile. Se baseando em casos de uso do mundo real, este trabalho

explicita os problemas recorrentes nos projetos de desenvolvimento de aplicativos

para dispositivos móveis e tenta introduzir possíveis soluções utilizando uma

abordagem comumente chamada de multi-plataforma, que pode aproveitar ou não

de ferramentas e tecnologias já disponíveis na WEB, facilmente acessíveis e

assimiláveis. Finalizando, lista opções de ferramentas já consolidadas no

desenvolvimento de aplicações multi-plataforma, híbridas ou nativas, que tentam

solucionar justamente os problemas discutidos durante o discorrer deste trabalho,

deixando claros todos os caminhos disponíveis para evitar ao máximo o desperdício

de recursos e tempo em um projeto de aplicativo mobile.

Palavras-Chave: Dispositivos móveis, Desenvolvimento, Aplicativos, Android, iOS, Windows Phone, Multi-Plataforma, Web

3

ABSTRACT

This paper has the goal of making an analysis of the current mobile

platforms situation, not only in the developer`s point of view, but in the business point

of view as well. Bringing a tecnical overview of each of the most popular platforms,

listing the pros and cons of each approach and suggesting a more viable option in

terms of cost and development time, using the web and it`s technologies as a high-

level interface for the native resources of mobile platforms. Based on real-world use

cases, this paper explains the recurrent problems in mobile application development

projects and tries to introduce possible solutions using a common approach called

cross-platform, which can make use or not, of accessible tools and technologies

already available on the web. Finally, it lists some tool options, that are already

consolidated in cross-platform applications development, hybrid or native, and tries to

solve the problems discussed during the discourse of this paper, making clear all

available paths in order to minimize the waste of resources and time in a mobile

application project.

Keywords: Mobile devices, Development, Apps, Android, iOS, Windows Phone, Cross-Platform, Web

4

SUMÁRIO

Resumo ...................................................................................................................... 2

Abstract ...................................................................................................................... 3

1 Introdução ............................................................................................................... 5

1.1 Mobile não é o futuro, é o presente ....................................................................... 5

1.2 A ascensão e queda das startups ......................................................................... 7

1.3 A abordagem multi-plataforma e a WEB ............................................................. 11

2 Comparando as abordagens ............................................................................... 14

2.1 Aplicativos nativos: vantagens ............................................................................ 15

2.2 Aplicativos nativos: desvantagens ....................................................................... 16

2.3 Aplicativos multi-plataforma/hibridos: vantagens ................................................ 18

2.4 Aplicativos multi-plataforma/hibridos: desvantagens ........................................... 19

2.5 Por que a abordagem multi-plataforma/hibrida é o ideal? ................................... 19

3 Ferramentas para desenvolvimento de aplicativos multi-plataforma ............. 21 3.1 Apache Cordova .................................................................................................. 22

3.2 Appcelerator Titanium ......................................................................................... 29

3.3 Intel XDK ............................................................................................................. 35

3.4 Sencha Touch ..................................................................................................... 40

3.5 NativeScript ......................................................................................................... 45

3.6 React Native ........................................................................................................ 50

4 Conclusão ............................................................................................................. 57

Referências .............................................................................................................. 59

5

1 INTRODUÇÃO

Este trabalho irá tentar explicitar o quanto ferramentas oriundas do

desenvolvimento WEB têm influenciado de maneira positiva no desenvolvimento de

aplicativos mobile e o porque esta abordagem pode a vir se tornar a maneira mais

popular de desenvolver aplicativos, devido a sua facilidade, rapidez, baixo custo e

manutenibilidade. Também serão abordados cases e exemplos das ferramentas

citadas aqui e como seus benefícios podem ajudar a baratear o custo do

desenvolvimento de um aplicativo, se tornando uma ótima maneira de validar uma

ideia e ajudando uma pequena/media empresa, startup ou desenvolvedor autônomo

à entrar no disputado mundo dos apps.

1.1 MOBILE NÃO É O FUTURO, É O PRESENTE

A plataforma mobile já deixou de ser coadjuvante no atual contexto

tecnológico e continua a ganhar espaço, sendo o único aparelho tecnológico até

hoje com a possibilidade de ser acessível por toda a população terrestre.

Há pouquíssimo tempo atrás pensávamos em smartphones como a “segunda

tela”, ou seja, um aparelho secundário que complementava a experiência do seu

irmão maior, o laptop ou desktop PC. Era um mundo que visitávamos somente

quando não tínhamos um PC próximo, porém o comportamento das pessoas

mudaram muito, em pouquíssimo tempo. O tempo que passamos utilizando um

smartphone já ultrapassou o tempo que passamos em frente do PC ou da televisão.

6

De acordo com o um estudo da Millward Brown, nos EUA, as pessoas

passam 151 minutos por dia utilizando o smartphone contra 147 minutos diários na

frente da televisão. Limitando o escopo somente para o Brasil, os números são

ainda mais impressionantes, os brasileiros gastam em média 149 minutos por dia

utilizando o smartphone, enquanto passamos somente 113 minutos diários

assistindo televisão.

A mesma pesquisa também revela que 34% da utilização de dispositivos

eletrônicos como smartphones, tables, PCs e TVs, são feitos de forma simultânea.

Comportamento que aumentou muito a necessidade de uma boa experiência cross-

device, ou seja, uma experiência consistente para o usuário que utiliza aquele

mesmo serviço ou produto em múltiplas telas.

Proporção de tempo que passamos utilizando cada dispositivo. (Fonte: http://www.millwardbrown.com/adreaction/2014)

7

Com esses números fica fácil de perceber como o mobile sendo o principal

canal de aquisição e retenção de clientes não é mais o futuro, e sim o presente, e as

empresas que não acompanharem esta tendência pode ficar para trás muito rápido

e alcançar as empresas que às ultrapassaram pode se revelar improvável.

1.2 A ASCENSÃO E QUEDA DAS STARTUPS

O contexto atual na área de tecnologia já está claro há algum tempo, qualquer

empresa que almeja continuar crescendo, seja ela pequena, média ou grande, deve

ter algum tipo de presença no mundo mobile, seja por meio de sites responsivos,

sites exclusivamente mobile ou aplicativos nativos. Sobre qual abordagem a

empresa deve tomar, depende muito do segmento, objetivo e aplicação, mas já é

comum ver as três abordagens serem utilizadas simultaneamente em grandes

produtos como Twitter, Pinterest e Gmail.

Além da necessidade de produtos já consolidados estenderem suas

presenças para o mobile, há também uma quantidade enorme de novas minúsculas

empresas que tentam validar suas ideias utilizando o mobile como escopo principal.

Essas empresas, comumente chamadas de startups, têm surgido no mundo todo,

incentivadas pelo sucesso de grandes cases como WhatsApp, Instagram e Vine.

Cases de sucesso que começaram como startups de pouquíssimos integrantes com

uma simples e inovadora ideia, e que em pouco tempo depois acabaram sendo

compradas por centenas de milhões, ou até dezenas de bilhões de dólares. Graças

à esses grandes cases, em 2015 o número de startups criadas no primeiro semestre

aumentou 300% em relação ao ano anterior.

Mas chegar no patamar dessas pequenas startups que se tornaram enormes

empresas, pode se revelar uma tarefa árdua. Segundo a revista Fortune, nove entre

dez startups acabam falindo antes de alcançar este objetivo, enterrando com ela

todo o esforço feito pelos envolvidos. A revista ainda lista os 20 principais motivos

pelo qual isso acontece.

8

São muitos motivos para se atentar, o que torna claro o quanto qualquer

pequeno erro nesta fase pode representar a falha da startup. Segundo o gráfico

acima o segundo maior motivo é o término do dinheiro para manter a pequena

empresa respirando, o que torna crucial para uma startup, que almeja chegar ao

patamar dos “peixes grandes”, planejar bastante seus custos na hora de validar uma

ideia que pode ou não ter valor no mercado.

As 20 razões pelas quais startups vem a falir, de acordo com seus fundadores (Fonte: http://fortune.com/2014/09/25/why-startups-fail-according-to-their-founders/)

9

O primeiro grande motivo para a “morte” das startups é a falta de valor no

mercado, mas isso também pode ser amenizado com uma boa gestão de custos

nesta etapa tão crucial, afinal se a ideia se revelar não-produtiva, mas ainda houver

dinheiro em caixa para manter a empresa em funcionamento é comum acontecer o

que chamamos de “pivot”, uma palavra bastante utilizada no mundo das startups

para representar a adaptação de uma ideia para que ganhe valor de mercado. Por

exemplo, o Paypal começou como uma empresa de troca de dinheiro virtual entre

dispositivos Palm, mas com o tempo perceberam que seu serviço tinha mais

potencial nos micropagamentos e na troca de dinheiro via web, e agora o Paypal é

consolidado o maior serviço de troca de pagamentos online do mundo.

Quando percebemos que qualquer erro na gestão de custos pode levar à

extinção da startup, fica claro que toda e qualquer forma econômica de validar uma

ideia deve ser tratada como ótima opção nesta fase.

Voltando para o escopo mobile, que é o foco deste trabalho, existem grandes

diferenças entre os caminhos que uma grande e consolidada empresa, e uma

pequena startup devem seguir para serem bem sucedidos ao introduzir seu produto

ou serviço no competitivo mundo das telas pequenas.

Uma empresa consolidada dispõe dos recursos necessários para atacar em

todas as frentes (site responsivo, Web App ou Apps de múltiplas plataformas) e

medir o sucesso de cada uma delas, iniciando um ciclo de implementação, medição,

aprendizado e aprimoramento em todas elas.

Uma pequena startup possui recursos muito limitados e precisam cuidar muito

bem deles, então a abordagem de validar a ideia economizando o máximo possível

de recursos é o ideal. Mas existem várias dificuldades ao tentar validar uma ideia de

maneira barata no contexto mobile, algumas delas são:

• Para atingir todo o público mobile é necessário atender a múltiplas

plataformas

• Para um produto passar credibilidade e qualidade, devem respeitar as

particularidades visuais de cada plataforma

• Tempo de concepção multiplicado por cada plataforma atendida

10

• Custo de concepção multiplicado por cada plataforma atendida

• Falta de mão de obra qualificada

Deixando claro que o fato de ter de atender à mais de uma plataforma é o

principal motivo de aumento de custos na durante o processo de desenvolvimento

de um aplicativo nativo de smartphone. Este fato torna o mundo mobile em um mar

perigoso para uma pequena startup estar.

Ficando explicito que um dos principais motivos de uma startup falhar é a

pobre gestão de custos ao validar uma ideia, a metodologia Lean Startup trouxe a

abordagem de validar essas ideias com versões simplificadas do produto de maneira

que o custo, tempo e risco da implementação dele seja bem menor, tornando

mínimo o ciclo de implementá-lo, medir seu sucesso, aprender com os resultados e

aprimorá-lo. Esta versão simplificada do produto é chamada de MVP, acrônimo para

Minimium Viable Product que representa o produto minimamente viável para validar

uma ideia.

Ciclo de desenvolvimento sugerido pela metodologia Lean Startup (Fonte: http://theleanstartup.com/principles)

11

Tendo em vista o que a metodologia Lean Startup prega fica claro que é uma

abordagem perfeita para pequenas startups, mas como podemos aplicá-la no

contexto mobile? Já que devemos ter em vista várias plataformas para maior

alcance, como podemos desenvolver um MVP que atenda todas as plataformas e

ainda sim ser simples, rápido e barato de implementar?

1.3 A ABORDAGEM MULTI-PLATAFORMA E A WEB

As plataformas mobile mais amplamente difundidas atualmente são duas:

Android (da Google, corresponde à 78% do mercado de smartphones) e iOS (da

Apple, corresponde à 18.3% do mercado de smartphones). Existem também

plataformas que alcançam bem menos pessoas mas ainda sim possuem seu lugar

no mercado e devem ser levadas em consideração, são elas: Windows Phone (da

Microsoft, corresponde à 2.7% do mercado de smartphones) e BlackBerry OS (da

Blackberry, corresponde 0.3% do mercado de smartphones). O gráfico abaixo

demonstra a mudança dessas estatísticas ao longo dos trimestres dos últimos três

anos.

12

Sabendo que há pelo menos quatro plataformas para serem atacadas,

existem várias abordagens para diminuir os custos de um projeto de aplicativo

mobile. Uma delas seria ignorar as plataformas menos populares no início e

somente atacar as outras plataformas assim que a ideia sendo validada se revelar

valiosa o bastante para continuar sua implementação. Embora essa estratégia seja

ótima para diminuir os custos de um projeto, uma grande massa de usuários em

potencial estão sendo ignoradas junto com as essas plataformas, o que pode

diminuir bastante as chances de sucesso na introdução de uma nova ideia no

mercado de aplicativos mobile.

E se existisse uma abordagem que tornasse possível atacar todas as

plataformas possíveis e ainda ter um custo menor que a abordagem descrita acima?

Essa abordagem existe, ela é conhecida como multi-plataforma.

A abordagem multi-plataforma surgiu da necessidade de atender à todas as

plataformas mobile existentes de forma mais barata, rápida e manutenível do que

criar e manter um projeto separado para cada plataforma que deseja atingir. Essa

Market share mundial de plataformas de smartphone (Fonte: http://www.idc.com/prodserv/smartphone-os-market-share.jsp)

13

abordagem torna possível manter somente um projeto, uma base de código, e por

meio de algum tipo de ferramenta de build e compilação, esta base código é portada

para cada plataforma escolhida, provendo uma experiência consistente em todas

elas.

Já existem dezenas de ferramentas que implementam a abordagem multi-

plataforma, muitas delas já consolidadas no mercado, e todas elas implementam

esta abordagem de maneiras diferentes para justificar sua existência.

Algumas ferramentas utilizam de linguagens como Java e C# para abstrair e

unificar as APIs similares de cada plataforma, resultando em só uma API, só um

framework, que é encarregado de compilar para sua versão nativa de cada

plataforma. Outras utilizam uma abordagem mais simples, que consiste em utilizar

um componente de WebView, que funciona como um navegador “embarcado” na

aplicação que irá renderizar telas criadas com as tecnologias web mais conhecidas:

HTML, CSS e Javascript. Além de fornecer uma API, geralmente via Javascript, para

comunicação com as características nativas que todo dispositivo mobile oferece,

como GPS, contatos, armazenamento local, acelerômetro e giroscópio, vibração e

até bluetooth.

A abordagem multi-plataforma utilizando ferramentas web já está muito

difundida entre os desenvolvedores que já possuem experiência com a tecnologias

web, pelo fato de não precisarem abdicar de todas suas habilidades e aprenderem

um novo ecossistema de ferramentas, somente para desenvolver um aplicativo

mobile nativo. Várias grandes empresas também aderiram esta abordagem para

melhor utilização de seus recursos na validação de um produto como aplicativo de

smartphones.

Este trabalho irá apresentar cases de sucesso e exemplos utilizando a

abordagem multi-plataforma, utilizando ferramentas web já consolidadas como

espinha dorsal de sua implementação. Serão apresentadas as ferramentas mais

populares que implementam essa abordagem, suas vantagens e desvantagens, e

como a adoção destas ferramentas em grande escala está mudando o mundo do

desenvolvimento de aplicativos nativos para sempre.

14

2 COMPARANDO AS ABORDAGENS

Até então foram citadas três abordagens (sites responsivos/web apps, apps

nativos e apps multi-plataforma/híbridos) para desenvolvimento de aplicações

mobile, embora este trabalho foque em somente um deles, é preciso listar as

diferenças entre cada abordagem e o porquê da solução proposta aqui, poder ser

uma abordagem melhor dependendo do escopo.

Na tabela abaixo é feita uma comparação entre as abordagens de ao longo

de vários items.

App nativo Web app / site responsivo

App multi-plataforma / hibrido

Skill / ferramentas necessárias para desenvolvimento em várias plataformas

• Objective-C / Swift

• Java

• C++

• C#

• HTML

• CSS

• Javascript

• Linguagem de back-end (nodeJS, PHP, Ruby...)

• HTML

• CSS

• Javascript

• Linguagem de back-end (nodeJS, PHP, Ruby...)

• Framework de desenvolvimento mobile

Apps necessários para atingir todas as plataformas mais populares

4 1 1

Instalado no dispositivo? Sim Não Sim

Distribuição App Store/Market Internet App Store/Market

Integração com dispositivo

Integração total: (câmera, microfone,

GPS, giroscópio, acelerômetro, upload de arquivos, contatos,

bluetooth)

Integração parcial:

(GPS, giroscópio, acelerômetro, upload

de arquivos)

Integração total: (câmera, microfone,

GPS, giroscópio, acelerômetro, upload de arquivos, contatos,

bluetooth)

15

Na comparação acima fica nítida que a abordagem multi-plataforma

utilizando ferramentas web une as caraterísticas da aplicação nativa com as

características do web app, formando um “híbrido” que reúne as forças das outras

abordagens (por isso são chamados de Aplicativos Híbridos). Mas ainda assim, ao

desenvolver aplicativos mobile, há vantagens e desvantagens de seguir cada

abordagem, e é imprescindível que elas sejam levadas em consideração ao iniciar

um projeto, pois cada abordagem somente é adequada para um caso, se este

atende os requisitos que a abordagem necessita.

2.1 APLICATIVOS NATIVOS: VANTAGENS

Melhor performance gráfica possível: Quando criados utilizando a

linguagem nativa do dispositivo, os aplicativos oferecem a melhor performance

gráfica e animações possíveis. Se o aplicativo necessita ter grande performance

gráfica, como um jogo, aplicativos escritos com sua linguagem nativa são sua

melhor opção.

Distribuição nas lojas de aplicativos: Aplicativos nativos são distribuídos

pelas lojas e marketplaces de aplicativos da sua plataforma. Distribuição em lojas de

aplicativos é essencial se o aplicativo necessita ser acessível para consumidores em

larga escala, ou em aplicativos que precisam ser vendidos. É importante notar que

aplicativos híbridos também podem ser distribuídos em lojas de aplicativos.

Integração com o dispositivo: Aplicativos nativos possuem total acesso ao

hardware do dispositivo como seu sensor GPS, lista de contatos, câmera, microfone,

giroscópio, acelerômetro e bluetooth. Essas capacidades são essenciais para

aplicativos que necessitam de informações do dispositivo como localização

geográfica ou posição/deslocamento do dispositivo. É importante notar que

aplicativos híbridos também possuem total integração com essas capacidades do

dispositivo.

16

2.2 APLICATIVOS NATIVOS: DESVANTAGENS

Sem portabilidade: Como cada aplicação nativa roda somente em uma

plataforma, deve-se tomar a decisão de construir o aplicativo para uma só

plataforma ou para várias. Infelizmente não há respostas fáceis. Como ilustrado pela

imagem abaixo, o panorama mobile possui quatro consolidadas plataformas de

smartphones e quatro consolidadas plataformas de tablets. Construindo um

aplicativo para uma só plataforma, exclui outras sete, já construindo para todas as

plataformas necessita de uma significante quantidade de tempo e recursos.

Instabilidade de plataforma: O panorama das plataformas mobile é

notoriamente instável. Uma plataforma popular hoje pode desaparecer em alguns

anos. Por exemplo, ambos Blackberry e Palm dominaram a indústria mobile há

somente cinco anos atrás. Hoje, Blackberry está lutando para continuar viva e Palm

não existe mais. Quando se escolhe a abordagem nativa sempre há o risco de

desperdício de tempo e dinheiro, construindo um aplicativo para uma plataforma que

pode não durar muito tempo.

Custo de desenvolvimento: Enquanto o custo do desenvolvimento de

aplicativos nativos varia de acordo com a complexidade do aplicativo, é facilmente a

(Fonte: http://www.mrc-productivity.com/)

17

abordagem mais cara e que exige mais tempo para ser seguida. Por exemplo, a

Forrester Research, em uma de suas pesquisas, estima que aplicativos nativos

necessitam de pelo menos seis meses de trabalho e custam entre $20.000 e

$150.000 dependendo da sua complexidade. A mesma pesquisa resultou em uma

tabela de custos bem desanimadora para pequenos empreendedores.

Custo de um

aplicativo

Número de aplicativos

necessários Custo total

Aplicativo de uma plataforma

$20.000 - $150.000 1 $20.000 - $150.000

Aplicativo de várias plataformas

$20.000 - $150.000 4 $80.000 - $600.000

Aplicativo de varias plataformas + aplicativos de tablets

$20.000 - $150.000 8 $160.000 - $1.200.000

No brasil, segundo uma pesquisa feita pela Esauce, “Um aplicativo de celular

de pequeno porte consome de 150 a 500 horas para ser desenvolvido. Tem o custo

aproximado entre R$ 10 mil e R$ 60 mil. Aplicativos mais complexos podem custar

entre R$ 100 mil e R$ 200 mil.” (esauce.com.br, 2014)

Tempo de desenvolvimento: Como mencionado acima, a Forrester

Research estima que um único aplicativo nativo necessita de seis meses de tempo

de desenvolvimento. Quando desenvolvendo aplicativos para mais de uma

plataforma, o tempo requerido aumenta dependendo do número de desenvolvedores

necessários e complexidade da aplicação. Por exemplo, utilizando somente um

desenvolvedor para desenvolvimento de aplicativos para várias plataformas de

18

smartphones aumenta o tempo de desenvolvimento para dois anos (4 aplicativos x 6

meses para cada). Porém, estimação de tempo de desenvolvimento quando

utilizando múltiplos desenvolvedores não é nada fácil. Por exemplo, se uma startup

utiliza quatro desenvolvedores diferentes para cada plataforma de smartphone,

estes irão receber quatro designs diferentes da aplicação. Como qualquer

gerenciador de projetos sabe, garantir que múltiplos aplicativos, desenvolvidos por

múltiplos desenvolvedores, tenham comportamentos e experiências idênticas é uma

tarefa que consume bastante tempo.

Custo de manutenção: Enquanto todas as aplicações necessitam de

manutenções e atualizações regulares, aplicativos nativos necessitam de muito mais

manutenções futuras quando comparamos com as outras abordagens de

desenvolvimento. Além da manutenção regular, aplicativos nativos também podem

ter que ser atualizados sempre que a plataforma é atualizada. Adicionalmente,

quando construindo aplicativos nativos para várias plataformas, também é

necessário manter estes aplicativos em várias plataformas, ou sejas, cada pequena

mudança em um aplicativo nativo de smartphone e tablet que possui versão em

todas as plataformas mais populares pode ter que ser replicada até oito vezes, uma

vez para cada plataforma.

2.3 APLICATIVOS MULTI-PLATAFORMA/HIBRIDOS: VANTAGENS

Look-and-feel nativo (sem o custo do nativo): Como aplicativos nativos,

aplicativos híbridos também são instalados no dispositivo e funcionam como uma

típica aplicação nativa. Esses atributos nativos fazem com que o aplicativo hibrido se

torne praticamente indistinguível de aplicativos nativos. Na verdade, muitas pessoas

não sabem que aplicativos “nativos” populares como Linkedin, Foursquare, e Twitter

são na verdade aplicativos híbridos.

Integração com o dispositivo: Como mencionado acima, aplicativos

híbridos funcionam exatamente como aplicativos nativos, então possuem total

acesso à capacidades nativas do dispositivo, sem exceção.

19

Distribuição nas lojas de aplicativos: Novamente aqui, como aplicativos

nativos, aplicativos híbridos podem ser distribuídos nas lojas de aplicativos da

mesma maneira, então “win-win".

Desenvolvimento multi-plataforma de baixo custo: Como geralmente é

necessário uma base de código para desenvolver e manter aplicativos para várias

plataformas, o custo e o tempo necessário são bem menores quando comparados

com a abordagem nativa. Por exemplo, se uma startup já tem um web app, o tempo

e custo para portar este aplicativo como aplicativo nativo são quase nulos já que

toda base de código pode ser reutilizada. Adicionalmente, todo conhecimento dos

desenvolvedores web podem ser aproveitados no desenvolvimento de um aplicativo

hibrido, o que diminui o custo na perspectiva de que não será preciso alocar tempo

para aprender uma nova plataforma de desenvolvimento ou gastar dinheiro

contratando um desenvolvedor que possui proficiência naquela plataforma.

2.4 APLICATIVOS MULTI-PLATAFORMA/HIBRIDOS: DESVANTAGENS

Performance gráfica limitada: Apesar da sua aparência nativa, aplicativos

nativos possuem as mesmas capacidades gráficas que web apps. Embora na

maioria dos casos esta diferença na performance é negligenciável, quando o

aplicativo necessita de grande capacidades gráficas, como games, a abordagem

ideal é a nativa.

Necessita familiaridade com algum framework mobile hibrido: Transformar um web app em um aplicativo mobile hibrido necessita do

conhecimento da ferramenta/framework mobile hibrido. Mesmo sendo muito mais

simples que o desenvolvimento nativo, a abordagem hibrida adiciona um nível de

complexidade ao processo de desenvolvimento do web app mobile, já que os

desenvolvedores necessitam se familiarizar com o framework hibrido.

2.5 POR QUE A ABORDAGEM MULTI-PLATAFORMA/HIBRIDA É O IDEAL?

20

A não ser que esteja num escopo onde o custo e tempo de desenvolvimento

não seja um problema (o que geralmente é improvável) ou que o produto final

necessite de magnifica performance no mobile (como games, por exemplo), não há

valor de negócios em seguir a abordagem nativa para validar um ideia ou ao iniciar

um projeto.

Após de levar em consideração os pontos levantados neste capitulo e os

conceitos que o Lean Startup prega, fica claro que a melhor maneira de desenvolver

um MVP no escopo mobile é seguir a abordagem multi-plataforma/hibrida. Ao fazer

isso, agrega-se os benefícios dos aplicativos nativos com os benefícios da web,

minimiza-se ao máximo suas desvantagens e ainda sim, com o menor custo

possível quando comparando com as outras abordagens.

Como a abordagem hibrida no desenvolvimento de aplicativos mobile nativos

possui maior valor de negócios, novas ferramentas que implementam essa

abordagem surgem todo dia, logo o principal problema se torna decidir qual

ferramenta é a ideal para o escopo da ideia que deseja validar, mas comparado à

problemas que podem extinguir uma startup embrionária, este é o menor deles.

21

3 FERRAMENTAS PARA DESENVOLVIMENTO DE APLICATIVOS MULTI-PLATAFORMA / HIBRIDOS

Dentre todas as opções disponíveis para desenvolvimento de aplicativos

multi-plataforma/híbridos há aquelas ferramentas que se destacam, embora isso não

signifique que as ferramentas menos populares não devem ser levadas em

consideração. Além disso, o panorama de desenvolvimento é um muito volátil, é um

mundo em constante movimento, em que a todo momento novas ferramentas

nascem e outras se tornam obsoletas, portanto a escolha deve levar em

consideração vários pontos importantes como:

• Escopo do problema a ser solucionado;

• Custo (nem todas as ferramentas são gratuitas ou open-source);

• Tamanho da comunidade (geralmente quanto maior a comunidade em torno

da ferramenta, mais informação sobre ela pode ser encontrada online);

• Qualidade do suporte e documentação;

• Habilidades já dominadas pelos desenvolvedores da equipe;

• Curva de aprendizado;

• Velocidade de desenvolvimento e facilidade de manutenção.

Sabendo como avaliar as opções, falta saber que opções avaliar. Neste

capitulo serão apresentadas as opções mais populares, serão listadas suas

vantagens e desvantagens e e seus cases de sucesso.

As ferramentas que serão apresentadas aqui são:

• Apache Cordova (Adobe Phonegap, Ionic)

• Appcelerator Titanium

• Intel XDK

• Sencha Touch

• NativeScript

• React Native

22

3.1 APACHE CORDOVA

Antes chamado de Phonegap, projeto open-source iniciado e mantido pela

empresa Nitobi que foi comprada pela poderosa Adobe, e por ter um grande número

de contribuidores (inclusive de grandes empresas como IBM), foi incluída no Apache

Software Foundation.

No inicio, o nome do projeto foi alterado para “Apache Callback”, mas depois

renomeado para “Apache Cordova” (nome de uma rua onde os escritórios da Nitobi

se situavam). A mudança de nome foi necessária pois, diferentemente do projeto, a

marca Phonegap fazia parte da compra da Nitobi pela Adobe.

Hoje Phonegap é somente uma distribuição “comercial” do Apache Cordova.

Para ilustrar melhor, Brian Leraux (um dos criadores do Phonegap) fez a analogia de

que “o Apache cordova é para o Phonegap o que o Webkit é para o Chrome ou

Safari” (LERAUX, BRIAN, 2011).

Como definido pelo própria documentação, o Apache Cordova é um conjunto

de APIs que permite que o desenvolvedor acesse funções nativas do dispositivo,

como câmera e acelerômetro, via Javascript. Quando combinado com um framework

de interfaces de usuário como JQuery Mobile, Dojo Mobile ou Sencha Touch,

permite que um aplicativo de smartphone ou tablet seja desenvolvido utilizando

apenas HTML, CSS e Javascript.

Enquanto utilizando as APIs do Apache Cordova, um aplicativo pode ser

construído sem a necessidade do desenvolvedor escrever sequer uma linha de

código nativo (Java, Objecttive-C, Swift, C#, etc...). Ao invés disso, tecnologias web

são utilizadas e servidas localmente, direto do aplicativo (normalmente não em um

servidor HTTP remoto).

Devido ao fato das APIs Javascript serem consistentes em múltiplas

plataformas de dispositivos e serem construídas em cima dos padrões web, o

aplicativo se torna portável para outras plataformas, com poucas ou mesmo

nenhuma mudança.

23

O Apache Cordova provê uma série de bibliotecas Javascript uniformes que

abstraem o código nativo especifico de cada plataforma e está disponível nas

plataformas: iOS, Android, Windows Phone, Blackberry, Palm WebOS, Bada e

Symbian.

Construído desde o início com o mindset em extensibilidade e plugabilidade, o

Apache Cordova provê um sistema simples de desenvolvimento, consumo e

contruibuição de plug-ins. Com exceção do Core, todas as APIs de acesso às

capacidades nativas do dispositivo só estarão disponíveis assim que seu plug-in

equivalente estive instalado no projeto. Por exemplo, caso seja necessário o acesso

à câmera do dispositivo, será necessário instalar o plug-in de câmera no projeto

utilizando a ferramenta de interface de linha de comando (CLI) do Apache Cordova.

Após o plug-in ser instalado, a API de acesso a câmera do dispositivo estará

disponível para o desenvolvedor via Javascript.

A maior parte da utilização do Apache Cordova é feita a partir de sua

ferramenta de CLI. Como esta ferramenta é baseada em Node.js, e distribuída via

NPM (Node Package Manager), é necessário como pré-requisito que o usuário

instale o Node.js e um cliente Git (o mais utilizado gerenciador de versões). Após a

instalação destas ferramentas, basta utilizar o comando “sudo npm install –g

cordova” (OS X ou Linux) ou “npm install –g cordova” (Windows), e a ferramenta de

CLI do Apache Cordova estará pronta para ser utilizada.

Após a instalação da ferramenta de CLI do Apache Cordova o próximo passo

é criar um projeto do aplicativo, que pode ser facilmente feito a partir do comando

“cordova create $DIR_DO_APP $ID_DO_APP $NOME_DO_APP“ na interface de

linha de comandos do sistema operacional sendo utilizado. Com isso será criado um

projeto de aplicativo com o nome de “$NOME_DO_APP”, identificador de aplicativo

“$ID_DO_APP”, na pasta “$DIR_DO_APP”.

24

A estrutura de arquivos do Apache Cordova foi pensada de maneira que

qualquer desenvolvedor que tenha familiaridade com as mais conhecidas ferramenta

web de front-end se sinta à vontade em seu ambiente. A estrutura de um projeto de

aplicativo do Apache Cordova é composta basicamente por quatro pastas de

arquivos e um arquivo “config.xml” na raíz do projeto. Abaixo uma breve descrição

sobre cada parte da estrutura:

• config.xml: Arquivo de configuração XML global, agnóstico de plataforma,

que controla vários aspectos de comportamento do aplicativo (como

ícones, splash-screen, customizações de plataforma e etc...);

• hooks/: Pasta onde são armazenados scripts que podem ser adicionados

por plug-ins, pela aplicação ou scripts de build, para customizar comandos

do Apache Cordova;

• platforms/: Pasta onde ficam armazenados os projetos de código nativos

de plug-ins e da própria aplicação. Este código quando compilado que

origina o executável do aplicativo que poderá então ser distribuído nas

lojas de aplicativos;

• plugins/: Pasta onde ficam armazenados os plug-ins instalados no

projeto;

Estrutura de arquivos de um projeto de aplicativo do Apache Cordova

25

• www/: Pasta onde ficam os principais arquivos do aplicativo e onde o

desenvolvedor construirá a interface para ser consumida pelo usuário

mobile. O arquivo index.html contido aqui é o ponto de entrada para o

aplicativo.

Apesar de ser possível testar o aplicativo direto do navegador do desktop ou

notebook sendo utilizado como maquina de desenvolvimento, o que torna o

desenvolvimento mobile bem mais dinâmico (sem precisar compilar aplicação

sempre que fizer uma modificação), também é possível testar a aplicação direto de

um dispositivo smartphone/tablet, ou simplesmente de um simulador da plataforma

desejada.

O comando “cordova platform add $PLATAFORMA” adiciona um projeto de

código nativo da plataforma escolhida, que permite compilar o aplicativo para aquela

plataforma. Executando o comando “cordova build $PLATAFORMA”, o Apache

Cordova executa o build que compila o projeto nativo da plataforma escolhida e cria

o pacote que pode ser enviado para loja de aplicativos para ser baixado pelos

usuários finais. Por fim, o comando “cordova run $PLATAFORMA” executa o

aplicativo em um dispositivo conectado em modo de desenvolvedor ou no simulador

daquela plataforma, se estiver disponível.

26

Como falado mais acima, o Apache Cordova somente revela APIs de

comunicação com as APIs nativas do dispositivo, deixando o desenvolvedor com a

total liberdade de utilizar qualquer framework de interface de usuários ou conjunto de

bibliotecas em que ele tiver mais proficiência. Esta flexibilidade fez que com que

vários frameworks web exclusivos para dispositivos mobile tenham nascido com sua

arquitetura pensada para total interoperabilidade com as APIs que o Apache

Cordova fornece. Estes frameworks ajudam a abstrair grande parte das

complexidades existentes ao criar uma aplicação web voltada para o mobile,

deixando o desenvolvedor focar no que realmente importa. Dentre os vários

frameworks e bibliotecas existentes, há os mais aceitos pela comunidade e com a

maior gama de cases de sucesso, alguns deles são:

• Ionic Framework (Baseado no framework Javascript AngularJS da Google)

• Onsen UI (Pode ser utilizado com Angular JS ou JQuery)

• JQuery Mobile (Baseado em JQuery e JQuery UI)

Aplicativo do Apache Cordova simples, rodando nos simuladores de iOS e Android

27

• Reapp (Baseado no framework de UI ReactJS do Facebook

• Sencha Touch (Abordado aqui com mais profundidade mais abaixo)

• Famo.us (Baseado em canvas HTML5)

Como foi dito acima, há vários cases de sucesso que utilizaram o Apache

Cordova como espinha dorsal do seu desenvolvimento de aplicativos mobile,

entre eles:

• Wikipedia: O aplicativo oficial do Wikipedia foi construído utilizando o

Cordova/Phonegap;

• Facebook: Utiliza uma versão alterada do Apache Cordova na sua API

mobile;

• Salesforce: Utiliza uma versão alterada do Apache Cordova na dua API

mobile;

• IBM: A plataforma IBM/Worklight de desenvolvimento mobile é baseada em

cima do Apache Cordova;

• Microsoft: Utiliza a plataforma Apache Cordova para criar alguns aplicativos

multi-plataforma, além de contribuir para o projeto (especificamente para

plataforma Windows Phone);

• Adobe: Como dito acima, a Adobe é atual mantenedora da maior distribuição

do Apache Cordova existente, o Phonegap. A Adobe possui todo um

ecossistema de criação de aplicativos utilizando o Phonegap.

28

O Apache Cordova é uma das maiores e mais consolidadas ferramentas de

desenvolvimento multi-plataforma utilizando o ecossistema web como sua base para

criação de interfaces de usuário para aplicativos mobile. Porém possui alguns

pontos ruins que devem ser salientados. Por exemplo, sua documentação é bem

“rasa” e nada intuitiva, obrigando o desenvolvedor a procurar a solução de possíveis

problemas em fontes menos confiáveis como blogs ou fóruns. Outra desvantagem é

que o Apache Cordova é atualizado com uma frequência relativamente baixa, o que

torna o acesso à novas capacidades nativas e soluções de bugs bastante

burocrático.

Concluindo, o Apache Cordova é uma ótima opção para projetos que

necessitam de grande flexibilidade no aproveitamento de conhecimentos prévios de

ferramentas web dos desenvolvedores envolvidos. Possui vários plug-ins que

aceleram o desenvolvimento e consequentemente diminuem o custo, têm uma das

maiores comunidades em torno dela, vários casos de uso e exemplos para serem

estudados, e por ultimo, mas não menos importante, é open-source. Para sempre.

Aplicativos construídos com Apache Cordova/Phonegap. (Fonte: http://phonegap.com/app/feature/)

29

3.2 APPCELERATOR TITANIUM

No ano de 2008, quando foi introduzido, o Titanium tinha como foco principal

o desenvolvimento multi-plataforma de aplicações desktop e era frequentemente

comparado ao Adobe Air, que tinha o mesmo propósito. Mas em 2009 foi adicionado

o suporte para desenvolver aplicações mobile para Android e iPhone, que foi

ganhando mais e mais importância e visibilidade, quando em 2012, o Titanium

Desktop foi separado e se transformou em um projeto mantido pela comunidade

chamado TideSDK. Durante os anos seguintes o Titanium Mobile SDK foi evoluindo

e ganhando suporte para cada vez mais plataformas como Blackberry, Tizen,

Tablets Android e iOS, e Windows Phone.

Em 2013, Jeff Haynie, CEO da Appcelerator (empresa criadora e

mantenedora do Titanium) anunciou que a tinham iniciado um projeto para

reescrever o Titanium SDK em Javascript para melhorias de performance e também

para tornar o acesso ao código de baixo nível do SDK mais simples para

desenvolvedores. Em um artigo ele escreveu: “Nós acreditamos que Javascript deve

ser a linguagem correta para construir o Titanium SDK em sí, e não somente

aplicativos desenvolvidos em cima do Titanium” (HAYNIE, JEFF, 2013). Neste ano,

segundo a Business Insider, estimava-se que 10% dos smartphones do mundo todo

estariam rodando aplicativos construídos com o Titanium, além disso, já possuía

uma base de mais de 500.000 desenvolvedores cadastrados.

O Appcelerator Titanium é um framework open-source, também licenciado

pela Apache, que permite a criação de aplicativos mobile multi-plataforma, e oferece

suporte para as plataformas Android, iOS, Windows Phone, Blackberry OS e Tizen,

com somente uma base de código em Javascript. O componente principal do

Titanium é o Titanium SDK, porém a Appcelerator desenvolveu também o Alloy, um

framework que segue o paradigma Modelo-Interface-Controladora (MVC) baseado

no Titanium que ajuda a acelerar ainda mais o desenvolvimento de aplicativos que

podem ser rodados nas mais populares plataformas mobile. Também incluído no

ecossistema do Titanium, a Appcelerator criou o Titanium Studio, um ambiente

30

integrado de desenvolvimento (IDE) proprietário que permite o desenvolvimento com

Titanium utilizando ferramentas visuais de criação de interfaces mobile.

As principais características do Appcelerator Titanium incluem:

• Uma API multi-plataforma para acessar componentes nativos de interfaces de

usuário, tais como barras de navegação, menus, e caixas de diálogo, além de

funcionalidades do dispositivo como sistema de arquivos, rede,

geolocalização, acelerômetro e mapas.

• Acesso transparente à funcionalidades nativas em que o SDK ainda não

oferece suporte.

Todo código-fonte da aplicação é instalado no dispositivo, onde é interpretado

utilizando o motor Javascript V8, da google. O carregamento do aplicativo pode levar

mais tempo do que em aplicativos desenvolvidos com sua respectiva SDK nativa.

Isso acontece porque o interpretador e todas as bibliotecas necessárias precisam

ser carregadas antes que a interpretação do código-fonte seja iniciada.

A Appcelerator afirma que o Titanium e seu ecossistema permite a

reutilização de 60% à 90% do código-fonte da aplicação quando desenvolvendo

para múltiplas plataformas, o que o torna uma ótima opção para prototipação e

validação de ideias com baixíssimo custo e curtíssimo tempo. A Appcelerator

também oferece uma extensa serie de ferramentas disponibilizadas por meio de

uma interface web simples e amigável que permite:

• Criar APIs para prover dados para os aplicativos;

• Gerenciar, escalar e estender APIs na nuvem;

• Enviar notificações Push;

• Gerenciar o ciclo de vida dos aplicativos;

• Receber visões diferenciadas de negócio;

• Monitorar performance e erros fatais de aplicativos;

31

Embora o Titanium SDK seja open-source, a melhor maneira de desenvolver

um aplicativo mobile utilizando-o, é por meio das ferramentas que a Appcelerator

oferece, e para isso ser possível é necessário o cadastro na base de

desenvolvedores do Appcelerator. O cadastro é gratuito, e suas ferramentas

também possuem versões gratuitas, porem para usufruir o máximo da plataforma

Appcelerator é necessário uma assinatura, que pode ser adquirida por $39 dólares

mensais. A plataforma Appcelerator permite três formas de iniciar a criação de um

aplicativo:

• Appcelerator Studio: Uma IDE baseada no Eclipse que provê uma ambiente

único e extensível para o desenvolvimento de aplicativos mobile;

• Appcelerator CLI: Ferramenta de interface de linha de comando que reúne

todos os comandos para criar e gerenciar aplicativos mobile;

• Importação de Aplicativos: Oferece ferramentas de análise, serviços e

testes para aplicativos construídos com Titanium SDK, ACS ou Node.ACS.

Representação do ecossistema Appcelerator (Fonte: http://www.appcelerator.com/)

32

Um projeto típico do Appcelerator Studio possui a seguinte arquitetura de

arquivos:

• app/: Diretório principal da aplicação, contém estrutura baseada em MVC;

o assets/: Arquivos que serão instalados como recursos do aplicativo

nativo;

o controllers/: Controladoras da aplicação;

o lib/: Bibliotecas de utilidades;

o migrations/: Arquivos de migrações necessárias de banco de dados

o models/: Modelos de acesso a dados da aplicação;

o styles/: Arquivos de estilo .tss, baseado em css, oferece uma

abstração unificada da construção de estilos de cada plataforma;

o views/: Arquivos de interface .xml, oferece uma abstração unificada na

construção de interface de usuários de cada plataforma;

o widjets/: Componentes pré-compilados reutilizáveis pela aplicação

o alloy.js: Arquivo executado antes da execução de qualquer controller,

utilizado para inicialização (bootstrapping)

Projeto criado no Titanium Studio

33

o config.json: Arquivo de configuração utilizado para revelar variáveis

disponíveis em toda execução da aplicação

• platform/: Contém cada projeto de código fonte nativo criado pelo Titanium;

• plugins/: Plugins utilizados pela aplicação;

• tiapp.xml: Configurações principais do aplicativo (como ID da App, versão,

etc...);

• ITunesConnect.png, MarketplaceArtwork.png: Imagens da loja de

aplicativos.

Graças ao tamanho de sua base de desenvolvedores e por ser consolidado

no mercado de híbridos por muito tempo, muitas empresas o escolhem como

primeira opção para criação de aplicativos mobile, o que tornou a lista de cases de

sucesso muito grande para serem listados aqui sem resumo. Uma lista dos

aplicativos mais populares construídos com Appcelerator Titanium inclui:

• Wunderlist (gerenciador pessoal de tarefas)

Mesmo aplicativo de mapa rodando no iOS e Android

34

• Paypal (serviço de pagamentos e troca de dinheiro online)

• ebay (anuncio de produtos)

• citi (gerenciamento de cartão de credito)

• Khan Academy (plataforma de treinamento de desenvolvimento)

• Vmware (virtualização)

• GameStop (loja de games)

Como foi dito anteriormente, o Appcelerator possui uma das maiores bases

de desenvolvedores cadastrados do mundo, é robusto, com um ecossistema

completíssimo de ferramentas que possibilitam a criação, manutenção e

monitoramento de aplicativos mobile. Oferece serviços de back-end em que o

aplicativo pode se apoiar, como criação de APIs e envios de notificações de Push. É

de fácil aprendizado, tem incrível performance quando comparado com outras

ferramentas de desenvolvimento multi-plataforma, simplifica e acelera o

desenvolvimento de protótipos e aplicativos pequenos. Porém o Appcelerator

Aplicativos desenvolvidos com Appcelerator Titanium (fonte: http://www.appcelerator.com/customers/app-showcase/)

35

Titanium também possui alguns problemas que devem ser levados em

consideração:

• Para usufruir de todas as ferramentas é necessário assinar os serviços da

Appcelerator, o quem para uma pequena startup ou desenvolvedor autônomo

pode não ser nada atrativo;

• Todas as ferramentas, incluindo as gratuitas, necessitam de login para ser

utilizadas e ocasionalemente o sistema de autenticação se torna instável, o

que pode impedir que desenvolvedores trabalhem nos seus aplicativos;

• Normalizar aplicativos em todas as plataformas, embora possa ser

considerado uma vantagem, também é uma desvantagem, já que é

necessário o aprendizado de tecnologia proprietária que pode não ser

diretamente transferível fora do ecossistema do Titanium.

Baseado em tudo que foi falado aqui, fica claro o quanto o Titanium pode

baratear e diminuir o tempo de um projeto de aplicativo mobile. Os seus serviços

completos e robusto, junto ao fato de somente estarem disponíveis a partir de uma

assinatura torna o Appcelerator uma opção mais apropriadas para empresas

pequenas que já possuem algum recurso para investir na validação de um modelo

de negócios, mas ainda precisam gerenciar esses recursos de forma eficiente e

eficaz.

3.3 INTEL XDK

Em 2013, a Intel adquiriu a AppMobi, uma plataforma de serviços integrados

voltados para aplicativos mobile, na iniciativa de oferecer um ecossistema integrado

de construção, manutenção, monitoramento, e serviços de back-end como APIs e

envios de notificações Push. Esse ecossistema foi então, integrado ao Intel XDK,

uma IDE centralizada que inclui o popular editor Brackets e um Editor WYSIWYG,

criando uma plataforma que hoje é um dos mais completos e consolidados conjunto

de ferramentas para desenvolvimento de aplicativos mobile multi-plataforma

36

existentes. O Intel XDK pode ser baixado gratuitamente em seu site, e possui versão

para todos os sistemas operacionais mais populares.

Diferentemente das outras opções, o Intel XDK não requer nenhuma

dependência para compilar aplicativos para as plataformas que ele suporta.

Utilizando o Apache Cordova por exemplo, para compilar um aplicativo iOS você

necessita do XCode e suas ferramentas, e consequentemente, é necessário que

esteja utilizando o sistema operacional Mac OS X para que seja possível iniciar o

processo de build. Com o Intel XDK isso não é necessário, como sua compilação é

feita na nuvem, graças aos seus serviços integrados, qualquer aplicativo pode ser

compilado para todas as plataformas de dispositivos em qualquer sistema

operacional. O Intel XDK suporta a criação de aplicativos mobile para Android, iOS,

Windows, Firefox OS e Tizen, além de suportar também o desenvolvimento Apps

para Chrome OS, Facebook, Amazon e Nook.

Embora seja gratuito, para iniciar o desenvolvimento com o XDK é necessário

que o desenvolvedor se cadastre na base de usuários da Intel, pois ao abrir a IDE

são requisitadas as credenciais do utilizador, que só quando validadas habilitam o

acesso as ferramentas integradas que ele oferece.

O Intel XDK utiliza o Apache Cordova como base de seus projetos, o que o

possibilita a importação de um projeto feito puramente com Apache Cordova,

transformando-o em um projeto do Intel XDK. A IDE oferece duas maneiras de

desenvolver os aplicativos: uma é utilizando um editor criado para desenvolvimento

web, o Brackets, que possui uma grande base de usuários, plug-ins e é mantido pela

Adobe. A outra maneira é utilizando um editor visual de interfaces onde o

desenvolvedor pode facilmente criar um protótipo por meio de “clique e arraste” de

componentes reutilizáveis. Esses componentes são baseados em frameworks

HTML5 específicos para interfaces mobile. Os frameworks suportados são:

• App Framework (mantido pela própria Intel)

• Ionic

• Twitter Bootstrap 3

• JQuery Mobile

37

• TopCoat

• Ratchet

As ferramentas da IDE são separadas por abas numa sequência lógica, que

tenta seguir os passos existentes no ciclo de desenvolvimento de aplicativos mobile,

as abas seguem a seguinte ordem:

1. Desenvolvimento: Onde fica o código fonte e as ferramentas de edição de

código ou o App Designer (Editor WYSIWYG);

2. Simulação: Usado para simular sua aplicação dentro de um dispositivo alvo,

é baseado no Apache Ripple, que é basicamente uma versão empacotada do

Chrome (Webkit) com suporte à algumas APIs extras;

3. Teste: Utilizado para testar seu aplicativo em um dispositivo real, utilizando o

aplicativo da Intel chamado App Preview que deve estar instalado no

dispositivo alvo;

4. Depuração: Por enquanto disponível somente para Android e iOS, permite a

depuração de aplicativos em tempo real via USB;

Ambiente de desenvolvimento do Intel XDK

38

5. Monitoramento de Performance: Somente disponível para Android até o

momento, permite o monitoramento de performance do aplicativo em tempo

real via USB;

6. Build/Packaging: Utilizado para criar o executável do aplicativo para ser

incluído nas lojas de aplicativos.

A estrutura de arquivos de um projeto criado ou importado pelo Intel XDK é

variável, já que ele oferece várias opções de frameworks, além da opção de criar um

projeto XDK ou Apache Cordova, cujo suas arquiteturas são muito similares. Um

desenvolvedor que tenha alguma experiência em desenvolvimento com Apache

Cordova terá pouquíssima fricção ao migrar para o Intel XDK, embora perca um

pouco da liberdade que o Cordova oferece, as ferramentas agregadas que o XDK

oferece podem ser atrativas dependendo dos requisitos do projeto.

39

Por ser uma ferramenta bastante completa, robusta e ter uma grande

empresa com a Intel por trás, o Intel XDK já é opção primária de algumas empresas,

startups e desenvolvedores autônomos, mas por ser uma ferramenta relativamente

nova a quantidade de aplicativos populares criados com o XDK é bem pequena,

porém existem. A maior parte dos projetos conhecidos desenvolvidos com XDK são

jogos, o que contradiz o fato de não ser possível desenvolver games com

ferramentas hibridas por causa da performance. Alguns dos aplicativos mais

populares são:

• Star Nomad Elite (Game de RPG/RTS)

• Nika Digital (Game de estratégia)

• Hostel HookApp (App para busca de albergue para estudantes)

Simulador integrado do XDK rodando um aplicativo de exemplo que utiliza a biblioteca Javascript d3js

40

• ZonzoFox (App de turismo italiano, que oferece informações de locais

turisticos na Itália)

• DeadShotZ (Game de tiro de zumbis)

Porém o Intel XDK tem algumas desvantagens que podem pesar na hora de

escolher a ferramenta certa para se iniciar um projeto, por exemplo, por ter tantas

ferramentas integradas em um só local, o XDK pode apresentar lentidão em várias

tarefas (pesadas, como rodar o aplicativo no simulador, ou até leves, como arrastar

um componente de um lado para outro no editor visual), e o fato de precisar de um

cadastro para utilizá-lo é algo que pode desestimular desenvolvedores mais

apegados ao open-source. Como dito anteriormente, por ser uma ferramenta

relativamente nova, pode haver dificuldades ao procurar recursos de informação

sobre problemas comuns, já que a comunidade em torno do XDK ainda é

relativamente pequena, porém a área de documentação e treinamento do Intel XDK

e suas ferramentas são excepcionais.

Todas as ferramentas integradas ao Intel XDK oferecem um suporte 360º ao

desenvolvedor/time no ciclo de desenvolvimento de um projeto de aplicativo mobile.

Permite uma rápida prototipação, que possibilita consolidar uma ideia em produto,

em pouquíssimo tempo com baixíssimo custo. É uma ótima opção para startups ou

pequenos desenvolvedores que desejam validar uma ideia com o menor custo

possível.

3.4 SENCHA TOUCH

Sencha Touch é um produto da Sencha, uma empresa conhecida pela

criação do ExtJS (popular framework HTML5). Foi criado com base na combinação

dos já consolidados frameworks HTML5 ExtJS, JQTouch e Raphael. Por ser um

framework concebido com o principal proposito de facilitar o desenvolvimento de

sites mobile, hoje ele suporta a grande maioria de navegadores mobile.

O Touch (como é chamado em alguns círculos) é um framework HTML5

baseado em MVC para criação de aplicativos web mobile, e utiliza de técnicas de

41

aceleração de hardware para prover componentes de interface de usuário de alta

performance em dispositivos móveis. Possui mais de 50 componentes reutilizáveis

disponíveis por padrão, cada um com seu visual e comportamento nativo para cada

plataforma alvo. O Sencha Touch suporta as plataformas iOS, Android, Blackberry e

Windows Phone.

Como já foi dito, o Sencha Touch é somente um framework HTML5 para

criação de interfaces mobile para web, logo, para ser utilizado para criação de um

aplicativo híbrido o Sencha Touch necessita de uma “casca” para abstrair a

comunicação com o dispositivo e dar acesso a suas habilidades nativas. A “casca”

utilizada pelo Touch é o, já abordado aqui, Apache Cordova. Por meio da ferramenta

de CLI do Touch é possível transformar a aplicação mobile web em um aplicativo

hibrido que pode ser incluído nas lojas de aplicativos e instalado em qualquer

dispositivo das plataformas suportadas.

O Touch é um dos frameworks específicos para mobile mais complexos, e

embora a curva de aprendizado possa ser mais íngreme quando comparamos com

as outras opções, ele permite que seja possível criar interfaces de qualquer

complexidade com relativa facilidade e além disso, a sua documentação é uma das

melhores e mais completas quando comparamos com as opções aqui citadas.

Complementando, a comunidade em torno do Sencha Touch é enorme, o que

equivale à uma vasta base de recursos de informação online, assim a tarefa de

iniciar os primeiros passos com o framework se torna bem menos dolorosa.

O Sencha Touch é totalmente integrado com o Apache Cordova, e oferece

abstrações das APIs do dispositivo nativo como câmera, geolozalização, contatos,

acelerômetro e giroscópio. Essas APIs são providas de forma consistente com todo

Mesma interface utilizando os vários temas disponíveis. (Fonte: http://moduscreate.com/5-best-mobile-web-app-frameworks-sencha-touch/)

42

seus sistema de namespace e classes, tornando todo o ecossistema do framework

homogêneo e bastante elegante.

Para continuar competitiva no mercado a Sencha precisou começar a

oferecer ferramentas facilitadoras do ciclo de desenvolvimento, então criou o Sencha

Architect, uma ferramenta visual que permite criar interfaces de usuário com o

Sencha Touch utilizando interações de “clique e arraste”. Outra forma de iniciar o

desenvolvimento de um aplicativo mobile com o Touch é por meio de sua ferramenta

de interface de linha de comando (CLI), chamada de Sencha CMD, quem tem como

objetivo prover o suporte com o projeto base, processo de desenvolvimento,

gerenciamento de temas, build, simulação e empacotamento do aplicativo (utilizando

o Apache Cordova ou o serviço Sencha Packager, também um serviço de

compilação em nuvem).

O Sencha Architect, embora seja gratuito para testar por 30 dias, a sua

licença anual possui um preço relativamente “salgado” para escopos onde não há

muito recurso financeiro para investir muito em uma ferramenta facilitadora, ainda

mais quando há uma alternativa gratuita, que é o Sencha CMD + qualquer editor

web que o desenvolvedor tenha mais proficiência. O Sencha CMD durante ou

desenvolvimento (por meio de um watcher, que acelera bastante o ciclo de escrever

código e verificar seu impacto no browser) ou empacotamento do aplicativo,

escaneia o código fonte, descobre suas dependências, remove o código não

utilizado, concatena e minifica o código final (tanto Javascript quanto CSS, por meio

do SASS, um pre-compilador CSS), resultando em um aplicativo web mais otimizado

possível para ser rodado eficientemente em um dispositivo mobile.

Para iniciar um projeto com o Sencha Touch utilizando o Sencha CMD é

necessário suprir algumas dependências:

• Baixar e descomprimir em qualquer diretório o SDK do Sencha Touch;

• O JRE (Java Runtime Environment) precisa estar instalado (O Sencha CMD é

escrito em Java);

• Ruby (para compilar o código SASS em CSS);

• Instalar o Sencha CMD;

43

Com todas as dependências supridas criar um projeto é tão simples quanto

executar um comando no console, especificamente “sencha –sdk

/caminho/para/sencha-touch-sdk generate app $NOME_DO_APP $DIRETORIO”, e

pronto, o projeto base está criado e pronto para iniciar o desenvolvimento.

A estrutura de arquivos de um projeto do Sencha Touch é simples de

entender para desenvolvedores que já estão acostumados com o ambiente front-end

da web. A arquitetura é a seguinte:

• app/: Diretório que contém os arquivos de modelos, interfaces, controladoras

e armazéns de dados da aplicação;

• build/: Diretório que contém os arquivos gerados pelo processo de build do

Sencha CMD;

• packages/: Diretório que contém os arquivos binários de cada plataforma

mobile, gerado pelo processo de build do Apache Cordova;

• resources/: Diretório que contém os estilos e imagens utilizadas do aplicativo;

• app.js: Arquivo de entrada principal do aplicativo;

• app.json: Arquivo de configuração do aplicativo;

Projeto base do Sencha Touch

44

• index.html: Arquivo HTML principal do aplicativo;

• packager.json: Arquivo de configuração utilizado pelo Sencha CMD para

gerar os binários nativos de cada plataforma com o Apache Cordova;

Utilizando o comando “sencha app build –run native” o Sencha CMD compila

a aplicação, gera os pacotes nativos de acordo com as configurações e abre o

aplicativo em algum dispositivo conectado em modo de desenvolvimento ou em

algum simulador local disponível.

Segundo a página de clientes da Sencha, eles possuem um grande número

de clientes corporativos, segundo eles mais de 10 mil, incluindo 60% da lista Fortune

100, que lista as 100 melhores empresas para se trabalhar, compilada pela revista

Fortune. Em meio a tantos clientes, não é difícil listar cases de sucesso do Sencha

Touch, mas uma pequena compilação de aplicativos inclui:

• United Heritage Insurance (Aplicativo de uma grande empresa de seguros)

• Open Banking (Aplicativo bancário)

• Smile Brands (Aplicativo para tablets, voltado para a área odontológica)

Mesmo aplicativo sendo simulado no iOS e Android.

45

• Ford Showroon (Aplicativo da Ford para tablets)

• Getorapher (Aplicativo de fotografia)

O Sencha Touch possui algumas desvantagens que podem não ser atraentes

para alguns desenvolvedores, por exemplo: embora seja gratuito, todo o

ecossistema do Sencha, incluindo o suporte, é pago e não possuem um valor

considerado negligenciável. O framework é grande e complexo e pode levar algum

tempo para aprender, além de ter uma performance limitada em plataformas que

não suportam Webkit.

O Sencha Touch é robusto, maduro e amplamente consolidado, o tornando

uma ótima opção para desenvolver aplicativos mobile híbridos. A melhor opção para

uma startup seria seguir o caminho gratuito que o Sencha Touch oferece, assim o

custo é bastante reduzido e os resultados são bem impressionantes. Embora possa

levar algum tempo para dominar o framework, depois que se pega o jeito, se torna

simples, criar um aplicativo relativamente complexo em pouco tempo.

3.5 NATIVESCRIPT

NativeScript é a ferramenta mais nova das opções aqui citadas, sua primeira

versão foi lançada em maio de 2015 e causou bastante alarde na comunidade de

desenvolvedores web por causa da maneira que aborda o desenvolvimento mobile

multi-plataforma. Diferentemente das outras opções de ferramentas abordadas até

agora, que resultavam em interfaces de usuário hibridas por meio de WebViews, o

NativeScript permite a criação de aplicativos mobile multi-plataforma com interfaces

de usuário realmente nativas e 100% de compartilhamento de código-fonte entre

todas as plataformas.

Uma ferramenta que faz algo similar, porém não será abordada neste trabalho

por não utilizar tecnologias web no seu processo de desenvolvimento é o popular

Xamarin, que utiliza o framework .NET da Microsoft e a linguagem C# como base de

seus projetos. Como um evangelista da Telerik (criadora e mantenedora do

NativeScript) explicou, “para a concepção do NativeScript focou-se fortemente no

46

conjunto de habilidades de um desenvolvedor web. O objetivo é que qualquer um

que esteja confortável hoje escrevendo HTML/CSS/Javascript se sinta

instantaneamente à vontade criando aplicativos mobile nativos usando NativeScript”

(ANGLIN, TODD, 2015).

Embora o NativeScript também ofereça “wrappers” ou abstrações de APIs

nativas do dispositivos, diferentemente das outras opções, ele não necessita de

atualização para tirar vantagem de novas capacidades caso uma nova API nativa

seja lançada ou uma API já existente seja modificada. Isso é possível porque o

NativeScript é o único que utiliza reflexão em tempo de compilação para tornar

qualquer API nativa ou biblioteca de terceiros disponível para o proxy Javascript, ou

seja, via Javascript é possível executar comandos com a exata interface da API

nativa e efetivamente chamar aquela funcionalidade equivalente em tempo de

execução. Mas as abstrações oferecidas pelo NativeScript são o meio recomendado

de acessar estas APIs nativas, pois expõem uma interface única, simples e multi-

plataforma. O NativeScript suporta as plataformas Android, iOS e Windows Phone.

47

Para padronizar a criação de UIs (interfaces de usuário) entre todas as

plataformas que o NativeScript suporta, é utilizada uma estrutura XML para definir os

layouts e seus componentes. Essas estruturas XML são separadas em páginas,

cada página representa uma tela do aplicativo, e são estilizadas utilizando CSS

(nem todas as regras são suportadas, somente um subconjunto delas). Para cada

página XML é necessário um arquivo escrito em Javascript ou TypeScript (um

verificador estático de tipos que compila para Javascript) com o mesmo nome da

página, que contém os comportamentos ligados à UI.

O NativeScript possui duas maneiras de iniciar um projeto de aplicativo

mobile, uma é utilizando sua plataforma integrada de desenvolvimento chamada de

AppBuilder, porém esta plataforma não é gratuita. A outra forma é utilizando sua

ferramenta de interface de linhas de comando (CLI), que é gratuita e open-source, e

suporta Windows, Linux e OS X. Utilizando o AppBuilder se torna possível compilar

aplicativos para qualquer plataforma suportada sem nenhuma dependência, por

Representação do mesmo código sendo compartilhado em várias plataformas com o NativeScript. (Fonte: http://www.telerik.com/nativescript)

48

meio do serviço de compilação em nuvem da Telerik. Utilizar o NativeScript CLI é a

opção de menor custo, porem possui as mesmas dependências que desenvolver

aplicativos nativos, já que serão compiladas no computador do desenvolvedor, por

exemplo: para desenvolver aplicativos para Android são necessários todas as

dependências que o ambiente de build do Android possui, incluindo o JDK (Java

Development Kit), Apache Ant (Ferramenta de build utilizada pelo Android) e o

Android SDK. Além disso é necessário a instalação do NodeJS, pois o CLI é escrito

em Javascript.

Após todas as dependências serem supridas e o NativeScript CLI estiver

instalado, iniciar um projeto é bem simples: o comando “tns create

$NOME_DO_APP” cria um projeto base no diretório $NOME_DO_APP. O comando

“tns platform add $ID_PLATAFORMA”, sendo $ID_PLATAFORMA uma das três

plataformas disponíveis (“ios”, “android” ou “windows”). Finalmente o comando “tns

run $ID_PLATAFORMA” instala e executa o aplicativo em algum dispositivo

conectado em modo de desenvolvimento conectado ao computador ou adicionando

o parâmetro “--emulator” o aplicativo é executado no simulador disponível da

plataforma escolhida.

A arquitetura de arquivos de um projeto NativeScript é bem simples e direto

ao ponto:

Projeto base do NativeScript

49

• app/: Diretório que é o espaço de desenvolvimento do aplicativo;

o app.css: Arquivo principal de estilos do aplicativo;

o app.js: Arquivo Javascript que serve como ponto de entrada principal

do aplicativo;

o bootstrap.js: Arquivo de inicialização de configurações de ambiente do

aplicativo;

o main-page.js: Controladora da página inicial do aplicativo;

o main-page.xml: Página principal do aplicativo;

o App_Resources/: Diretório que contém arquivos de recursos para

cada plataforma, como ícones, imagens, splash-screens e etc..

o tns_modules/: Diretório que contém todos os módulos Javascript de

abstração das APIs nativas que o framework oferece;

• platforms/: Diretorio que contém os projetos nativos de cada plataforma

adicionada ao projeto;

Como o NativeScript é uma ferramenta muito nova, até o desenvolvimento

deste trabalho não há nenhum grande case de aplicativo mobile desenvolvido com

Mesmo aplicativo de exemplo do NativeScript rodando nos simuladores de iOS e android.

50

ele, porém é só uma questão de tempo, já que a abordagem criada pela Telerik

atraiu os olhos de muitos desenvolvedores e empresas, que já adotaram o

NativeScript como ferramenta de desenvolvimento para aplicativos mobile multi-

plataforma, tornando o futuro do NativeScript bem promissor.

Como todas as opções abordadas aqui, o NativeScript também possui suas

fraquezas, por exemplo, por utilizar componentes visuais nativos (e não interfaces

de usuário web como seus concorrentes) ele necessita de compilação sempre que

uma alteração é feita no código e o desenvolvedor queira ver o impacto dela no

aplicativo rodando do dispositivo ou simulador. Por ser muito nova, falta recursos de

informação na web sobre possíveis problemas que os desenvolvedores possam

encontrar durante o ciclo de desenvolvimento. Sua abordagem de criar uma

estrutura XML para criação de UIs adiciona uma camada de complexidade que exige

que o desenvolvedor aprenda como ela funciona, e esse conhecimento não pode ser

reaproveitado fora do escopo do NativeScript.

O fato dos componentes da interface de usuário de aplicativos desenvolvidos

com NativeScript serem totalmente nativos também o torna a opção mais

performática quando comparada com as outras ferramentas abordadas aqui, logo se

a performance é uma preocupação na hora de fazer a escolha entre elas, a resposta

se torna meio óbvia. Além disso o NativeScript é open-source, tem uma

documentação simples e sólida, provê grande compartilhamento de código entre as

plataformas alvo, o que o torna uma ótima opção para desenvolver aplicativos

nativos em múltiplas plataformas em pouco tempo e com baixo custo.

3.6 REACT NATIVE

Embora sua versão publica tenha sido lançada dois meses antes do

NativeScript, os engenheiros do Facebook afirmam estarem usando o React Native

em seus aplicativos mobile há mais de dois anos. Em março de 2015 o Facebook

tornou o React Native open-source e a partir daí as coisas foram acontecendo

extremamente rápido. Vários artigos dos integrantes mais populares da comunidade

51

de desenvolvedores web foram publicados, e rapidamente uma grande massa de

curiosos interessados a trabalhar com a “próxima grande ferramenta” para

desenvolvimento de aplicativos mobile nativos se aglomeraram, uma nova

comunidade se formou, e ainda está em rápido e continuo crescimento.

Parte da popularidade repentina do React Native se deve ao fato de ter sido

desenvolvido pelo Facebook, que contribui consistentemente com a comunidade de

desenvolvedores web e mobile. Outra parte desse rápido ganho de adeptos é

oriundo do fato dessa ferramenta utilizar um dos mais populares frameworks de

interfaces de usuário web hoje, o React, também criado pelo Facebook. O React é

um framework Javascript para criação de aplicações web com interfaces de usuário

dinâmicas. O React antes de ter sido tornado open-source, também já era utilizado

nos produtos do facebook há bastante tempo, e hoje é utilizado em larga escala em

projetos de pequeno, médio e grande porte fora do Facebook, por várias empresas,

startups e desenvolvedores autônomos.

O que diferencia React de outros frameworks de UI para aplicações web é

que ele introduz um conjunto de abordagens muito diferentes dos frameworks

Javascript concorrentes, como AngularJS ou EmberJS. Por exemplo, a sua API de

construção de interfaces é declarativa ao invés de imperativa, significa que ao invés

de chamar métodos para renderizar dados de algum modelo em um componente,

você simplesmente declara por meio de “tags” JSX (baseado em XML, mas é

transformado em Javascript puro).

52

O React Native foge do padrão das outras ferramentas abordadas aqui, no

sentido de que o objetivo dele não é compartilhar o código-fonte entre todas as

plataformas alvo, e sim compartilhar o conhecimento assimilado nele em todas as

plataformas alvo. No artigo de anuncio do lançamento do React Native, o engenheiro

do facebook Tom Occhino explica o porquê da escolha desta abordagem:

“... É importante salientar que nós não estamos perseguindo o

objetivo de tornar o React Native mais um framework ‘escreva uma

vez, rode em qualquer lugar’. Plataformas diferentes possuem

visuais, experiências e capacidades diferentes, logo, devemos

desenvolver aplicativos diferentes para cada plataforma, mas os

mesmos engenheiros devem ser capazes de desenvolver aplicativos

em qualquer plataforma que escolherem sem a necessidade de

aprender um novo conjunto de tecnologias fundamentalmente

diferentes para cada uma delas. Nós chamamos esta abordagem de

‘aprenda uma vez, escreva em qualquer lugar’...”

(OCCHINO, TOM, 2015)

Exemplo de código declarativo do React Native, repare como o XML se mistura com o Javascript. (Fonte: https://facebook.github.io/react-native/)

53

React Native possui um conjunto de características que realmente empolgam

qualquer desenvolvedor, seja ele oriundo do desenvolvimento web ou já experiente

no mundo mobile. Todos os componentes são totalmente nativos. Toda

comunicação do código Javascript do aplicativo com a plataforma nativa é feita de

forma assíncrona, ou seja, qualquer interpretação pesada como decodificação de

imagens ou escrita/leitura de arquivos são feitas em uma thread diferente, o que não

bloqueia a interface de usuário. Possui um sistema avançado de reconhecimento de

toques que possibilitam o reconhecimento de toques e gestos de maneira simples e

precisa. A estilização dos componente é totalmente baseada em CSS, escrita por

meio de simples objetos Javascript, facilita a criação de layouts com o modelo de

Flexbox do CSS. Oferece abstrações de APIs nativas como conexão HTTP ou

gelocalização por meio de interfaces Javascript descritas pelos padrões W3C. As

mensagens de erros são as mais descritivas já vista em qualquer framework web ou

mobile, o que ajuda bastante ao encontrar e eliminar um erro. Permite fácil criação

de componentes nativos que o React Native não trás por padrão por meio da

ferramenta de exportação oferecida pelo framework. Por ultimo e não menos

importante, não é necessário compilar o aplicativo sempre que uma mudança é feita

no código, é necessário somente que uma atualização seja feita por uma tecla de

atalho no simulador e pronto, a mudança já será exibida.

Até o desenvolvimento deste trabalho o React Native só suporta o iOS, mas

embora não tenha sido divulgada nenhuma data, os engenheiros por trás do React

Native garantem que em breve será adicionado o suporte ao Android e em seguida

Windows Phone. Para iniciar um projeto com o framework é necessário atender à

alguns requisitos:

• Sistema Operacional OS X;

• XCode (IDE do iOS nativo);

• NodeJS (para instalar e utilizar a ferramenta de CLI);

• Watchman (para reload continuo do aplicativo sem necessidade de

recompilação);

• react-native-cli (Ferramenta de interface de linha de comando para dar

suporte na criação e durante o desenvolvimento do projeto);

54

Depois de todas as dependências supridas para iniciar um novo projeto com o

projeto base do React Native é necessário executar o comando “react-native init

$NOME_DO_PROJETO” e será criado um diretório com o nome

$NOME_DO_PROJETO que contem o ambiente de desenvolvimento base do React

Native. Para rodar o projeto, é necessário abri-lo no XCode e compilar o aplicativo

por lá, do mesmo jeito que com um projeto iOS comum.

A estrutura de arquivos de um projeto do React Nativo é extremamente

flexível para o desenvolvedor separar os arquivos da forma que ele desejar, porem

há uma estrutura básica:

• iOS/: Diretório que contem as bibliotecas e recursos nativos do projeto de

iOS;

• $NOME_DO_PROJETO.xcodeproj/: Diretório que contém o projeto nativo de

iOS;

• $NOME_DO_PROJETOTests/: Diretório que contém os teste da aplicação;

Projeto base do React Native

55

• node_modules/: Diretório que contém as dependências Javascript, incluindo,

mas não se limitando ao React Native;

• index.ios.js: Arquivo de ponto de entrada principal do aplicativo;

• package.json: Arquivo que contém configurações de dependências do

projeto;

O React Native ainda tem um longo caminho pela frente, e é discutível se está

pronto para ser utilizado em produção. Existe uma longa lista de problemas que

podem desencorajar quem procura algo mais maduro e robusto para desenvolver

seus aplicativos, além do fato dele só suportar o iOS por enquanto, não

necessariamente diminui os custos de um projeto o bastante para escolhe-lo ao

invés de usar a tecnologia nativa diretamente. Porém o Facebook utiliza-o em vários

de seus produtos há muito tempo e garantem ter tido muito sucesso desenvolvendo

com React Native até agora. A lista de aplicativos do Facebook que utilizam o React

Native inclui o próprio aplicativo do Facebook para iOS, o aplicativo de Facebook

Groups para iOS e o aplicativo Facebook Ads para iOS.

Projeto base rodando no simulador iOS

56

Documentação incompleta, alguns bugs em tempo de execução, baixo

numero de recursos de informação online, sem suporte para outras plataformas e

alguns outros problemas o tornam um risco para quem presa por algo mais

consolidado, mas é uma ótima opção para quem gosta de estar sempre à frente com

as tecnologias mobile, já que apesar o longo caminho que precisa percorrer, o React

Native tem potencial para ser a próxima grande ferramenta para desenvolvimento de

aplicativos mobile nativos multi-plataforma. E no estado atual, já é possível criar um

aplicativo nativo iOS em pouco tempo. Se isso for o bastante para a decisão de

escolha da startup ou desenvolvedor autônomo à procura de opções de frameworks

para desenvolver seu próximo aplicativo, então React Native pode ser uma boa

opção.

57

4 CONCLUSÃO

Cada vez mais rápido os dispositivos mobile vem ganhando espaço no dia a

dia das pessoas. O que durante algum tempo foi pensado como “a segunda tela”,

hoje é a primeira, ultrapassando o computador pessoal e a televisão. Hoje, 50% da

população mundial possuem smartphones, e há estimativas quem até 2020 esse

numero subirá para 80%, o que torna muito claro que a, já altíssima demanda,

continuará crescendo rapidamente.

E junto com a demanda de dispositivos mobile, a demanda de aplicativos para

esses dispositivos também continuará em constante crescimento, e para

acompanhar este rápido crescimento é necessário uma abordagem otimizada que

tenha ambos baixo custo e rapidez no desenvolvimento do produto.

É sabido que muitas vezes grandes ideias, ideias que vão suprir a alta

demanda de usuário, ideias que vão solucionar problemas do cotidiano das pessoas,

ideias que podem mudar o modo como vivemos, essas ideias podem surgir de

pessoas que não possuem muitos recursos para colocá-las em prática. E hoje é

comum essas pessoas receberem esses valiosos recursos de investidores que

acreditam em sua ideia. E é assim nascem as chamadas startups, o tempo todo, em

qualquer lugar do mundo. Porém os recursos disponibilizados para validar aquela

ideia sempre vão ser muito limitados no início, e necessitam que sejam gastos com

bastante eficiência ou então esta grande ideia pode nunca se concretizar.

Foi sugerido aqui que o modo mais eficiente de validar uma ideia de um

aplicativo mobile é utilizando a abordagem multi-plataforma que reaproveita

conhecimentos, código-fonte e ferramentas da web para ser aplicada. Deste modo, é

possível economizar valiosos recursos durante o desenvolvimento do aplicativo e

ainda chegar à uma versão totalmente funcional que valide esta ideia em

pouquíssimo tempo, utilizando os conceitos de Lean Startup.

Foram apresentadas várias ferramentas que implementam esta abordagem,

todas elas com suas diferentes formas de abordar o problema. Foram apontadas

suas vantagens, desvantagens e seus inúmeros casos de sucesso. As informações

58

compiladas neste trabalho deixam claro que as ferramentas web já invadiram o

mundo de desenvolvimento de aplicativos mobile há muito tempo e isso está

fazendo muito bem, tanto para os desenvolvedores que podem reaproveitar suas

habilidades desenvolvendo experiências verdadeiramente mobile, quanto para os

usuários, que são bombardeados com várias opções de aplicativos novos todos os

dias e muitas das vezes nem percebem a diferença de um aplicativo criado com a

abordagem multi-plataforma/hibrida de aplicativos criados com seus SDKs nativos.

Esta abordagem está ganhando cada vez mais adeptos devido as suas

vantagens e todo esse interesse faz com que novas ferramentas sejam criadas o

tempo todo. Logo haverá tantas opções para desenvolver aplicativos mobile com

tecnologias web que será necessário um minucioso estudo de cada uma delas para

saber qual ferramenta se adequa melhor ao aplicativo que será criado.

Este trabalho listou e apresentou informações técnicas sobre as mais

consolidadas ferramentas de desenvolvimento mobile multi-plataforma atualmente,

que utilizam ferramentas web. Ferramentas que são mantidas por empresas grandes

e maduras, o que às tornam as melhores opções a longo prazo.

O presente e o futuro é mobile, e dentro do mundo de desenvolvimento

mobile, o futuro é a eficiência e sustentabilidade. O futuro é a abordagem multi-

plataforma utilizando tecnologias web.

59

REFERÊNCIAS

• PAKA, A. The Rise of Micro Startup Acquisitions. TechCrunch, 2015:

http://techcrunch.com/2015/04/15/rise-of-micro-startup-acquisitions/

• GITAHY, Y. O que significa fazer pivot de uma startup. Exame, 2011:

http://exame.abril.com.br/pme/noticias/o-que-significa-fazer-o-pivot-de-uma-

startup

• GRIFFITH, E. Why startups fail, according to their founders. Fortune, 2014:

http://fortune.com/2014/09/25/why-startups-fail-according-to-their-founders/

• THE LEAN STARTUP. The Lean Startup Methodology. The lean startup,

2011: http://theleanstartup.com/principles

• ABROZIMOVA, K. Native VS Cross-Platform. Yalantis, 2013:

https://yalantis.com/blog/native-vs-cross-platform-app-development-shouldnt-

work-cross-platform/

• GOLDENBERG, A. Pros and Cons of Developing Native vs. Cross-Platform

Web-Based Mobile Aplication. DBBest, 2013:

http://www.dbbest.com/blog/pros-and-cons-of-developing-native-vs-cross-

platform-web-based-mobile-application/

• HOCKING, J. Native vs. Hibrid: developing cross-platform mobile apps. The App Business, 2014: http://www.theappbusiness.com/native-vs-hybrid-

developing-cross-platform-mobile-apps/

• SITANSHU, J. Native vs Cross Platform for Application Development.

Sitanshu J, 2015: http://blog.zymr.com/native-vs-cross-platform-for-

application-development

• HEIKOTTER, H. HANSCHKE, S. MAJCHRZAK, T. Comparing Cross-Platform

Development Approaches for Mobile Applications. Muenster University,

2012: https://www.wi.uni-

muenster.de/sites/default/files/public/department/pi/publications/heitkoetter/Co

mparing-Cross-Platform-Development-Approaches-for-Mobile-Applications.pdf

• MADAUDO, R. Native versus Cross-Platform frameworks for mobile

application evelopment. Universitá degli Studi de Bergamo, 2013:

http://2013.eclipse-it.org/proceedings/6_Madaudo-Scandurra.pdf

60

• MICHAELS. ROSS. COLE. Native mobile apps: The wrong choice for

business?. MRC Productivity, 2013: http://www.mrc-

productivity.com/research/whitepapers/NativeAppsWrongChoice.pdf

• KOERBEL, A. Qual a equipe necessária e quanto custa um app?. Esauce,

2014: http://www.esauce.com.br/qual-equipe-necessaria-e-quanto-custa-criar-

um-app/

• APACHE CORDOVA. Apache Cordova docs. Apache Cordova:

http://cordova.apache.org/docs/en/5.0.0/guide_cli_index.md.html

• ANDREW. Who uses Phonegap/Cordova? Trice Designs, 2012:

http://www.tricedesigns.com/2012/03/27/who-uses-phonegapapache-cordova/

• PHONEGAP. Apps built with Phonegap. Adobe:

http://phonegap.com/app/feature/

• ADAM, J. Why Titanium App Development is a smart move for startups who

need apps. Tech.co, 2014: http://tech.co/titanum-app-development-get-top-

notch-cross-platform-applications-2014-03

• TITANIUM DOCS. Appcelerator CLI docs. Appcelerator: https://web.appcelerator.com/product/cli

• APPCELERATOR. Apps Showcase. Appcelerator: http://www.appcelerator.com/customers/app-showcase/

• INTEL XDK. Intel XDK details. Intel, 2014: https://software.intel.com/pt-

br/intel-xdk/details

• INTEL. Developer success stories. Intel: https://software.intel.com/pt-

br/success-stories

• DAWNSON, R. Getting Started with Intel XDK. Tutsplus, 2014:

http://code.tutsplus.com/articles/getting-started-with-intel-xdk--cms-22205

• KOKO, A. A new cross-platform option, introducing Intel XDK. Sitepoint, 2014: http://www.sitepoint.com/introduction-intel-xdk/

• SENCHA TOUCH. Sencha Touch Overview. Sencha:

http://www.sencha.com/products/touch/#overview

• GRISOGONO, G. 5 Best Mobile Web App Frameworks: Sencha Touch.

Modus Create, 2014: http://moduscreate.com/5-best-mobile-web-app-

frameworks-sencha-touch/

61

• RUDOLPHI, T. Using Sencha Touch as a Strategic Platform – An Evaluation.

Zühlke Blog, 2013: http://blog.zuehlke.com/en/using-sencha-touch-as-a-

strategic-platform-an-evaluation/

• STOYCHEV, V. NativeScript 1.0.0 is now available. NativeScript Blog, 2015:

https://www.nativescript.org/blog/nativescript-1.0.0-is-now-available

• VANTOLL, TJ. How NativeScript Works. Telerik Developer Blog, 2015:

http://developer.telerik.com/featured/nativescript-works/

• WITALEC, S. Getting Started with NativeScript. Telerik Developer Blog,

2015: http://developer.telerik.com/featured/getting-started-nativescript/

• TODD. The difference beetween Xamarin e Telerik`s NativeScript.

StackOverflow, 2015:

http://stackoverflow.com/questions/28829316/difference-between-xamarin-

and-teleriks-native-script

• NATIVESCRIPT. NativeScript Docs. Telerik, 2015:

https://docs.nativescript.org/

• OCCHINO, T. React Native: Bringing modern web techniques to mobile.

Facebook Code, 2015:

https://code.facebook.com/posts/1014532261909640/react-native-bringing-

modern-web-techniques-to-mobile/

• LONG, J. First impressions using React Native. James Long, 2015:

http://jlongster.com/First-Impressions-using-React-Native

• EBERHARDT, C. React Native Tutorial: Building Apps With Javascript. Ray Wenderlich Blog, 2015: http://www.raywenderlich.com/99473/introducing-

react-native-building-apps-javascript

• MCCORKELL, R. React Native – The Killer Feature that Nobody Talks About.

Red Badger, 2015: http://red-badger.com/blog/2015/03/04/react-native-the-

killer-feature-that-nobody-talks-about/