Hi Thiago,
> Is this method supposed to work elsewhere too? Is there a reason not to > use it > everywhere? > This method should work on every supported platforms but I cannot obtain the correct result using it on Linux. I mentioned before that I believe there is a bug on the QtBluetooth library because when I start a full SDP discovery agent I cannot find the SPP service from my HW OSTCs device. The same thing happened on Rick's environment with his Petrel2 device. I sent some e-mails on the qt-interest list but I didn't receive any response to the last one. That is why I decided to use directly the port number on Linux platforms. It would be interesting to test whether this happens on other Android > devices > too, especially those using BlueZ instead of Bluedroid. > I tested the application on two different devices (Nexus 5 and Nexus 8) but unfortunately both have the same Android version (5.1.1). If I don't wait for the scanning process to finish, the download gets stuck. Also I tried to install the application on a device with Android 4.3 but I cannot use any buttons and cannot access the one with the "Import" functionalities. You can find some links with two screenshots([1], [2]) from Android 4.3 and one from Android 5.1.1 [3]. I don't know why, but on Android 4.3 the header is missing. I am not sure how the Bluetooth will work with the Android Emulator tool and I don't know how to test if this issue persists on Android versions with BlueZ stack. By the way, the pair/unpair functionalities are not available on Android because we cannot access the context menu :). I will change the UI after I will finish the support for Windows platforms. > What's the use for this? How likely is answering in 20 seconds when in 5 it > didn't answer? If 25 seconds is better, why not always wait for 25 seconds? > If the device is in Connecting state or in ServiceLookUp it means that the connection step took more than expected and maybe we should give it another try and wait longer. This can happen when it is the first time when you try to connect to that device. I didn't want to always wait for 25 seconds because if somehow the Bluetooth from the dive computer was stopped before I started the download, then the application can freeze for 25 seconds. Therefore I decided to let a timeout for 5 seconds to receive a feedback from the remote BT device. If I don't receive anything it means that there is something wrong with the device. These values are not final and we can make them smaller. Please add a simple comment to the source code why this is done, in addition > to the commit. Something like "// on Android, the device gets stuck in if > we > try to use it before discovery is done" > I will do that. Thanks for the feedback! Claudiu
_______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
