2012-10-11 Android Developer Lab+ – Connectivity APIs

2012-10-11 Android Developer Lab+ – Connectivity APIs


MALE SPEAKER: Welcome to another
Android Developer Lab. So thanks for joining us. We are running three
minutes late. But that’s OK. Hopefully that’s given you
enough time to join. So with that being said, let’s
get started with the news. The first bit of news
is really exciting. And we’re really proud of it. The Nexus 7 tablet has won
gadget and tablet of the year. So that’s really awesome,
really fantastic. We couldn’t be prouder of the
Android engineering team, as well as our partners ASUS. And other than being a great
tablet for consumers to use, it’s a fantastic development
tablet, too. So yeah, we’re really,
really happy. All right, moving onto more
developer-specific news. We launched our trials
for subscriptions. So now you get a period
where you can try the subscription app– not just magazines,
but even apps. You can trial it for a little
while before the user has to commit to purchasing it. So this is a great way for users
to get a taste of the app before they purchase it. And we think it’s going to
be really beneficial for developers. The next thing is that this
week has been tablet week. Well, we said it
was last week. And we certainly started
off with it, and our European team as well. We published some materials
this week. So first was the blog, the
Android developers’ blog. And we talked about building
quality tablet apps. It also had a link to our
developer portal called Building Quality Apps. And so on that Building Quality
Apps, there’s actually three sections. And one of them specializes
on tablets. It has a checklist to say, well,
this is what makes a quality tablet app. So for those of you that are
building phone apps and not building tablet apps, now is
the best time to get in. Last week’s a ADL+ covered
fragments, which are really a fundamental piece of building
apps for phones and tablets. So if you haven’t seen it
already, you should definitely view last week’s ADL+ app, and
then go along with this new checklist that we’ve
published. Next slide, please. And over to you Anirudh. ANIRUDH DEWANI: Hi guys. So for today’s talk, we are
going to cover Connectivity APIs, for Jelly Bean. And we’re going to announce
something really exciting at the end of the presentation,
unconnected with the API, so stay tuned. So what we’re going to look at
is, what are connectivity APIs, and what’s new
with Jelly Bean. So basically, these are a set
of wireless APIs, and they enable devices to communicate
between each other. So they can communicate
with the cloud. And that’s about using your
regular Wi-Fi to connect to your service on the cloud
and pull data. And they can also talk
to each other. So some of these technologies
that can enable this kind of communication on Wi-Fi,
Bluetooth, and Android Beam, which is built on
top of of NFC. And these have existed
since ICS. We had Android Beam. And then Wi-Fi and Bluetooth
have done that much before. So in terms of what’s new for
Jelly Bean, we introduced something called Wi-Fi Direct
Service Discovery and Network Service Discovery. And these are the two topics
we’ll cover in detail. With the launch of ICS, we
introduced Wi-Fi Direct, which is a peer-to-peer technology
for connecting devices. And with Jelly Bean, we’ve kind
of introduced Service Discovery along with Wi-Fi. So first look at
what Wi-Fi is. Like I mentioned, it
allows peers– which is devices within
their Wi-Fi range– to find and discover
each other. And once they discover each
other, they perform discovery. They are able to connect and
then use sockets for transferring data. And it’s kind of interesting,
because the Wi-Fi range is much larger than the
Bluetooth range. And also the connection
is high-speed connection with Wi-Fi. So it is a very interesting
and fast way of connecting high-speed connections
between devices. Which brings us to the new APIs
in Jelly Bean, which is Wi-Fi Service Discovery. So with regular Wi-Fi Direct,
which was introduced in ICS, you could connect to devices. And once you connect, you
first perform discovery. And once a discovery is done,
you get the network details of the other device, which is the
IP address to connect to. And then you connect
to the device. Once you connect to the device,
your application sort of has to publish the services
available through the application. If your app is a game– a Market Play game– so only when the other device
was able to connect to you, you can say hey, I have
multiplayer lobby available. And this is how you start
exchanging data with me. So this was actually a very
good user experience, that you’d have to connect to devices
to figure out what services are available. So that’s where the Wi-Fi
Service Discovery comes in– Wi-Fi Direct Services
Discovery. And it’s a pre-association
discovery. So you can actually find
services before establishing or associating yourself to the
AP, which is the access point. So you can figure out what
services are available. And if you’re interested, you
can connect to a particular device which is hosting that
service, or the app that is hosting that service
on the device. So the devices– and this comes from
Wi-Fi direct– the devices are not connected to
a network, or don’t have to be connected to a network. You do not have to have an
existing Wi-Fi network around– a classic router-based access point around. The devices can just connect to
each other whenever they’re near the Wi-Fi range
of each other. Which basically means, before
they’re assigned an IP address on the network, they are able
to discover each other. They discover the services and
the device itself, and then if interested in the service,
establish a connection. So this actually leads to
a really improved user experience. So you browse printing services
find transfer services that are available
nearby. And then you connect to a
device that you want to. OK, some of the key APIs
for Wi-Fi P2P are– sorry, we’ve got a video
feed from someone– let me see. MALE SPEAKER: Are we getting
some echo, Anirudh? ANIRUDH DEWANI: So some of the
key APIs available as part of the Wi-Fi P2P Service
Discovery APIs are– and these are the
objects listed– there’s a Wi-Fi P2P service
info which encapsulates a Wi-Fi P2P service. And P2P here stands
for peer-to-peer, which is Wi-Fi direct. So there’s a Wi-Fi direct
service involved which encapsulates a service which
you want to publish. Then there’s a service
request. And then there are two
specializations of these, service request and
service info. One is a DNS SD– this is DNS-based service
discovery. And the other one is UPnP, and
that is a popular Universal Plug-and-Play protocol that
you find in a lot of media devices and peer and their
compliant devices. And this is specialized for
media technologies like rendering and publishing streams
of audio and video. So there’s a specialization
for DNS space service, and UPnP-based service. So now we’re going to get a bit
more technical and take a look at coding and some code
snippets to see how does this actually work. So the first thing you want to
do from device A, which is the first device that’s interested
in connecting, or is interested in being part of a
peer-to-peer exchange, will publish a service. So before you can actually
connect to a service, you need to publish a service. So you create a local
service object. And what you do is you
have an instance name and a service type. So the instance name is
something that your application is. So this could be test, or
myChat or myPnPService. And then there is a service
type, which is a standard name that’s followed. And this list of names are
registered with IANA, which is body that manages the
service types. And so if you’re publishing a
service that’s not already included as part of the IANA
services, you can register your service type with
the IANA body then use a service type. So this would typically be
something, for example, for chat service, we use something
called presence. And presence is the name for
chat service so your service type will be presence. And similarly, there are names
for printing and for other network services. So what we’ve seen is, you’re
able to create a local service object. And then you register this local
service with the Wi-Fi P2P manager. Wi-Fi P2P manager is a system
utility that’s a frame of class that’s available to you,
just like the connectivity manager or the telephony
manager. You say
contacts.getSystemService and then you say Wi-Fi P2P manager,
and you get a handle to the manager object. So we’ve seen the part of where
a device is able to publish a service. Now, on the peer device which
actually wants to use the service or consume the service,
you will create a service discovery request. And then you will go ahead and
perform a service discovery. So first you create an
associated object that describes your request. Basically you have some fields
that we will look into. And then you ask the
Wi-Fi P2P manager to perform the discovery. So when you’re implementing
this in Android, the first thing is let’s set some
of the permissions. You need a change Wi-Fi state
and an access Wi-Fi state permission. Actually you need internet
permission. It’s not because we are
going to exchange data off the internet. It’s only because we are going
to use sockets to communicate between the devices. And the sockets main
permission is typed to sockets usage. So you would require
this permission as well in your manifest. So now, at a code level, these
are the snippets of code. And it’s pretty easy
to write this code. Just do three lines
per operation that you want to perform. So the first thing to
do to add as a peer adding a local service. So here’s the service class that
we talked about earlier as a key API. This is Wi-Fi P2P DNS
service info. And we just use a static
initializer on that same new instance. And the two things that you
are looking at, the parameters, they are
the instance name and the service type. So the instance name is our
instance of a service, which is _test here. And because it’s a kind of chat
m we are using a standard name for the chat service. And notice the naming
convention here. This is followed for all the
services type for all DNS-based services. So it’s underscore service type,
underscore the protocol it’s going to follow
on the network. So the third thing is
really interesting. It’s record. And this is a DNS
text recorder. And this is also pretty much
standard, and this gathers additional metadata about
your service. So for example, if it’s a chat
service, along with saying that you have a chat service,
you also want to say that, as a user, I am available to chat
at this point of time, or I am busy and I cannot chat. So the service is available,
but you are busy. And you cannot respond
to chat messages. So DNS TXTRECORD is
a key value thing. And this is where you can
publish some additional metadata about your service. You can keep publishing these
records, which these records can change over time. So your service is published. And it’s available as
a chat service. And then you can keep pushing
the DNS TXTRECORD, saying, I’m available at this point
of time, I’m not available, I’m busy. So once you’ve done that, we
add the local service. And the mManager object that
you’ll see here is the Wi-Fi P2P manager. And then you add this
local service. And there is a callback. Many operations or almost all
operations of Wi-Fi P2P direct and DNS network service
discovery are asynchronous. And you always register
a callback for success or failure. So this is a standard
template for all operations of service discovery. So we instituted a service info
object, which had our instance name and service type
on the DNS TXTRECORD. And so once we’ve created that,
we go ahead and say myManager.addLocalService. And as soon as you do that, your
service is published over the Wi-Fi network. And in case there is an editor,
you can handle that error and show appropriate
messages to the user. So like I said, all the
operations are asynchronous. So every time you perform an
operation, you’re going to pass a callback or register for
an action listener, like a success/failure. And because it’s asynchronous
in nature, you don’t have to worry about where you’re
placing this call. It can be in your main thread. The underlying network call is
always off the main thread. So you don’t have to worry about
writing asynchronous. So it’s in task and placing
these calls. They’re inherently
asynchronous. So we’ve now published
a service with those two lines of code. So the other peer that’s in
present been consuming where your app is running, if it wants
to discover the nearby service and connect to it, it
first needs to create a DNS as the service response listener,
which basically is a callback that has one method that says
onDnsSdServiceAvailable. And we talked about UPnP. And this is the same kind of
mechanism that we follow around for UPnP. So when there’s a UPnP service
available, you would see onPnpServiceAvailable
with a UPnP service response listener. So this is a callback– the
method around the anonymous implementation there is called
when the framework is available to discover
a service. When the Android device
discovers a service, it’s going to give you a
callback there. So the first thing you do is
you initiate a service response listener. And you set it in
the managers. So you say, Wi-Fi P2P
manager, here is my service response listener. In case there is a service,
call me back. So we’ve set our response
listener. And then what we want
to do is actually create a service request. This, once again, if
you remember, is one of the key APIs. So you will say, use the Wi-Fi
P2P service request object to get a new instance– again, a static initializer
there. And once you’re able to get a
service request, you add the service request to the
Wi-Fi P2P manager. And again, there’s an
asynchronous callback success/failure. Once this is done, you actually
go ahead and perform discovery by saying
mManager.discoverServices. And then this is when the
firmware actually starts discovering the services. You’ve already registered
a response listener. You’ve given your
service request. And now the framework is able
to perform discovery. And if it finds something, it’s
able to callback on your interfaces. So once the DNS SD service is
available, you will also see the Wi-Fi P2P device object
along with it. This is basically a structure
that has details about the peer IP and the other
connection details. And this is when you can
actually go ahead and form a network connection. So you’re able to query
the Wi-Fi P2P manager for nearby services. And suppose you find the service
of maybe a printing service, or maybe a chat
service that you want connect to. At this point of time– which is
after performing discovery, and the thing that gives you a
callback on your interface– you can now receive the
connection details and go ahead and connect with
other device. And this basically means
initiating an access point association, and so once this
is done you’re on the same network now. You get assigned IP addresses
on the same network, at the same Wi-Fi P2P network. And once this is done, you’re
able to open sockets because you’re on the same
network now. You can open TCP sockets and
start exchanging data, which is your app data. So what the framework is
really giving you is a mechanism, it’s sort of a
framework for discovering and consuming other services. So this was completely Wi-Fi
P2P, which is based on a Wi-Fi peer-to-peer network. So the condition there was,
there doesn’t have to be an existing network. Two devices capable of Wi-Fi
P2P direct will find each other, discover the
services, and go. And the other thing is, the
other API that we just linked with network service
discovery. And this is basically based on
the fact that you’re already part of the network that
you want to join and discover services. So you’re connected to
the network already. In this network, you want to
discover services which are available in your
local network. So this is pretty similar to
Bonjour, if you’ve worked with Bonjour on the Apple systems. Or there are other Zeroconf
networking solutions available on DNS and other platforms. And this is basically bringing
the same Multicast DNS-based service discovery to Android. And we call it network
service discovery. And like I mentioned, it’s
different from Wi-Fi Direct, because Wi-Fi Direct we didn’t
really need the network. And this is when you’re
actually logged in to a local network. Suppose you bring your device
to your workplace and you connect to your corporate
internet, and you have some printers available and you
want to print maybe some document, some PDF from
your mobile phone. And many other printers
understand what is network service discovery and
Multicast DNS. So you can discover these
printing services available and then go ahead and print
after you are able to make the connection. And again, file sharing is one
of the big things on the local network, and multiplayer gaming
is really useful and can really benefit from
technologies like Wi-Fi, P2P Direct, and network
service discovery. So we’re going to technical
details of how it works. In this case, you will
create something a registration listener. This is the device that’s
publishing a service. This may already be an existing
device on the network, or it may be an
Android device which is offering maybe a multiplayer
gaming lobby, or a chat service. And this is how to go ahead
and publish its service. So you create something called
the registration listener. And in terms of DNS-based
network service discovery, we call it registration instead of
saying publishing a service on the network. So naming convention
is followed here. So you register your service on
the network by creating a callback for registration
listener. And then you, again, have this
whole same kind of details. You have the instance on
the service the type. And the service type is
compliant with IANA. And so here is some code. Basically it’s, again, a
callback on anonymous implementation of registration
listener, which has some standard methods, which is
your service has been registered– onServiceRegistered,
onRegistrationFailed, onServiceUnregisered, and
onUnregistrationFailed. So the framework is going to
call any of these methods, depending on what really
happened with your request. So you can listen to these
notifications and show the proper URL go-ahead
with actually connecting to devices. So once you’ve created a
registration listener, what you want to create is a
description for your service. And again, we use something
called NSD service info. The class is similar to those we
looked at earlier as Wi-Fi P2P service info. So the NSD service info here,
we set the service name, the service type, and the network
port it’s going to run on. Because we are already in the
network, we can specify what port my service will run on. And you get a handle to NSD
manager, same as Wi-Fi P2P Direct and other system
services. You say Context.getSystemService
and get a handle to NSD manager. And once again the manager
handle, you create a registration listener. And you can say, register my
service, here is the info of the service, and here is
registration listener, which is the callback where the
framework will call you back depending on what goes
on with your request. So with this, now you’ve
registered your server. So as you can see it’s just two,
three lines of code per operation, and it’s pretty
easy to implement. So now you’ve registered your
service on the network. Or a DNS-based network NSD
service you’ve registered. And now you want to discover
those services. So what really happens behind
the scene is Multicast DNS technologies involved here. And you’re listening to
a network broadcast. And using some framework APIs,
you can filter out what services you want to consume
or do not want to consume. And again, it’s asynchronous
API just like Wi-Fi P2P Direct. All the operations are performed
off the main thread. So you could make your
call-in here. So just like registration
listener, when you’re discovering services you
create something like discovery listener. And this will be used to
initiate service discovery. Again, as you would have
guessed, it’s a callback which the framework is going to use
to call you back when it’s able to find something
for you. So there is onDiscoveryStarted– the framework has started
discovering services. Again, time to update your
UR, tell the user about locating service. You’re finding finding services
of OnServiceFound. You get the callback with the
service info, what that service is. And this is where you can
perform [INAUDIBLE]. If you’re not interested in
connecting to the service you can reroute the service. And there’s some other callbacks
when the service is lost, suppose the device goes
out of network or goes down. You get the service lost. Discovery is sort of
an ongoing process. [INAUDIBLE]. So you can actually request
the framework to stop discovering. And that’s when you get the
callback on discovery stop. And some other callbacks, if
something failed, discovery will stop discovery
fail, you get a couple of other callbacks. So now you’ve created a
discovery listener. And what that means now is
to request discovery. So you’d see an NSD manager
dot discover services. Here is my discovery listener. And you get the callbacks when
the framework has an update for you, which is a table to
perform discovery and find some service, or it failed. It gives you a callback on
your discovery listener. So all good, if the framework is
able to find your service. And this is on the callback
onServiceFollow. When it’s able to do that, you
initiate something called a resolve listener, which is to
find network details of the peer so that you can connect. So the resolve listener will
have callbacks again when the framework is the able to resolve
the service for you, which is to resolve
the IP for you. And then you call the framework
once you create the resolve listener and provide
them implementation, you call NSD manager to resolve
service. And that’s it. You get the IP details of the
device of the network machine that’s publishing the service. And it’s time for you
now to connect. And the connection is basically
sockets, like we discussed earlier. You’re on the network. And if the service is
TCP-based, you get a TCP-software or datagram. So to summarize, we’ve looked at
two new key APIs, which we like to call connectivity
APIs. And these are Wi-Fi P2P service
discovery and Wi-Fi Direct service discovery and
network service discovery. So Wi-Fi P2P service discovery
protocol has a DNS and support for UPnP implementation. The thing about UPnP balance,
it’s closely tied up with, associated with the DLNA
protocol that’s used between many devices. Your HD televisions, your
PlayStations, your Xboxes– a lot of media– DVD players, Blu-Ray players,
they’re using DLNA protocol to share and see media. So one device is acting as
a streaming device that’s streaming the media. The other acts as a renderer and
is able to show what the other device is streaming. And this is while working on top
of DLNA, UPnP protocols. So Wi-Fi P2P service discovery
provides you the ability to connect and publish
these services. You could the media renderer
or you could share media. And then there is network
service discovery, which is sort of a Zeroconf networking
thing that’s sort similar to Bonjour. And then you’re able
to find DNS-based services on the network. And with this you can find
services when you’re not connected to the network using
Wi-Fi P2P Direct, and when you are connected to
a network using network service discovery. So this brings us to the end
of the presentation here. MALE SPEAKER: Thanks, Anirudh. So Anirudh’s obviously covered
a lot of things today about all the options that you have
when it comes to connectivity on Android. And we think that the
capability is great. And what we’d like to see is
more people use it and sort of impress us to show us what are
the creative things you can come up with. So today I would like to
announce something new that we’re doing. We’re calling it a
ADL+ experiments. And we’re going to launch our
first experiment today. So what ADL+ experiments is, is
it’s a plus page that you should go ahead and circle. And this announcement that we’re
just doing right now, we will be making the same
announcement on the plus page as well. So ADL+ experiments is a way for
you to get involved with the things that we present. And today, we’re launching our
first experiment, which is based on the connectivity
APIs that Anirudh has presented for us. So the goal is very
simple, actually. You’re tasked with building
a cool app. This is obviously optional for
you, whether you want to get involved or not. But we think this is a really
great way to showcase your talents to the rest of the
developer community. So build a cool app. Come up with some great
concept using these connectivity APIs, and then what
you should do is share that APK with the plus
ADL experiments page. So just send us a link to the
APK– a download link, whether it’s Google Drive, or Dropbox,
or any other sort of service that you may use. And when you share with us, tell
us what the app is, and, more importantly,
how to use it. And tell us what makes
it special. You can choose to share the
source code if you want, whether you’re using a GitHub
repository or otherwise, Google code, for example. And yeah, we’ll take a look. And this program in itself is
quite an experiment, where we’re launching it for
the first time. So it’s a way for you to
showcase your talents. It’s a way to sort of energize
the community. And by all means, you
can collaborate. So send us the submissions. We put a cutoff date of
the 30th of October. And feel free to send
the before then. As we get submissions, we’re
going to go through them. And after that cutoff, the
incentive for you is we’ll pick a handful that we think
are really, really nice. And we will highlight
these apps. So it will drive some
downloads to you. But more importantly, we’d like
to invite you to a future ADL+, so you can tell us how
you built the app, what challenges you had, and
have other people ask questions as well. So try and utilize these topics
that we’re presenting. And yeah, that’s ADL+
experiments. Anirudh, is there anything
you want to add to that? ANIRUDH DEWANI: Just for this
specific topic, if you want to learn more, there is an Android
training available called Connecting Devices
Wirelessly. And this can help you with your
first experiment, so go ahead and take a look. It’s published on our Android
Developer site. MALE SPEAKER: So hopefully this
means that people are going to start submitting
apps, some work that they’re doing. And these things don’t need
to be complete apps. They don’t need to be published,
necessarily. If they’re published on
Play, that’s great. But these can be just tech
demos, effectively, where you’re showcasing something
cool that you’re doing. We love this developer
community. And we’re trying to see how
we can get you more involved in the ADL+. So ADL experiments– we really hope you engage,
because it means that if you find this sort of thing useful
then we’ll do more of these experiments in the future. So we’re going to talk about
this or mention ADL experiments every week up
until that code cutoff. And then in a future ADL+, we’ll
try and showcase some of these apps and see if
we can bring the developers on as well. So with that, we shall move on
to Q&A. We have one person that’s live on the Hangout
at the moment who hasn’t said anything. But did you have any questions
to us before we shift to the moderator page? Doesn’t look like it. That’s OK. So we have a couple of questions
on moderator. I’ll read out the first one. “I get errors from ICS users
with MapActivity. An exception which is
basically a no class definition exception found. Android.security.MessageDigest. If I Google the error, people
say that it’s a problem because an older version of
MapAPI is on the device. How do I solve the problem? The target SDK is version 16.” So I had a look at this. And there’s a handful of cases
where this has been reported on Stack Overflow. I wanted to ask you,
you said ICS users. But on those Stack Overflow
threads, there were people with Ice Cream Sandwich devices
that were saying hey, this works fine for me. I don’t have problems
with this APK. So I must admit, this
is an issue that I haven’t heard of before. I’d love to get down to
the bottom of it. So this is Mackan from Sweden. And I apologize if I messed
up the pronunciation. But please reach out
to me on Google+. And let’s see if we can
diagnose it further. I’m interested in knowing
whether the devices that you were testing on, is there
something special about them? Are they normal Ice Cream
Sandwich devices that you buy from a shop or from
your Telco? Or are they running
custom ROMs? Is there a chance that these
devices don’t have the Google services on them because they’re
running a custom version of the platform or
something along those lines? And more importantly, are you
saying every single Ice Cream Sandwich device is struggling
to run this APK? So please reach out to me. I’d love to follow up further. Anirudh, did you want to
add anything to that? ANIRUDH DEWANI: No, I think just
give us some more info and we’ll be able to help you. MALE SPEAKER: Yeah, we should
definitely try and get to the bottom of this. So next question. “I’m new to Android development
and don’t know how to design and develop any app. Could you please give me some
references from where I can learn about the environment
setup and app development? Thanks.” So this is Harshad from
Mumbai, India. Look, the best place to start
is developer.android.com. There’s a section
called develop. And there’s a getting
started guide there. It shows you how to download
the SDK, how to set it up. And it even has some sample
apps that help you sort of build the tutorials there. So developer.android.com– it’s the place where you’ll
find all of our tools. It’s where you’ll find all
of our documentation. If you have any sort of specific
questions, you should definitely be posting
to Stack Overflow using the Android tag. And you’ll have a huge
community of Android developers that’ll be just ready
and willing to help you. The important thing is that your
question is very broad. You’re saying, hey look, I don’t
know how to design or develop any app. It’s really important to just
get your hands dirty. Stop playing with the
tutorial, start writing sample apps. And in the beginning
it may be hard. You may feel like, hey this is
not a very high quality app. That’s OK. That’s how you learn. And that’s really
the focus of it. Next question. “Can I retrieve data from the
Google Maps API so I can use it for my location-based service
application that I’m developing?” This is Prisy
from Philippines. Anirudh, do you want
to take this one? ANIRUDH DEWANI: Yes. So the API that’s available is
called Google Places API. And that’s what you would
probably like to use with your location-based sources
available. You can use this API. It’s a rest-based API. And there is a token you need. So what you need to do is go
to your developer console, which is
code.google.com/api/console. This is where you create a
project whenever you’re trying to use any of the APIs there. So there, you need to enable
Google Places API. And I think there is
some quota that’s available to you free. And then you need
to pay beyond a certain number of requests. So if you’re just trying
out, you could probably try it for free. And the Google Places
API is there. And if you go to our
developer website, developers.google.com, you can
look up the service reference, and all the API reference,
and the different clients available to you if
you do have a Google Java client library. And yes, you can pretty much
use the Places API. And if I remember correctly, I
think Reto Meier, one of our advocates– you probably
know him– he published a tutorial on
location-based services. And he also shared the
sample source code. So if you just look up the
history of the archives of Android blog, you will probably
find this tutorial. And he is using Places API
there to fetch places of interest for another
location-based service, basically allowing users to
check it when they want. So go ahead and there’s a lot
of samples of complete applications that you
search in there. So you’ll find a lot of sample
code there on how to use Google Places API. MALE SPEAKER: Cool, thank you. So the final question. “Why can’t the Google Play store
send back the install referrers back either at the
Google Play developer console or through an API? Currently the in-device install referrer process is broken. We have big product marketing
plans around that feature.” And that’s from Gopinath
in Bangalore, India. Do you want to take this
one as well, Anirudh? ANIRUDH DEWANI: Yeah. So I don’t really know if
it’s not available. And if it’s not available, I
would say that this is a feature request we can
take up to our team. So just hang on to your big
product marketing plans before it’s released. And I’m not even sure if it’s
going to be released yet. We will just take your feedback
to our product team and see how they want
to prioritize this. MALE SPEAKER: I was under the
impression that definitely we do support referrers. But I think the key thing here
might be that in the question he mentions about the in-device
experience– or on-device I think is
what he meant– that the referral process
might be broken. Because if you do it by the
web, I’m pretty sure that process works pretty well. And I’d be surprised
if it didn’t translate well to the device. Yeah, let us look that up for
you and run that past our team and see if we get a response. So please do reach out to either
Anirudh and myself. And we’re going to look
up the answer anyway. But there’s no way for us to
contact you directly here. So yeah, we’ll do that. Just so you know, this question
I think is a fairly new question. It wasn’t there a couple
of hours ago. So we haven’t had the
opportunity to have an answer ready for this one. I haven’t seen any further
questions on moderator. Are there any questions
on the thread where we’ve hosted this? Felix, could you just
check the– we’re just checking
the thread. Nope, there doesn’t
seem to be. Well, thank you for
joining us. We mentioned before that we
were announcing something. And it was ADL experiments. It’s really for developers to
get their hands dirty with this stuff. So we hope that’s
useful for you. It’s exciting for us, because
we get to see some of the creativity the developers
come up with when using these new APIs. So thanks, Anirudh, for
presenting connectivity. And thanks to all of
you for tuning in. So that’s us signing
off for this week. We’ll catch you next week. ANIRUDH DEWANI: See you, guys. MALE SPEAKER: See you later.

Leave a Reply

Your email address will not be published. Required fields are marked *