Alamofire for iOS Track Number of Active Download Requests - ios

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.

Related

Alamofire, push a new request ahead of others queued

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.

Watch Kit Asynchronus data

I am creating a simple watch kit app that shows me the local bus schedule. To get the schedules I have to make a request to the bus company's website and parse the HTML. (They have no public api....)
Alamofire is used to make a request and then parsing the HTML with SwiftySoup. The data is then saved into an array with structs and the table is created. Then the array is saved to a JSON file. So when the app is force closed and starts again, the app checks if the current time is past the first bus time, if true the app request the website again to get the next schedules otherwise it just creates the table with the number of schedules.
Since Alamofire is doing an asynchronous request, the app finishes "starting" even if it does not have any data. How can I "force" the app to wait for the request and parsing to be finished before displaying the UI?
As Josh Caswell mentioned it is not possible. So created UI for the loading state.
If the app did not have any schedules cached or the cached data was old, the app pushed the loading interfacecontroller. When the loading was finished the interfacecontroller poped itself and the main interfacecontroller initilized with the corred UI.

why are my new flurry parameters not showing up?

I have been tracking flurry events in my iOS app and they show up in the dashboard. I tried to add a new parameter to an existing event, and then activated the event on my phone a bunch of times yesterday, but I still don't see any occurrences of the new parameters on that event in the dashboard.
Does flurry not allow you to add new parameters to an existing event?
We noticed this too a little bit ago, and emailed support#flurry.com about it. Here's what they said:
Typically, Flurry sessions never completely report back to Flurry until the next time the app is launched. So, be sure to launch the app one more time after you complete a testing session. Furthermore you should make sure you launch the same build of the app. If you make a new build between sessions you may be removing incomplete sessions before they get reported. If you are running tests via an emulator, please ensure that the home button is pressed before closing the app. Then you should relaunch the app one more time with the same build to ensure all session data is reported.
If the app pauses or moves to the background for more than 10 seconds, the NEXT time the app runs, Flurry agent will automatically create a new session and end the previous session. Otherwise, Flurry agent will continue the same session. This can be updated via the setSessionContinueSeconds method. If the app is terminated, a new session will be created when the app runs again.
When we receive the complete session data (after the app is relaunched) the event logs should update first within 10 minutes or so. Please allow about 6 hours for this to populate to the dashboard, parameters pie chart etc.
Basically, what we were doing is just booting up the app, doing the thing that would send an analytic event, then quitting the app or whatever. Which wasn't giving the flurry agent enough time to actually send the event. (turns out that, contrary to the log events, flurry wasn't sending the log event right then :/)
Hope that helps!
The Flurry SDK only communicates with our servers twice per session. The first time is when the session is started and sets the timestamp for the session, counts a new user or updates an existing user as active. The second time is when the session ends and all event data is sent in one batch.
In cases where we do not receive the second report we refer to this as an "incomplete session". This arises in a few scenarios but mainly
-No network connection when the session ends
-The app is sent to the background for >10 seconds and the session continues running
In these cases the event data is stored on the device's disk and sent the next time the app is launched.

Manage iPhone app both offline and online

I am stuck to a point, I am managing my app offline also.. first time i get all data (images) from a webservices and store its path into sqlite, now I take an int value 0 or 1 and store its state into NSUserDefaults now I am facing problem in updating those images, like if images are changed how should I notify into my app, I searched it on Google and only solution is to send push notification to app when record is updated. What if user do not allow push notification?
Is there any other solution to manage app offline and update only when record is changed from online database?
You can sync your Data with server Periodically , like call a webservice which check if images have been changed then fetch the new images and if images are not changed then continue with old data.You can add a Boolean Value on server end which can tell you if data on server is updated or not or you can check this with Time stamp like when data is updated last time then compare your local time with Server time at which data has been updated . Good Luck !!
There are ways to handle such kind of situation:
Use push notifications which is the best solution for such situation.
Query the server periodically by giving the ability to the user to set the time interval from app settings.
Query the server whenever the app came from background to foreground.
An idea is to use BackgroundFetch to update the app content while it is not running. I am using similar fetch for one of my apps where I update the content before the user opens the app. I am fetching a small list of items that is indicating which one is up to date and which is not. Then, at runtime I present an option to the user to manually update these items, but of course you can also download all that while in backgroundfetch. My app is without network reach most of the time, and backgroundFetch will update the items list first thing when there is some internet connection.
There are two important methods here that you need to register, setMinimumBackgroundFetchInterval: and application:performFetchWithCompletionHandler: . You can read more about them in Apples guides for background modes.
You can also check out this good tutorial about this fetching capability: http://www.appcoda.com/ios7-background-fetch-programming/
There is way which has being most popular as most of peoples are preferring
At server side build mechanism, which can send lists of images updated after particular date/time.
To keep track of last sync date/time at locally.
Pinged on server with last date/time in case of first time pass any past date and check for update, if there is then download updated images, Otherwise.
Now you have to decide this process when would be query to server
1) At every first time application will be load. (At didFinishLaunchingWithOptions).
2) Query the server periodically by giving the ability to the user to set the time interval from app settings or else where would be preferable.
3) Query the server whenever the app came from background to foreground.

Is Facebook Caching FBAppEvents

I'm trying to integrate FBAppEvents. I've already created my app and all I need to do now is call FBAppEvents logEvent:
However, I want to know if I need to cache my Events just in case logging wasn't successful due to sudden connection loss or something. If I'm caching them, my app could resend the events.
If FB is caching events and handling failed events on their own, then that would be awesome.
If not, then I would need to create my own event caching. Sadly, I couldn't find callback methods to inform me that events were successfully logged or not. Is there a way I could do to achieve what I want?
From the FBAppEvents documentation page: https://developers.facebook.com/docs/reference/ios/current/class/FBAppEvents
Events are not sent immediately when logged. They're cached and
flushed out to the Facebook servers in a number of situations:
when an event count threshold is passed (currently 100 logged events). when a
time threshold is passed (currently 15 seconds). when an app has gone
to background and is then brought back to the foreground.
Events will be accumulated when the app is in a disconnected state,
and sent when the connection is restored and one of the above 'flush'
conditions are met.

Resources