Apples for Christmas

[Vlad Skarzhevskyy]

Hi BlueCove users
I'm holding off the BlueCove 2.0.2 release until Christmas. There
was not many changes and no critical defects since 2.0.1 so release
can wait. If you need the changes
(http://code.google.com/p/bluecove/wiki/Changelog) in your project you
can always get working version from Nightly Build. Windows code is
pretty stable and I'm doing regression tests after every significant
change.

As I expect for Christmas we will get a new OS X platform support for
BlueCove. I started OS X development base on Eric Wagner code and with
consultation by Bea Lam (http://lightblue.sourceforge.net/)
The major discovery that I made is that OS X can work nicely on Intel
platform and I was able to afford the purchased a box for testing. I
will use Intel as development platform for OS X but the build result
would support Power PC as well. OS X is one more UNIX after all with
proper documentation for Bluetooth API so the task for creating native
interfaces is achievable....

BlueCove will support OS X 10.4 and newer.

--
Vlad

PS
Once again I would like to express my gratitude to Bea Lam for giving
positive feedback on my OS X efforts.

[Robert Brewer]

On Nov 12, 8:27 pm, "Vlad Skarzhevskyy" <skarzhevs...@gmail.com>
wrote:

> As I expect for Christmas we will get a new OS X platform support for
> BlueCove. I started OS X development base on Eric Wagner code and with
> consultation by Bea Lam (http://lightblue.sourceforge.net/)
> The major discovery that I made is that OS X can work nicely on Intel
> platform and I was able to afford the purchased a box for testing. I
> will use Intel as development platform for OS X but the build result
> would support Power PC as well. OS X is one more UNIX after all with
> proper documentation for Bluetooth API so the task for creating native
> interfaces is achievable....
>
> BlueCove will support OS X 10.4 and newer.

That's great news! I eagerly await the OS X port, so I can use
BlueCove on both OS X and Windows instead of having to use Avetana on
OS X.

[extra...@gmail.com]

yeah this is great news!
I'm here if you need a beta tester. I downloaded the latest source but
couldn't get it to compile
on os x. There's no compiled jar for testing yet i think?

thanks!

[Vlad Skarzhevskyy]

Only device discovery and service search is implemented on OS X now.

compiled jar are available on Nightly BlueCove Build
native code for OS X is not yet distributed in this jars but can be compiled using xcode.
Once I made a working RFCOMM client I will add compiled OS X native library to nightly build.

Regards,
Vlad

[Vlad Skarzhevskyy]

Hi,
Nightly build now contains support for RCOMM client connections,
device discovery and service search on OS X.

N.B. RCOMM server and L2CAP client and server are not implemented.

Let me know if you will see any problems.

Thank you for testing,
Vlad

> --
> Vlad

--
Vlad

[Dale Newfield]

Early Christmas!

Vlad Skarzhevskyy wrote:
> Nightly build now contains support for RCOMM client connections,
> device discovery and service search on OS X.

WooHoo! Device and Service discovery worked, and I was able to find and
use do OBEX with a btgoep (SPP over RFCOMM, I think) connection to push
an image to a bluetooth picture frame from a mac! All I did was drop in
the new .jar! You rock, Vlad!

-Dale

P.S.: Since your new machine is probably intel and 10.5, here's
confirmation that it's also working on a 10.4 powerpc based machine.

[Dale Newfield]

Dale Newfield wrote:
> Device and Service discovery worked

Forgot to mention, this app also tests friendly name discovery, which
also worked. (I'm still unclear on how that works--does it fall out of
device or service discovery, or is it it's own special communication?)

-Dale

[Vlad Skarzhevskyy]

Hi Dale,
"friendly name" is part of device discovery. In fact is just one
function on OSX IOBluetoothDeviceRemoteNameRequest
Aloso I have Intel 10.4.8 so it is good that app is tested on powerpc.

--
Vlad

[Dale Newfield]

Vlad Skarzhevskyy wrote:
> "friendly name" is part of device discovery. In fact is just one
> function on OSX IOBluetoothDeviceRemoteNameRequest

From earlier reading I was under the impression that the friendly name
is not part of the information packet received during device discovery,
and that instead the method is really a stub to yet another round trip
communication to request and receive the name. Glad to hear that's not
the case.

-Dale

[Vlad Skarzhevskyy]

Technically this is another round trip if name was not received in
device Inquiry!
In case of BlueCove OSX version name is not received during device
Inquiry: OSXStackDiscovery.mm:63 [_inquiry setUpdateNewDeviceNames:
FALSE];
Only when you call remoteDevice.getFriendlyName(false) and name does
not exists already from from previous search BT will issue another
connection to device and will get its name...

--
Vlad