refresh current spot when app has been backgrounded for a while

[michaelkirk]

Given I launch biketag Then I see the current spots When I background the app And then I put my phone down for 30 minutes, or a day, or a week And I pull biketag back to the foreground Then the current spots list should refresh itself

[michaelkirk]

@ferndopolis I think this will involve the UIViewController life cycle hooks.

There is some hook that gets called everytime the view gets displayed. That would be a good time to check if we need a reload.

pseudo code:

class HomeViewController {
  func viewWillAppear() {
    if ( timeSinceLastReload > 30.minutes ) {
      refreshCurrentSpots()
    } 
  }
}

I'm not sure that "viewWillAppear" is the right life cycle hook, but it might be...

See here for more info: http://stackoverflow.com/questions/5562938/looking-to-understand-the-ios-uiviewcontroller-lifecycle

[jmoody]

On the Objective-C side you should call super in each on of these lifecycle methods.

viewWillAppear might not be a good choice if refreshCurrentSpots() is a synchronous method. If it is async, maybe it doesn't matter.

It might be worth doing this:

1. in viewDidAppear, check if you need to refresh
2. if you need to refresh, indicate that you are refreshing to user with a UIActivityIndicator

Also of note is this UIApplicationDelegate method:

- applicationSignificantTimeChange:

Have a look at the RiseUp repo to see how I used NSUserDefaults to track the "app lifecycle" - you could do something similar to figure out how stale the spots are.

https://github.com/jmoody/RiseUp/blob/develop/RiseUp/RiseUp/RuAppDelegate.m#L308

[michaelkirk]

refreshCurrentSpots is an async method, and it already manages displaying/hiding an activity indicator.

I've never used applicationSignificantTimeChange. It looks like an interesting method, but reading the docs it seems irrelevant to our problem.

From:https://developer.apple.com/library/ios/documentation/UIKit/Reference/UIApplicationDelegate_Protocol/#//apple_ref/occ/intfm/UIApplicationDelegate/applicationSignificantTimeChange

Examples of significant time changes include the arrival of midnight, an update of the time by a carrier, and the change to daylight savings time.

That doesn't sound like what we're talking about. You're using it in the very specific case of a user editing a record at midnight, presumably to ensure that the "daily record" is recorded for the correct date when a user is editing across midnight. We had to handle something similar back in WLC days. That's not what this feature is about. It's about "has it been a while since the user looked at the app"? I don't think "30 minutes from now" necessarily qualifies as a "significant" time change in the sense that apple is using the term.

So, just to clear the waters for @ferndopolis who is on day 1 of swift development, I don't think you should do any of the things in @jmoody's comment, and proceed as planned using viewWillAppear... correct me if I'm mistaken @jmoody.

On Fri, Jul 10, 2015 at 4:43 PM, Joshua Moody notifications@github.com wrote:

On the Objective-C side you should call super in each on of these lifecycle methods.

viewWillAppear might not be a good choice if refreshCurrentSpots() is a synchronous method. If it is async, maybe it doesn't matter.

It might be worth doing this:

1. in viewDidAppear, check if you need to refresh
2. if you need to refresh, indicate that you are refreshing to user with a UIActivityIndicator

Also of note is this UIApplicationDelegate method:

• applicationSignificantTimeChange:

Have a look at the RiseUp repo to see how I used NSUserDefaults to track the "app lifecycle" - you could do something similar to figure out how stale the spots are.

https://github.com/jmoody/RiseUp/blob/develop/RiseUp/RiseUp/RuAppDelegate.m#L308

— Reply to this email directly or view it on GitHub https://github.com/jackpine/biketag-ios/issues/48#issuecomment-120517084 .

[jmoody]

@michaelkirk You are correct.

[ferndopolis]

OMG @michaelkirk, just trying to calculate time difference on swift is a pain.

timeSinceLastReload > 30.minutes

been looking at the NSDate, NSDateFormatter, NSCalendar and NSDateComponent, so complicated library compared to moments.js or ruby Date.

[michaelkirk]

fixed in #94