[ GSoC Progress ] Android Divecomputer Downloader

[Anton Lundin]

On 16 June, 2014 - Venkatesh Shukla wrote:

> Hello
> 
> I have been successful in extracting the dive data from dive computer on
> Android for the first time. This was possible after heavily tweaking
> libusb, libftdi and libdivecomputer in order to get required permissions on
> android and using them, to create a libusb_device and extract data from the
> divecomputer. This proves that it is actually possible to download
> divecomputer data on android. The proof of concept application can be
> viewed here : https://github.com/venkateshshukla/dc_import_android
> 

Great!

> Now, the real task is to be done, creating the framework for import of
> dives that can be utilized by subsurface. As is glance's suggestion, I must
> first try to assemble it with subsurface-android. This would help in
> testing if my framework works. After this has been done, we can move
> forward to making a touch friendly U of subsurface for android.
> 

Fantastic.

> For this task of assembling the android dive downloader with
> subsurface-android, I have the following things in mind.
> As the entire codebase of subsurface and libdivecomputer is in C, the
> framework should be consistent with this. In order to achieve the same
> output in C that I have in java in dc_import_android project above, java
> native interface is to be used. I have spent last 3 days in gaining a
> little understanding of this topic. I have migrated major amount of java
> code in C. But the thing remains that some Java is necessary in the present
> implementation.
> To get over the above limitation, I will try to use NativeActivity provided
> by android.

I think Going NativeActivity is the wrong path here. NativeActivity is
for apps that only would like a Activity and a OpenGL context to draw
the rest of its things from there.

I would say that you should more look at how the qt parts of Subsurface
uses the c-parts. A rough sketch would be to replace the Qt parts with
Native android parts and create JNI wrappers to be able to call the
relevant c code from Java.

That way we can reuse as much as possible, and be as compatible as
possible with "mainline", but still create a usable touch UI.

( Another approach would be to build a touch-friendly UI in Qt/Qml and
use the same models as "mainline", but that might be even harder )

> The overall plan is to make libdivecomputer useful in android. If this
> succeeds, then the tweaked libdivecomputer can directly be utilized by
> subsurface-android for downloading dives.

I think thats a good incremental step to actually be able to test
downloading of real data, and verify that the approach is viable.


Bonus tasks / Future work:

Do we need to run the download thread in a separate thread/service so we
don't get interrupted or get timings wrong if user switches app?

Android bluetooth?

How bad would the latencies get for the round trip to java and back to
libdivecomputer? I've seen that both prolific and ftdi have released
Java-based drivers for Android.

//Anton

-- 
Anton Lundin	+46702-161604