pre beta test subsurface-mobile 689

[Dirk Hohndel]

On Thu, Jan 21, 2016 at 11:11:52AM +0100, Jan Mulder wrote:
> 
> After the mysterious crash of yesterday (version 683) first a little focus
> on the most recent changes with that respect. First, running on the desktop,
> I can easily crash the app by pulling the divedetails slider. Difficult to

Can you explain in a bit more detail what exactly you mean by "pulling the
divedetails slider"? Do you mean the horizontal bar at the bottom of the
screen?

Which OS are you running? Which version of Qt are you running with (btw,
that's in the log display that you can get to from the left drawer under
Developer)?

> judge that there is any change here. However, running on a 5" device, I only
> managed to crash it once (identical crash stack compared to 683), but the
> stability has improved significantly. From very easy (for me, Dirk cannot
> reproduce it on his device), it is changed to pretty difficult to recreate.
> I assume that the edit drawer change has caused this change, but obviously,
> this is a wild guess.

I'll admit that I had silently been hoping that maybe changing the
hierarchy of which sizes depend on which might have made a difference. No
such luck I guess. My plan was to also go through the dive details qml and
see if I can mess with the ways the grid is layed out there but I ran out
of steam :-/

> Back to other functionality:
> 
> Editing of dive details. Ok, it works, and I can press save. When the save
> button is hit there is no feedback that the save button is actually pressed
> (in hindsight I think that that is true for all button hits throughout the
> app).

I thought that was implemented in Rick's change to abstract out the
SubsurfaceButton.qml but didn't pay much attention to that detail. Yes,
the button should change when pressed - different color or something. Jan,
would you like to try to play with this? This is a really nice and simple
way to get your feet wet with QML (and you clearly are already building
your own on the desktop).

Look at qt-mobile/qml/SubsurfaceButton.qml - you'll see the different
colors assigned depending on whether the button is pressed or not.
Can you figure out if making a bigger difference in color helps (those are
defined in qt-mobile/qml/main.qml)

> This is confusing because saving takes multiple seconds to complete.
> In addition. what is the dive-edit save actually doing? It doesn't save to
> the actual cloud, but (I assume, did not check the source) but only to the
> local cache.

Yes - I discussed this on the mailing list a while back. On the desktop
app save just marks the dive list as changed and then prompts you to save
on exit; that doesn't make sense on mobile. So instead we save to the
local cache when we save. But we only save to the cloud if you do so
explicitly from the left drawer menu.

> So, exited the app, checked the cloud data from my desktop. The
> latest save (from the divedetails edit page) is not in the cloud. Opened on
> the device again, and the last edit shows. Now, reopen the cloud on the
> desktop. And yes, the last save is now also in the true cloud. So: on start
> of the app, the local cloud is synced to the true cloud. I am not sure that
> that is what a mobile user expects. This all said, it edited and saved
> correctly.

Yes. that is kinda strange, now that you mention it. Maybe we should save
to the local cache and return to the execution thread and in separate
thread try to sync with the cloud. I just want to make sure that the UI
doesn't get stalled by this.

> The editing itself. The notes box is bigger than the screen. So when
> starting to enter text, you run out of screen and do not see what you type.

Really? What device? What screen resolution?

> Re-positioning of the edit screen does not work (it slides back when
> swiped). Basically, re-styling the edit screen would solve this (labels on
> top instead of in front).

But that uses a lot more vertical space overall. I'll play around with the
options there to optimize. Maybe do this just for the notes...

> Then the situation that the cloud is newer than the local cache. The app is
> opened, splash screen follows, and after that the divelist is shown. Hit any
> dive, but nothing happens. Ok, the app is busy refreshing the divelist and
> local cache data. It is visual feedback that is missing here.

Yes and I have no idea what to do in that case. I want to show the dive
list from cache right away. That's just a much better user experience. But
then after the sync from the cloud is completed, what do we do if there's
a change?

> Then some things that used to work but not any more:
> - the divetrip header/footerline in the divelist.

Yes, we lost that at some point. Need to bisect when this happened :-)

> - clicking underlined divesites would take me to (for example) Google Maps.
> Now, nothing happens.

Again, regression. Good catch.

> Some functionality that I really would like to be it a useful tool:
> - the auto complete edit things from the desktop app (for example buddy
> names, and divesite names).

Oh no. No no no no no. Maybe in version 2. But we will not add that
nightmare of complexity to the first version of the mobile app.

> - some way to filter dives. For example, when on a trip, I like to check for
> previous dives on that site. The cloud web interface is currently perfect
> for that.

Again, great for version 2. Not for the initial version.

Please file these as "enhancement" requests on the bug tracker so they
don't get lost.

> FYI. I'm testing on a true logbook with approx 750 dives including numerous
> dives of multiple hours, so its a relatively big dataset. This might be the
> cause of some laggy effects I see.

And maybe it's why you can more easily create the crashes. For simplicity
reasons I usually test with a logbook of about 30 dives... I don't have a
750 dive logbook (I'm at 422), but it's easy enough to create a much
larger dive file to load the app a little more, so I'll do that next and
hopefully have an easier time crashing it.

Yay! :-/

Thanks for the detailed feedback!

/D