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