This never seemed to show up on the list, so I'm re-sending it. - Eric Begin forwarded message: From: Eric Brown <esb@apple.com> Date: Thu Nov 14, 2002 8:54:06 PM US/Pacific To: Eric Kolotyluk <eric@sfu.ca> Cc: bluetooth-dev@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@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@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.