Internal browser state is often lost when app is backgrounded

When viewing a story in the internal Newsblur browser, exiting the app and returning to it later does not return you to where you were, and in addition, considers the story read.

Example:

1. Open a story in the internal browser view.
2. Hit the home button and launch another app (ideally one large enough that Newsblur is forced to close in the background)
3. Return to Newsblur.
4. The app launches "fresh" to the main screen.

Even though a user may only be part way through long content in Newsblur, the app loses state and considers the content read. I've "lost" a story this way, when the story is the only one for a given feed.

I understand that the OS is closing the app (thus the loss of the browser view state), however, the app should save this state and restore it when relaunched. Right now the app is overly optimistic that it will remain in memory in the background in order to resume. This is not a safe assumption under iOS.

Because of this, I am a personally leery of using the internal browser view with any long form content, which is a shame because I adore the app.

Alex Shaffer

3 Posts
0 Reply Likes

Posted 3 months ago

3 months ago

Samuel Clay, Official Rep

5250 Posts
1171 Reply Likes

Yeah, I completely understand. Storing the internal state is something I planned to do, but I'm not sure everybody wants it. Personally, it's nice to come back to the app and have it in a fresh state. But now that i have offline in iOS, I can quite easily return you to the original place.

Anybody else want to see this? (Also, this *really* should have been identified as an idea, not a problem, as this is an entirely new feature).

Comment

3 months ago

Alex Shaffer

3 Posts
0 Reply Likes

The reason it's a problem is that with long form content on feeds with infrequent content, I've lost items. I start reading within Newsblur, and when I come back, the story is closed and Newsblur marks the item read and it disappears from the unread items. Since it might be hours since I opened the item, I don't recall where it came from.

An app really should always maintain state, otherwise you're advocating it's ok for an app to decide when users are done with a task they explicitly started. Apple's own guidelines make it clear that this is the expected behavior. From the iOS Human Interface Guidelines (https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/MobileHIG/StartingSt... ):

Save the current state when stopping at the finest level of detail possible. In this way, people don’t lose their context when they switch back to your app. For example, if your app displays scrolling data, save the current scroll position. You can learn more about efficient ways to preserve and restore your app’s state in Preserving Your App’s Visual Appearance Across Launches in App Programming Guide for iOS.

If the app is NOT going to maintain the browser state, then it should NOT mark the article read until the user closes the browser. Then it's at least non-destructive. Right now, it's losing important information (read/unread status).

It wouldn't be hard to push into the NSUserDefaults a flag that the browser is open and the URL it is on, and clear it when the browser is closed. Then when the app is launched, the presence of that info allows you to resume.

Comment

3 months ago

Alex Shaffer

3 Posts
0 Reply Likes

(However feel free to categorize it as an idea. I put it as a problem because I see it as a data loss issue, which I view as a problem, and also I personally feel abandoning user state when backgrounded is a serious no-no for an app as an app developer myself. Apps should always resume exactly the way you left them in my mind, and doing otherwise is a defect, since users pretty much expect that behavior, and Apple states that as well.)

Comment

3 months ago

ooobo

27 Posts
15 Reply Likes

I don't often use the app, and had this happen yesterday -- I think it's pretty much the only reason I don't use the app often. Would love to see this bug fixed.
<edit> Sorry, just noticed this is the iOS app. I have same issue with Android app.