-1

I've taken over a project that handles which screen to show first in the "applicationDidBecomeActive" function inside the AppDelegate. This has been causing problems because whenever the app asks for a permission sometimes, not all, it will trigger this block of code and send the user to the incorrect screen. I'm not sure what to do since I've never encountered this before. Any ideas why this is occurring or ways to circumvent this? I've tried adding a flag variable, however, that doesn't seem to work consistently because it looks like it gets un-set before the applicationDidBecomeActive is triggered.

Jay
  • 2,591
  • 1
  • 16
  • 28
  • Duplicate of https://stackoverflow.com/questions/53197130/avcapturedevice-requestaccess-presents-unexpected-behavior-with-a-uinavigationco and my answer is the same. If your code cannot cope with the app being deactivated and activated at any time, it is bad code or located in the wrong place. – matt Dec 11 '18 at 19:41
  • Do you have any articles or links that can help me improve structure the code? Condescendingly pointing out the obvious doesn't really help me learn. I would appreciate some constructive criticism or insight because I'm not sure where to begin. I was looking at the coordinator paradigm, but I'm not aware of any alternatives. Furthermore, as I stated above, this isn't code that I wrote, but a project I took over. I'm looking to improve it, which is why I originally asked this question. – Jay Dec 11 '18 at 19:49
  • Unclear what the goal is, as you show no code. If this is about initially showing a login or help screen unless the user has seen it, see my project at https://github.com/mattneub/RegistrationExample – matt Dec 11 '18 at 20:05
  • That's very fair, I didn't provide enough information for you to go off of. The way the app works currently is whenever the app is brought to the foreground, a launch screen is modally presented, while it handles a series of checks to the server. The responses dictate what screen the user is sent to; there are 5+ different possibilities of where the user is sent to. This is a mandatory process due to the sensitivity of the data. What are some approaches or solutions to a problem like this? Would your project still apply? – Jay Dec 11 '18 at 20:11
  • Furthermore, it is not guaranteed that the code will send the user any where. Sometimes, it is supposed to simply hide the launch screen and present the last screen the user was working with. – Jay Dec 11 '18 at 20:12
  • Well let me ask you this. If the user swipes down to summon the notification center and up again to reveal the app, that triggers didBecomeActive too. Or if we go to the app switcher and come back. How was your app coping with that, and why is the permission dialog any different? – matt Dec 11 '18 at 20:20
  • These are great questions and things that the team hasn't thought about before. I recently jumped on this project, so I will raise these points up. What it comes down to though, is that there needs to be changes made. Where do you think the best place to put this code is? – Jay Dec 11 '18 at 21:14
  • 1
    I’ve no idea because you have not shown it. Nor is that what this question was about. The question you asked was very limited and has been well answered. I recommend accepting an answer and asking a new question that actually explains what you’re trying to do and shows the current code. – matt Dec 11 '18 at 21:17
  • Unfortunately, I cannot show any code due to the legality, but why is the code necessary, shouldn't this be more of a conceptual/architectural problem rather than implementation specific? I think I can learn something from your answer to that question. – Jay Dec 11 '18 at 21:34

3 Answers3

2

When system notifications such as Permissions are presented, the application is sent to background, or becomes "inactive". When the Permission notification is dismissed, the application becomes "active" again. This would explain why didBecomeActive is triggered.

https://developer.apple.com/documentation/uikit/uiapplicationdelegate/1622956-applicationdidbecomeactive

DevKyle
  • 1,091
  • 6
  • 22
  • this is a great start, thank you for providing this. Do you have any suggestions on how I can prevent the incorrect screen transition from ruining the user experience? – Jay Dec 11 '18 at 18:57
  • Can you provide more information in terms of why a segue (when you mean by sending users to another screen, do you mean a segue is performed?) needs to happen when didBecomeActive is triggered? – DevKyle Dec 11 '18 at 19:10
  • I don't mean a segue, I mean pushing a VC on to the UINavigationController stack. There is no real reason, other than the fact that this was the original implementation, put there by another developer. The reason being, the data in the app is highly sensitive, so each time the app opens(whether coming from the background or opening the for the first time), the app needs to run through a series of checks that verify if the app is in a state that is consistent with the server & has the valdiated credentials to access the rest of the app. – Jay Dec 11 '18 at 19:55
  • To clarify, if a user put this app in the background voluntarily (pressed home button) and then opened the app again, does the user need to return to the screen last seen or to another VC as specified in code logic? – DevKyle Dec 11 '18 at 21:01
  • It depends on several other factors, like the expiry of the token or session duration and such. So it could lead the user to the previously visited page, or it could take them to a completely new page. There are a lot of factors to consider which makes this process so complex and cumbersome. – Jay Dec 11 '18 at 22:26
  • I think below link might help as it summarizes which method is called during launch vs re-entering foreground (AppDel vs VC). I think you should move the code block in question out of the didBecomeActive method. https://stackoverflow.com/questions/15864364/viewdidappear-is-not-called-when-opening-app-from-background – DevKyle Dec 11 '18 at 22:51
  • Hey I also realized the reason we have code in didBecomeActive is due to the fact we need to access keychain as a step in this process. And it is not guaranteed that I can access it in the applicationWillEnterForeground. So does it make sense to have the code related to accessing the keychain in the launch screen? – Jay Dec 12 '18 at 20:09
  • I'm not very familiar regarding that particular use case, but looks like this post might be of some help. https://stackoverflow.com/questions/35360453/when-should-i-store-and-re-store-to-keychain-on-ios-swift – DevKyle Dec 12 '18 at 20:51
  • I saw this and unfortunately, it doesn't. There aren't many articles/resources on this particular case. I'll just ask another question, thank you for taking the time to answer this. – Jay Dec 12 '18 at 20:53
1

As a solution; you can use the applicationWillEnterForeground(). It's being called before the applicationDidBecomeActive() and not being triggered by permission request.

Ali Şahbaz
  • 59
  • 2
0

I've taken over a project that handles which screen to show first in the "applicationDidBecomeActive" function inside the AppDelegate... Any ideas why this is occurring or ways to circumvent this?

The simple answer is: don't do that work in applicationDidBecomeActive(). As you've seen, the application can become inactive and then active again while the app remains in the foreground, so that's not the right state transition for what you're doing. Identify the app state transitions where you really do want to choose a screen. For example, you might want to do it when the app launches, and also when it transitions from background to foreground, so you could use application(_:didFinishLaunchingWithOptions:) and applicationWillEnterForeground(_:). (Obviously, you don't want to put the same code in both places, so put it in a separate method and just call it from those two methods.)

Apple has a document that covers this very topic: Managing Your App's Life Cycle. There's also a lot of information on application states on the UIApplicationDelegate reference page. Both documents include helpful state transition diagrams and descriptions of what the various states mean.

Caleb
  • 124,013
  • 19
  • 183
  • 272
  • So the reason it needs to be in the applicationDidBecomeActive is that during the checks, I need to retrieve data from keychain access, which can only be reliably retrieved from this delegate method. Putting the code inside the applicationWillEnterForeground isn't a possibility for this reason. What do you suggest I do? – Jay Dec 12 '18 at 22:59