[TIMOB-13776] ti.background events are not sent until the next app session start
| GitHub Issue | n/a |
|---|---|
| Type | Bug |
| Priority | High |
| Status | Reopened |
| Resolution | Unresolved |
| Affected Version/s | n/a |
| Fix Version/s | n/a |
| Components | iOS |
| Labels | enterprise_cluster |
| Reporter | Michael Goff |
| Assignee | Unknown |
| Created | 2013-05-07T07:01:05.000+0000 |
| Updated | 2018-02-28T20:03:32.000+0000 |
Description
Vasil and I observed while tailing logs of events sent by both the ipad/iphone simulator and from actual devices that end events are buffered in the device until a subsequent session starts again.
In other words we're seeing:
ti.enroll
ti.start
(flush batch to server)
ti.background
… time passes between sessions.. simulator is restarted…
ti.start
(flush batch to server)
ti.background
etc...
Is the policy that a flush happens after a start event (ti.start ti.foreground) or is it based on a timeout or number of event threshold?
This messes up active session calculation by realtime analytics since the session will only be ended when the next session starts (if ever). It seems that if the app is backgrounded or killed gracefully, the final ti.background event could be sent to api.appcelerator.net in a background task when the app enters the inactive state (on iOS at least).
[~ayeung] and [~blainhamon] can you guys add your thoughts?
Not really sure how this is implemented in iOS, but we don't have the Ti.Background event in android. In android, the events are stored into a local database, and then a service is started to send out the analytics events. The service is usually started promptly after the analytics event is stored in the database, but it is possible that events can be queued up during the startup of the service. Even in that scenario, you can tell which events happened first from the timestamp field.
Thanks for the explanation. Yes, on iOS we do see all of the events with timestamps. However, we're working on the realtime analytics solution for 360 that needs more accurate session data. If the background event is not sent out immediately, then it may be hours, days, or never until it's sent out, giving us incomplete session data. The analytics team will implement a heuristic to artificially end sessions, but it would be much better to get timely data from the app itself.
Another observation on iOS is that when you: 1. background the app 2. kill it (press and hold, hit the wiggly X) 3. relaunch the app The ti.background event is never sent.
> Is the policy that a flush happens after a start event (ti.start ti.foreground) or is it based on a timeout or number of event threshold? Both. Analytics events are batched up during normal running as a timeout to avoid battery drain, but during shutdown, there is not enough time to reliably send an analytics message, so we have two options:
Batch up the event to fire the next time we can (IE, at start time next time)
Try to send the event, then be killed and logged as an 'application hung' crash, with no event, even to batch, and be rejected by the app store for crashing.
We decided to stick to 1. Because of this, and because of airplane mode, and because of going into an area with bad coverage, and because of application crashes, and because of end user force-quits before a chance to save the change, it's pretty much guaranteed that analytics will be missing at least one, if not multiple, end events per device. This is a fact of any iOS application. Moving that the ticket be marked invalid.Makes sense for the iOS behavior. I am curious why we do not send background and foreground events for Android applications. At what point Android applications send end events?
Foreground and background don't really make sense in android. You could add it to the onPause()/onResume() on the root activity, but this would be invalid as soon as you open a heavyweight window. There isn't an accurate way for android to track foreground and background since it can also open other activities that aren't specific to your app... like the camera app for example.
OnPause and OnResume is the right terminology. From a user's point of view, when I press the back button, application goes to the background and then I can bring it back to the foreground. Anyway, we are more interested in the end events. When does Android application send session end events?
End events are called in the onDestroy() of the root activity. This can be either when the user completely backs out of the app, or when the user's phone runs out of memory and the os needs to call onDestroy() on the root activity.
Resolving this ticket invalid as it appears that both iOS and Android platforms are sending the correct analytics events providing OS allows them to do so.
Closing ticket as invalid.
[~lmorris] why? It's very much a valid issue.