readFromDiveComputer strategy

[Dirk Hohndel]

Hi William

Let's keep this all on the mailing list :-)

On Thu, Dec 31, 2015 at 02:26:43PM +0200, Willem Ferguson wrote:
> 
> In short, the strategy should be to use as much as possible of
> the existing c++ code base and not to write a whole parallel code base for
> Subsurface-mobile. There are four issues:

Definitely. The more is shared, the better.

> 1) Importing all the dive computer vendors and dc model names. These already
> exist in Qt QStringLists, and within the downloadfromdivecomputer C++ code,
> as linked lists. But the linked lists only exist while
> downloadfromdivecomputer.cpp is executed and then it is very tightly coupled
> to downloadfrondivecomputer.ui which is not useful here. The qml is exactly
> there to replace this specific ui file. Is this accurate? If the existing
> downloadfromdivecomputer.ui  is not useful for the mobile app, then it would
> probably be more efficient to create the lists of vendors and of dc-models
> de novo within qml. Now, qml does not have a sophisticated text file read
> infrastructure, but it looks it can be done. There are at least two
> approaches. (1) Write an independent c program that takes
> SupportedDivecomputers.txt and writes a qml script that creates a complex
> qml element with all the vendor and dc-modelname information. This is used
> to fill qml combo boxes in the mobile interface for selecting the
> appropriate dive computer to download from. This c program is invoked before
> compiling the qml code to ensure that all qml elements exist before
> compile-time. (2) One can write a c++ plugin used by qml. This is possibly
> the more sophisticated approach. See
> http://rschroll.github.io/beru/2013/08/12/opening-a-file-in-qml.html.

We should simply reuse the same code - create the model for the
manufacturers and then the other models for the dive computers per
manufacturer. QML is very good at visualizing things based on such models.
So what we should do is to move the models into qt-models and call the
same model from both desktop and mobile

> 2) Once the appropriate dc and input mechanism (USB/BT) have been selected,
> the indices of the combo boxes should be transformed into suitable values
> that can be stored in the data object (in downloadfromdivecomputer.cpp) with
> which to call libdivecomputer. For this, there is every reason to use the
> existing c++ code. One might have to write a wrapper but I hope the basic
> calling sequence to c++ is doable. One thing I am not sure about is whether
> Android can handle the threads created by downloadfromdivecomputer.cpp.

I am pretty sure it can. This should "just work". Anton had the full
desktop app working on Android :-)

> 3) Once the dive data have been downloaded into the the equivalent of the
> data object in downloadfromdivecomputer.cpp, this needs to be presented as a
> list with a checkbox for each new downloaded dive. The easiest approach is
> possibly not to create yet another screen, but to clear the existing screen
> in which the dive computer is selected and to write the table with dives to
> that screen. This probably will require the use of dynamic objects that can
> be destroyed.

Yes, we should create a UI similar to what we have on the desktop that
allows the user to pick which of the dives to actually add to the dive
list

> 4) Then the dive data need to be added to the existing local dive log. I do
> not have a clear idea, but the infrastructure for doing manual entry of
> dives will probably by a useful final step. This means that information from
> the existing dive structure (comprising the list of dives uploaded and
> selected with checkboxes) will be broken down and added one-by-one by
> filling the fields used for manual editing. One thing I am not sure about is
> the creation of dive profiles because I doubt that the hand-entering of
> dives on the mobile version will allow the creation of dive profiles.

No, I don't think it has to be this complicated. We just take the dives
the user picks from the list of downloaded dives and merge it into the
existing dive_table. All the code for this exists already and should be
callable from the QML code. There will be some glue necessary, but this
should be the easiest part.

> This is about it. The main purpose of this mail is to try and get enough
> perspective so that I can focus on the specific problems that need solving
> in order to create the download facility. I need as much perspective as
> possible, especially with respect to the re-usability of the existing code
> and avoiding writing too much duplicate or parallel code. I also need
> perspective about which approaches are likely to be more easy in qml. I am
> very discouraged by your recent problems to use signals. But I need  an
> appropriate perspective to decide on the best ways of achieving the above
> four goals.

I definitely want to reuse as much existing code as possible. I'll be
happy to help with refactoring code where needed - Tomaz and I have done
quite a bit of that already but it seems some more is needed. I have a
long todo list but I will prioritize this as this is definitely one of the
big things missing for the mobile app. I don't think it is REQUIRED to
have download from dive computer for the first version, but given that you
have some time available I'll make sure you have all the pieces you need
in the infrastructure.

/D