{
	"id": "113911",
	"key": "TIMOB-13776",
	"fields": {
		"issuetype": {
			"id": "1",
			"description": "A problem which impairs or prevents the functions of the product.",
			"name": "Bug",
			"subtask": false
		},
		"project": {
			"id": "10153",
			"key": "TIMOB",
			"name": "Titanium SDK/CLI",
			"projectCategory": {
				"id": "10100",
				"description": "Titanium and related SDKs used in application development",
				"name": "Client"
			}
		},
		"fixVersions": [],
		"resolution": null,
		"resolutiondate": null,
		"created": "2013-05-07T07:01:05.000+0000",
		"priority": {
			"name": "High",
			"id": "2"
		},
		"labels": [
			"enterprise_cluster"
		],
		"versions": [],
		"issuelinks": [
			{
				"id": "29423",
				"type": {
					"id": "10002",
					"name": "Duplicate",
					"inward": "is duplicated by",
					"outward": "duplicates"
				},
				"inwardIssue": {
					"id": "115636",
					"key": "TIMOB-14145",
					"fields": {
						"summary": "iOS: Analytics - If you background an iOS app, the background event does not get sent until next launch",
						"status": {
							"description": "The issue is considered finished, the resolution is correct. Issues which are closed can be reopened.",
							"name": "Closed",
							"id": "6",
							"statusCategory": {
								"id": 3,
								"key": "done",
								"colorName": "green",
								"name": "Done"
							}
						},
						"priority": {
							"name": "High",
							"id": "2"
						},
						"issuetype": {
							"id": "1",
							"description": "A problem which impairs or prevents the functions of the product.",
							"name": "Bug",
							"subtask": false
						}
					}
				}
			},
			{
				"id": "29206",
				"type": {
					"id": "10003",
					"name": "Relates",
					"inward": "relates to",
					"outward": "relates to"
				},
				"inwardIssue": {
					"id": "115264",
					"key": "TIMOB-14059",
					"fields": {
						"summary": "Analytics: Ti.end event not sent after killing and relaunching the app on Android",
						"status": {
							"description": "The issue is considered finished, the resolution is correct. Issues which are closed can be reopened.",
							"name": "Closed",
							"id": "6",
							"statusCategory": {
								"id": 3,
								"key": "done",
								"colorName": "green",
								"name": "Done"
							}
						},
						"priority": {
							"name": "Critical",
							"id": "1"
						},
						"issuetype": {
							"id": "1",
							"description": "A problem which impairs or prevents the functions of the product.",
							"name": "Bug",
							"subtask": false
						}
					}
				}
			}
		],
		"assignee": null,
		"updated": "2018-02-28T20:03:32.000+0000",
		"status": {
			"description": "This issue was once resolved, but the resolution was deemed incorrect. From here issues are either marked assigned or resolved.",
			"name": "Reopened",
			"id": "4",
			"statusCategory": {
				"id": 2,
				"key": "new",
				"colorName": "blue-gray",
				"name": "To Do"
			}
		},
		"components": [
			{
				"id": "10206",
				"name": "iOS",
				"description": "iOS Platform"
			}
		],
		"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.\r\n\r\nIn other words we're seeing:\r\n\r\nti.enroll\r\nti.start\r\n(flush batch to server)\r\nti.background\r\n… time passes between sessions.. simulator is restarted… \r\nti.start\r\n(flush batch to server)\r\nti.background\r\netc...\r\n\r\nIs 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?\r\n\r\nThis 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).",
		"attachment": [],
		"flagged": false,
		"summary": "ti.background events are not sent until the next app session start",
		"creator": {
			"name": "mgoff",
			"key": "mgoff",
			"displayName": "Michael Goff",
			"active": true,
			"timeZone": "America/Los_Angeles"
		},
		"subtasks": [],
		"reporter": {
			"name": "mgoff",
			"key": "mgoff",
			"displayName": "Michael Goff",
			"active": true,
			"timeZone": "America/Los_Angeles"
		},
		"environment": null,
		"comment": {
			"comments": [
				{
					"id": "250580",
					"author": {
						"name": "ingo",
						"key": "ingo",
						"displayName": "Ingo Muschenetz",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"body": "[~ayeung] and [~blainhamon] can you guys add your thoughts?",
					"updateAuthor": {
						"name": "ingo",
						"key": "ingo",
						"displayName": "Ingo Muschenetz",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"created": "2013-05-07T17:13:24.000+0000",
					"updated": "2013-05-07T17:13:24.000+0000"
				},
				{
					"id": "250593",
					"author": {
						"name": "ayeung",
						"key": "ayeung",
						"displayName": "Allen Yeung",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"body": "Not really sure how this is implemented in iOS, but we don't have the Ti.Background event in android.\n\nIn 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.",
					"updateAuthor": {
						"name": "ayeung",
						"key": "ayeung",
						"displayName": "Allen Yeung",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"created": "2013-05-07T17:46:53.000+0000",
					"updated": "2013-05-07T17:46:53.000+0000"
				},
				{
					"id": "250598",
					"author": {
						"name": "mgoff",
						"key": "mgoff",
						"displayName": "Michael Goff",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"body": "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.",
					"updateAuthor": {
						"name": "mgoff",
						"key": "mgoff",
						"displayName": "Michael Goff",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"created": "2013-05-07T18:09:46.000+0000",
					"updated": "2013-05-07T18:09:46.000+0000"
				},
				{
					"id": "250627",
					"author": {
						"name": "mgoff",
						"key": "mgoff",
						"displayName": "Michael Goff",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"body": "Another observation on iOS is that when you:\n\n1. background the app\n2. kill it (press and hold, hit the wiggly X)\n3. relaunch the app\n\nThe ti.background event is never sent.",
					"updateAuthor": {
						"name": "mgoff",
						"key": "mgoff",
						"displayName": "Michael Goff",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"created": "2013-05-07T20:47:52.000+0000",
					"updated": "2013-05-07T20:47:52.000+0000"
				},
				{
					"id": "250714",
					"author": {
						"name": "blainhamon",
						"key": "blainhamon",
						"displayName": "Blain Hamon",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"body": "> 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?\n\nBoth. 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:\n\n# Batch up the event to fire the next time we can (IE, at start time next time)\n# 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.\n\nWe decided to stick to 1.\n\nBecause 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.\n\nMoving that the ticket be marked invalid.",
					"updateAuthor": {
						"name": "blainhamon",
						"key": "blainhamon",
						"displayName": "Blain Hamon",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"created": "2013-05-08T01:01:57.000+0000",
					"updated": "2013-05-08T01:01:57.000+0000"
				},
				{
					"id": "250719",
					"author": {
						"name": "ngupta",
						"key": "ngupta",
						"displayName": "Neeraj Gupta",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"body": "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?",
					"updateAuthor": {
						"name": "ngupta",
						"key": "ngupta",
						"displayName": "Neeraj Gupta",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"created": "2013-05-08T01:06:33.000+0000",
					"updated": "2013-05-08T01:06:33.000+0000"
				},
				{
					"id": "250721",
					"author": {
						"name": "ayeung",
						"key": "ayeung",
						"displayName": "Allen Yeung",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"body": "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.",
					"updateAuthor": {
						"name": "ayeung",
						"key": "ayeung",
						"displayName": "Allen Yeung",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"created": "2013-05-08T01:10:28.000+0000",
					"updated": "2013-05-08T01:10:28.000+0000"
				},
				{
					"id": "250723",
					"author": {
						"name": "ngupta",
						"key": "ngupta",
						"displayName": "Neeraj Gupta",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"body": "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?",
					"updateAuthor": {
						"name": "ngupta",
						"key": "ngupta",
						"displayName": "Neeraj Gupta",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"created": "2013-05-08T01:15:18.000+0000",
					"updated": "2013-05-08T01:15:18.000+0000"
				},
				{
					"id": "250837",
					"author": {
						"name": "ayeung",
						"key": "ayeung",
						"displayName": "Allen Yeung",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"body": "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.",
					"updateAuthor": {
						"name": "ayeung",
						"key": "ayeung",
						"displayName": "Allen Yeung",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"created": "2013-05-08T17:13:50.000+0000",
					"updated": "2013-05-08T17:13:50.000+0000"
				},
				{
					"id": "250953",
					"author": {
						"name": "ngupta",
						"key": "ngupta",
						"displayName": "Neeraj Gupta",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"body": "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.",
					"updateAuthor": {
						"name": "ngupta",
						"key": "ngupta",
						"displayName": "Neeraj Gupta",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"created": "2013-05-09T06:40:03.000+0000",
					"updated": "2013-05-09T06:40:03.000+0000"
				},
				{
					"id": "413981",
					"author": {
						"name": "lmorris",
						"key": "lmorris",
						"displayName": "Lee Morris",
						"active": false,
						"timeZone": "America/Los_Angeles"
					},
					"body": "Closing ticket as invalid.",
					"updateAuthor": {
						"name": "lmorris",
						"key": "lmorris",
						"displayName": "Lee Morris",
						"active": false,
						"timeZone": "America/Los_Angeles"
					},
					"created": "2017-03-20T21:27:50.000+0000",
					"updated": "2017-03-20T21:27:50.000+0000"
				},
				{
					"id": "414497",
					"author": {
						"name": "pclark",
						"key": "pkclark",
						"displayName": "Patrick Clark",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"body": "[~lmorris] why?  It's very much a valid issue.",
					"updateAuthor": {
						"name": "pclark",
						"key": "pkclark",
						"displayName": "Patrick Clark",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"created": "2017-03-21T21:47:29.000+0000",
					"updated": "2017-03-21T21:47:29.000+0000"
				}
			],
			"maxResults": 12,
			"total": 12,
			"startAt": 0
		}
	}
}