6

I have a media player app that is playing music with MPMoviePlayerController. I need to update the UI based on the playback position. The best I can tell, there is no way to actively receive this info from the player with a callback or something, and I basically need to poll for it myself.

So I thought I would use a simple timer, run every second, for that. The code is such:

Somewhere in the setup code:

[NSTimer scheduledTimerWithTimeInterval:1 target:self selector:@selector(updatePlaybackProgressFromTimer:) userInfo:nil repeats:YES];

And then:

- (void) updatePlaybackProgressFromTimer:(NSTimer *)timer {

    if (([UIApplication sharedApplication].applicationState == UIApplicationStateActive) && (player.playbackState == MPMoviePlaybackStatePlaying)) {

        CGFloat progress = player.currentPlaybackTime / player.duration;
        // do something useful with this info            
    }

}

The timer is run every second, even when the app is in the background. The method first sees if the app is active and the player is playing, and then does some UI updating.

Is there any battery life implication to running a timer every second in this fashion? Should I be more diligent and try to tear down the timer when entering the background and reactivating it when activating the app? I’m sure there’s some battery life effect, but realistically, how serious is it? Or is there any other recommended ways of doing this kind of thing?

Jaanus
  • 17,688
  • 15
  • 65
  • 110
  • 1
    just use a timer as suggested by @ChrisGummer. There is no KVO for the MPMoviePlayerController framework or similar callbacks. There is however such thing for AVFoundation (AVPlayer) - still, no need to refrain from a timer for the given reasons. – Till Jun 04 '12 at 18:35

1 Answers1

7

I can't imagine using an NSTimer will significantly impact battery life - unless the work being done when it is triggered impacts battery life. The timer is simply being added to the current run loop:

A timer is not a real-time mechanism; it fires only when one of the run loop modes to which the timer has been added is running and able to check if the timer’s firing time has passed.

NSTimer Class Reference

According to the documentation, you should be pausing any timers when your application is about to resign its active status:

In response to this change, your app should do the following in its applicationWillResignActive: method:

  • Stop timers and other periodic tasks.
  • Stop any running metadata queries.
  • Do not initiate any new tasks.
  • Pause movie playback (except when playing back over AirPlay).
  • Enter into a pause state if your app is a game.
  • Throttle back OpenGL ES frame rates.
  • Suspend any dispatch queues or operation queues executing non-critical code. (You can continue processing network requests and other time-sensitive background tasks while inactive.)

When your app is moved back to the active state, its applicationDidBecomeActive: method should reverse any of the steps taken in the applicationWillResignActive: method. Thus, upon reactivation, your app should restart timers, resume dispatch queues, and throttle up OpenGL ES frame rates again. However, games should not resume automatically; they should remain paused until the user chooses to resume them.

iOS App Programming Guide

Chris Gummer
  • 4,772
  • 1
  • 24
  • 17