Acessando banco de dados remoto com Android (inclui 6+)

Atualizado em 12/08/17!

Este tutorial estava há tempos para ser escrito e na verdade é muito mais simples do que a maioria dos desenvolvedores pensam. Programadores Java em geral estão acostumados a utilizar o framework JDBC para realizar conexões aos seus bancos de dados favoritos como MySQL e SQL Server, diretamente.

Entretanto, o Android não oferece suporte nativo à conexões remotas em SGBDs (por diversos motivos) e este tipo de conexão deve ser realizado através de uma API.

Esse é um post iniciante. Caso queira um post mais avançado de como consumir APIs externas em Android usando a biblioteca Retrofit, leia este aqui.

Veremos neste post:

  1. A API
  2. O app
  3. Conectando as duas pontas

Vamos lá!

#1 – A API

Como o intuito deste post não é ensinar como criar uma API, que neste exemplo nada mais é do que um webservice, usaremos uma API pronta. Caso tenha interesse em aprender a criar webservices, em meu livro de Android tenho exemplos de como fazê-lo em Java, PHP, .NET e Node.js (aqui no blog tem um tutorial de API em Node.js também).

O site http://freegeoip.net oferece uma API aberta e gratuita para descobrir a geolocalização de um dispositivo com base em seu endereço IP. Ou seja, você informa o IP e a API deles retorna um JSON, CSV ou XML com os dados de localização, quando encontrados.

Você pode testar a API fazendo chamadas a http://freegeoip.net/formato/seu_ip onde ‘formato’ deve ser substituído por json, csv ou xml e ‘seu_ip’ deve ser substituído pelo IP que deseja consultar, ou nada, para consultar a localização do seu IP atual. Neste exemplo usaremos a URL http://freegeoip.net/json/8.8.8.8 que é o IP do servidor de DNS do Google, na Califórnia.

Mas o que isso tem a ver com acesso a bancos de dados remotos, você deve estar se perguntando. O FreeGeoIP nada mais é do que uma base de dados remota onde seus desenvolvedores criaram um webservice REST para consulta de dados a a partir de qualquer plataforma, ou seja, eles permitem através da API que qualquer um possa acessar seu banco de dados, e é exatamente isso que um desenvolvedor Android necessita fazer para integrar de maneira prática e eficiente um banco de dados remoto ao seu app.

Atenção: caso venha a utilizar uma API local (que você desenvolveu) para testes, aponte a URL da api para 10.0.2.2 no seu app, pois se você usar localhost ele vai procurar a API no Android, ao invés do sistema host.

#2 – O App

O primeiro passo é abrir nossa ferramenta, o Android Studio (se você não sabe do que estou falando, dê uma olhada neste post). Outras ferramentas possíveis incluem o ADT Bundle e o NetBeans com suporte à Android. Mande criar um novo projeto do tipo Android Application e lhe dê o nome de LocationApp. A versão de Android fica ao seu gosto, enquanto eu utilizei a versão 4.0 em meus testes, oferecendo compatibilidade com toda a família IceCream Sandwich e posteriores, incluindo o Android Kit Kat (4.4).

Crie uma Blank Activity chamada LocationActivity que herdará da Activity base e que criará ao mesmo tempo o arquivo de layout activity_location.xml na pasta de layouts. Crie seu layout de maneira bem simples, usando widgets padrões do Android SDK como TextViews, EditText e Button, como mostra o trecho de código abaixo (devido a problemas em meu plugin, está tudo em minúsculo):

O layout pretendido é esse:

tela

Com o layout criado, é hora de começar a programar nossa Activity, fazendo o binding de cada widget com variáveis de mesmo tipo, como mostra o trecho de código abaixo que fica no evento onCreate da Activity.

#3 – Conectando as duas pontas

O próximo passo é criar uma classe para consumir a API do FreeGeoIP.net, que chamamos de ClienteGeoIP, além de uma classe para representar o objeto Localizacao do nosso app, que possui as referidas informações que queremos exibir na tela. A classe ClienteGeoIP conecta-se na API usando um cliente HTTP e convertendo o retorno para o formato JSON, usando as bibliotecas nativas do Android.

Primeiro a classe Localizacao.java:

Agora a classe ClienteGeoIP e seu único método que consome a API:

Com o método de retornar localização criado, devemos definir o método do evento OnClick do botão de carregar a  localização da nossa LocationActivity (note que existe uma chamada a um evento carregarLocalizacao no XML do Button). Esse método deve ser declarado na LocationActivity, logo abaixo do evento onCreate:

Não esqueçamos que uma vez que vamos conectar à Internet precisamos informar essa permissão no AndroidManifest.xml, conforme mostrado abaixo.

Testando nosso app em um AVD conseguimos ver que ele funciona perfeitamente e com isso encerramos mais este breve tutorial.

Atenção para versão Android 6+: a partir da versão 6 do Android o modelo de permissões mudou drasticamente. Da Marshmallow em diante o usuário pode conceder permissões para o app consumir recursos específicos, como a Internet, somente no momento em que o app vai usar esse recurso pela primeira vez. Além disso, ele pode mais tarde revogar esta permissão nas configurações do aplicativo.

Com isso em mente, é importante para desenvolvedores que queiram evitar problemas em versões recentes do Android sempre verificarem, no momento em que vão precisar de Internet, se possuem tal permissão. Caso não possuam, devem pedir ao Android que peça ao usuário. O código abaixo ilustra isso.

Que tal juntar esse app com o recurso de mapa que o Android fornece? Dê uma olhada neste tutorial aqui sobre como criar apps com mapa.

Ou então, que tal juntar com o recurso de GPS do smartphone? Nesse caso, dê uma olhada neste tutorial aqui sobre como usar o GPS do celular.

Um abraço.

final

* OBS: curtiu o post? Então dá uma olhada no meu livro de Android clicando no banner abaixo pra aprender a criar outros tantos apps incríveis!

Criando apps para empresas com Android

Tudo sobre o arquivo build.settings do Corona SDK

Saiba tudo sobre Corona SDK com o único livro em Português sobre este incrível framework, com quase 500 páginas. Saiba mais!

Alguns desenvolvedores, especialmente aqueles novos com Corona ou com desenvolvimento de apps em geral, têm problemas com as configurações e parâmetros que são necessários para compilar com sucesso um app para testar e eventualmente, lançar no mercado. Em Corona, estas configurações são ditadas através do arquivo build.settings, mas inspecionar um build.settings complexo pode ser intimidador. Entretanto, se você entende tables Lua e mentalmente separar este arquivo em seções, você irá entender melhor este elemento crucial do projeto.

Overview

Essencialmente, o arquivo build.settings contém informações que determinam quais recursos devem ocorrer em tempo de compilação. Estes são divididos em 5 áreas primárias:

  • Orientation – controla as orientações de tela suportadas;
  • iOS Settings – características especiais do iOS
  • Android Settings – características para Android
  • Plugins – carrega vários plugins que um app pode precisar acessar
  • Excluded Files – Exclui certos arquivos das suas compilações de app.

Isto tudo começa com uma simples table Lua chamada settings:

 

Desta forma, esta table pode conter vários pares de chave-valor para cada uma das cinco seções, e cada uma destas tables pode ter vários pares chave-valor aninhados, muitos dos quais exploraremos neste tutorial.

Declaração Chave-Valor

Estas seções chave-valor podem ser definidas de uma de três maneiras, ou uma combinação de todas três, dependendo da sua preferência ou, e alguns casos, o nome da chave sendo definida.

1. Propriedades da Table

 

2. Array Associativo

 

Note que este método é exigido quando sua chave contém caracteres especiais como um traço. Por exemplo, se você precisa definir uma chave como hokey-pokey, você precisará especificar ela como settings[“hokey-pokey”] e não como settings.hokey-pokey que é considerado inválido em Lua. Isto será muito importante quando definirmos os plugins.

3. Estrutura de Tables Aninhadas

 

Observações Adicionais

Todos os três formatos são perfeitamente válidos, mas o formato padrão mostrado em nossos exemplos e documentação é o formato table aninhada.

Cada uma destas seções chave-valor é opcional. Se você está compilando somente para iOS, você não precisa incluir a table android. Da mesma forme, se estiver compilando para Android, você não precisa incluir a table iphone. Se você não usa quaisquer plugins, você pode omitir a table plugins. E, embora você não precise de uma table orientation, você deve fornecer uma em praticamente todo app para definir as orientações permitidas ao app.

A ordem destas seções não é importante, desde que inclua-as corretamente como pares de chave-valor.

A table Orientation

A seção orientation é a mais fácil das cinco – ela meramente define qual orientação é a padrão para o app, e quais outras orientações são permitidas se o usuário girar o telefone.

 

Existem duas chaves para esta table: default e supported. O valor default é uma string que determina a orientação na qual o app irá começar. Strings válidas incluem:

  • “portrait”
  • “portraitUpsideDown”
  • “landscapeLeft”
  • “landscapeRight”

O valor supported é uma table indexada (sem chaves) que pode conter quaisquer das quatro opções listadas acima, separada por vírgulas. Note que esta table deve incluir o mesmo valor que você definiu como default, em adição a quaisquer outras orientações que você deseja suportar. No exemplo acima, o app irá carregar em “landscapeRight”, mas também permite trocar para a orientação “landscapeLeft”, visando fornecer uma melhor experiência aos usuários.

A table iphone

A table iphone contém todas as configurações necessárias para compilar para dispositivos iOS. Note o seguinte:

Esta table deve ser digitada como iphone (tudo em minúscula) mesmo que o dispositivo seja normalmente chamado de “iPhone” – este é um problema comum para novos usuários, então certifique-se de digitar corretamente.

A table iphone cobre todos os dispositivos iOS incluindo iPhone, iPad e iPod Touch, então você só precisa desta seção para compilar para todos eles.

A sub-table plist

A table iphone sempre contém outra table aninhada chamada plist. Esta é uma table cujos valores são copiados dentro do dicionários plist do projeto XCode. Logo, se você precisa incluir itens nessa lista, adicione-os aqui.

As chaves dentro da table plist são as mesmas do XCode, mas os valores são orientados ao Lua. Por exemplo, em XCode existe um par chave-valor chamado UIApplicationExitsOnSuspend que aceita valores booleanos do XCode como YES e NO. Entretanto, Lua usa true ou false, logo, para definir esta preferência para um app Corona, sua table iphone deve incluir isto:

 

A maioria das tables iphone incluirão mais do que isto, e alguns desenvolvedores comumente copiam esta table de build.settings existentes sem entender seu conteúdo. Considere o seguinte exemplo:

 

Esta table pode parecer complexa, mas vamos dar uma olhada e explorar os vários elementos:

  • CFBundleIconFile – esta String declara o nome base do seu ícone do app. Este valor pode ser geralmente “Icon.png” (note que é case-sensitive com I maiúsculo).
  • CFBundleIconFiles – esta é uma table indexada (sem chaves) que diz ao iOS quais arquivos de ícone devem ser usados nos vários dispositivos. Para uma experiência de usuário melhor, você deve incluir todas estas opções, e deve criar todos os arquivos de ícones associados nos tamanhos apropriados.
  • UIApplicationExitsOnSuspend – este valor boolean instrui o IOS que o app não deve terminar quando é suspenso. Este valor deve ser false na maioria das vezes.
  • FacebookAppID – para implementar a funcionalidade do Facebook, você precisará incluir este par chave-valor. Seu valor único pode ser obtido no painel de desenvolvedor do Facebook.
  • CFBundleURLTypes – este é um array indexado de chaves-valores que descrevem os esquemas de URL suportados pelo app (consulte a documentação da Apple para maiores detalhes). Por causa desta estrutura, esta table começa com uma sub-table sem chaves adicional. No exemplo acima, relacionamos um esquema de URL para o Facebok.

Outros Elementos

Este tutorial não pode discutir cada elementos que possa existir na table iphone, então consulte a documentação oficial do Corona e da Apple para maiores informações.

A table android

O Android é razoavelmente simples na maioria dos casos – tipicamente é somente uma lista de permissões e características. Note que você deve incluir uma table usesPermission dentro da table Android que é uma lista de permissões que você quer conceder ao app. No exemplo seguinte, permitimos ao app Corona acesso à Internet.

8

Uma versão um pouco mais complexa pode incluir uma table usesFeatures que diz ao Android Marketplace quais capacidades de hardware o app precisa ou não precisa.

9

Outros Elementos

Este tutorial não pode discutir cada elemento que pode existir na table android, para isso consulte a documentação oficial do Corona e a documentação do Google, na parte de permissions e features.

A table plugins

A seção final a ser discutida é a table que suporta os plugins do Corona SDK. Um exemplo básico que habilita o plugin AdMob se pareceria com isso:

10

Note que o nome da chave para est plugin (CoronaProvider.ads.admob) inclui pontuação. Devido a isto, você deve usar colchetes e aspas ao definir esta chave. Mesmo que o nome do plugin não inclua pontuação, este método fornece um nível de consistência:

11

Neste exemplo mostramos um aspecto importante de incluri plugins: a sub-table supportedPlatforms. Se você usar um plugin que é específico de uma plataforma, você pode usar a chave supportedPlatforms para instruir os servidores de build do Corona a somente incluírem o plugin na plataforma específica.

Porque Facebook é considerado “platform specific” no contexto de plugins? A funcionalidade do Facebook é, na verdade, disponível para iOS e Android, mas desde algum tempo que o Facebook para iOS foi removido do core do Corona e agora é implementado via plugin. Se você está usando uma versão mais recente do Corona e está compilando para iOS, você deve incluir a chave acima [“facebook”] na sua table plugins, juntamente com a sub-table supportedPlatforms.

Precauções Importantes

1. Copiando e Colando Blocos de Código

Comumente, desenvolvedores copiam e colam exemplo de código a documentação do Corona. Tudo bem, mas você deve estar atento a manter a organização de todas tables dentro do build.settings. Não copie simplesmente os exemplos mostrados acima e se copiar tome cuidado em não colar as sub-tables nas seções errradas, como colar um bloco plugin dentro de uma table iphone.

2. Indentação Apropriada

Realmente ajuda indentar seu código. A maioria dos editores de código modernos manipulam a indentação do código automaticamente, e é ainda mais importante indentar o código do build.settings porque ele será normalmente uma miríade de tables e sub-tables. Com a indentação apropriada, será mais fácil de manter seus elementos organizados e legíveis.

Conclusão

O build.settings pode ser bem complexo, mas no fundo, nada mais é do que tables Lua aninhadas com seus pares de chave-valor, e quanto mais confortável você estiver com esses aspectos, mais fácil será construir um build sem falhas para todas plataformas.

* OBS: curtiu o post? Então dá uma olhada no meu livro de Corona SDK clicando no banner abaixo pra aprender a criar outros tantos apps incríveis!

Livro Corona SDK
Livro Corona SDK

Supercell: Zero a U$3 bilhões em 3 anos

supercell-founders

Tem algum tempo que venho acompanhando a empresa finlandesa Supercell. Talvez você não a conheça pelo nome, mas se tem um smartphone, certamente conhece seu trabalho com os games Hay Day e Clash of Clans. Ambos jogos se tornaram febres tão grandes que possuem até mesmo comerciais de TV. Eu jogo Clash of Clans tem três meses e minha esposa joga Hay Day tem uns 6. Saiba mais sobre essa grande empresa de games para celular neste compilado de informações retirados de jornais americanos.

Helsinki

Petteri Koponen visitou um escritório sujo na periferia da capital da Finlândia em 2010 para conhecer um grupo de desenvolvedores lançando uma companhia de games mobile chamada Supercell.

“Basicamente era somente uma sala com janelas muito pequenas,” lembra-se Sr. Koponen, um investidor anjo de startups. “Naquele momento, eles não tinham cadeiras para todo mundo.” O co-fundador da empresa, Ilkka Paananen, estava debruçado sobre uma caixa de papelão que ele usava como mesa enquanto discutíamos os planos da empresa.

Em 15 de outubro de 2013, o banco japonês SoftBank Corp. concordou em comprar 51% da empresa finlandesa, que tinha somente dois jogos (hoje são 3) e 130 empregados, por U$1.5 bilhões de dólares. Este é o maior investimento de todos os tempos em uma empresa de apps mobile, de acordo com Rutberg & Co. Os dois co-fundadores da Supercell levantaram mais de U$200 milhões de dólares cada um com suas ações.

O investimento na Supercell é outra engrenagem no império que se alastra do CEO do SoftBank, Masayoshi Son, que também inclui a Sprint Corp. É um negócio arriscado: a Zynga Inc., criadora de jogos sociais americanos que veio ao público em 2011, tem um valor de mercado de U$2.8 bilhões, uma queda de 60% desde o seu IPO. Suas projeções falharam ao não conseguir criar um sucessor convincente à sua franquia Farmville.

Supercell está no meio de um exército de novas empresas que querem gerar valor significativo rapidamente e quebrar indústrias maduras baseando-se nos sistemas de distribuição como a app store da Apple e apps no Facebook. Mas ao contrário de muitos dos seus concorrentes, Supercell é lucrativa.

A companhia serve como um ícone para a estratégia de distribuição freemium. Esta estratégia permite que os jogadores possam baixar e jogar os jogos de graça, mas requer que eles paguem pelos extras, como armas especiais ou melhorias no jogo que aceleram a jogabilidade.

Cerca de 10% dos usuários da Supercell compram extras in-game, o que é muito maior que o normal da indústria (Chris Anderson fala em Free: o Futuro dos Preços, sobre uma média de 6% de pagantes no modo freemium). Em 2012, a empresa lucrou mais de 40 centavos de dólar para cada U$1 de itens vendidos, ou U$40.3 milhões de lucro sobre os U$105 milhões de faturamento.

hay-day

 O sucesso da Supercell vem com somente dois jogos: “Hay Day”, um app que simula uma fazenda, e “Clash of Clans”, que simula combates. Ambos estreiaram em 2012 para iOS e “Clash of Clans” foi disponibilizado para Android em 2013 planejando atingir melhor o mercado asiático.

Supercell se capitalizou na ascendência dos tablets. Criando jogos para uso primário em produtos como iPad, a Supercell nunca experimentou a dor de ter de mexer na sua plataforma para suportar dispositivos mais novos, como consoles e computadores. Inicialmente, Supercell tinha interesse em usar o Facebook como plataforma, mas a estratégia foi alterada uma vez que os executivos entenderam que os tablets iriam superar os computadores e consoles como a ferramenta primária de jogos nos próximos 5 anos.

Sr. Paananen conheceu o co-fundador em 2011, em um café na estação Paddington, em Londres, e começaram a discutir a decisão de desplugar um jogo de Facebook chamado “Gunshine” e tirar esta dependência da rede social. Esta decisão também significaria matar outro jogo da Supercell, codinome “Magic”, que estava em desenvolvimento havia 5 meses.

Supercell tinha pouco dinheiro para gastar com marketing, então a parceria com a Apple, que dá alta visibilidade aos jogos que eles vêem que possuem alto potencial, era um ingrediente crítico. Desenvolvedores cruzam seus dedos esperando que seus apps apareçam em destaque, pois a Apple, que cobra 30% das vendas, não cobra pela exposição.

Sr. Paananen já disse mais uma vez que a companhia é “incrivelmente sortuda”. Ele também nota que “Clash of Clans” e “Hay Day” são jogos sociais, permitindo que os jogadores convidem outros jogadores, criando um efeito avalanche. Usuários que competem com amigos online tem a gastar mais com compras in-app do que jogadores sozinhos.

jogando

Desde essa decisão até o lançamento de “Hay Day” e “Clash of Clans”, Supercell mudou-se de um startup de uma salinha para uma das empresas de mais rápido crescimento na história da indústria de games, com vendas superiores a U$203 mil dólares em 2011, para U$105 milhões de dólares em 2012. Ainda mais surpreendente foi a marca alcançada apenas nos 4 primeiros meses de 2013: U$178 milhões!

O valor da companhia também alavancou. Em abril de 2013, Supercell levantou U$130 milhões em investimento de um trio de investidores, incluindo a Institutional Venture Partners, da California. Nesta época, o valuation da empresa era de U$770 milhões. Seis meses depois o valuation subiu em 289% para U$3 bilhões, ou o maior valuation de uma empresa de apps mobile, de acordo com Rutberg.

Em uma entrevista em 2013, Sr. Paananen, CEO da Supercell, disse que o sucesso da empresa na Ásia foi o que rapidamente aumentou o valor da empresa. Ele disse que “Hay Day” e “Clash of Clans” estão entre os apps mais baixados na China e Japão. Ele atribui o sucesso em parte também ao acordo de promoção mútua fechado com a GungHo no verão de 2013.

“O Japão tem sido um grande cemitério para as empresas de jogos orientais,” ele disse. “Eu acho que o que aconteceu desde a rodada anterior de investimento é que nossos jogos tem mantido seu poder nos mercados orientais e agora estamos provando isso cada vez mais forte.”

Sr. Paananen, agora com 35 anos, co-fundou uma empresa de games chamada Sumea em 2000 que basicamente distribuia jogos para operadoras móveis, incluindo Vodafone e AT&T. Ele cresceu durante uma era que ele chama de “Era Dourada” dos jogos, gastando horas com títulos como “The Sims” e “Monkey Island”. Ele vendeu Sumea mais tarde em 2010 para descansar, mas seu sabático não durou muito.

Juntou-se com Mikko Kodisoja, um amigo de longa data, e registraram uma nova companhia em maio de 2010 para começar a trabalhar. O sonho, após Paananen ler sobre a cultura flat do Netflix, era construir uma empresa com pouca necessidade de gerentes.

O primeiro escritório foi um retrato da austeridade,equipado com móveis usados comprados em um brique. Os bens foram levados ao pequeno escritório no Passat 2006 de Kodisja, e o estofamento se rasgou durante a mudança. Conforme Supercell cresceu, eles eventualmente alugaram um andar em um prédio da Nokia em Helsinki.

Sr. Kodisoja e Sr. Paanane levantaram cerca de U$237 milhões no acordo com o SoftBak, mas Kodisoja não abandonou seu Passat ainda que ele tenha a foto de uma Ferrari na parede do seu escritório desde quando criou sua primeira empresa de games 16 anos atrás, quando tinha apenas 20.

Os desenvolvedores da Supercell tem empregados alguns dos mais tradicionais métodos para se manter afiados. Nas noites de quinta, o escritório se torna uma casa de jogos de mesa, com a 10 a 20 empregados pegando caixas na cozinha do escritório com títulos como Puerto Rico, Terra Mystica, Coloretto e Battlestar Galactica.

Um dos empregados da empresa é o fundador da Sociedade Finlandesa de Jogos de Tabuleiro e Touko Tahkokallio, game designer da empresa, iniciou sua carreira como designer de jogos de tabuleiro.

Ao criar Supercell, Sr. Paanane disse que buscava o modelo de companhia que ele chama de “time de hockey de primeira classe” e não de “liga recreacional para crianças”. A companhia orgulha-se de ter contratado os melhores talentos que pôde encontrar, muitas vezes pagando bônus para atrair grandes profissionais de longe de lugares mais quentes do que Helsinki.

Supercell é um conglomerado de “células”, ou grupos consistindo de meia-dúzia de trabalhadores trabalhando em algum projeto autônomo que está mais para falhar do que ter sucesso. Em 2012, o ano em que lançaram “Hay Day” e “Clash of Clans”, eles também mataram 4 jogos. Em 2013, outros dois, de três, foram para o lixo, diz Paananen.

Quando a empresa mata um jogo, os empregados se reúnem em volta e abrem garrafas de champagne para cada membro do time, enquanto que o sucesso é celebrado com cerveja. Uma criação que não deu certo foi “Battle Buddies”, um jogo de estratégia cartunesco que tendia a ter mais apelo que “Gunshine”. O projeto “Magic” tinha cinco empregados trabalhando dia e noite até que foi cancelado.

A fórmula da Supercell não é única. Perto dali em Estocolmo, por exemplo, Mojang AV tem se tornado uma máquina robusta e lucrativa com seu jogo de construir blocos “Minecraft”. O sucesso do título transformou Mojang em uma sensação do dia para a noite em poucos anos, saltando de U$90 milhões de faturamento em 2012 para U$235 milhões em 2013.

Como Supercell, Mojang emprega somente poucos e seletos empregados, que tem pouco apreço por hierarquia corporativa e que são extremamente conservadores quando o assunto é lançar jogos. Empregados rotineiramente interrompem o CEO da empresa durante reuniões, e a maioria das novidades da empresa é distribuída via postagens aleatórias no Twitter por qualquer um dos seus 35 empregados que se recusam a assinar acordos de não divulgação com parceiros.

E aí, que tal você criar um hit de sucesso? Esse livro ensina como!