-1

I am currently working on a task with background and foreground stuffs. Is it possible for me to detect my app when my app WILL GO to background? I've searched and read many information from internet but I didn't get what I want. When I search on internet It's all about "when the app moves to background", "when the app already in background", and something that it's already happen in background.

So far, I already tried with UIApplicationWillResignActiveNotification but, willResignActive does not mean it is going into the background -- it means it is going inactive. (an incoming call on top of your app , when I click Siri, and when notification come).

I already tried with DidEnterBackground but ya, It only triggered when it's already in background mode.

Why I want to know this answer? Because, I want to enable Picture in Picture mode when the app is in the background mode (not in the foreground mode). So, I disable the Picture-in-Picture in the foreground mode then I enable that when in background mode. I know, normally Apple auto enable the PiP in the background and when user click the PiP mode.

The reason why I want make this because, it's so annoying if user always must enable the PiP mode. So, I think It would be 'clean' if I enable this feature when my app in background mode.

So, how do I know if my app Will Go to background? I am open with any suggestion.

E_net4
  • 27,810
  • 13
  • 101
  • 139
Anastasia
  • 7
  • 1
  • 4
  • 1
    Does this answer your question? [Detect iOS app entering background](https://stackoverflow.com/questions/34744783/detect-ios-app-entering-background), another [question](https://stackoverflow.com/questions/3712979/applicationwillenterforeground-vs-applicationdidbecomeactive-applicationwillre) that should be helpful – Joakim Danielson Oct 21 '20 at 13:31
  • thank you for your quick response. Unfortunately, those aren't answering my question :( I've already tried all of the methods but, they only triggered when in background and when in inactive mode – Anastasia Oct 21 '20 at 13:48
  • And that is all you have at your disposal, you can not get notified before the app goes into the background – Joakim Danielson Oct 21 '20 at 14:10
  • @Anastasia - you may want to explain *why* you want to know this. – DonMag Oct 21 '20 at 14:19
  • @DonMag yes! I already added my reason why I want to know that method. Please check my post – Anastasia Oct 21 '20 at 14:35
  • @JoakimDanielson I see, sadly I can't get the method. I wish Apple could make that method :( – Anastasia Oct 21 '20 at 14:35
  • 2
    I think it would be a bad idea since it could possibly mean that the user experience a delay when switching between apps because the app going into background is doing something that takes time. – Joakim Danielson Oct 21 '20 at 15:05
  • 1
    A general trend i've grudgingly learned from iOS is that usually the simplest and most well known delegate methods that Apple gives you also provide the best UX/UI. And that if there isn't a way to do something... Apple probably doesn't want you doing it – Sanzio Angeli Oct 21 '20 at 18:08
  • How about using ```viewWillAppear``` and ```viewWillDisappear```. This is not at all related to the app going into the background, but it may work here. I don't think these get triggered for e.g. an incoming call but I think they do get triggered when the app goes into background. iOS has these quirks and as Sanzio says you either do it the Apple way or you suffer. I think you need to general methods, say ```toBack``` and ```toFront``` with an ivar to indicate which is active now and so that you do not trigger it twice. I think I'll post some code rather ... it is getting cramped ... – skaak Oct 22 '20 at 06:34

1 Answers1

0

Just an idea ... create an ivar, say inFront and two methods, as follows

// Signals that app is going to the back
- ( void ) toBack
{
  if ( self.inFront )
  {
    self.inFront = NO;
    // stuff e.g. start PiP
  }
}

// Signals that app is going to the front
- ( void ) toFront
{
  if ( ! self.inFront )
  {
    self.inFront = YES;
    // stuff e.g. stop PiP
  }
}

The problem is that it is not as clean as you may want it to be. Now you need to find the places to hook this up to, e.g. viewWillAppear and viewWillDisappear but you can also hook it up to more. You can also add more logic but the idea is to package it nicely and then you can call these multiple times from different places and for different events and hopefully it will solve your problem.

skaak
  • 2,988
  • 1
  • 8
  • 16