UKC

Bookmark on the app

New Topic
This topic has been archived, and won't accept reply postings.
 scottdurrant 22 Oct 2020

I just wondered is there any intention to add bookmarks to sections of the crag in the app?

Say your on the app at the stanage popular Heaven crack section, it would be really handy to be able to bookmark the section so if you closed the app you wouldn't have to scroll through areas and crag sections to look at the next route to climb. Just click on bookmarks and it'll take you there. 

Just a thought. 

In reply to scottdurrant:

Hi Scott. Can you describe in a bit more detail the issue you're facing?

We've had a feature request that's been accepted for favouriting crags[1], but the way you describe it I wonder if there's a problem with the current implementation of state restoration.

If you're looking at a crag, then put the phone away, when you next get it out the app should still be showing you the same place, even if the system has killed it to reclaim its resources (this will not be the case if you force close the app - then no state restoration happens). Are you not seeing this state restoration? What platform are we discussing here?

[1]https://github.com/UKClimbing/rockfax-digital-issues/issues/3

OP scottdurrant 24 Oct 2020
In reply to Stephen Horne - Rockfax:

Hi, so currently if I'm looking for routes at high neb I open the app scroll to stanage north then high neb and look for the route I want to climb. I then swipe to close the app put my phone away do the climb get my phone out open the app and have to navigate back to stanage north then through to high neb. If I don't close the app it'll stay on high neb. It would just be handy to have a button on top to mark the high neb crag for when I open the app again if I've closed it. 

In reply to scottdurrant:

What platform are we talking about here?

When you say you close it, do you mean that you force-terminate the application, or you just make it got to the background?

OP scottdurrant 24 Oct 2020
In reply to Stephen Horne - Rockfax:

On my android phone. Just swipe to close the app

In reply to scottdurrant:

Ok thanks. It sounds like something isn't quite working there. Unless you do a force-quit of the app it should take you back to where you were last time, even if the system kills it when it's in the background. 
 

I'll check with the android dev and see what he says. 

OP scottdurrant 27 Oct 2020
In reply to Stephen Horne - Rockfax:

Ah ok cheers, I've just checked and it does the same on my iPhone. Swipe to close the app and upon reopening it I have to navigate back to where I was 

In reply to scottdurrant:

Ah, ok. That sounds like you're force-quitting the app. Are you (on ios) activating the app switcher, then flicking the image of the app up off the screen?

In reply to scottdurrant:

Mobile operating systems work in a slightly different way to desktop ones. Much of the responsibility for managing application lifecycles is taken over by ios or android, rather than leaving it to the user.

Where on the desktop you need to be careful about how many applications are open, hogging resources, ios and android are far more restrictive of user applications. The idea being that a user never needs to quit an application – they just switch to the next one they want to use and if resources get sparse, the OS will kill something that's running in the background.

With this idea come state restoration. Because the OS may well arbitrarily kill an application that's running in the background, a user may be a bit perturbed to navigate back to that app in the app switcher, only to find themselves at the opening view – not where they were when they last used the app. So the OS tells the app on launch if it should try to restore its previous state.

Crucially, this only happens if the app was killed by the OS whilst in the background; it will not happen if the user kills the app themself.

So when you activate the app switcher and see at the back of the stack some app you've not used for months, you can be sure it's not using any resources. The system will have killed it long ago. If you activate it, the system will launch it and tell it that it should restore its previous state. Whether it does that or not is up to the developer, but I think it's easier in android from what martin has told me.

In reply to Stephen Horne - Rockfax:

The takeaway tip I get from understanding this a bit more now that Stephen has laid it all out is that the popular idea that flick-quitting apps thinking it will save battery and boost processor speed is a misconception - it doesn't and it makes the app functionality slightly worse.

Alan

In reply to Alan James - Rockfax:

Yeah that's it. Although I've realised I forgot the caveat that some apps do perform stuff in the background (eg mail apps might fetch mail), but to do that they have to use specific background apis which are much more limited, and I think only allowed a certain amount of cpu time. The rockfax app and most apps probably don't do this (excluding all the evil ones).

Post edited at 16:23

New Topic
This topic has been archived, and won't accept reply postings.
Loading Notifications...