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.
Related
As of the new 3D Touch capabilities with the new iPhone 6s/6s+, I'm trying to add some home screen quick actions to my app.
I was able to implement the normal flow of force touching the app's icon in the home screen -> choose one of the quick actions available -> taking care of it properly in all possible app states.
My question is: Is it possible to create a silent action among the available quick actions? By silent I mean that a certain action will take place, yet the app won't complete its launch? Or alternatively launch but won't be in foreground?
UPDATE
I'll elaborate on what I'm trying to achieve - I want to have similar behaviour to the one HealthKit offer with its background delivery - where upon a change in the store, HealthKit wakes my app and give me a chance to do something in the background (with HealthKit example - query for the new data in the store).
After reading much of Apple's documentation on the topic I have the feeling it is not possible with the current API available - but I hope someone will surprise me...
Nope. The user invoking a home screen Quick Action always activates the app.
If your app was already running and is suspended, it comes to the foreground and your app delegate gets the application:performActionForShortcutItem:completionHandler: message. If your app has not been running (i.e. has not been run since install, or was previously backgrounded/suspended but later purged from memory), it launches and your app delegate gets the application:didFinishLaunchingWithOptions: message and then the application:performActionForShortcutItem:completionHandler: message. (So, your did/willFinishLaunching handler needs to check the options dictionary for the possibility of launch via quick action.)
Either way, your app comes to the foreground.
I'm making a simple app with a Today Widget extension that logs events.
The user can tap a button in the app or the related Today Widget to log an event. These events are saved with Core Data any time the button is pressed either place.
Whenever a new event is logged in the app, I run a function called updateLocalNotificationsFromCoreData(). It handles the setup of UILocalNotifications based on the most recent event in Core Data after clearing the appropriate existing notifications.
However, when a new event is logged from the Today Widget, I can't use this function because I need to register the Local Notification with UIApplication.sharedApplication().scheduleLocalNotification(), and UIApplication is not available in the Today Widget extension.
I realize I'll probably need do something unconventional or hacky to get this working, so I'm trying to evaluate possible approaches and come up with a relatively robust solution.
Basically, I want to find a way I can call my
updateLocalNotificationsFromCoreData() function right away any time a new event is logged.
If I can't do it every time an event is logged, an alternative would be to trigger the updateLocalNotificationsFromCoreData() function periodically (somewhat frequently) another way. Here are some solutions I was thinking about using, but I don't like any of them:
Do it in AppDelegate when the app is launched (or another state change)
One approach I'm thinking about is running my updateLocalNotificationsFromCoreData()function in AppDelegate somewhere, like didFinishLaunchingWithOptions.
The downside is that it would require the user to open the app periodically. If the user didn't open it much the notification behavior would be inconsistent. I'd prefer a solution where a user could interact with only the Today Widget and reliably get Local Notifications without ever opening the app.
Sync the events to a server and use Push Notifications
I've thought about syncing the data in Core Data to a server, then setting up Push Notifications to the user's phone based on that.
I don't like this, because I want the user to still be able to get notifications without an Internet connection. It also introduces a lot of extra overhead of syncing the data with a server.
Ping a server, and send a content-available Push Notification
When someone logs an event with the widget, I could ping a server. That server could send back a silent content-available push notification to trigger the app to run updateLocalNotificationsFromCoreData() in the background.
I found a similar question (Scheduling local notification from within a Today extension) where one answer proposes a similar solution. Unlike the previous solution, an Internet connection is not needed to receive the notifications, but an Internet connection would be required to make sure the notifications are up to date when a new event is logged.
Background fetch
I thought about using Background Fetch to fetch something arbitrary from a server, then run the updateLocalNotificationsFromCoreData(). This would be a way to trigger the update in the background, although it seems silly to fetch data if that data isn't being used, and seems like something for which an app could be rejected. There also seems to be a risk of the system not calling the background update regularly if the user doesn't open the app much and mostly uses the Today Widget.
Use background location updates
This seems like the dumbest approach, but I thought I would mention it anyway since I thought about it. I could use one of the low accuracy background location update modes to trigger updateLocalNotificationsFromCoreData().
It would require the user to allow location in the background, which would be hard to explain. And, it would require the user to at least move around a few blocks to trigger the function, which could provide an inconsistent user experience. Also, it would increase power consumption of the app for a silly reason.
I'd really appreciate fresh ideas about how I might be able to reliably schedule local notifications when Core Data changes on a device that doesn't have an Internet connection!
Or, if that doesn't seem possible, I'd appreciated feedback on which approach seems to make the most sense.
EDIT: I came up with a new solution. It's not ideal, but I think it's better than these other approaches I was considering. When someone taps the button to log the event, I launch the full app. It's annoying because I have all the data I need at that point to give the user feedback and log the event within the Today Widget without launching the app, but by launching the app I have the opportunity to check and schedule local notifications.
Also, in iOS 9 the annoyance on the user is slightly minimized because the system-wide "back" button will appear and let the user go back to the previous app easily once my app has launched from the Today Widget.
In the future I may try a solution where one of the server-based approaches above is used when an Internet connection is available, and I would then fall back to this system of opening the app only when the network connection is not available and I need to schedule the local notifications within the app.
As of the new 3D Touch capabilities with the new iPhone 6s/6s+, I'm trying to add some home screen quick actions to my app.
I was able to implement the normal flow of force touching the app's icon in the home screen -> choose one of the quick actions available -> taking care of it properly in all possible app states.
My question is: Is it possible to create a silent action among the available quick actions? By silent I mean that a certain action will take place, yet the app won't complete its launch? Or alternatively launch but won't be in foreground?
UPDATE
I'll elaborate on what I'm trying to achieve - I want to have similar behaviour to the one HealthKit offer with its background delivery - where upon a change in the store, HealthKit wakes my app and give me a chance to do something in the background (with HealthKit example - query for the new data in the store).
After reading much of Apple's documentation on the topic I have the feeling it is not possible with the current API available - but I hope someone will surprise me...
Nope. The user invoking a home screen Quick Action always activates the app.
If your app was already running and is suspended, it comes to the foreground and your app delegate gets the application:performActionForShortcutItem:completionHandler: message. If your app has not been running (i.e. has not been run since install, or was previously backgrounded/suspended but later purged from memory), it launches and your app delegate gets the application:didFinishLaunchingWithOptions: message and then the application:performActionForShortcutItem:completionHandler: message. (So, your did/willFinishLaunching handler needs to check the options dictionary for the possibility of launch via quick action.)
Either way, your app comes to the foreground.
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
I have an app that syncs records created on the phone with a web-server.
When app does not have internet connectivity, it store everything locally (Core Data) and then syncs it when internet is available again.
Now a user has come up with a valid user case scenario ... say he is in an airplane making records (without network) ... so everything is getting stored locally. All is well till the air hostess commands him to switch off the phone. While in the app he immediately turns if off. Now the data is getting lost. I am saving sate while app goes in background or even when phone is locked. But how do I warrant for this?
When user switches off the phone (long-pressing lock button), they still have to slide a bar and devices takes some time before switching off ... so there is some time I can save state in ... which delegate method is called during this time?
Your app will get applicationWillResignActive, applicationDidEnterBackground, applicationWillTerminate calls, in that order.
http://developer.apple.com/library/ios/#documentation/iphone/conceptual/iphoneosprogrammingguide/ManagingYourApplicationsFlow/ManagingYourApplicationsFlow.html#//apple_ref/doc/uid/TP40007072-CH4-SW3
You can use applicationWillTerminate as a cue to save stuff.
However it is standard good practice to make sure your data is saved periodically as you go along and not just in these situations - what about if your user has entered lots of lots and data and then your app crashes, the data will be lost.
I'm not very familiar with Core Data but surely it must have atomic save ability.