This only deletes the fix on the mobile device, not on the server.
And it is really really slow. Re-reading the data from the settings just isn't
a smart way to do this.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
So far the user can't interact with these. We should implement an ability to
visualize the GPS fix and to delete it.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This is a bit more complicated because we are asking the user to edit the text
field instead of giving them a date and time picker. This is not a great
choice, but let's run with it for now.
One downside is that the user is likely going to edit the date "Oct 29" -> "Oct
25" without adjusting the day of the week. And if we then try to parse that Qt
correctly complains about an invalid date. So we hack around this by removing
the day of the week from both the format and the date entered (which of course
now will break things if the user did, in fact, adjust the day of the week). As
I said, not a great solution.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This isn't quite perfect yet. If it takes too long to get the GPS fix (i.e., if
you save it before you get the fix), this will simply fail and not store a
position. But in normal conditions (you check the box, you edit the data, you
save), especially when outside on a dive boat, this should work fine.
For the other cases we need to implement some kind of callback to still collect
the data.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Instead of doing the silly "onEditingFinished" we get the strings from the QML
components at the time we commit the change. Much more logical, much more
straight forward, no issues with the TextArea not having an onEditingFinished
signal.
This still has a few open todos: the temperatures aren't parsed, the edit
screen is missing depth and duration, we can't edit the dive time (and it isn't
passed in on the commit). But it's progress.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Now we at least start out with the corret date, time and number. This still
isn't functional as a lot of the data aren't used and the way you save the data
is completely silly, but it's another step in the right direction.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
I'm not sure this is the best way to do this - QML should be able to get to the
model data directly (I hope?). But this seems to work and I need it to make Add
Dive be semi-correct.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This is of course stupid and NOT what we want to do, but one could argue it's
better than nothing (well, not sure, whatever). If we have a GPS location
associated with a dive and you tap on the location name when showing the dive
details, it opens a static image of a satellite map with a marker for the dive
site.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Now the message should make more sense. First it tells you that it's looking
for dives. Then you get some progress during the git download, and error
messages if things failed.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We really need to verify that the credentials are valid before trying to access
our backend resources. Trying to do so in a clean manner caused quite a bit of
changes to how we retrieve the webservice userid and how we load the dive list
from cloud storage.
So instead of accessing the network resources directly, this adds a handler
function that first checks the validity of the credentials (by using the
rederict handler on the cloud server), and only calls the function that does
the actual work (looks up the web service userid, loads the dives) if that
succeeds.
Right now there is no good user feedback mechanism - this just gets logged on
the log page. But this is a massive improvement if there are issues with
network connectivity or if the user mistyped their credentials.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The logging to the UI didn't work anymore since the message area had been
removed in commit 8646934ba3 ("Simple DiveList as initial Page").
This way all the updates simply land on the Log page.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This prevents people from overwriting a perfectly fine repository with an empty
one. Typically happens when you first enter your cloud credentials and then
don't Load Dives right away.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
While this is primarily something targeted at a mobile device, with many
of the 2 in 1 devices it is possible that the user might be running the
desktop version of Subsurface on a mobile device.
As a first step to make it possible to collect GPS fixes on such a device
we need to make the infrastructure to do so available in the desktop
application as well.
This still needs to be hooked up in the desktop UI.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
It's just not user friendly to have two different user IDs for two
different web services that we provide. Instead in the following commits
we'll add a way to retrieve the location service web service userid with
your cloud storage user id.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
qDebug is nice when testing on the desktop, but it has to go to the
message area on an Android device to make things easy.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Start working on the add dive feature, to enable the user add a
new dive using the mobile UI.
Signed-off-by: Grace Karanja <gracie.karanja89@gmail.com>
This implements saving of some dive details to the cloud service. When the
user closes an open dives, any changed details will be cached, and when they
click on the 'Save Changes' button is pressed, the changes will be saved to
the cloud.
Signed-off-by: Grace Karanja <gracie.karanja89@gmail.com>
Load dives from the Subsurface cloud service using the user's saved
credentials. This will display the dives in the same way as loading
them from a local file.
Signed-off-by: Grace Karanja <gracie.karanja89@gmail.com>
Add a QMLManager class. This class will be used as a link between
the C++ and QML aspects of the mobile application.
Signed-off-by: Grace Karanja <gracie.karanja89@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
