I've integrated Google Analytics iOS SDK in my iOS App, I want to set a long dispatch interval to avoid frequent network calls. I want to set 6 hours or longer interval.
// set Google Analytics dispatch interval, eg: 20 seconds
[GAI sharedInstance].dispatchInterval = 6*60*60; // dispatch after every 6 hours
I have few queries:
Q1. What will happen if App is killed just before the data is dispatched, will data be sent immediately when app is launched next time? (eg: app killed just few minutes before the dispatch interval).
Q2. Let's suppose app tries to dispatch data after 6 hours but network is not available at that time. will data be dispatched again after next 6 hours as aggregate of 12 hours data?
Any suggestion for optimised approach? I don't want to consume network bandwidth after every few seconds or minutes just for minor data.
dispatchInterval default is 120 (2 min).
Did you send a lot of datas? If you have vital datas, I suggest to keep it as 120(or better). As it use very minimal bandwidth.
If you are offline, the data will be sent when you are online again. (use event to test it easily in your app)
According to Google.:
Data collected using the Google Analytics SDK for iOS is stored locally before being dispatched on a separate thread to Google Analytics.
If a user loses network access or quits your app while there are still hits waiting to be dispatched, those hits are persisted in local storage. They will be dispatched the next time your app is running and dispatch is called.
More info here: https://developers.google.com/analytics/devguides/collection/ios/v3/dispatch
Related
I am trying to call an endpoint after every 5 minutes and it's working fine with Timer when app is active but when app goes to background the Timer stops firing because timers don't work in background. Is there any possible way to achieve this even with the use of private api because i am not planning to upload the app on AppStore.
In a word, no. Apple goes to significant lengths to prevent apps from doing this sort of thing since it is a significant battery drain.
You might look at using the BGTaskScheduler API to schedule background requests that you would like the system to perform on your behalf, but you won't get a frequency anywhere near every 5 minutes.
I have a app that starts in the background, and since iOS 13 gets about 30s of background runtime using beginBackgroundTask(expirationHandler). I am trying to fetch data from an external service that takes about 40s to calculate its final output, so I need to extend background fetch and set a DispatchQueue for 40-60s later, or directly call the function in background 60s later.
I have looked up Background fetch, but I don't think it is adequate, for it fetched data forever (and on big time intervals), while I only need it 1 minute after the background calculations have finished.
I also looked at similar posts, which where outdated saying iOS could background task for 3 or 10 minutes as it could before iOS 13 and iOS 7
For context, the app receives a BLE packet in background making the app background task for about 30s, and sends the received data to a server which makes certain calculations, updating a GET http method which gives the app its final results
Clarification: I don't have access or can modify the server.
If there is not a way, is there any similar methods of doing the same thing?
I'm using C# (Xamarin) on iOS, but I suspect this question applies to those programming in Objective C as well. iOS 7 introduces the background "fetch" functionality which lets the app download data while it is in the background.
All of the docs I've read (on both Xamarin's and Apple's sites) state that this functionality is for downloading updates, and that you have around 30 seconds to finish the download; however, nowhere are restrictions stated. I'm wondering if it's acceptable for my app to also upload things to our servers when in the background.
Yes!
Sorry for the short answer. I have implemented fetch in one of my apps available in AppStore where I upload or download a very small txt file. You are right about 30 sec window. So far its been working fine with no problems.
You can even simulate fetch upload and download in your XCode simulator to see if you run into any time limit problem.
Again the point of fetch is to keep your upload / download data light and you already know that you cannot control how frequent fetch wakes up to do those action. It maybe every 10 mins or once a day depending upon users internet usage pattern.
Yes you can upload data/file whenever Background fetch method is triggered and you are right like rain about the 30 sec window.
I have managed to increase the 30 sec window to around 180 sec (3 mins) by combining the background fetch with UIBackgroundTaskIdentifier.
From iOS 7 180 sec (3 mins) is the maximum permitted time for iOS apps for background execution before the app goes into suspended mode, Earlier it was around 600 sec (10 mins).
I am working a cocoa touch static library for the applications, and the library has a feature to download network resources by NSOperation in the period time, and provide some methods.
I knew the IOS applications enter the background has limited,(like 5 seconds in main thread, 10 min to long task...) So I want to know IF some application used my library entered in the background, My Library's period download task will be terminated or alive? And the application also used my library's function successfully?
Think of moving into the background as having your app 'freeze dried" - all state is frozen at that moment. When your app moves to the foreground, then the app starts running using the now somewhat dated information. NSTimers etc will continue to work but the "gap" between the last firing and the next firing will be huge. [I believe (but don't recall for sure) that if you had had a timer set for 2 min, and you went into the background with 1 min remaining for say 10 min, that when you move to the foreground the timer will fire immediately].
What I ended up doing was keeping a NSDate object that had the time of the last firing - so I could detect large gaps due to getting moved into the background - and taking appropriate action.
Note that web fetches etc that were in process should just return a timed out status - but again, if you keep a NSDate around of the time you initiated the fetch, you can detect this case.
I can't find any specific documentation about the dispatchPeriod variable in the Google Analytics SDK for iOS.
If I set it to 10 does that mean it will send data to the Google Analytics server every 10 seconds? Does it only send data if new page views or events have been recorded or is it going to send data regardless? I don't want to use this feature if it will eat up too much battery life but my app has very few events to record (basically just launching and exiting). If I set the dispatch time to 10 seconds and only record events when the app opens and when it closes will it be continually dispatching during my apps runtime or will it only dispatch when those events are recorded?
I have just added Google Analytics to my app and here is what I found out:
If you don't explicitly call dispatch and have set the dispatchPeriod to let's say 10 secs, then when you call trackPageview/Event/Whatever, these requests to Google Analytics are being queued and actually sent in those 10 secs periods. If there are no requests in the queue, your app doesn't send anything (to be precise I didn't sniff the network communication, but at least the GANTrackerDelegate methods are not called).
Confirmed, just sniffed communication with Wireshark and there is no traffic between my iDevices and the world when I don't track anything.