November 2002 - Bluetooth-dev

Total Newbie Looking for Documentation on Bluetooth + T68i
by John Cleary Design 19 Nov '02

19 Nov '02

Hi there, I'm totally new to this bluetooth stuff, but am working on an app i'd like to implement it for, and was wondering if you know where i'd best be looking for documentation on things such as sending SMS messages via the phone, showing incoming calls, etc. - i.e. the stuff the address book does at the moment ;) Also, is there a listing somewhere of what info in the phone can be accessed and pulled into the computer? Specifically I'm using a T68i Ericsson, Dlink Bluetooth adapter and Mac OSX 10.2.2. Thanks a lot, John Cleary -- Sent from the PowerMac G4 of John Cleary jcdesign(a)mac.com http://jcleary.dyndns.org Melbourne, Australia -- _______________________________________________ bluetooth-dev mailing list | bluetooth-dev(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/bluetooth-dev Do not post admin requests to the list. They will be ignored.

1 0

Re: Objective C API Broken?
by Eric Kolotyluk 19 Nov '02

19 Nov '02

Thanks, that did the trick. Cheers, Eric K On Saturday, November 16, 2002, at 07:04 PM, Marco Pontil wrote: > Hi Eric, > > You are correct, replace: > > if (([discoverer discoverWithDeviceList:nil serviceList:serviceArray > serviceRecord:&serviceRecord] == kIOReturnSuccess) && > > with: > > if (([discoverer discoverWithDeviceAttributes:nil > serviceList:serviceArray serviceRecord:&serviceRecord] == > kIOReturnSuccess) && > > and everything should be o.k. > > ... Marco > > > > On Thursday, November 14, 2002, at 02:25 AM, Eric Kolotyluk wrote: > >> I make a copy of the RFCOMMClientSample and commented out the line in >> ChatBluetoothInteface.h >> >> #DEFINE USE_C_API >> >> and built and ran the project but got warnings at compile time and >> errors at run time >> >> 2002-11-14 02:14:55.741 RFCOMMClientSample[1955] *** >> -[IOBluetoothConcreteServiceBrowserController >> discoverWithDeviceList:serviceList:serviceRecord:]: selector not >> recognized > _______________________________________________ > bluetooth-dev mailing list | bluetooth-dev(a)lists.apple.com > Help/Unsubscribe/Archives: > http://www.lists.apple.com/mailman/listinfo/bluetooth-dev > Do not post admin requests to the list. They will be ignored. _______________________________________________ bluetooth-dev mailing list | bluetooth-dev(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/bluetooth-dev Do not post admin requests to the list. They will be ignored.

1 0

Re: Public API for Bluetooth Inquiry
by Eric Brown 19 Nov '02

19 Nov '02

On Sunday, November 17, 2002, at 03:33 PM, Paul Davis wrote: Eric, I put some time into this and would like your opinion on my conclusions: 1. I looked into using the IOBluetoothPairingController class as a means for obtaining the device name. The runPanelWithAttributes works fine however it returns nothing. Therefore, it's not very useful. That would be a problem, wouldn't it. It will be fixed in the next dev release. 2. Next I used IOBluetoothDeviceSelector class. The runPanelWithAttributes returns a pointer to an IOBluetoothDevice with all the salient information pertaining to the selected device from the GUI. This is extremely useful. I'm having some trouble extracting the details of the Service Record but I won't burden you with questions until I have spent more time on this. Let us know how it turns out. There should be API to do everything you need. 3. After thinking more about this, the API Apple is working on that will give access to the list of paired devices would be useful. Probably a better method in lieu of public inquiry API. That sounds good - especially if you require the device to be paired to use. 4. I can't get the getRFCOMMChannelID method in the IOBluetoothSDPServiceRecord class method to work. It always bombs and was hoping you could comment. Are there are issues with this method? Is the app crashing or is it throwing an uncaught objc exception? The code does have a couple of holes in the case where the ProtocolDescriptorList attribute is improperly formatted. It checks the first UUID in each sequence in the ProtocolDescriptorList for the RFCOMM UUID. Then it assumes that the sequence has a second element and attempts to get the RFCOMM channel ID from it. So if one of the sequences has no elements or if the first element is the RFCOMM UUID and there is no second element, it will cause an exception to be thrown. That's a bug and we'll fix it. But it should work properly if the ProtocolDescriptorList is formatted correctly. - Eric _______________________________________________ bluetooth-dev mailing list | bluetooth-dev(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/bluetooth-dev Do not post admin requests to the list. They will be ignored.

1 0

Re: Public API for Bluetooth Inquiry
by Paul Davis 17 Nov '02

17 Nov '02

On 11/16/02 2:29 PM, "Eric Brown" <esb(a)apple.com> wrote: > > On Saturday, November 16, 2002, at 07:29 AM, Paul Davis wrote: > >> To whom it may concern: >> >> I know you have discussed this topic in recent threads but I would >> like to >> add my 2 cents. I spent 2 days reading your Bluetooth API documentation >> trying to figure out how to do an inquiry without the GUI. >> >> The application I am working on will involve using an OBEX connection >> to >> send data between client and server. I absolutely do not want the user >> to >> have to choose the device/service record in order for this to work. I >> will >> probably require the user to pair devices initially. However, after >> this my >> design requirement is to simply find the device and verify the service >> I >> need is available using SDP query. The user will not be aware of this >> activity. >> > > If you do require the user to pair, you can easily use the pairing > panel we provide (IOBluetoothPairingController) and then save off the > user's selection. We're also adding API to access the list of paired > devices so once that is in place, you could still find the device you > are interested in if the user used the pairing panel in the pref pane. > > One problem with attempting to dynamically detect devices is that > performing an inquiry is a somewhat expensive and intrusive process. > Depending on what hardware is in use, connections can be completely > interrupted while the inquiry is in progress. Doing one while the user > isn't expecting it could be annoying at best. > > Even if you have the user initiate the discovery process and then > perform SDP queries on each device to find the one (more than one?) > that has the service you are interested in, that process could be > rather lengthy if there are many discoverable devices around. It gets > even longer if any of the devices don't respond to the page/connection > process. With failed connections taking anywhere from 15 to 45 > seconds, a discovery process like this in a dense environment could > easily run into several minutes. > >> In summary, the quicker I can have access to the inquiry API, the >> better. >> Any chance you can give a more definitive date addressing when the >> stack >> will be released with the inquiry API? >> > > Unfortunately I can't comment on upcoming releases at this time. > > - Eric > Eric, I put some time into this and would like your opinion on my conclusions: 1. I looked into using the IOBluetoothPairingController class as a means for obtaining the device name. The runPanelWithAttributes works fine however it returns nothing. Therefore, it's not very useful. 2. Next I used IOBluetoothDeviceSelector class. The runPanelWithAttributes returns a pointer to an IOBluetoothDevice with all the salient information pertaining to the selected device from the GUI. This is extremely useful. I'm having some trouble extracting the details of the Service Record but I won't burden you with questions until I have spent more time on this. 3. After thinking more about this, the API Apple is working on that will give access to the list of paired devices would be useful. Probably a better method in lieu of public inquiry API. 4. I can't get the getRFCOMMChannelID method in the IOBluetoothSDPServiceRecord class method to work. It always bombs and was hoping you could comment. Are there are issues with this method? Thanks, Paul Davis _______________________________________________ bluetooth-dev mailing list | bluetooth-dev(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/bluetooth-dev Do not post admin requests to the list. They will be ignored.

1 0

Re: Objective C API Broken?
by Marco Pontil 17 Nov '02

17 Nov '02

Hi Eric, You are correct, replace: if (([discoverer discoverWithDeviceList:nil serviceList:serviceArray serviceRecord:&serviceRecord] == kIOReturnSuccess) && with: if (([discoverer discoverWithDeviceAttributes:nil serviceList:serviceArray serviceRecord:&serviceRecord] == kIOReturnSuccess) && and everything should be o.k. ... Marco On Thursday, November 14, 2002, at 02:25 AM, Eric Kolotyluk wrote: I make a copy of the RFCOMMClientSample and commented out the line in ChatBluetoothInteface.h #DEFINE USE_C_API and built and ran the project but got warnings at compile time and errors at run time 2002-11-14 02:14:55.741 RFCOMMClientSample[1955] *** -[IOBluetoothConcreteServiceBrowserController discoverWithDeviceList:serviceList:serviceRecord:]: selector not recognized _______________________________________________ bluetooth-dev mailing list | bluetooth-dev(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/bluetooth-dev Do not post admin requests to the list. They will be ignored.

1 0

Re: Public API for Bluetooth Inquiry
by Eric Brown 16 Nov '02

16 Nov '02

On Saturday, November 16, 2002, at 07:29 AM, Paul Davis wrote: To whom it may concern: I know you have discussed this topic in recent threads but I would like to add my 2 cents. I spent 2 days reading your Bluetooth API documentation trying to figure out how to do an inquiry without the GUI. The application I am working on will involve using an OBEX connection to send data between client and server. I absolutely do not want the user to have to choose the device/service record in order for this to work. I will probably require the user to pair devices initially. However, after this my design requirement is to simply find the device and verify the service I need is available using SDP query. The user will not be aware of this activity. If you do require the user to pair, you can easily use the pairing panel we provide (IOBluetoothPairingController) and then save off the user's selection. We're also adding API to access the list of paired devices so once that is in place, you could still find the device you are interested in if the user used the pairing panel in the pref pane. One problem with attempting to dynamically detect devices is that performing an inquiry is a somewhat expensive and intrusive process. Depending on what hardware is in use, connections can be completely interrupted while the inquiry is in progress. Doing one while the user isn't expecting it could be annoying at best. Even if you have the user initiate the discovery process and then perform SDP queries on each device to find the one (more than one?) that has the service you are interested in, that process could be rather lengthy if there are many discoverable devices around. It gets even longer if any of the devices don't respond to the page/connection process. With failed connections taking anywhere from 15 to 45 seconds, a discovery process like this in a dense environment could easily run into several minutes. In summary, the quicker I can have access to the inquiry API, the better. Any chance you can give a more definitive date addressing when the stack will be released with the inquiry API? Unfortunately I can't comment on upcoming releases at this time. - Eric _______________________________________________ bluetooth-dev mailing list | bluetooth-dev(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/bluetooth-dev Do not post admin requests to the list. They will be ignored.

1 0

Public API for Bluetooth Inquiry
by Paul Davis 16 Nov '02

16 Nov '02

To whom it may concern: I know you have discussed this topic in recent threads but I would like to add my 2 cents. I spent 2 days reading your Bluetooth API documentation trying to figure out how to do an inquiry without the GUI. The application I am working on will involve using an OBEX connection to send data between client and server. I absolutely do not want the user to have to choose the device/service record in order for this to work. I will probably require the user to pair devices initially. However, after this my design requirement is to simply find the device and verify the service I need is available using SDP query. The user will not be aware of this activity. In summary, the quicker I can have access to the inquiry API, the better. Any chance you can give a more definitive date addressing when the stack will be released with the inquiry API? Paul Davis _______________________________________________ bluetooth-dev mailing list | bluetooth-dev(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/bluetooth-dev Do not post admin requests to the list. They will be ignored.

1 0

Fwd: Understanding SDK
by Eric Brown 15 Nov '02

15 Nov '02

This never seemed to show up on the list, so I'm re-sending it. - Eric Begin forwarded message: From: Eric Brown <esb(a)apple.com> Date: Thu Nov 14, 2002 8:54:06 PM US/Pacific To: Eric Kolotyluk <eric(a)sfu.ca> Cc: bluetooth-dev(a)lists.apple.com Subject: Re: Understanding SDK On Wednesday, November 13, 2002, at 09:09 PM, Eric Kolotyluk wrote: Well, if you could release the source for IOBluetoothUIUserLib, that would go a long way to understanding how to use the stack and SDK libraries - or do these library routines call nonpublic APIs like the Inquiry code? Correct... in addition, the UI functions are really part of our proprietary code, so it isn't likely that we'll release the source at this time. I guess I was wondering if I wanted to write an app without a GUI, how I would find devices without using the various service and device selector panels? But what you're saying is that "Apple have create GUI based utilities for inquiring about remote devices." Again, correct... however that doesn't mean that the inquiry routines will be private forever. If you have a specific need that isn't covered by the UI library (or the standard library), please let us know. We want to make sure that you can do everything you need to, but in a safe, organized manner that is guaranteed not to interfere with other applications. One of the considerations that we've had regarding releasing the Inquiry functions is that typically you want more than just the inquiry results. If the user is going to be involved at all, you will also likely need the device name as well as possibly some SDP information. The problem is that all of that information isn't immediately available. In that case, there are various ways that the developer can choose to implement the UI. We've tried to make that whole experience as painless, efficient and consistent between applications as possible for the end user. Additionally, we've seen different HCI controllers that have different capabilities when it comes to performing some of these activities simultaneously. Some hardware lets you do more at once, while others make you wait one at a time. By keeping all of that logic and UI management code internal, we can optimize it as best as possible for the various hardware devices while insulating you, the developer from having to know anything about the hardware capabilities. By cover functions do you mean that the C API can be used instead of the objc API or are the C routines needed in addition to the objc API? On the other hand can I stay entirely in the objc API for the most part? The C API can be used instead of the objc API. Most of the C functions are actually wrappers for the objc equivalents. In most cases, the documentation has carried over from the objc routines to the C functions, but for the class-level descriptions, the objc headers (and headerdoc) typically has more information. So even if you are only using the C API, the objc headerdoc might provide you with more information. Thanks for your clarifications. Eric If you have specific, or more directed questions about how things work or are organized, please post them here. I'd be happy to provide more guidance on how the libraries are intended to be used. - Eric On Wednesday, November 13, 2002, at 06:49 PM, Eric Brown wrote: On Wednesday, November 13, 2002, at 06:23 AM, Eric Kolotyluk wrote: I've been spending the last couple of days trying to follow the RFCOMMClientSample applications in the Bluetooth Examples directory, but cannot find the source for IOBluetoothUIUserLib. In particular, the examples are incomplete without access to the source of procedures like IOBluetoothServiceBrowserControllerCreate. Is the source for IOBluetoothUIUserLib buried somewhere in the SKD, or can it be made available for study? This would help in trying to understand the SDK. Those are all library routines for which we do not supply source. Its the same as say NSOpenPanel. Also, are there any plans to release some more comprehensive design or architectural documentation on the SDK, perhaps a developers guide? That is definitely in the plans. For now, the best source of information is the headerdoc. Especially the objc class descriptions. There should be quite a bit of information about the individual classes in there. For the most part, the C API provides cover functions for the objc objects and methods. Finally, there do not seem to be any services for directly invoking an Inquiry of remote devices. Can I assume that this is a function of the underlying O/S? It's not clear how I actually discover what other remote devices are out there - is it via the local discovery services? That's that's why it would be nice to see the source code for IOBluetoothUIUserLib. Currently, there is no public API for performing inquiries. Do you need functionality beyond what is in the various service and device selector panels? - Eric _______________________________________________ bluetooth-dev mailing list | bluetooth-dev(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/bluetooth-dev Do not post admin requests to the list. They will be ignored. _______________________________________________ bluetooth-dev mailing list | bluetooth-dev(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/bluetooth-dev Do not post admin requests to the list. They will be ignored.

1 0

Fwd: Understanding SDK
by Eric Brown 15 Nov '02

15 Nov '02

This never seemed to show up on the list, so I'm re-sending it. - Eric Begin forwarded message: From: Eric Brown <esb(a)apple.com> Date: Thu Nov 14, 2002 5:21:42 PM US/Pacific To: Eric Kolotyluk <eric(a)sfu.ca> Cc: bluetooth-dev(a)lists.apple.com Subject: Re: Understanding SDK What are you trying to do? IOBluetoothUIUserLib.h provides API for using the standard device and service selector panels. The routines that the panels use to do the inquiry is not currently public. Do you need to do something other than allow the user to select a device or service? - Eric On Wednesday, November 13, 2002, at 08:40 PM, Eric Kolotyluk wrote: Michael, I've reviewed IOBluetoothUIUserLib.h extensively, but it is just not useful. What I need is IOBluetoothUIUserLib.c (or whatever it is). I need the cake, not the icing ;-) Thanks anyway. Cheers, Eric On Wednesday, November 13, 2002, at 06:48 PM, Michael Larson wrote: The file should be at: /System/Library/Frameworks/IOBluetoothUI.framework/Versions/A/ Headers/IOBluetoothUIUserLib.h Is it not at that path on your System? -larson On Wednesday, November 13, 2002, at 06:23 AM, Eric Kolotyluk wrote: I've been spending the last couple of days trying to follow the RFCOMMClientSample applications in the Bluetooth Examples directory, but cannot find the source for IOBluetoothUIUserLib. In particular, the examples are incomplete without access to the source of procedures like IOBluetoothServiceBrowserControllerCreate. _______________________________________________ bluetooth-dev mailing list | bluetooth-dev(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/bluetooth-dev Do not post admin requests to the list. They will be ignored. _______________________________________________ bluetooth-dev mailing list | bluetooth-dev(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/bluetooth-dev Do not post admin requests to the list. They will be ignored.

1 0

Re: Understanding SDK
by Bubba Giles 15 Nov '02

15 Nov '02

Hi Eric, > Well, if you could release the source for IOBluetoothUIUserLib, that > would go a long way to understanding how to use the stack and SDK > libraries - or do these library routines call nonpublic APIs like the > Inquiry code? We have not released any public API to do inquiries. When we release public APIs we are forced to support them forever. We could not get this API finished in time with the needed polish to be able to support it now and forever. We figured 99% of the cases out there would be happy with the panels we provide, and so far this has been found to be true. Also, I'm not really sure giving you the source to that file would go far in helping you understand the stack, and would only make it worse for us because we could not change the underpinnings without worrying about breaking some code that you wrote based on assumptions made by reading the code. Finally, the panels really only return you a Bluetooth device or service representation, so even if you could look at that code, it isn't going to tell you how to use the stack with those objects, which is really what you are trying to do. You'd still need to read the headerdoc and look at the samples to see how those objects are used to communicate over Bluetooth. If you have specific questions about how to get started using one of these objects, etc. please let us know and we'll try and help as much as possible. It also would help to know a little about what you are trying to accomplish in your project and what protocol you intend to use (OBEX, RFCOMM, L2CAP, etc.). > I guess I was wondering if I wanted to write an app without a GUI, how > I would find devices without using the various service and device > selector panels? But what you're saying is that "Apple have create GUI > based utilities for inquiring about remote devices." You are correct - you could not do it. You will need to display a panel at some point for the user to select a device/service. Unless you wanted to use the raw device address, which is less than optimal. We do hope to release an API to do this. If the lack of this API this is absolutely prohibitive to what you are trying to do, let us know and we'll escalate its importance on the to-do list. > By cover functions do you mean that the C API can be used instead of > the objc API or are the C routines needed in addition to the objc API? > On the other hand can I stay entirely in the objc API for the most part? What he meant was that we have written pretty much everything in objc, and that we have put a C convenience wrapper around it. So, you should be able to do everything with the Bluetooth stack in pure C or objc, and never have to mix the two. If you find this is not the case, please let us know so we can fill the gap. I hope that helps clarify a few things, Jason bubba(a)apple.com > > On Wednesday, November 13, 2002, at 06:23 AM, Eric Kolotyluk wrote: > >> I've been spending the last couple of days trying to follow the >> RFCOMMClientSample applications in the Bluetooth Examples directory, >> but cannot find the source for IOBluetoothUIUserLib. In particular, >> the >> examples are incomplete without access to the source of procedures >> like >> IOBluetoothServiceBrowserControllerCreate. >> >> Is the source for IOBluetoothUIUserLib buried somewhere in the SKD, or >> can it be made available for study? This would help in trying to >> understand the SDK. >> > > Those are all library routines for which we do not supply source. Its > the same as say NSOpenPanel. > >> Also, are there any plans to release some more comprehensive design or >> architectural documentation on the SDK, perhaps a developers guide? >> > > That is definitely in the plans. For now, the best source of > information is the headerdoc. Especially the objc class descriptions. > There should be quite a bit of information about the individual > classes in there. For the most part, the C API provides cover > functions for the objc objects and methods. > >> Finally, there do not seem to be any services for directly invoking an >> Inquiry of remote devices. Can I assume that this is a function of the >> underlying O/S? It's not clear how I actually discover what other >> remote devices are out there - is it via the local discovery services? >> That's that's why it would be nice to see the source code for >> IOBluetoothUIUserLib. >> >> > > Currently, there is no public API for performing inquiries. Do you > need functionality beyond what is in the various service and device > selector panels? _______________________________________________ bluetooth-dev mailing list | bluetooth-dev(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/bluetooth-dev Do not post admin requests to the list. They will be ignored.

1 0