Download dives from dive computer on mobile, status report.

[Tomaz Canabrava]

All noted. I'll try to make the list better looking, fortunately this is
one of the things that's really easy to do with qml.

I'm actually impressed by the amount of qml code I had to write for that
(mostly nothing) - a great percentage of the work I did was basically
removing the hardcoded stuff for D.C. Download from the qt widget
implementation to a pure QObject implementation.


On Sat 27. May 2017 at 11:11, Jan Mulder <jlmulder at xs4all.nl> wrote:

> On 26-05-17 21:49, Jan Mulder wrote:
>
> On 26-05-17 18:11, Tomaz Canabrava wrote:
>
> Today I made  a breakthrougth and I can actually download the dives on the
> mobile version.
> The code is 100% shared with the desktop version, so nothing new was
> written to support that, this means that I kept code written to a minimum
> (moving things around, creating some helper classes to deal with desktop
> and mobile), for instance.
>
> Some points:
> 1 - the deviceName currently is hardcoded to "/tmp/ttyS1"
> 2 - I tested with the simulator since I don't have a BT hardware
> 3 - Bt is not done nor tested.
> 4 - The downloaded dives are not being save yet.
>
> I'm going to the Opensuse Conf this weekend, so I'm not sure if I will
> have the time to hack on this on the weekend, but if you guys wanna help,
> my branch is in https://github.com:tcanabrava/subsurface.git /
> DiveComputerQml
>
> picture to proof.
>
> Tomaz
>
>
> I have tried the following:
> 1) mobile on desktop, reading from the libdc simulator => working (as
> expected),
> 2) mobile on desktop,reading from OSTC3 over BT. For this, I hardcoded the
> BT address of my OSTC, and set the BT mode to true (obviously). The OSTC
> goes correctly in download mode, and stays there for multiple minutes. The
> console finally shows "Finishing the thread dives downloaded 125". So,
> the next breakthrough today :-) The first download over BT from a real dive
> computer :-) And most impressive, without changing any of the code from
> Tomaz. Obviously, there is something needed: a progress (toast) style
> thingy, or any other indication that it is downloading. Further, I was
> downloading in my normal logbook, so I did not expect any dives downloaded
> that were already downloaded (without looking to any code at this point).
> 3) mobile on mobile ... ok, this is not working yet. I verified that
> pairing is ok, and I can trigger a download over my mobile (using terminal
> input), so raw serial traffic. So the two devices can communicate. It seems
> that subsurface mobile is not attempting any communication.
>
> --jan
>
>
> And some more progress. Just downloaded 125 dives from my OSTC3 to the
> mobile app on my phone. Ok, all device specific stuff is hard coded at this
> point. The reason that 3) above did not work is that we have to open the
> socket based on  uuid as port number is not supported on Android. So in,
> qtserialbluetooth.cpp we need to something like:
>
>     QLatin1String serviceUuid(<the UUID of the already paired
> divecomputer>);
>     QBluetoothAddress remoteDeviceAddress(<the BT address of the paired
> divecomputer>);
>     QBluetoothUuid uuid(serviceUuid);
>     serial_port->socket->connectToService(remoteDeviceAddress, uuid,
> QIODevice::ReadWrite | QIODevice::Unbuffered);
>
> Thinking of some QML and other things:
> - it might be nice when the list of dive computers is filtered (in the BT
> case) to the set of paired dive computers. Why bother the user with a long
> list of dive computers that are not paired (so not ready for
> communication)? Obviously, I am assuming that pairing will be done at
> OS/Android level, and not in the mobile app.
> - the list of downloaded dive on the phone looks crap. Font sizing is way
> off.
>
> that's all for today, now time from a nice dive on this almost tropical
> day in the Netherlands.
>
>
> --jan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20170527/4caa0ab5/attachment.html>