Add ability to do an on-line share of current active route about gpslogger

[GrazianoCapelli]

Feature merged to master branch (commit 363dc73).
The new functionality will be deeply tested, and it will be available in the next app release (v.2.1.6).

[GrazianoCapelli]

Yes, starting from v2.0.0 there is never any loss of data.
Each fix is written into the local Database immediately and the various KML / GPX / TXT files are generated on-demand by each share / export / view process.
In the worst case the user will lost the last point, if processed but not already written.

This commit does't change the way to store data; the current track was simply not passed to the tracklist.
Until the previous commit.

[GrazianoCapelli]

I'm thinking (long since) it would be a great feature for the app.
The app code could easily do it, in the same way of the finished tracks.
The real problem is to find the best way to implement the feature into the app GUI.

The best way I've found so far is to also include the current track into the tracklist.

Some related aspects should be evaluated in order to implement the feature correctly:

1. The tracklist must be refreshed every time you collect a fix, in order to keep updated the tracklist card stats; we must check and quantify the real increment of the battery consumption;
2. The "in-progress" track should be highlighted in some way. Maybe with a different background color of that card;
3. It is better to NOT generate the thumbnail of the "in-progress" track, to minimize the battery draining;

Since now I received no request about that feature, so I decided to leave the app as is.
Maybe it is time to start again to think how to implement this feature.

[GrazianoCapelli]

A new branch has been created. The functional part has been implemented.
The ability was already there, has been very easy to bring it out (8 lines of code: commit 61f50d2).

Now begins the hardest part: find a nice way to implement into the User Interface.
The card could appears like the other cards, or maybe we could differentiate a bit the current track from the others (The current track has no thumb indeed, and delete means stop the in-progress current track and delete it).

I try to explain what I mean with a fast mockup picture:
(The darker card in the mockup appears into the tracklist only when there is a (non empty) in-progress track)

Let's use this issue to collect ideas and informations about this topic!

[JLJu]

Lovely! The track is handled in such a way that it is possible to recover the collected points after the battery quits/dies/other?

[GrazianoCapelli]

Several tests will be done in the next days.
A possible final implementation of the feature is finished.
For now I choose to exclude the delete command from the context menu of the current track.
Thus it's no possible to directly delete the current track. It is necessary first to finish it.
The context menu for the current track is the following:

We are almost ready to merge the current_track_on_tracklist branch into the master branch.

Maybe it would be nice to also add the delete menu?

[JLJu]

I don't like complexity. I rather not add the shortcut for delete the track.

[GrazianoCapelli]

You are right about that.
The activation of the delete menuitem also for the current track could add a risk for the user, because in that case he will do 2 different operations in the same way:

• Delete a finished track = delete the track from DB and from tracklist;
• Delete the current track = stop recording? + delete the track from DB and from tracklist;

This is the fact that adds complexity.

For now I suggest to force the user to finalize the track (operation that stops recording) and THEN to delete the (just finished) track like all other archived tracks, in order to have a single linear behavior.
This way we'll add features without add complexity.

We'll evaluate (as always) the user's feedbacks and, in case, we'll change it!