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
_______________________________________________
subsurface mailing list
[email protected]
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
