{ "id": "63056", "key": "TIMOB-2424", "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": [ { "id": "11234", "name": "Release 1.6.0 M01", "archived": true, "released": true, "releaseDate": "2010-12-20" } ], "resolution": { "id": "1", "description": "A fix for this issue is checked into the tree and tested.", "name": "Fixed" }, "resolutiondate": "2011-04-17T01:59:04.000+0000", "created": "2011-04-15T03:19:21.000+0000", "priority": { "name": "Low", "id": "4" }, "labels": [ "ios", "iphone", "notifications", "push", "release-1.6.0", "rplist" ], "versions": [], "issuelinks": [], "assignee": { "name": "rseagraves", "key": "rseagraves", "displayName": "Reggie Seagraves", "active": true, "timeZone": "America/Los_Angeles" }, "updated": "2011-04-17T01:59:04.000+0000", "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" } }, "components": [ { "id": "10206", "name": "iOS", "description": "iOS Platform" } ], "description": "{html}
Extra data passed in a Push Notification is stripped before it\nget's to the app.
\ne.g. acme1 & acme2 are not readable:
{
\n\n\"aps\" : {\n \"alert\" : \"You got your emails.\",\n \"badge\" : 9,\n \"sound\" : \"bingbong.aiff\"\n},\n\"acme1\" : \"bar\",\n\"acme2\" : 42
\n
\n}
This sticket has been sitting unassigned, with no milestone and\nlow priority...
\nI guess this came in directly, outside of HelpDesk.
\nAssigning to myself for triage
Blain please take a look at whether we allow this.
For developers they can use this workaround:
\n{
\n\"aps\" : {
\n\n\"alert\" : \"You got your emails.\",\n\"badge\" : 9,\n\"sound\" : \"bingbong.aiff\",\n\"payload\" : { \n \"acme1\" : \"bar\",\n \"acme2\" : 42\n}
\n
\n} }
\nWe will be looking in to this for the next release following\nR1.5.0
I raised the ticket after being told by help desk this was an\nenhancement (I disagree):
\nhttp://developer.appcelerator.com/helpdesk/view/40681
For reference, the example was pulled from this page:
\n\nhttp://developer.apple.com/library/ios/#documentation/NetworkingInt...
This bug is causing my push notifications to have the very ugly\nwork-around of having essential payload data in the user-visible\nmessage & parsing it out in my app, e.g.
\n\"aps\" : {
\n\n\"alert\" : \"There are new matches to your search (a834,1,624632)\",\n\"badge\" : 9,\n\"sound\" : \"bingbong.aiff\"
\n
\n},
\nAs you can imagine, users are confused.
What about my example above of the payload workaround? I don't\nsee the last code example by James Wragg using that.
\nWe will look at the the format of the first example and from\nHelpDesk and evaluate whether we think we should support that going\nforward.
(from [4d2377fb38804d1177ac8369181daa276f688609])\n[#2424] Include full dictionary in push\nnotifications, but still copy APS props to toplevel for backcompat.\n\nhttps://github.com/appcelerator/titanium_mobile/commit/4d2377fb3880...
Forgot to tag fixed-in-qa.
Correcting the milestone, this was committed on master. It is\nnot in the 1.5.1 release.
1.6.0.0db09d1e 4gt touch, 3.1.3 iphone