Hi Claudiu, On 16 Jul 2015 5:09 am, "Claudiu Olteanu" < [email protected]> wrote: > > 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.
I can test on my Galaxy s6, which apparently run on Android 5.02. Well I could test it if I knew how. > > 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 >
_______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
