iOS 8 – Conheça todas as novidades

OMG says:

Muito bom! 😀

Nunes says:

onde é que está o iBeacon no Android?
só um exemplo

Ricardo says:

@Nunes

Se não estou enganado, o iBeacon funciona no Android, porque é uma funcionalidade do Bluetooth Low-Energy.

Ricardo says:

@Nunes

Sim, eu sei que usa o BLE, e sim cada app tem se ter a sua implementação, mas já vi na NET o protocolo e é muito simples e fácil e rápido de se fazer (sou developer), mas a parte de ser necessário ter a app aberta é completamente falsa. No Android existe uma coisa chamada Serviços (programas a correr em background no sistema) e permite que as apps estejam fechadas enquanto o serviço faz o seu trabalho e notifica as apps quando necessário.

Nunes says:

e já agora, isto era um exemplo de algo desenvolvido pela Apple que não existia no Android. Se tens agora no Android aplicações que permitem parte da funcionalidade é porque seguem o que a Apple desenvolveu!

Nunes says:

@ Ricardo
Um serviço fazer isso para todas as apps significa introduzires suporte no sistema, e as aplicações saberem dele – não é isso que existe actualmente no Android
Quanto ao serviço de localização não me parece que possas fazer isso dessa maneira sem introduzir verdadeiro suporte no sistema para os beacons! O serviço de localização é baseado nos dados recolhidos dos Beacons, que por sua vez só são identificados pelas aplicações, pois são estas que sabem quais os beacons relevantes e onde se encontram geograficamente. Ter só o serviço de localização não te iria permitir saber dos beacons, necessitas de integrar tudo, isto é, fazer o que a Apple tem no iOS.
E o Android necessita tb de mudanças na stack de bluetooth para receber todos os pings dos beacons, e dessa forma aumentar a precisão! Creio que mesmo assim continuaria a haver diferenças, pois o método de localização da Apple não é conhecido na sua totalidade

Ricardo says:

@Nunes
Mas ai é que está a beleza do Android, basta a instalacão de um servico e todas as apps podem usufruir dele sem ser preciso mexer no sistema. Olha o chromecast por exemplo, no android a API do chromecast está numa aplicação chamada Google Play Services.
Não é preciso cada app ter uma implementacao do protocolo usado no chromecast.

http://developer.radiusnetworks.com/ibeacon/android/

Ricardo says:

@Nunes

Meti um link para uma biblioteca que utiliza os serviços com o iBeacon.

E continuas com uma coisa que talvez ainda não tenhas percebido. No Android, para adicionar novas API’s não é preciso mexer no sistema! Basta instalar uma app (ou serviço) que forneca essa API e depois todas as apps conseguem utilizar!
Um grande exemplo:
Nos dispositivos Samsung, o DLNA está “integrado” no sistema. Porque entre aspas? Porque não está no sistema, são apenas uns serviços que podes instalar em qualquer dispositivo e fica com as mesmas API’s de DLNA dos dispositivos samsung, e qualquer app pode utiliza-los!
http://developer.samsung.com/allshare/repository/android/latest/components/services/

E também já te dei o exemplo do chromecast, em que as API’s estão num serviço (https://play.google.com/store/apps/details?id=com.google.android.gms, vê a secção das novidades) que é atualizado constantemente na play store, e sempre que vem uma nova atualização, é como se viesse um update do sistema Android

Nunes says:

@ Ricardo
:S mas estás a desconversar?
O Google Play Services é controlado pela Google, com acesso especial ao sistema e implementando permissões, conhecido por todos os programadores, por isso sabem a que serviço ligar na aplicação – centralização.
Não tens isso para o iBeacon no Android agora. Cada programador terá de criar o seu serviço e não faz ideia se há outros a fazer a mesma coisa no aparelho. O que leva a multiplicação de trabalho. Pode alguma entidade tentar estabelecer um serviço comum para todas as aplicações, mas para isso terão que criar/usar outras bibliotecas que permitam esse tipo de integração, preferencialmente com a instalação de um serviço independente. Haverá questões de segurança e privacidade, necessitará de estabelecer permissões quanto à informação que cada aplicação recebe, para não se espiarem umas às outras.

Ricardo says:

@Nunes

Eu já disse que o mais provavél é todas as apps terem o seu serviço, não me estou a referir a isso.
E o facto de o Google Play Services ser controlado pela Google nada tem a ver, porque também já te dei o exemplo das API DLNA da Samsung que funcionam da mesma maneira!!!! E não são controladas pela Google!!
E se dúvidas que não funciona, então podes experimentar a minha app do wareztuga que faz uso desses serviços de DLNA!!

Ricardo says:

@Nunes

Bam!
http://www.androidpolice.com/2014/06/06/exclusive-google-will-soon-introduce-nearby-to-let-other-people-places-and-things-know-when-youre-around/

Um serviço de localização integrado no Google Play Services que fará o que o iBeacon faz e mais!

Para veres como eu tinha razão que basta um update ao Google Play Services e incorporar um serviço de localização para ter uma funcionalidade como o iBeacon!

Eu sou programador, já fiz ROM’s (compiladas é claro) e por isso sei bem como funciona o Android.

Ricardo says:

@Nunes

O iBeacon não determina a localização geográfica assim do nada. Precisa de ter os chamados Beacons numa determinada região e depois o iOS faz a triangulação para saber a sua localização dentro daquela região.
Para além disso, os Beacons têm a capacidade de mandar informação extra para o iOS para este mostrar notificações ou usar essas informações para outro fim.

O Nearby, para além de receber informação dos dispositivos (que permite fazer tudo que o iBeacon faz, incluindo a pseudo localização), também consegue enviar informação para esses dispositivos, o que possibilita uma funcionalidade como a do AirDrop nativa do sistema sem ser preciso apps de terceiros.

Nunes says:

@ Ricardo
Creio que necessitas de procurar por um pouco mais de informação sobre como o iBeacon funciona.
O iBeacon é primeiro que tudo um protocolo que usa o BLE, que define como é que os Beacons se devem comportar e identifcar. Não é simplesmente ter bluetooth e ver um identificador, os Beacons têm que fazer Pings dentro de determinada frequência e potência, e informar sobre as suas propriedades aos dispositivos à volta.
É este comportamento dos Beacons que permite determinar distâncias relativas pelo dispositivo com alguma precisão – esta aumenta com a frequência e dentro de certos limites de distância, que varia com a potência de sinal. Por outro lado, o UDID do Beacon permite determinar o local geográfico, já que as aplicações instaladas têm informação sobre os UDID que interessam, sabem onde estão – outra parte do protocolo. É por saber onde é que está e a quem pertence o Beacon, que o sistema determina se deve haver alguma interacção. O sistema pode igualmente melhorar o cálculo da sua posição relativa dentro dum espaço físico, mas isso depende duma boa disposição dos beacons no espaço.
O iPhone pode até ser transformado num Beacon.

“O Nearby, para além de receber informação dos dispositivos (que permite fazer tudo que o iBeacon faz, incluindo a pseudo localização)”,
Desculpa mas não fazes a mínima ideia disso, não tens informação que te permita perceber que o Nearby estabelece algum protocolo para determinar localização da forma que já expliquei por alto.
Aliás a descrição feita dá a ideia de que simplesmente vê que UDIDs estão por perto. Diz que pode ligar periódicamente o WiFi, bluetooth, etc; ora para poder fazer o que o iBeacon faz, o bluetooth tem que estar sempre ligado, não é só de vez em quando. Chega inclusive a dizer que a Google necessita de dados de localização do aparelho para que se possa usar o Nearby… Não precisas de nada do género para o iBeacon

Tal como disse o iBeacon é muito específico.
Se queres comparar o Nearby terás que pegar noutra coisa, talvez o multipeer connectivity
http://www.wired.com/2014/03/apple-multipeer-connectivity/
embora tb não seja a melhor comparação

Nunes says:

@ Ricardo
Não, não disse o mesmo. Expliquei-te que o protocolo dá-te uma localização geográfica, e uma posição relativa ao Beacon, não é uma pseudo-localização, pois o seu objectivo é conhecer a posição real da pessoa para transmitir a informação relevante para o local.
“Apenas sabe que esta perto daquele, daquele e daquele beacon, por isso esta no meio deles os 3”
Desculpa mas para quem diz que leu parece que não leu a parte em que consegue calcular a distância relativa a cada um. Assim consegue determinar a posição com bastante exactidão. Os problemas que tu levantaste é para certas aplicações que requerem ainda maior exactidão, em que é preciso ajustar o tamanho de célula.

Quanto ao Nearby, esse sim é pseudo-localização, já que a informação que interessa é a existência de outros na proximidade, sem retirar daí informação geográfica.
“se ele liga o bluetooth de certeza que é para receber os broadcasts de dispositivos”
Parece que não percebeste que se fosse idêntico ao iBeacon, o bluetooth não andava desligado, doutra forma não escuta nada, nem transmite nada. E um broadcast por si só não implica saber a posição geográfica…

“e a localização para poder ainda melhor saber a localização extata do dispositivo em vez de estar a depender dos beacons que dão uma localização aproximada.”
Isso já andas a divagar…
Explica como é que vais saber uma localização exacta sem ter mais do que um ponto de referência com posições exactas? É para isso que se usa os Beacons, a sua posição é conhecida no mundo e é possível determinar a posição da pessoa no mundo. É o princípio para todos os sistemas de localização em uso.

Nunes says:

@ Ricardo
Mas será que não entendeste de que a aplicação tem informação sobre os UDID dos beacons, informação como a localização geográfica…
Estás a confundir a parte com o todo. Estás a confundir a parte do protocolo em que determina a posição relativa face a um beacon, com o todo do protocolo em que é se determina uma posição real usando o resto da informação disponível.
Percebeste agora???
O método de localização é idêntico a muitos outros, como os que usam as redes WiFi, ou até mesmo pelas redes celulares. Identificas um ponto de referência e verifcas onde é que este se encontra por outra parte do método – não é o ponto de referência que te informa a posição geográfica, mas uma base de dados.
E se implementares um protocolo que consiga determinar distâncias face a pontos de referência, consegues melhorar a exactidão do local calculado. Daí a vantagem dos beacons, já que foram pensados para terem um comportamento que facilite o cálculo. Não consegues o mesmo só por um dispositivo qualquer fazer um broadcast, já que os broadcasts ocorrem a muito menor frequência e diferentes potências, não dando informação suficiente para melhorar a exactidão, sabendo apenas que está por perto, tanto faz se ao lado ou a 40 metros.

Ricardo says:

Onde viste que a google vai usar ndk?!
Ela já usa isso desde o inicio para fazer codigo nativo para correr mais rapido, mas nunca ouvi dizer que irá abandonar a VM, a proxima aposta é a do ART.

OMG says:

Sim. código nativo é invenção da Apple, não é?

Ricardo says:

@Nelson

Ah, mas foi uma inferência tua. Porque a google abandonar completamente a VM não pode ser, senão todas as apps que existem até ao momento deixavam de funcionar. Mas o Android usar codigo nativo é umas das coisas que eu desejo que aconteca desde que conheci o Android por dentro (já ha muitos anos), e vepois vem esse problema das várias arquiteturas, com a VM uma app corre em tudo, com código nativo tinha de ser feito um app para cada arquitetura.

O melhor caminho a seguir é mesmo o ART, e optimizá-lo até não poder mais, porque assim continua-se a programar em Java, mas no dispositivo corre como código nativo.
Ah, e implementar um tipo de ARC no compilador e mandar o GC co car***o

Ai sim, continua com a mesma facilidade mas corre tudo muito mas mesmo muito mais rápido e sem os breaks do GC.

Ricardo says:

@Nelson

Pois, lá está, usa o VM por causa da quantidade de arquiteturas em que o android corre.

Mas não conhecia esssa do apportable, é realmente muito interessante

Ricardo says:

@Nelson

1º Eu não disse que corria em arm v8, apenas disse que corria em arquiteturas diferentes, não mencionei o arm v8

2º Sem contar com o CPU da Apple, ainda não ha CPU’s arm v8 em dispositivos, por isso se o Android corre ou não, não sei, mas também para já não vale a pena visto que não há CPU’s.