I have an app that is firing a lot of initial Alamofire GET Requests to an API to eventually collect the data. However there are buttons on the app screen which also fire off POST requests to save etc. Though when i tap on the buttons, the alamofire requests take a long time to fire off due to the fact all the other GET Requests are still running.
Is it possible to make it so I can push the POST request ahead of the queue?
There is no way to do this using Alamofire or the underlying URLSession APIs. What you'd want to do is build your own request queue that lets you keep perhaps half a dozen requests in flight at any time. You would enqueue all of your GETs and then push your POSTs to the front of the line when needed.
Related
I am trying to find a simple way to display a counter in the status bar of my app that shows the current number of active downloads using the AlamoFire package in the default session.
We have both data downloads and image/document downloads that occur sumiltainiously. I cannot find a solution as all my searches either return information about the authtoken interceptor or how to cancel request. I have tried using snippets from both of those solutions but cannot get the function to return more than 1 active request when I know there is actually 3 - 25 active requests in process.
Currently I am using a notification that I created to says a request has started and adding 1 to the counter. I am then also sending a notification when a request completes either successful or unsuccessful that subtracts 1 from the counter. The issue comes when the app is placed in the background and/or there was a request that was retried by the interceptor causing the count to go negative or get stuck being positive.
I have handled the uploads by using my uploads queue and simply retrieving the count. I do not have a similar queue for downloads as the history of them is not as important to us and we don't have start, in process, and completed triggers for them like we do uploads.
I've spent a lot of time looking at the options but am still not 100% clear, so wanted to reach out for some guidance.
Scenario is this:
User submits an HTTPS request to our backend server for some data via an iOS app
Depending on the data, the first (only) request can take a REALLY long time. like, say, 10+ minutes (shocking i know)
When that payload finally does become available and is returned via the HTTPS request, we then want to use it to update the UI in background.
The assumption here is that the user has moved on to another app whilst waiting for the data to arrive (and lets also assume they haven't killed the app).
Is it possible to handle this via iOS 8+ API's without the app being force/killed by Apple when in the background ?
Could we use background task for example?
var backgroundTask: UIBackgroundTaskIdentifier
xxx.beginBackgroundTaskWithName...
etc
Before testing some code blocks we just wanted to see if someone has (a) already done this and/or (b) whether we're heading in the right direction
Thanks for your help.
You should re-think on your web service which may take almost 10 min to process. If you are not able to optimize server task processing time then below one of the idea may be help you.
You can divided your one request into multiple request to reduce processing time and get response in faster way.
Your server should sent notification to app when its done with its task. So app will came to know task is done.
I am not sure why you try to update UI when apps in background mode , you may try to update UI when users come to foreground mode from background mode.
Please check this link which show as example of long running task. Where its use a blank audio play to keep alive app background task.
You can used "Background fetch" functionality.
For learning purpose you can refer this link
If you aren't that into Android, there's something called a "background-service" for the applications in that OS. Which basically gives the developer a opportunity to make some background tasks without forcing the application to be in foreground.
So are there something like this in iOS? (Version 5 and newer) What I basically want to do is to call a API and fetch some JSON data every minute, then parse the result and then present a local notification banner to the user depending on the result that were fetched from the HTTP request. I hardly believe that this shouldn't be possible in iOS, but I haven't found anything like this yet.
Call the API once every minute and fetch some JSON data.
Parse the JSON data into and add some logic to handle the data.
If a local notification should be presented or not, depends on the result from the request.
This can only be done in a very limited manner. Pure background processes are only allowed in special forms (for example media players, VOIP or location based services). You can start limited background tasks with beginBackgroundTaskWithExpirationHandler:, but they won't run forever.
More information can be found here: Run app for more than 10 minutes in background
I have made an application which uploads a bunch of photos to a web server. It does so by repeated html calls, using multiple AFNetworking's AFHTPRequestOperation inside an operation queue. Right now, of the user exits the application, the queue stops. However, I want to continue the uploading queue until it's done, and then let the application go to sleep like it normally does.
I know that iOS provides a background expiration handler using "beginBackgroundTaskWithExpirationHandler" . I also know that AFURLConnectionOperation which is superclass of every HTTP operation class in AFNetworking can use that using
- (void)setShouldExecuteAsBackgroundTaskWithExpirationHandler:(void (^)(void))handler
But is there any way of making this work with an operation queue? Will setting the expiration handler of each operation do the job properly if I want to upload, let's say 10 photos?
I would appreciate any comments on background tasks with AFNetworking, or if anyone has experienced the same problem as me.
When an app goes to background, the OS will decide whether or not to completely stop your app or give it some time to complete what it's doing. In case it wants your app to stop, the expiration handler is called. If that's happening you should suspend all your tasks as fast as possible and prepare for a complete kill of the app, because that is what will happen a very short time after (5 seconds max). Take a look here.
In my app for iPad, I have a requirement that I have to post some data almost after each 30 sec. So for that I'm creating a new http request every time and adding the request to a queue.
Is there any other efficient way to do so?