I would like to add Flurry to an iPad app that is meant to stay running in the foreground for several weeks.
Flurry apparently only uploads information to its servers on events such as app start, app close, app pause, but I don't expect my app to enter those states very often. I need app feedback sooner.
Is it possible to force Flurry to send data on a timer, say every hour or two?
I found a way that seems to work. To test, I created an NSTimer that calls [FlurryAPI startSession:#"yourKeyHere"] every five minutes, then let my program run without stopping or pausing it in any way, and the event data is appearing on the Flurry server.
The comments above that method in the .h file do say "start session, attempt to send saved sessions to server", so in a sense it's documented, but it feels like a hack to have to call something called startSession more than once per application run. This is partly why I'm switching to MixPanel, which has a documented upload interval feature.
Related
I'm currently working on an iOS app which involves recording and uploading videos (from the built-in camera) to a server.
It all works reasonably fine and dandy, but for a new version, the customer has requested a new feature: continuing this process without needing the app to up on the screen, and active.
At present, you record a video, it's stored as an MP4 on the file system, and a background thread uploads the file to the server. This all happens while the app is open, culminating in a screen which essentially tells you to wait until the process has finished.
If you press the home button to "minimise" the app (I'm not fluent in iOS terminology, forgive me), currently all upload processes are paused. The customer wants to have it so that you can minimise and do something entirely different as this process continues, with a notification being shown once the uploads are complete.
My understanding is that iOS offers a few special cases for downloading, streaming music and location stuff.
Supposedly once upon a time you could obtain ten minutes or so of background time while your app was minimised to finish tasks - after which time iOS would forcefully pause everything until the app was front and active again. This apparently has been changed in newer versions of iOS meaning you can't rely on a specific figure anymore - but ten minutes wasn't really good enough anyway.
I can think of hacky ways of abusing the above features but I'm half-concerned Apple might discover this during the iTunes submission process. Really I'm looking for a cleaner method - how do I continue uploading videos while the app is minimised?
I am assuming there's a solution - Dropbox can handle this situation?
Surprisingly I got somewhere with this, despite quite a few guides suggesting it was virtually impossible and even Dropbox admitting it has to do a hacky location-based thing.
The code was utilising the NSURLSession class, and for uploading, you use its uploadTaskWithStreamedRequest() method, passing an HTTP request and getting a NSURLSessionUploadTask instance in return.
What wasn't immediately clear to me, however, was that "resuming" that task led to files being uploaded independently from the rest of the app, i.e. when the app is minimised, this task continues until it either completes or iOS forces it to pause.
In a sense I had already achieved what I asked for without realising, however this task can still be interrupted by iOS after a few seconds. The rest of the app is also paused, so communication is hampered until the app is brought back to the front again.
The trick is these two methods:
uploadTaskID = UIApplication.sharedApplication().beginBackgroundTaskWithExpirationHandler({})
and
UIApplication().sharedApplication().endBackgroundTask(uploadTaskID)
with these in place, any code after the "begin" function will run regardless of whether the app is minimised, and will do so until the "end" function is called. With a bit of tweaking, I've been able to get files to upload sequentially and post a notification when the process is done.
I haven't seen this solution be hinted at so it might be a bad idea, but it seemingly works.
I am looking for a good way how to make my app "upToDate". These are my requirements:
I have an RESTful Webservice, with tasks for different users. Every user has an iOS App, which should get automatically updated when the Server/Service assigned a task to that User.
So first ill created a manuall "Sync" Button, which checks for new Tasks. Fetches the data with Alamofire, and updated the UI.
But, my goal is automatically sync if there are new tasks.
So, ill guess there are 2 different ways to solve that:
1. Make a Background Fetch (with a NStimer?) every xx Minutes and check if there are new tasks.
After checking that tutorial here:
http://www.raywenderlich.com/92428/background-modes-ios-swift-tutorial i am not sure if a background fetch is a good way to solve that. In that case the App uses an scheduler, to check once for new updates, and not every xx minutes.
So in my case i would create an NStimer in the AppDelegate (maybe in applicationDidEnterBackground) and check every xx minutes for new data (but when there are 3 days not any new task, that would be unnecessary battery consumption, or?)
2. Using Push Notifications.
My other idea is to use Push Notifications, so when there is a new task, ill send a Push Notification an manually start the sync. In my opinion that would use less battery, because he will only start the sync when there is a new task available.
Generaly Questions about using Background Services
So ok, if the user finished the task, some data should be automatically uploaded to the server. Normally not a problem, with the manual sync ill check if there is something to upload. But, what if, when there is no internet connection (ill check if before uploading) - and the user do not press on "manual sync".
So i would prefer to check in my "Background Service" if ill got an Internet connection, and if yes - start uploading some data.
Ill know this is not a specific question, but ill think there are lots of users who have the same requirements and it would be great if someone can help me out whats the best way to solve that in the best and practical way.
Thanks in advance!
Background updates sound wonderful until you realise that Apple throttles them heavily: you can ask to be updated as frequently as possible, but iOS decides what that value actually means based on how often users open your app and when they do so. Apple considers background updates the kind of thing that should happen just before a user opens your app so the latest content is right there, rather than something that runs proactively in the background.
Your push notification solution is a better one, particularly if you use CloudKit to subscribe to record change events using CKSubscription and CKNotificationInfo. If you do this you'll automatically get push messages in your app, so you can get what you want with very little work. You can read my tutorial for more information on subscribing to CloudKit to get push messages.
I have made an application which needs to send Location and status update to server every 1 minute.
I tried below ways but none of them helped me out. is there any solution for this?
1 - NSTimer - Many people suggested to do this way. but the problem is going to backgroundMode and it only works for 20 minutes. after that application stops sending data.
2 - BackgroundFetchMode - at beginning looks like the correct solution. But this ability do not guarantee to run application at every 1 minute. it has an algorithm that iOS decide which application should run.
This API is not like a timer task, system will decide when to call the
handler depending on many constraints.so if you set timeInterval to
2.00f(2secs), handler is called for every 2+(minimum) secs.
3 - LocationUpdate - again this way do not works because it only run your application if you move at least 500 meter.
Apps can expect a notification as soon as the device moves 500 meters
or more from its previous notification. It should not expect
notifications more frequently than once every five minutes. If the
device is able to retrieve data from the network, the location manager
is much more likely to deliver notifications in a timely manner.
4 - Push Notifications - in an article said in this method you can run an application within defined time and it really does !
you can schedule a notification within defined schedule time. but the problem is showing notification to user. which I need something silent in Background.
Also , you can not run some code every 1 minute. it just show a notification to user. and user should tap on your notification and then didReceiveLocalNotification
can be available and you can run the code.
As Apple states in their documentation:
In iOS, only specific app types are allowed to run in the background:
Apps that play audible content to the user while in the background, such as a music player app
Apps that record audio content while in the background
Apps that keep users informed of their location at all times, such as a navigation app
Apps that support Voice over Internet Protocol (VoIP)
Apps that need to download and process new content regularly
Apps that receive regular updates from external accessories
Apps that implement these services must declare the services they
support and use system frameworks to implement the relevant aspects of
those services. Declaring the services lets the system know which
services you use, but in some cases it is the system frameworks that
actually prevent your application from being suspended.
You can read all about implementing and declaring those background tasks in the link. However, if yours is another type of App, or you cannot use the system frameworks, there is no way for your App to run in the background indefinitely. And even if it is, you should always expect that the system stops your task for some reason (f.e. restarting the phone).
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.
I've been looking at some analytics frameworks for mobile apps, but as usual I am never satisfied and now I have decided to roll my own solution. I will only track a small amount of things such as launches/certain taps/session length. Not advanced like flows etc.
I noticed that most analytics use application:didFinishLaunchingWithOptions to run something like a startSession. Makes sense.
But do they don't seem to track this method applicationDidBecomeActive and I am not sure why. If the user starts a session and does something in 10 seconds, then minimises the app for a couple of minutes and later opens it again. Then it wouldn't record this new session would it? Or is there usually some code within the framework itself to distinguish events like this.
After writing this question it seems like a dumb question, since each framework can (and probably do) have way different solutions. But if anyone have dealt with this I'd love some info on best practises (or any practices).
When home button pressed and app put in multitasking menu (session still active)
-(void)applicationWillResignActive:(UIApplication*)application
After 3 minutes of inactivity in multitasking menu (not being re-opened) you can kill your session here
-(void)applicationDidEnterBackground:(UIApplication*)application
When app is re-opened use this method to compute the difference between going on background and the time your app gets reopened. If this time interval exceeds lets say 3 minutes kill the old session and create new one
-(void)applicationWillEnterForeground:(UIApplication*)application
User deletes the app from multitasking menu kill your session here
-(void)applicationWillTerminate:(UIApplication*)application