TREVOR JOHNS: Hello, and welcome to Dear Android, the
show previously known as Android
Developer Office Hours.
We got a bit tired of developers always trying to
show us up by asking us a question that we couldn't
answer every week.
So we decided to try new format for a change.
We'll be selecting the best Android application
development questions from across the internet, including
Google+, and answering them for you here on YouTube.
If you're watching this live, which is every Wednesday at
2:00 PM Pacific, we'll be hanging around for a few
minutes after each episode to answer any questions about the
current episode.
So with that out of the way, let's go ahead and move on to
this week's question, which comes from Dancio on Stack
Overflow, who's a user from Poland.
He asks, if I have a custom service that I'm broadcasting
via Bonjour, and that I'd like to either broadcast or
discover using wi-fi or Bluetooth, is
this possible on Android?
To answer this question, we have Alex Lucas, who is a
member of our Android developer relations team, who
wrote many of the docs about both network service discovery
and wi-fi on our developers site.
Alex, could you help us answer this question?
ALEX LUCAS: Absolutely.
So to break the question into two sub-parts, will
Bonjour-like services work on Bluetooth and will
they work on wi-fi?
The answer is, yes on wi-fi, no on Bluetooth.
Thank you for tuning in.
That's our show.
TREVOR JOHNS: See you, Alex.
ALEX LUCAS: Bye.
So we should actually probably answer this question in a
little bit more detail.
To start with the Bluetooth part, Bluetooth is a really
great protocol for lots of device to device applications,
like streaming music or communicating
with heart-rate monitors.
But on Android, it does not actually support TCP.
So what that means is you cannot create a TCP socket and
connect to it over Bluetooth to other devices.
Because network service discovery, or at least the
Android implementation of network service discovery run
over TCP, this creates a fundamental incompatibility
between Bluetooth and TCP.
That said, it does actually work over wi-fi.
TREVOR JOHNS: All right.
So before we go into a bit more detail, let's give a bit
of background about what exactly what NSD is.
So NSD is network service discovery, which is Android's
implementation of multicast DNS, using the DNS service
discovery protocol.
And what this does is it allows applications to
broadcast to their existence on the local network, along
with connection details for that application to any other
devices in the same proximity, which would be any other
devices, again, on the same local network.
So this is useful for things like social applications,
games, or even networks services like
printers or web servers.
So that way you can find out what devices are nearby.
ALEX LUCAS: When NSD broadcasts this information
over the network, there's four fundamental pieces of
information it's going to send over.
One of them is the device identifier.
The device identifier is often going to be either the user's
name or the device host name.
Another item is going to be the service name.
The service name is often going to be the name of the
application.
For instance, if you have a game called Replica Island
that you want to play with other users over the network,
and Replica Island has network service discovery built in,
the service name is probably going to be something like
Replica Island.
Another item is going to be the host address, which you
don't actually have to enter yourself at runtime.
Android will just figure that out for you and send that
along and the NSD packets.
The final item is going to be the port.
And I wanted to make a special note about the port, which is
that for mobile applications, the easiest thing to do when
you're designing the game or the application, is not
actually to pick your own port at runtime or
hard code one in.
What you want to do is get a server socket and
set it to port zero.
And what that's going to do is it's going to tell the Android
framework, just give me whatever port is available on
the system.
When the server socket returns the port number to you, you
then enter that port number into the network services
discovery broadcast.
The handy thing about this is that if you, for instance, had
decided that you wanted port 53 to be one your application
runs on, and some other application developer decided
that they wanted port 53 to be the one that their application
runs on, there would never be a conflict.
And there would never be an issue where the user had to
choose between your application or someone else's
application running at any given time.
TREVOR JOHNS: Right, that's a nice fact.
It means if you don't have to request or reserve to port
from the IANA.
Now you do still have to go and register your service
name, but it's as simple as just filling
out a simple form.
And the chances of there being a conflict are pretty much
nonexistent.
ALEX LUCAS: Yeah, very small.
You don't actually need the IANA reservation for when
you're doing internal testing.
But as soon as you let your application out onto the
internet to roam free, it's a really good idea to get
registered.
TREVOR JOHNS: Yeah, it's just good practice.
All right, now we talked a bit earlier about Bluetooth.
And even though you can't use NSD on Bluetooth , there's
another answer we want to give you, a better answer.
And that's called Wi-Fi Direct.
Wi-Fi Direct is a peer-to-peer version of wi-fi.
So it lets devices communicate with one another without
having to go through an access point.
This provides many of the same benefits as Bluetooth,
device-device connections, but with the advantages of wi-fi,
which means increased speed and increased range.
This is available on devices running Android 4 or above.
That's Honeycomb.
And if you happen to be running Android 4.1, Jelly
Bean, you also get service discovery.
Now unlike the traditional case of network service
discovery, which we just addressed, Wi-Fi Direct
service discovery will work even when you're not connected
to a network.
So think about that for a second.
Devices running your application nearby can be
detected, even if they're not connected to the
same network as you.
That's pretty cool.
ALEX LUCAS: What my favorite thing about that-- what that
basically means, is if you're in a movie theater waiting for
the previews to start.
Let's say, you've gone to midnight showing or
something like that.
You have an hour to kill.
You can open up the application and see who else
in the theater or in line is playing the same game you are
and connect to them and play a game, having no
idea who they are.
TREVOR JOHNS: It gives you physical proximity.
ALEX LUCAS: Right.
Physical proximity, which is awesome, because you know that
the movie theater's not going to have a wi-fi network there.
They're probably--
a lot of them these days actually, are designed to
block incoming calls and signals and stuff.
TREVOR JOHNS: Please don't use that as an excuse to play the
game during the movie.
ALEX LUCAS: Right.
Don't play during the movie.
There's lots of helpful previews that tell you that's
just a bad idea.
It's rude.
There'd be a bright screen in front of the
people behind you.
And we're not suggesting that.
But when you have time to kill in line, or before the
previews, knock yourself out.
Now we do want to point out that it's still important to
implement network services discovery for when you're
connected to a network.
There's a couple reasons for this.
One of them is that Wi-Fi Direct is not going to work at
all when you are connected to a network, because of the way
the underlying technology works.
You're either connected to a network or you're surfing
around for Wi-Fi Direct devices.
The other item is that there are a lot of services and
hardware that broadcast services that are designed to
be discovered on a network.
Examples of this are network cameras and network printers.
Most companies will not set up their network printers to be
Wi-Fi Direct accessible.
Because that means anyone who was within and physical
proximity, who didn't necessarily have permission to
use that printer, could print out whatever they wanted.
So being on the network and requiring the user to be on
the network provides a sort of permission system or just a
small area of security.
So really your best option is to implement both
Wi-Fi Direct and NSD.
And that way, your application will have the best of both
worlds and increase the chances of your users being
able to connect to each other, no matter what circumstance.
In order to use Wi-Fi Direct service discovery, the
necessary class that you'll want to use is wi-fi P2P
manager, which provides an implementation of DNS-SD
similar to the way standard NSD does.
For more information about how to actually implement network
service discovery and service discovery over Wi-Fi Direct,
we have a training class available at
developer.android.com/training.
And we really recommend you go there and
read through the tutorial.
We also provide some sample code.
And it walks you through a real world example of how to
implement this functionality in a preexisting application.
TREVOR JOHNS: And if you have any questions about either NSD
or Wi-Fi Direct, join us via Hangout after the live
broadcast, where we'll be able to help answer those
questions for you.
And if you have any questions for next week's broadcast,
post them to Stack Overflow or send them to us via Android
Developers at Google+, and we'll pick the best of them
for next week's broadcast.
And with that, we'll see you all next week.
Thanks for joining us.
ALEX LUCAS: Bye guys.