I am trying to change the setup of my iPad app. I would like to set it up in a way so that only a certain section requires authentication. Right now, the app verifies authentication on launch, and that is simply not very user friendly, specially when it comes to information that should be visible without having to authenticate.
My question is more along the lines of: How to check for inactivity on the app? So that after 30 minutes or so I automatically log user off.
Has anyone worked on a similar setup that could point me in the right direction?
For what I have gathered, I can use a notification for when the app goes to the background. Should I set up the timer on that method? Will it be preserved when the app is on background? In which case, once that timer reaches the set time, simply log user off? And set up another notification for when the app will enter foreground within that time frame so that it reset's the timer?
Related
I Did lots of BG tasks in the past, But Trying to get data when app is killed (Even when user is giving Always permission) seems not to work.
I wonder if there is a solution for that.
To make things clear, I am not talking at the moment when app change from Active or Background even to suspended mode. I'm talking about if the user is using the app and set permissions but then kills the app and after that i need every hour to get data from the user and send data to them.
Is there a way to do that?
Can a Today widget help me with that? Does a Today widget "lives" all the time and i can get that from it 24/7?
Whet is working is CLLocation manager. This is working even when the app is killed. But only when the user is changing a location.
I need that to work when the user is in the same place also.
Non of the other methods work. Not BGTask (I need every hour on the hour and not when apple decide to do things), Nor Silent Push Notification for some reason (Regular ones work, but i Don't want to bother the user with a push every hour just for getting and sending data).
Sorry there is no code to show as this is a very general question. But i think that is very important one to many people and can't find an answer for that.
I have a group email app where customers create emails in a standard iOS compose window. If they write a long email, then switch apps to do a memory intensive task, iOS may close the compose window, losing the contents of their email.
Is there a way to prevent the window being closed? or a way to ensure iOS saves the email to drafts before closing it?
I am wondering if I am not retaining a link that I should be, perhaps?
Can anyone else confirm whether they see the same problem?
The best way to do this is to understand the App Life Cycle on iOS.
When the App is running in background, the method applicationWillTerminate will be called, this is one of your options to save the content of the email. But this method is not called every time, it is only called when your app isn't suspended or when the user reboots his device.
One solution is to save this data inside the method applicationDidEnterBackground, it is called as soon as your app starts to run in background. And reload the data inside application:didFinishLaunchingWithOptions, this allows you to perform any final initialization before your app is displayed to the user.
Is there a way to prevent the window being closed? or a way to ensure iOS saves the email to drafts before closing it?
There's nothing you can do to prevent the window from being closed, because iOS is killing the app. What you can do is to save the email at some point before that happens. Since the user obviously can't modify the email while the app is in the background, saving the message when the app goes into the background would be a good choice. That way, you'll have the data saved if iOS does end up killing the app, and you can check to see if there's a saved message that needs to be restored when the app launches.
If you take that approach, though, you'll also have to figure out a way to help the user get back to their saved message, which means that you also need to keep track of how they got there in the first place so you can recreate that state. If it's just a simple message, maybe all you need to do is to open a message editor view and set it up with the saved message. In general, though, this can be a thorny problem. Luckily, Apple has provided a nice solution...
The View Controller Programming Guide for iOS has a section called Preserving and Restoring State, which explains how you can set your app up to automatically save and restore its state. With a relatively small amount of work, you can set your app up so that the user will never even notice that the app has restarted -- if they launch it after iOS has killed it, the app will recreate the view controllers so that it looks like the app was running the whole time, even if the device was shut down in the interim.
Our app is fitness-related. It uses location services in the background. The user clicks a button when the app is in foreground and then we trigger startUpdatingLocation. We initially set the accuracy to kCLLocationAccuracyNearestTenMeters (force GPS) and distance filter to 1500. After that the user locks the screen and put the mobile in a pocket.
The problem is that this doesn't work for 5-10% of our ios users (it works perfectly for the rest). We have logged when the location update event occur and we can see that it doesn't trigger. When the user clicks the button in the foreground we also setup a timer to trigger x minutes later and the timer does not trigger either (for the users it doesn't work for).
We have not been able to reproduce the issue in-house, so it's hard to do good troubleshooting.
I know that the OS can terminate the app if the user is using other apps in the foreground, but from what I understand it may call applicationWillTerminate and we have not seen any logs from that event being called. However it still might be the case that the OS decides to terminate our app. If that is the case, what can we do about it? Our app is wanted by the user and starting another app (for example taking a photo) does not mean that the user want our app to stop working. So the question now is if it's related to that OS terminates our app, is there anything we can do?
Notes:
pausesLocationUpdatesAutomatically is to NO
Background App Refresh is enabled
We have not enabled gps or location-services in UIRequiredDeviceCapabilities (plist) since our app can be used in two ways. With or without GPS.
We require "always on"-setting to be enabled when the user clicks the button in the foreground.
We have confirmed that backgroundTimeRemaining property returns the max value (indicating that the app is allowed to run in the background indefinitely)
The problem occur for a variety of ios versions both 8.x and 9.x.
We have a customer who wants us to have our iOS app check for new data posted every night and download it if it is available. As far as I can tell this is only possible if the app is already open or if they have someone physically accept a notification or initiate the process themselves.
Is this correct? I can't imagine Apple wanting to allow launching of an app and downloading data with no user interaction at all.
Yes, generally you can only download data at exactly specified times if the app is actually running in the foreground, that is correct. It wouldn't matter if the app was open already or the user opened it from a notification, the point is that user interaction is required. So, the client can't have exactly what they want.
Look at background downloading (fetch) from iOS7+ where you can register the app to perform background downloading in advance of usage. iOS is fully in control of this and it may choose to run the app and it may not. iOS will monitor when your app is usually used by a particular user and, if appropriate, it will allow the app to run in the background to do some downloading before the user is expected to use the app.
In particular you're looking at setMinimumBackgroundFetchInterval: and setting the UIBackgroundModes key with to fetch in the Info.plist.
As an aside, here's an idea based on your expanded information:
Use idleTimerDisabled to prevent the app from sleeping during main usage and keep a track of the time
After the main usage period of the app is over, start your downloads
After the downloads are done allow the screen to sleep
On the next day, if a user opens the app, repeat
It isn't perfect, but it's an approximation
My app is successfully notifying the user when an activity is due by displaying an alert/banner on the iOS device lock screen. So up to here, no issue.
When the user swipes the alert/banner they are taken directly to the app. Again no issue here.
Here's where it becomes problematic:
If the user has set up Passcode, iOS is forcing them to enter their password after they swipe the alert/banner (which is normal). But once they enter their passcode, it is not taking them directly to the application. Instead they're on the home screen and they have to click on the application to get in and to see the notification.
So my question is how is it possible to have the user taken directly to app after they have entered their password?
I thought this passcode issue was a default behaviour from iOS until I found out that Pinterest app can take you straight to the app after you've entered your password. And their stuff works pretty clean.
Any solution/advice/method here would be much appreciated. Thanks.
What is your app doing when the notification is swiped? Is it trying to access Core Data?
My suggestion is to see if there is anything your app is doing when the local notification is swiped that could cause it to crash due to the lock screen being on. This would have the effect of never taking the user into your app.
(I had a passcode issue with my app. When a location event is received, it creates a local notification. In the process it needs to access Core Data. When the lock screen is on, the app could not access Core Data. It crashed silently when trying to do so. I never saw my local notification in the lock screen. Very hard to debug!)