Subsurface-mobile for Android first release

[Dirk Hohndel]

On Fri, Mar 11, 2016 at 02:44:41PM +0200, Willem Ferguson wrote:
> Test of version 4.5.2.1058 on Android 5.1.1
> 
> Remove existing app and all data.
> Raw install from Playstore. ok.
> Supply credentials. ok.
> Load divelist from cloud. ok. Quite acceptable speed, around 10 seconds for
> 212 dives.

Yay!

> Scroll to bottom of dive list.
> ********* Same problem as previously reported: parts of screen is white.
> This is worse if one scrolls rapidly.

This is either a QML problem or a Kirigami problem. We have nothing in our
code that impacts how this is shown. We need to talk to the QML experts
about this, but their responses so far to our other report aren't
encouraging.

> Scroll among dives in Details view. ok.
> View dive location on Google Maps. ok.
> Create dive by hand and save. ok
> ********* Having checked "Use current GPS location" for this manually-added
> dive, the dive site name is not underlined in the details view and one
> cannot check the location on Google maps. However, the location is recorded
> as I can see the location after loading the dive list from mobile via cloud
> onto the desktop version.

That's odd. There is a bit of a timing issue with the "add dive manually /
use current GPS location" feature. The problem is that if you try this
inside, at your desk, and just fill in some fake data, being inside makes
the GPS accuisition very slow and just adding random data (or very little
data) makes you finish the interaction fairly quckly, so for me often
there was no fix by the time we tried to commit the data.

When you are outside, at a dive site / on a dive boat, the fix acquisition
should be very quick and if you add actual information that should take
long enough.

But from what you say you did get a fix, it just wasn't marked as such.
Hmm. I'll stare at the code and see if there's something obviously wrong,
but this isn't something I'd hold the release for.

> Details view of newly-created dive otherwise ok.
> Scroll horizontally among detail views of dives ok.
> Save dive list to cloud. ok.
> Download dive list from cloud onto desktop version ok, can see manually
> added dive, including coordinates.
> Delete manually-added dive from mobile app. ok.
> Download GPS fixes from cloud ok.
> View list of GPS fixes ok, except see comments below.
> Delete GPS fix ok.

Your test was exhaustive. Thank you for that, Willem. Really appreciated.

> View location of GPS fix on Google Maps ok.
> ********* I gave the GPS part of the software a thorough test during the
> last two weeks of diving (but not using this very latest version of
> Subsurface-mobile). But the bugs reported then still remain. Times of GPS
> fixes are not parsed correctly, resulting in a semi-ordered list with early
> dives (07h00-09h00) ABOVE more recent dives (10h00-16h00). What about using
> 24h time notation rather than am/pm?

That seems reasonable. I thought the sort was already using raw date
(i.e., the monotonic time_t value) but I need to doublle check that.

> Secondly, GPS coordinates are rounded
> to three digits, when downloading, thus losing three digits of accuracy on
> the original GPS fixes.

I have tried really hard to find where we do this. And I can't seem to
figure it out. I did a fake dive trip with my car and all of the fixes
seemed to be spot on with no lost precision. I continue to be baffled by
this.

> In general, there is still the problem of starting Subsurface-mobile on
> Android 5.1.1, most of the time it crashes but its starts ok on the
> 3rd/4th/5th try. It seems to help if one first kills all the existing
> running apps, found when one taps the bottom-left system button of the
> Android 5.1.1 device and one kills all windows of previously-active apps.
> This is after closing Subsurface-mobile by hitting "Back" while the dive
> list is shown (I hope I make sense). So maybe this is a system interaction.
> Will it help when Subsurface-mobile is closed, to make sure it is really
> killed? But I nevertheless get no easily-repeatable procedure for activating
> the app in a reliable way. I just mention these things in the hope that it
> may lead someone with lateral vision to see the source of this crash.

I wonder if you are running out of memory. Subsurface (because of the way
it is built, and the interaction with git) is a fairly memory hungry
application... what phone/tablet is that on? Do you happen to know how
much memory that device has?

/D