WWDC2004 Session 502

Transcript

Kind: captions
Language: en
good morning thanks for coming everybody
I am Eric Brown the bluetooth software
manager at Apple and i'm here to talk to
a little bit about developing bluetooth
applications so let's go ahead start off
talk about bluetooth industry
developments in the past year and kind
of look to the future a little bit in
the past year we've seen bluetooth
version 1.2 introduced by the bluetooth
sig a couple of notes about 1.2 it is
fully backwards compatible with previous
versions so it should be fully
interoperable with all of the Bluetooth
hardware out there they've introduced a
new new function called adaptive
frequency hopping or a sh for short you
might have seen it in some of the apple
literature but what it does is allows
bluetooth to avoid interfering with
other 2.4 gigahertz wireless
technologies so the way that works it
actually pays attention to where it
notices interference and then just avoid
communicating over those frequencies so
technologies like airports your your
cordless phone things like that it can
be rest assured that you won't have
problems with those also in bluetooth
1.2 is a new fast connect capability
which between two devices that are both
1.2 compliant it allows greatly reduced
connection times to speed up
communicating between the two devices
have also added a new enhanced go
capability which improves the voice
quality when talking with headsets we in
the past year we've introduced the
Bluetooth firmware update 1.1 that adds
cape adds support for the bluetooth 1.2
spec and we definitely encourage
developers of new hardware to adhere to
the 1.2 spec we're definitely focus on
that going forward
now there's a number of new new hardware
features coming in the next year I can
only talk about about one of them but we
think it's going to be a pretty big
pretty important feature and that's what
the bluetooth sig is calling enhanced
data rate they announced it earlier this
month and it actually improves transfer
speed three times so upwards of 2.1
megabits per second over the Bluetooth
wireless link in addition the enhanced
data rate actually allows for lower
power consumption between devices so
that should improve battery life of your
battery-powered devices unfortunately
because it is a new design and
enhancement over the way that Bluetooth
communicates over-the-air it will
require new hardware so hopefully later
this year we'll see this new enhanced
data rate ratified by the bluetooth sig
and we'll definitely be looking to see
exactly where that goes back in January
the bluetooth sig announced that there'd
been over that at that point they were
selling more than 1 million or rather
other companies are selling more than 1
million Bluetooth devices each week well
as it turns out they're now up to two
million devices each week and to date as
of the beginning of June there have been
over 150 million Bluetooth devices sold
worldwide so it's definitely a pretty
popular technology it's really finally
getting out to the masses
so now let's take a look at over the
past year we've added a number of new
features to Panther added support for
Bluetooth headsets Bluetooth printing
and as I just mentioned a 1.2 spec I'm
going to talk a little bit in detail
about exactly what these features are
and how they work in February we're
elisa bluetooth 1.5 software update
which was later rolled into mac OS 10 10
point 3.3 that add to support the
headset support is implemented pretty
straightforward set up a headset with a
bluetooth setup assistant and it shows
up as any other audio device on the
system any application that that does
audio input or audio output can take
advantage of it as part of the headset
profile in the bluetooth spec they
define two different roles there's the
headset role and the gateway troll
headset role obviously applies to
headset devices gay ways to find applies
to things like your phone and the mac in
our case we've only implemented the
gateway portion of the profile so what
that means is with the existing headset
support for example your phone can't
communicate with the mac because both
are gateway devices as well the the
headset support is actually integrated
into a Scotty Oh drivers so it isn't
really generic schoo support per se but
rather all integrated together at the
same time that we introduced the 1.5
Bluetooth update there was an ichat beta
release of 2.1 that supported the
bluetooth headsets additionally a couple
things to note about the the way that
the schoo links work is that currently
hardware limitations restrict us to once
co link at a time so just as a little
bit of background the schoo link is the
type of connection use between the
headset and and your Mac to to
communicate the audio data however again
since only one link is supported at a
time that restricts our ability to
support things like multiple headsets at
once or look
in the future maybe using your Mac
talking to your phone and your headset
at the same time an additional
limitation is that speech recognition
isn't supported for Bluetooth headsets
unfortunately it requires 22 kilohertz
16-bit audio whereas the Bluetooth schoo
audio support only provides 48 kilohertz
16-bit audio unfortunately it's just a
limitation in the technology at the st.
in the same software update a Bluetooth
1.5 update we added support for
Bluetooth printing now this was done
through what's called HDR p or the hard
table replacement profile again in
addition to being able to configure new
printers with the bluetooth setup
assistant bluetooth support is
integrated into the print panel and the
printer setup utility now the way that
the support was added it's just straight
forward cups back-end that talks
bluetooth to the bluetooth hardware we
definitely recommend that printer
manufacturers that are looking to add
bluetooth support to the printers do so
using HCR p is it should just be plug
and play with or rather unplugging play
with the bluetooth wireless technology
with our support one thing to note is
that in order to guarantee that a
particular printer works properly over
bluetooth the printer manufacturers must
provide a bluetooth certified driver so
typically that just means testing it and
providing the driver with the necessary
information embedded in it saying that
it is blue to certified but that just
avoids cases where printers might appear
to work but don't
then finally as I mentioned over the
past year we we added support for the
Bluetooth 1.2 specification in the
hardware those of Bluetooth firmware
update version 1.1 that supports both
Apple built in modules as well as the
external d-link modules now one thing to
be aware of there have been several
different revisions of the d-link
modules so it only supports the dbt 120
with revision be two or later so you
definitely want to make sure of that
before trying the firmware updates the
new firmware adds support for the 1.2
baseband specification so now let's move
on to tiger that's what you're all here
to to see about we've added a number of
new api's and developer applications
that that should hopefully be of
interest to see a lot of you as far as
the api's go we've added a new device
inquiry API in the form of sub the tooth
io Bluetooth device inquiry object we've
added a new obex transfer services
object to provide some generic obex file
transfer capabilities as well as then a
set of scho audio services to enable
third parties to use to use the schoo
capabilities that we built in bluetooth
device in query object to performs two
basic services it will perform the
inquiries and notify you about devices
that are in range and discoverable as
well as part of the process it will
fetch the names of the duly discovered
devices now one big warning here and
this is the primary reason why this is
the first time we've introduced a
Bluetooth in query API is that warnings
that inquiries are definitely expensive
they take bandwidth away from other
other Bluetooth connections and they
have the potential to degrade 802 11
performance as well as interfere with
other 2.4 gigahertz wireless
technologies so it's really not
something that's designed to run all of
the time and just continue to really
look for other devices because it will
have a negative impact on
on other things going on now as a result
of this we've actually implemented
throttling support so that inquiries
will be throttled if they are tempted to
be performed for too long a period of
time now typically if you just need to
perform one or two to present the user
with a a list of devices in the area you
won't be affected by the throttling but
if you do try to just perform inquiry
over and over again over time the amount
of time that you'll be able to perform
an inquiry for will be decreased now the
Bluetooth device in query object is
fully asynchronous as well with full C
versions of the API available there's a
new header file that this API is now
available in the tiger seed there's a
new header file file I Bluetooth device
in career eh that has the full API so
basically what the device inquiry gives
you is more or less a full functionality
of the Bluetooth device selector minus
the UI of course so you should be able
to do everything that the Bluetooth
device selector does but embedded in
your own code now we still highly
recommend if you need to allow the user
to select a device or to provide the
user with a list of devices in range
that you actually use the built-in
Bluetooth device selector because it
really it provides a consistent user
experience across multiple applications
let's take a quick look at the API
itself class method to create a new
inquiry object now the a delegate is
required because the API is fully
asynchronous the delegate is needed to
provide the callbacks of when the
different different phases of the
inquiry are taking place you can control
the length of the inquiries through set
inquiry length you can control whether
the inquiry process will update the
device names or not now if you're
presenting them the list of the users
you will very likely want the inquiry
object to fetch a names for you there
are some restrictions depending on what
hardware you're running on on exactly
when the names can be fetched compared
to when the inquiry can run so we've
actually embedded all of that logic
knowing about what the hardware
capabilities are into this object so if
you use the capability or if you use the
name update facility you'll
automatically take advantage of all that
knowledge built-in then you also have
the expected to start and stop 14 to
start and stop the inquiry now being
curry will stop on its own when the
length of time that is supposed to be
running as hit has hit additionally once
you call start the inquiry might not
actually start immediately if the
throttling code has been engaged it may
take some amount of time before the
inquiry will actually begin because
there's a delegate and the API
asynchronous their number of delegate
methods that get called during various
stages of the inquiry so you get
notified when the inquiry is started
that way you can know the amount of time
between you call start and it actually
starts now if it can start right away
you might get the inquiry started
routine called immediately there's a
notification when a new device gets
found notification when the name update
process begins notification when the
names when each name is actually fetched
and then notification once the inquiry
is completed
so let's go ahead and take a look at
kind of a sample timeline and what's
going to go on when using the device and
query object so your application is
going to create a new one it's going to
go ahead and call start to start the
inquiry may be immediately maybe
sometime in the future you'll get the
device inquiry started notification at
that point the discovery process is
ongoing so for each device found you get
a result device in queried device found
that tells you the device address the
class of device so you know are you
talking with the keyboard are you
talking with the phone etc but at that
point you won't have the name unless the
system has previously fetched it and
cash the name once the actual discovery
process completes it will begin the name
discovery so at that point you get a
update device names tells you how many
devices are left to have their names
fetched and then during the name
discovery process you go ahead and get
notified each time a device name has
been fetched so that way one by one
you'll know exactly what the names are
for each device that have been
discovered and then finally you get the
inquiry complete when that's finished
another new API we've added entire is a
new OBEX file transfer services that's
the name of an object an objective-c
object in again in in tiger and the
tiger seed new header file for it what
it does is it provides a simplified API
on top of obex for kind of a generic
object exchange functionality basically
provides the raw implementation of the
object push profile and the file
transfer profile provides kind of all
the basic low-level file manipulation
primitive tease expect put and get
change directories fold their listings
manipulate the remote file system by
adding removing folders and files as
with the device in query object the file
transfer services object is fully
asynchronous with C versions available
so basically with this new API outside
of the UI you get the full functionality
of the bluetooth file exchange including
the object push and file transfer
services let's just take a quick run
through the API I'm not going to spend a
whole lot of time on X as a little more
detail than then the device inquiry but
you have the basic basic methods for
creating a new object with a know BEC
session again as with the inquiry object
it takes a delegate for all the
callbacks there's methods for accessing
the current stake and in current path
notifying whether the device whether the
connection is busy or not whether it's
connected API for connecting
disconnecting depending on what type of
service you're using connect to ftp or
connect to object push services as well
as then the disconnect operation api for
sending receiving files as well as then
the remote manipulation adding removing
folders and files changing directories
as well as on the capability to abort an
operation that's in progress and
retrieve the current folder listings
delegate methods again there's quite a
number of them there's basically a
completion for each action that can be
performed so for example when you tell
the API to connect to a service it's
going to go ahead and call the
connection complete method when it's
done pretty much the same for all of
these so there are a couple of things to
note here is the there to AP is for
actually transferring files for sending
and receiving each one of those contains
a transfer progress method as delegate
method as well as a transfer complete
method now the progress includes a
number of useful bits of information in
addition to to just the amount of data
that's been transferred and how much is
left it includes the elapsed time as
well as estimated time remaining and
instantaneous transfer rate calculations
so that should actually make it pretty
easy to wire that information into your
UI so let's just take a quick run
through a sample object push operation
you're going to create the new webex
file transfer services object then call
in this case connect to object push
service that's going to go ahead send a
message to the remote device to connect
up once that completes you get the
connection complete message if there was
an error you'll be notified at that
point once the connection is complete
it's ok to perform any of the operations
in this case since we're only using
object push send file is the only
facility that we have available to us so
we're going to go ahead call send file
then as the file transfers you'll
continuously at regular intervals gets
decent file progress with the transfer
progress so you can know exactly how far
the transfer is completed once that's
finished you go ahead and get a sense
file complete with the error code as
well so if an error occurred during the
time this is the notification that
you'll get once the transfer is complete
you actually have the option of you can
perform another operation or go ahead
and disconnect once the disconnections
finish to get this connection complete
met
so now let's move on to new Scotty API
that we've added in tiger now in Panther
we really had limited go support we did
have built-in support for Bluetooth
headsets but there was really no no api
to customize this go behavior or to tap
into the schoo functionality
additionally core audio was the only
means to access that data so that was
the only communication that any external
developer had with ASCO with a headset
or others go audio device and Tiger now
we're adding this newest go audio api
that really provides full control over
the schoo link so you control exactly
when the skull link is created it
provides an audio driver and ability to
configure exactly how that driver
appears so you can say exactly how many
audio controls are created you know does
it have a volume control does it have a
mute control what is the volume range
etc the new API supports both incoming
and outgoing connections so again which
you have control over so depending on
exactly what type of device you're
talking to what profile you're using you
can implement it exactly the way that's
intended as part of the API asko audio
driver is created but instead of having
as with panther all of the support for
communicating with headsets built-in it
just provides the audio i/o services in
as far as the api goes we've actually
split it here we have the I bluetooth
framework for all the standard Bluetooth
services so for example in the case of
the headset profile it needs to use an
RF comm channel to communicate with the
headset to indicate things like ring
button press volume changes etc so again
the Bluetooth framework is where you're
going to communicate over any of the
standard Bluetooth services then core
audio is the API to be used both for
audio i/o as well as to communicate with
the driver in terms of being notified
about
applications on the system wanting to
create an audio connection and being
able to control exactly when those go
links gets created and being formed of
any audio related errors the API itself
on the surface appears pretty simple
there's just two functions although it
does get a bit a bit more complex than
that there's a basic two functions I'll
bluetooth ads go audio device a
bluetooth removes go audio device the
add function basically will create ask
oo do driver for your device as part of
the API a configuration dictionary
parameter is provided and that's really
what it provides the core of the
customizable features in the Audio API
so it's that configuration dictionary
that allows you to specify exactly what
audio controls are created and how they
appear in the system specify behavior on
new connections among others now the
caller of this this API is responsible
basically to create any new Bluetooth
services so for example if the audio
support you're adding allows the device
to connect back up to the host you'll
very likely need to add a Bluetooth SDP
service record that matches the service
that you're providing so the device
knows exactly how to connect up and how
to talk to you additionally any non
schoo data again like l2cap RF com needs
to be handled by the client in this case
the system will not do it for you by
bluetooth remove school audio device API
simply will remove that driver from the
system so add functionality adds it
remove removes it it's basically up to
the client to do everything else
in addition of those new AP is we've
created a couple of new applications
that should help you develop
applications for Bluetooth applications
for Mac OS 10 that did a new packet
logger tool and Bluetooth Explorer
utility the packet logger is pretty much
a completely rebuilt version of the
previous package code or two application
with a lot of new functionality it's
actually really nice it helps a lot when
developing applications so it supports
multiple packet log windows the previous
application had only a single window
where you could either view the current
log of the system or one loaded and file
where the new one allows as many open
documents as you want we've added
improved decoding and searching support
so that the what you see in the packet
log is a little bit more for both it
provides a little more the information
that you're likely to need and then the
searching capabilities allows you to
quickly type in a particular block of
data that you're looking for whether
textually or using hex there's also a
couple of new data views in addition to
the decoded view like you're used to
seeing there's a raw view that provides
just the basic raw data if if that's the
way that you want to look at it if
that's what you're used to seeing you
can go ahead and see exactly what's
being sent received over the Bluetooth
link and it also provides a new flow
data view which kind of provides a
summary by connection exactly what
packets are on the system so basically
all of the kind of the connection and
disconnection event are summarized and
so you can choose what connection you're
interested in what l2cap channel what
our comm channel and it will defend
restrict the blocks the packets that it
listed those associated with that
channel we've added support for data
markers so if there are certain parts of
the log that you want to mark and come
back to later you can do that we
provided some additional auto backup
support previously in the packet to go
to or 2 applications it would
automatically assuming you choose to do
so it'll automatically save the current
packet log to disk
but every time you started and stopped
the decoder it would overwrite the
previous log so it's real easy to
accidentally lose an important log the
new this new packet logger application
will actually support multiple backup
files and won't overwrite the previous
one instead it will create a new one and
then finally this hopefully would be
helpful for a lot of people is that
there's no SDK required in order to run
the packet lager tool before you had to
install an SDK with a custom build of
the Bluetooth family text where now it's
just built in the logger tool itself
will just require authentication then
once you've authenticated you can go
ahead and capture Bluetooth data on any
system the other application we've added
this new Bluetooth Explorer utility
which provides kind of a snapshot of the
Bluetooth stack and the Bluetooth
hardware and provides active inquiry
information so if there's an ongoing
inquiry it will show exactly what
devices are in the area and the relevant
information about them it provides
detailed information about the hardware
on your system including all of the
Bluetooth features that it's a core two
device address specific versions of the
various Bluetooth technology that it
implements etc we've added new support
for the device cash being managed so you
can actually view the current cash
devices on the system as well as delete
them there's also a panel that allows
you to switch between multiple
controllers so if you have a built-in
Bluetooth module and say you have an
external one that you want to test out
to make sure it works with your hardware
for example you can simply insert that
go to the the root tooth controller set
up and switch to that module in the
system will just automatically switch
over to using it then finally there's a
connection monitor functionality which
basically is the old Bluetooth monitor
application just integrated into the new
Bluetooth Explorer so I'd like to one
bite one of the bluetooth software
engineers
some gels up here to go ahead and demo
some of the new applications for you
thanks Eric so let's check out these
applications that are to just talked
about I can I get demo one okay so the
first one like this show is the
Bluetooth Explorer application this
application has a recognition was a
reworked a Bluetooth monitor and we've
added a whole bunch of new features that
we think will help make your developing
lives easier so first thing I'd like to
show us the local device information
panel and as you can see here you get a
snapshot of the hardware that is
currently in use in the Bluetooth system
and as you can see it has the general
hardware information including the
device address the manufacturer of the
part hgi and LMP version information as
well as the Bluetooth specification
hardware features such as three slot
panic packets attachment so as you can
see the black the ones in black are the
ones that are supported on this
particular run a dongle the ones in gray
are not supported I'm afraid a different
dongle you probably see different
attributes highlighted how we also have
via version easily accessible for you so
if you're going to send us a bug report
we highly recommend that you send us the
the stack version because that really
really helps us determine what exactly
is going on in the system this panel or
this tab is the class of device tab this
is a representation of how other devices
sees your computer so you can see it has
what services it has or what device
class it shows so typically the
Bluetooth system automatically
determines where the major and minor
device class and services or on your
system but if you had a need to not a
spoof a different kind of device on a
computer like let's say you wanted this
computer to be a cellular phone you
could just select phone and choose what
type of phone for the minor class now if
you set that class of device on the
system all other devices your phones
other computers would see this computer
as a phone so that's an interesting
thing that might be useful to you if you
have that needs
finally there's a services tab but it
shows you the installed services on the
Bluetooth system so on this system we
have the Bluetooth PDA sync service as
well as the OBEX object press service if
you're installing your own service on
the system now it would show up in this
panel if it does not show up here it's
probably not installed correctly and the
system the Bluetooth system is not
seeing that service and you should
revisit your code and check for errors
so the next thing we've added is a HDI
controller selector and this allows you
to actually have multiple Bluetooth
hardware dongles installed on your
machine and you could use different ones
if you wanted to test your software out
with different vendors hardware so in
this this particular system i have set
up a broadcom donegal as well as a csr
donegal as you can see over here we're
currently using the broadcom dongle if
we switch to the csr one and make that
active this is an administration
operation so does it requests or ask for
your password type that in go over to
refresh as you can see now we're using
the csr part to do Bluetooth activity
this is not persistent if you restart
your machine they will reset itself to
the default HDI controller and you will
have to go back here it's just like a
different one so there's other things
than the bridge ative explorer offers we
invite you to check it out on the Tigers
seat so the next one I like to show is
the packet lager and you'll notice on
launch the first thing it asks you is to
authenticate and that is because it
doesn't require the SDK anymore but it
does require administration access to
get to the data so here we have a live
packet decoder window and if we go over
to the preferences file preference
system preferences panel it generates
some breakthroughs traffic there you see
and so here we have 13 packets and there
we go no SDK build and we've received
the tooth packets
so i say i'm going to show you is a file
that i've recorded doing an ftp transfer
from a mobile phone to your computer and
as Eric pointed out there's three new
three views to the pack and lager window
now known as the Dakota view the flow of
you and the raw of you so if we were
interested in seeing let's say this SD
SD p package here as it relates to other
pieces of the system we could go over to
the flow view and see that here at all
here's the SDP information packets that
have been sent and received this is the
one that I selected and here it shows
its relation to the l2cap layer and so
these these packets were generated based
on this connection response and this
connection in else your cap and then we
can keep going back further and see that
all this l2cap traffic was generated
based on this HDI connection this is
great when you have multiple connections
to different devices in the same packet
more even to the same device for example
in this case we have on the device we've
requested SDP information but we've also
in a different connection done RF column
traffic and then you can even go into
this honor of chrome connection for
example on channel 7 and note that these
are all the packets that were
transferred over this channel and then
finally we have the raw of you so if I
was interested in this packet here and
seeing what the raw bytes were sent /
received to and from the Bluetooth hard
work I can switch to the raw of you and
see the actual bytes that were since
so now I'd like to demonstrate the
markers capability that we have added
clicking the M button brings up the
markers panel and as you can see here
yeah I've already established two
markers in this file the first ftp
folder listing we can go to that that
packet to be received there and this
takes us right to where we want to to
basically like bookmarks in your logs
that show you interesting places or so
other developers interesting places if
you send us a packet log to look at we
would love for you to put in markers
that you've specified to enables us to
go quickly to where you think there's a
problem so will notice that the RF com
data is not being decoded at this point
as OBEX this is no vex transfer so if i
open up the filters of view we can
change all of the RF com data on channel
7 to be OBEX decoded and you'll notice
that the view is refreshed and if we go
back to our our marker we can see that
the packet that we were showing before
is now decoded odex and if we twist that
down we can see that we send the type
header and a connection ID header the
next marker has set as the first get jpg
command that we send to actually receive
a file to request a file from the ftp
server that we've connected to so for
example you received a connection
infused or request refused or bad
request error you could actually twist
this down and see okay here's my request
that actually sends out there's the
picture of three that we file that we
requested in the connection ID if
something was wrong we could see that oh
you know we didn't send the name
properly or something like that we can
also see that yeah the data is embedded
throughout the whole boo to stack so for
example this is an obex packet and we
can see that the RF com packet is right
here and we can look at the details of
that are calm packet and then from there
we can go into the l2cap all the way
down to the ACL later
so you can see all of the data top to
bottom and really quickly another thing
is that we've added is a fine panel so
if you're interested in a particular
command that you sent like let's say and
OBEX command disconnect because you
suspect there's something wrong with the
disconnect this will bring up all the
packets that are related or that have
that search the search keywords you can
do an operator if it's not a keyboard
characters as well if you put in an or
character or an and character you can
actually do hand or switches so if you
click on this feet are quickly taken to
the appropriate packet if we wanted to
add a marker to that particular packet
for someone else to see over here and we
this is the description field we can put
in a description this is the effect
you're going to have that marker and now
once we save the changes into our
document other you can go quickly back
refer quickly back to that spot at any
time lastly I'd like to show you is the
inspector panel this is a very simple
way for you to look at the top down data
structure as well so you could either
twist down through the layers or if you
can or you could just select any
particular packet and see the data from
top to bottom starting with obex color
coded into our comm and then l3 cache
and finally ACL and then here at the
bottom we have the raw data on decoded
for you to look at so those are the two
applications we hope that they make your
bluetooth development lives a little
easier and right
[Applause]
thanks Jason
let's go ahead and move on to the next
topic I want to talk about asynchronous
application design it's kind of a
mouthful and it it actually a little bit
more than that when you actually go to
try and design an application using
asynchronous API so it definitely can
cause some confusion among developers
and is a little bit tricky to get right
at times so to go ahead basicness API
basics so all asynchronous asynchronous
operations use callbacks typically the
callback will be made when the operation
completes seems pretty obvious but it
isn't always and the documentation isn't
always totally clear about that
additionally the callback that gets made
as a result of a particular operation
may actually be called after that
operation returns that's what actually
causes a lot of the trouble when
developing an application using these
types of AP is a lot of times you want
to execute a number of operations
synchronously that typically disco
execute them one right after another on
the same block of code unfortunately now
that the first operation might not
complete until after the initial
function returns you now have to go and
move that second call into the callback
for the first and then maybe move the
third call into the callback from the
second all of the Bluetooth operations
have asynchronous versions additionally
some of our API is especially just a
couple of new ones that we saw today the
device inquiry and obex file transfer
services are only asynchronous so you're
pretty much forced to actually develop
your application that way an additional
note here is that the a Bluetooth
framework is not thread-safe so you
can't just simply fire off another
thread to go ahead perform the
asynchronous operation do you know 1 2 3
etc because all of the Bluetooth calls
must be made from the same threat
so you know why why do we even create
these eggs are going to safety eyes and
why should you use them well primarily
Bluetooth itself is asynchronous we send
the command then we have to wait for the
device to respond both the local
hardware and the remote device so our
implementation really is based on that
design that's how it works additionally
and many times it can be less complex
than using multiple threads there's no
locking to worry about you don't have to
deal with multithread issues like that
and it's really similar to the cocoa
delegate model so a lot of you that have
done cocoa work it should be very
familiar so it's definitely a number of
pros and cons associated with it on the
pro side the operations don't block so
your UI doesn't lock up it provides for
very you know much better user
experience when doing those things the
user doesn't click a button and then
wait wait wait watching the cursor spin
as some long-running operation takes
place it also provides the developer
with the ability to implement you I that
allows a user to cancel the operations
so it's a lot more user-friendly in that
way unfortunately while asynchronous
design can make it simpler and that you
you know don't have the multiple thread
issues and also can be more complicated
because the sinker the sequential
operations that you might want to do
can't be all implemented at once let's
take a look at basically some sample
asynchronous behavior kind of what goes
on within the Bluetooth stack so what
first happens is based on the first call
into the Bluetooth framework the
Bluetooth framework itself will create a
number of rum loop event sources to
handle the asynchronous callbacks from
the various parts of the system the
colonel and the demon the blue d process
so go ahead and create those realm of
event sources now one thing to note here
is that the
run loop for the thread that first calls
into the stack is the run loop that will
be used for all of the asynchronous call
backs so that thread has to have a run
loop run on it after the Bluetooth calls
are made and that from that point on
it's the only thread that you can make
calls into the Bluetooth stack so none
of the other threads can actually make
the calls now you might try it and it
might work but it's not guaranteed to
work there's no locking in there it's
very you know easy for multiple threads
to step one on one another and have
really unpredictable results an
additional note is that if you're
performing you I operations through the
Bluetooth UI framework that only the
main thread can be used to the meikle
Bluetooth calls now that's because the
typically all the UI operations have to
occur on the main thread so let's take a
look a little more detail about a how a
Bluetooth connection operation will work
within this model so the first thing
that happens is your applications just
going to call bluetooth device open
connections it's going to pass himself
for the callback so that's going to go
into the Bluetooth framework at that
point the framework is going to turn
around and make a call into the kernel
to go ahead and perform that connection
operation so makes a call down to the
colonel the board now we're still on the
original thread although it's executing
in the colonel the colonel is going to
go ahead and take a look at the callback
information provided by your client it's
going to go ahead and then store that
away so that when the operation actually
completes it knows what who made the
call and who needs to get notified at
that point depending on the state of the
system the colonel may actually send the
HCI command to create the connection or
it might chew it up for later depending
on if the hardboard Izzy or not so in
this case we'll go see it sends the
command
and then at that point this particular
operation is done the client thread is
going to return your run loop is going
to be free to run process user events
etc so the system is just now waiting
for this operation to complete if you
have a UI application the user is free
to go ahead and perform other tasks once
the operation is complete we'll actually
see the command complete event coming in
from the device this gets run the the
call back into the kernel is done on a
kernel thread so I'll see the hardware
notified the kernel with the command
complete event at that point the colonel
says okay let me try and find to see if
there was a an asynchronous call that
did the original connection so it's
going to go ahead look up the callback
information this case it finds
information about our client application
so it knows exactly which application
made the call and which needs to call
back at that point the colonel will then
just send a message to the framework in
the application using that realm of
event source that was created at this
point the colonel is done the colonel
thread is finished is off doing other
things the application thread now the
run loop event source we'll go ahead and
receive the kernel message the framework
will extract the callback information
and then just call the original caller
notifying it that the command has
completed now that seems pretty simple
but there are definitely a number of
design considerations that need to keep
in mind so for example when you have
multiple operations to perform your
application really is to keep track of
it may do multiple things at once need
to know exactly what's outstanding be
able to deal with errors that come up at
any time if there are future operations
that it needs to perform wants a certain
events complete it needs to keep track
of exactly what it needs to do next so
depending on exactly what you're doing
you may need to implement some kind of
queuing mechanism or state machine to
keep track of what's going on and what
should be done next that's really where
the complexity comes in
an additional point to note is that your
UI will be active while the operation is
pending so the user is free to go ahead
and perform any operation that's
available to them as a result it's
really recommended that you disable any
controls that shouldn't be accessed
while this particular operations
outstanding we also really recommend
that you provide some kind of status and
potentially a progress notification that
a particular operation is going on as
well and then as much as possible
providing you I to be able to cancel an
operation that may be long-running
really is a lot more friendly to the end
user then lastly really pay attention to
the error codes they are definitely
there for a reason all of the Bluetooth
API returns error codes all the callback
include error codes typically if the
nares returned from an api call itself
it means that the operation that the
callback itself will not be called that
the operation failed during the initial
phase if you get an error in the call
back again it usually means that that
operation failed to complete so if you
had the next operation that depended on
the first one completed successfully you
don't want to call that because it won't
succeed either now there may be some
exceptions to those there are a couple
of error codes that actually indicate
success but the system may be in a state
other than what was expected in those
cases those codes will be documented so
now we've got a number of avenues that
you can go to for more information our
technology evangelist is Craig Keithley
and he is pretty much the main contact
for any developer relations issues as
well as going through just the standard
developer support we've also provided a
Bluetooth developer mailing list that
you can get to anybody on I believe any
ADC member is is free to join the
developer mail list all right Craig okay
well anybody can join the mailing list
and it's it kind of the traffic comes
and goes but feel free to join look at
the traffic going on see what kind of
questions people are asking feel free to
ask your own the Bluetooth engineers of
Apple we do monitor that lists regularly
we don't always have we can't guarantee
that we're going to be able to respond
to every question but you know we do try
to pay attention and answer where we can
also got sample code and documentation
written as well so there's working with
Bluetooth devices documentation
Bluetooth device access and Bluetooth
user interface that are all in the
installed Tiger documentation