My iOS application is kind of messaging app, so user can send audio, video, images, etc. When user typing the message and app went background for more than 30 seconds then app launches from Home screen and all that messages, everything will be lost. Before 30 seconds app launches at the exact point where it went background. So how to do that same after 30 seconds also, at least I should maintain this state for 30 minutes.
Is using background process and schedule task will be a good method here in iOS 13+?
I particularly don't want to do anything on the background but when app comes from background to foreground within 30 minutes I want to maintain that state.
Messages Disappearing
Well, first of all, why are all the messages lost? if your trying to make a snapchat like experience where the messages disappear after you see them then that's fine but otherwise it might be worth adding a local storage for these messages using CoreData.
Cause
The main issue, after a little while iOS will but an app to sleep so to say, in this scenario it will remove all temporary data within your app, this means when you re-open it it will start from the beginning, it does this to save memory.
Solution
There are a few ways to solve this, you could use State Restoration
For a beginner though this could be quite tricky as the documentation on it is quite sparse.
Another option would be to save the last screen in UserDefaults and then when the app re-launches you can use the value to push the last screen the user was on. For both these solutions though you will need a way to persist the messages and re-fetch them (a database) CoreData would probs be your best bet
I do personally think State Restoration is the best option especially since it sounds like that's exactly what you want to do:
but when app comes from background to foreground within 30 minutes I want to maintain that state.
Related
I’m putting an app into background.
Assuming that I’m not doing anything to keep the app alive in the background, then the app goes through suspended state in a matter of 5 seconds. Right?
What happens if I then tap on the app icon? That’s not suppose to trigger a didFinishLaunch right? It will just bring me back to the last screen I was at and also trigger didbecomeActive & willenterforeground notifications. I won't be getting any other callback. Right?
Assuming there is no restart of the phone, point 2 is true even if there are hours between me tapping home and then tapping back the app icon. Right? Does it also persist device restarts but not force-restart?
The only time I won’t be brought back to the screen I was at (before hitting home) is if the device receives a memory warning and my app is flushed out of suspended state. At this point tapping on the app icon will result in didFinishLaunch. Right?
(I’m asking all of this because sometimes after putting the app in the background and tapping the app icon again (e.g. 10 minutes later), the app is going through it’s launch phase. Most of the time it just goes back to its previous screen)
I've already seen Will ios terminate the app running in background after a specific time? but that doesn't address all aspects I want.
It will just bring me back to the last screen I was at and also trigger didbecomeActive & willenterforeground notifications.
Right, if your app was not terminated in the background.
I won't be getting any other callback.
Not necessarily true. If you were summoned to the front by a local notification, for example, you'll also get an event about that.
Assuming there is no restart of the phone, point 2 is true even if there are hours between me tapping home and then tapping back the app icon.
Not necessarily. The app might well be terminated silently in the background.
Does it also persist device restarts but not force-restart?
Absolutely not. How can the app run when the device is off? Shutting down the app terminates every app.
I’m asking all of this because sometimes after putting the app in the background and tapping the app icon again (e.g. 10 minutes later), the app is going through it’s launch phase
It's not a matter of time. The watchdog process is constantly combing the suspended apps looking for the ones that take up too much memory so that other apps can run. You must not be surprised if yours is one of them.
You can come back to the front launching from scratch or by coming back to life from suspension; it's the most basic fact of iOS app life! You just need to accept it.
But there are lots of things you can do to reduce your chances of being terminated in the background. Giving up memory-consuming objects as you background is first on the list.
I have a Swift iOS app consisting of 3 view controllers – the initial one with a tableview, the second one with the chosen element and ability to create a new time session and the third one with the actual timer for the session (let’s call it the timer vc).
In this case, the focus is the timer view controller. However, the question is not about the timer itself. It works both in foreground and background mode. The problem is this:
The app goes background. Then over a certain fixed period of time, it receives a local notification – a reminder to go back to the timer vc and save the results. Most of the time, it works fine but sometimes when you go back to the app (through notification), it opens the initial vc with the tableview instead of the timer vc, which seems like the system terminates the background app after a while and then reopens it when you go back through the notification. In this case, all the data from the timer vc are obviously lost since the app logic requires that the user save the data after the session is finished.
What I think, the essence of the problem may have to do with how long the app can stay in the background without being terminated or suspended (If I’m not mistaken, in this state, all the current data associated with the app are removed from the memory). I mean, when you set the notifications to be triggered like every 1, 5 or 10 minutes, everything seems to be fine. However, when the notification is set for 30 minutes or more, the mentioned bug seems to appear from time to time (especially when testing on an actual device instead of a simulator). For the most part, it appears if the device storage is almost full - under 1Gb of free space). Which leads me to believe that this may also be a memory management issue.
How to make this timer vc run in the background as much time as needed? Also, does anybody know how much time an iOS app is guaranteed to stay in the background without being removed from the memory? Thanks a lot.
There is no guarantee of your's app execution time when it is in background mode. The operating system can suspend it anytime, Operating system has the responsibility only to notify your app which you will receive in the app delegate.
For setting up the local notification, you need to get the help from OS only. You can't rely on your app's execution in the background thread. For scheduling and handling of local notifications, you can go through the following documentation.
https://developer.apple.com/library/content/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/SchedulingandHandlingLocalNotifications.html#//apple_ref/doc/uid/TP40008194-CH5-SW1
I'm having issues with my app not properly restoring its previous state after it has spent some time in the background ( I'd say around 15 minutes ).
To work on that bug, I usually compile my code, put my app in background and wait around 15 minutes. Then I select my app again and I can use it with the debugger activated.
That's not efficient at all, so I was wondering if there was a way to simulate the fact that an app spends some time in the background.
Thanks!
My app works like this - you press an uibutton and it starts appending data inside a tableView with a specific delay, cell by cell. Sometimes it may take hours to append, because of the manually set delay parameter.
The problem is each time i switch it to background - the app gets suspended after several minutes (up to five usually) and the whole process breaks.
Is there any approach to handling this situation?
Thank you.
That's the designed behavior, an app return to background normally only have very short active time, then it will be suspended, but there are some exceptions:
Apps that play audible content to the user while in the background, such as
Music player app
Apps that record audio content while in the background
Apps that keep users informed of their location at all times, such as a navigation app
Apps that support Voice over Internet Protocol (VoIP)
Apps that need to download and process new content regularly
Apps that receive regular updates from external accessories
Basically speaking, if your app need to interact with outside for resource that can not be generated inside your app, you can apply for background running.
Any every app can legally apply a background task to run for a short time when the app enter background mode.
In your case, even if you implemented the background running, your app will possibly be rejected. If your app is doing the adding to table action controlled by a timer, you should be able to simulate the behavior yourself.
save a the system time stamp locally, maybe in UserDefault
when app launch or enter foreground, get the system time, you can calculate the time difference and figure out how many actions you should take and perform that with a batch action.
after that, clear the saved time stamp ensure next time your data won't be messed up.
Is there any way to show a particular type(some important) of push notification for some 5-10 seconds on the iOS device screen when app is in background.
No, the time is fixed.
You cannot customize it - a push-notification should be a short message that in the best case makes the user tap it and open the app. There is actually not really a need for a longer time. Keep it short, simple and interesting and the user will react accordingly anyway. A longer time should not really make any difference other than people getting annoyed because your messages are always staying on top, blocking other messages and wasting screen space.