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