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
Related
I Did lots of BG tasks in the past, But Trying to get data when app is killed (Even when user is giving Always permission) seems not to work.
I wonder if there is a solution for that.
To make things clear, I am not talking at the moment when app change from Active or Background even to suspended mode. I'm talking about if the user is using the app and set permissions but then kills the app and after that i need every hour to get data from the user and send data to them.
Is there a way to do that?
Can a Today widget help me with that? Does a Today widget "lives" all the time and i can get that from it 24/7?
Whet is working is CLLocation manager. This is working even when the app is killed. But only when the user is changing a location.
I need that to work when the user is in the same place also.
Non of the other methods work. Not BGTask (I need every hour on the hour and not when apple decide to do things), Nor Silent Push Notification for some reason (Regular ones work, but i Don't want to bother the user with a push every hour just for getting and sending data).
Sorry there is no code to show as this is a very general question. But i think that is very important one to many people and can't find an answer for that.
I'm almost certain the answer to this question is 'no', but if it's not, it's worth asking.
My app allows a user to track their anxiety at an interval (e.g. every 15 minutes) while they work. It schedules a local notification to alert the user that 15 minutes is up, and when they touch the notification and open the app, it prompts them to rate their anxiety.
One thing that causes me anxiety when I'm already super stressed is text messages, so I sometimes turn on Do Not Disturb mode while I work. However, I'd still like to hear my app's notifications, and I think this would be a fairly common use case for my user base. Is there a way for my app to request permission to ignore Do Not Disturb, like there is for the app to request permissions to send notifications in the first place? The Apple Clock app can make noise, but I'm guessing they have access to an SDK with greater capabilities.
If the answer is no, like I assume it is, is there a clever work-around for this? (Manually turning off notifications for every other app on my phone, and then turning them back on when I'm done working is not worth it to me.)
Unfortunately no, there is no opt out for Do Not Disturb and any clever workarounds that may exist are likely to get rejected as messing with notifications breaks the guidelines:
2.5.3 Apps that ... disrupt the normal operation of the operating system ... including Push Notifications ... will be rejected.
https://developer.apple.com/app-store/review/guidelines/#software-requirements
You are left with clunky workarounds, like getting your users to manually create their own clock alarms.
I have a volume control app in the iOS store, but one problem that my users have frequently is that the device kicks it for memory control. Is there any way to either force it to stay active (by permission) or to at least alert the user when its no longer active or in danger?
All the answers are under Background Execution in the iOS Developer Library.
Of course, here's the philosophy:
Always try to avoid doing any background work unless doing so improves
the overall user experience.
See Table 3-1 for the types of background execution. There's a category for audio but it requires audio to be played from the app. It does not sound like your app fits in here. So you'll want to look at notifying the user.
You could send a notification to the user when the app falls to background with applicationDidEnterBackground(), or just before it quits with applicationWillTerminate(), supposedly time-permitting.
Running in the background is permitted. I have an app that does it and while the rules have changed and adapting to it has been gut wrenching at times, it is pretty straightforward. In your case, I would think that you could setup to be notified and then just disappear, no? waking from a notification is part of the state changing protocol and you should be able to do that.
As a point of comparison, in Android, background operations like yours would be implemented as services and would have no fear of being terminated. The strangest thing about the way ios chooses to allow background activity is that you are applying for status one time. In Android, I was able to indicate that a single activity should be kept alive when the app is backgrounded, all others could be terminated. There is no way to do that in ios.
I take it my disappear and wait for notifications is probably not going to work for you because there is no way to be notified of volume changes. You must be polling? In which case, you probably are going to have to ask to be kept alive. Would be nice if you could just piggyback on other services, e.g. keep me alive while music is playing.
To answer your other question, yes you will get notified if/when you really are going to get termed, so you could send a notification at that point.
I have a background app with a UIBackgroundMode of location.
I would like my app to additionally contact a server every few or several hours to see if there is some new data for it (because using apple notification push would notify the user and that is not desirable).
Polling is something I would never use on any other OS, but with iOS they don't leave you much choice if there is certain functionality you would like to try to achieve.
If the polling interval is quite lengthy such as a few or several hours between polls, and the polling activity itself only lasts several seconds then the usual knee-jerk reaction about it draining battery life is greatly diminished.
Would a repeating NSTimer fire when an app is in background mode? If not is there another type of timer or mechanism available?
If it's just to check for new content, and not really time sensitive, you COULD use the significantChanges background location method...but if the user stayed fairly immobile it'd rarely/never fire. I would probably also add the update check in applicationWillEnterForeground to be more sure
No, that's not allowed. You should have a look at Push Notifications and find a server side solution.
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.