{
	"id": "132573",
	"key": "ALOY-1070",
	"fields": {
		"issuetype": {
			"id": "2",
			"description": "A new feature of the product, which has yet to be developed.",
			"name": "New Feature",
			"subtask": false
		},
		"project": {
			"id": "11113",
			"key": "ALOY",
			"name": "Alloy",
			"projectCategory": {
				"id": "10400",
				"description": "Tools for developing applications",
				"name": "Tooling"
			}
		},
		"fixVersions": [],
		"resolution": null,
		"resolutiondate": null,
		"created": "2014-07-03T12:33:53.000+0000",
		"priority": {
			"name": "Low",
			"id": "4"
		},
		"labels": [],
		"versions": [],
		"issuelinks": [],
		"assignee": null,
		"updated": "2018-03-07T22:26:05.000+0000",
		"status": {
			"description": "The issue is open and ready for the assignee to start work on it.",
			"name": "Open",
			"id": "1",
			"statusCategory": {
				"id": 2,
				"key": "new",
				"colorName": "blue-gray",
				"name": "To Do"
			}
		},
		"components": [
			{
				"id": "12326",
				"name": "XML",
				"description": "View XML and parsing"
			}
		],
		"description": "h3. TL;DR:\r\n- Alloy views at compile time generate native primitives\r\n- Native code would use these objects to build the UI bypassing JS land for better speed and performance including bypassing the bridge\r\n- No more compiling markup to business logic that can lead to (IMHO at least) hard to define corner cases.\r\n- This would make Alloy views titaniums cross platform version of iOS xib files\r\n- Sample code can be found here -> https://gist.github.com/mattapperson/0e9ef2947c1b1221d619\r\n\r\n\r\nh3. My full thoughts\r\nIMHO Alloy views are inefficient, they might save on dev time, or draw on familiar concepts for those with a web background, but they don't add a lot in terms of performance and stability VS well written vanilla Ti. Not to mention if/when there are errors in the compiled JS from the views.\r\n\r\nI suggest that titanium via a module or built in APIs support the processing of Alloy markup files.\r\n\r\nClearly, parsing XML at runtime is a bad idea, the Carbon Titanium module used JSON as parsing was faster, but this was still not ideal as parsing adds overhead.\r\n\r\nI would thus further suggest that markup be compiled to native primitives such as in this example for iOS -> https://gist.github.com/mattapperson/0e9ef2947c1b1221d619\r\n\r\nI would argue that compile directly to iOS/Android/Hyperloop views is IMHO a bad idea in that you can get odd corner cases, and that dynamically built views based on data such as explained above is better and more stable.\r\n\r\n*Note:* I did look into maybe compiling alloy vies to xib's and such, but xib's dont have all the features that alloy markup supports leading to business logic generation along with native view markup... this felt nasty/ugly so moved on from that idea... maybe someone else is smarter then me and can make that work in a less ugly way",
		"attachment": [],
		"flagged": false,
		"summary": "\"Native\" Alloy views",
		"creator": {
			"name": "mattapperson",
			"key": "mattapperson",
			"displayName": "me@gmail.com",
			"active": true,
			"timeZone": "America/Los_Angeles"
		},
		"subtasks": [],
		"reporter": {
			"name": "mattapperson",
			"key": "mattapperson",
			"displayName": "me@gmail.com",
			"active": true,
			"timeZone": "America/Los_Angeles"
		},
		"environment": null,
		"comment": {
			"comments": [
				{
					"id": "312425",
					"author": {
						"name": "mpmiranda",
						"key": "mpmiranda",
						"displayName": "Mauro Parra-Miranda",
						"active": true,
						"timeZone": "America/Mexico_City"
					},
					"body": "The original reporter is me@mattapperson.com",
					"updateAuthor": {
						"name": "mpmiranda",
						"key": "mpmiranda",
						"displayName": "Mauro Parra-Miranda",
						"active": true,
						"timeZone": "America/Mexico_City"
					},
					"created": "2014-07-04T20:54:09.000+0000",
					"updated": "2014-07-04T20:54:09.000+0000"
				}
			],
			"maxResults": 1,
			"total": 1,
			"startAt": 0
		}
	}
}