I have an iOS weather app and am looking to add support for SiriKit Intents.
The basic intent I've set up works correctly with dummy data, but where I'm struggling is with getting my main app / framework to request the forecast from my server and hand it back to the shortcut so I can provide a response in the completion handler:
func handle(intent: GetUVIndexIntent, completion: #escaping (GetUVIndexIntentResponse) -> Void) {
//TODO: Get the main app to request weather data and hand the result back to Siri.
completion(GetUVIndexIntentResponse.success(uvIndex: NSNumber(value: 1), burnTimeEstimate: "I'll fix this later! "))
}
In my main app I handle this by firing off the server request from my model, awaiting a response and using NotificationCenter to communicate the outcome to the View Controller so it can update itself. This sort of pattern doesn't seem like it is suitable for use with Siri Intents though. Are there any alternative patterns/approaches I could use here?
Thank you!
Related
I am making an iOS application for myself only. I need to execute certain code every 30 minutes when application is in background.
As I am only user of this app, don’t need to worry about batter percentage and apple review process. I can use any/all background modes VOIP, music, etc.
Is is possible to run that code in background every 30 minutes?
Kindly guide me the direction.
Its posible.
One way to do it is to create a fake VPN packet tunnel extension. And put your code in VPN Manager class.
VPN extension part will keep running while your app is in background or even force quite by user.
You can write your code in this method
NEPacketTunnelProvider
override func startTunnelWithOptions(options: [String : NSObject]?, completionHandler: (NSError?) -> Void) {
fetchData()
}
func fetchData() {
// Do not use the NSTimer here that will not run in background
let q_background = DispatchQueue.global(qos: .background)
let delayInSeconds: Double = 300.0 // seconds
let popTime = DispatchTime.now() + DispatchTimeInterval.seconds(Int(delayInSeconds))
q_background.asyncAfter(deadline: popTime) {
// Fetch your data from server and generate local notification by using UserNotifications framework
fetchData()
}
}
Why not go with Background Fetch?
It is available for apps likes News or Social media, so that apps can have the latest data even before the user interaction. It allows periodic background execution as is.
A simple call will fetch data every hour.
// Fetch data once an hour.
UIApplication.shared.setMinimumBackgroundFetchInterval(3600)
Lastly its not a workaround or any private API. Your app will be accepted by appstore as well.
I have a coaching app that has a section where I can push realtime updates out to the players like: "No Practice - Do to inclement weather, practice will be pushed until Friday"
I have been trying to figure out how to send automatic notifications when I update this UpdatesTableView with a new post. Like "New Update Posted".
I post my updates to the Firebase Database. There must be a way to listen for changes and when there is to push a notification out to all the users?
I already have firebase notifications set up in my app but I have to utilize the Firebase console to push these notifications every time i push an update. Does anyone know how to automate this? Thanks!
You can easily do that by listening/Observing to any data change at a particular location in firebase. If new child is added to that path, associated block will be called.
In your case, you can observe UpdatesTableView. and whenever you post any update, call the block which will send notification to all users.
If you are using Swift:
func observe(_ eventType: FIRDataEventType, with block: #escaping (FIRDataSnapshot) -> Void) -> UInt
If you are using Objective C:
- (FIRDatabaseHandle)
observeEventType:(FIRDataEventType)eventType
withBlock:(nonnull void (^)(FIRDataSnapshot *_Nonnull))block;
According to official firebase documentation :
observeEventType:withBlock: is used to listen for data changes at a particular location. This is the primary way to read data from the
Firebase Database. Your block will be triggered for the initial data
and again whenever the data changes.
And, Whenever you would like to stop listening to data changes, you can Use removeObserverWithHandle
Use removeObserverWithHandle: to stop receiving updates. - parameter:
eventType The type of event to listen for. - parameter: block The
block that should be called with initial data and updates. It is
passed the data as a FIRDataSnapshot. - returns: A handle used to
unregister this block later using removeObserverWithHandle:
For more and detailed information, Read iOS firebase#Attaching Observers to read data Documentation.
Also, For sending Notifications to users effieciently, you can use Firebase Notification. Have a look at it. i dont know about your usecase properly, But i think this will help.
I also stucked with same problem where I wanted to show notification to users whenever data changes in Firebase irrespective of application in foreground or background.
I achieved it by binding ChildEventListener with a service which keeps running in background. At every childAdded event data is stored in sqlited db and a new notification object is created and shown to user.
I'm trying to call multiple request from the share extension.
The request flow is follows
1. call request one - returns id
2. call request two using request one id
3. call request three using request two id
To make this work, I only have to dismiss the extension sheet after the request three completion.
As per apple documentation we can't hold the extension sheet for a long time. So we have to use the background session for each request and dismiss the extension sheet immediately.
But in my case the requests depends on its previous request completion. So if we dismiss the extension sheet then the OS kills the extension from memory and the request two and three calls never be made.
Is there any way to call these request one by one?
Any suggestion will be helpful. Thanks in advance.
I need something similar to Facebook's offline post capabilities. Basically I want users to create content locally on the device regardless of connection state, and whenever internet becomes available it should POST/PUT to the server.
I've searched the internet for a solution and I found that NSURLSessionUploadTask can be used for POST-ing in the background. But I couldn't figure out if the following scenarios are supported:
Will my task remain in the background queue when the user is offline and will the operating system try to execute items in the queue upon reconnecting with a network?
What happens if the application is force-closed by the user or crashes?
What happens if the operation fails?
First of all, background NSURLSession allows file upload only. If that is ok for you:
The task will be in the queue until it receives a server answer.
If your app is force-closed, the task will still be executing. When the request is done, your app will be launched in non-interactive background state and receive application:handleEventsForBackgroundURLSession:completionHandler:. After you process the signal and call the completion handler or 30 second timeout, the app will be closed.
I the operation fails, you will receive URLSession:task:didCompleteWithError:
There is a good tutorial on background NSURLSessions. I suggest you to read all 4 parts of this great article.
If file upload is not an option for you, i suggest you to save information into local database and then wait for internet is reachable. (a good approach here is use of Reachability library, Alamofire allows to do that too). When internet becomes available, simply call your http requests with saved data.
We were running into connectivity issues with our internal apps, so we wrote a Swift framework that allows any network operations to be enqueued and sent whenever the device has access to the internet -
https://cocoapods.org/pods/OfflineRequestManager. You'll still have to handle the network request itself within the object conforming to OfflineRequest, but it sounds like a good fit for your use case.
The simplest use case would look something like the following, though most actual cases (saving to disk, specific request data, etc.) will have a few more hoops to jump through:
import OfflineRequestManager
class SimpleRequest: OfflineRequest {
func perform(completion: #escaping (Error?) -> Void) {
doMyNetworkRequest(withCompletion: { response, error in
handleResponse(response)
completion(error)
})
}
}
///////
OfflineRequestManager.defaultManager(queueRequest: SimpleRequest())
Perhaps I have been reading the wrong stuff, but one thing that all of the literatures that I have been reading seem to agree on is that: iOS does not allow background threads to run for longer than ten minutes. That seems to violate one of the greatest principles of app development: the internet should be invisible to your users. So here is a scenario.
A user is going through a tunnel or flying on an airplane, which causes no or unreliable network. At that instant, the user pulls out my email app, composes an email, and hits the send button.
Question: How do I the developer make sure that the email is sent when network becomes available? Of course I am using email as a general example, but in reality I am dealing with a very much simple http situation where my app needs to send a POST to my server.
Side Note: on android, I use Path’s priority job queue, which allows me to set it and forget it (i.e. as soon as there is network it sends my email).
another Side Note: I have been trying to use NSOperationQueue with AFNetworking, but does not do it.
What you want to achieve can be done using a background NSURLSession. While AFNetworking is based on NSURLSession I’m not quite sure if it can be used with a background session that runs while your app doesn’t. But you don’t really need this, NSURLSession is quite easy to use as is.
As a first step you need to create a session configuration for the background session:
let config = URLSessionConfiguration.background(withIdentifier: "de.5sw.test")
config.isDiscretionary = true
config.waitsForConnectivity = true
The isDiscretionary property allows the system to decide when to perform the data transfer. waitsForConnectivity (available since iOS 11) makes the system wait if there is no internet connection instead of failing immediately.
With that configuration object you can create your URL session. The important part is to specify a delegate as the closure-based callbacks get lost when the app is terminated.
let session = URLSession(configuration: config, delegate: self, delegateQueue: OperationQueue.main)
To perform your upload you ask the session to create an upload task and then resume it. For the upload task you first create your URLRequest that specifies the URL and all needed headers. The actual data you want to upload needs to be written to a file. If you provide it as a Data or stream object it cannot be uploaded after your app terminates.
let task = session.uploadTask(with: request, fromFile: fileUrl)
task.resume()
To get notified of success or failure of your upload you need to implement the URLSessionDataDelegate method urlSession(_:task:didCompleteWithError:). If error is nil the transfer was successful.
The final piece that is missing is to handle the events that happened while your app was not running. To do this you implement the method application(_:handleEventsForBackgroundURLSession:completionHandler:) in your app delegate. When the system decides that you need to handles some events for background transfers it launches your app in the background and calls this method.
In there you need first store the completion handler and then recreate your URLSession with the same configuration you used before. This then calls it’s delegate for the events you need to handle as usual. Once it is done with the events it calls the delegate method urlSessionDidFinishEvents(forBackgroundURLSession:). From there you need to call the completion handler that was passed to your app delegate.
The session configuration provides some more options:
timeoutIntervalForResource: How long the system should try to perform your upload. Default is 7 days.
sessionSendsLaunchEvents: If false the app will not be launched to handle events. They will be handled when the user opens the app manually. Defaults is true.
Here is a small sample project that shows how everything fits together: https://github.com/5sw/BackgroundUploadDemo
Your app needs to store the data internally and then you either need something which will cause the app to run in the background (but you shouldn't necessarily add something specially if you don't already have a reason to be doing it) or to wait until the user next brings the app to the foreground - then you can check for a network connection and make the call.
Note that e-mail is very different to a POST, because you can pass an e-mail off to the system mail app to send for you but you can't do exactly the same thing with a POST.
Consider looking also at NSURLSessionUploadTask if you can use it.
In three words: you don't.
And that's actually a good thing. I certainly do not want to have to think and speculate about my last 20 apps, if they are still running in the background, using memory and battery and bandwidth. Furthermore, they would be killed if more memory is needed. How would the user be able to predict if it completed its task successfully? He can't, and need to open the app anyhow to check.
As for the email example, I'd go with showing the email as "pending" (i.e. not sent), until it transferred correctly. Make it obvious to the user that he has to come back later to fulfill the job.
While every developer thinks that his app has an extremely good reason for backgrounding, reality is, for the user in 99% it's just a pain. Can you say "task manager"? ;-)
I wrote a pod that does pretty much this - https://cocoapods.org/pods/OfflineRequestManager. You'd have to do some work listening to delegate callbacks if you want to monitor whether the request is in a pending or completed/failed state, but we've been using it to ensure that requests go out in poor or no connectivity scenarios.
The simplest use case would look something like the following, though most actual cases (saving to disk, specific request data, etc.) will have a few more hoops to jump through:
import OfflineRequestManager
class SimpleRequest: OfflineRequest {
func perform(completion: #escaping (Error?) -> Void) {
doMyNetworkRequest(withCompletion: { response, error in
handleResponse(response)
completion(error)
})
}
}
///////
OfflineRequestManager.defaultManager(queueRequest: SimpleRequest())