Closed GoogleCodeExporter closed 9 years ago
I don't understand.
if you:
PayLoad aPayload = new PayLoad();
and don't add anything to it...is that not what you are looking for?
Original comment by idbill.p...@gmail.com
on 1 Jan 2011 at 11:44
no...the Payload is not empty by default it contains an 'aps' entry :
this.apsDictionary = new JSONObject();
try {
this.payload.put("aps", this.apsDictionary);
} catch (JSONException e) {
e.printStackTrace();
}
I just need to create an empty payload without 'aps' entry.
Original comment by david.screve@gmail.com
on 2 Jan 2011 at 11:13
That would lead me to believe that the aps 'root' object is required by apple.
Are you suggesting that we require all users of this library to add that?
Maybe if you explained what your goal is, I'd could be more helpful.
Original comment by idbill.p...@gmail.com
on 3 Jan 2011 at 2:15
No, I don't suggest that all users add this manually..;I suggest just to add
another constructor with a boolean parameter that allow to avoid adding the aps
dictionary. There are special case (under NDA) that requires that.
Original comment by david.screve@gmail.com
on 3 Jan 2011 at 9:50
Sorry, but that is untrue. And also untrue regarding NDA. It is open
documentation anybody can read...
"This dictionary must contain another dictionary identified by the key aps. The
aps dictionary contains one or more properties that specify the following
actions"
...aps dictionary is required and also required to have one or more of the
three options. In addition, it may have custom payloads, but you still need the
aps dictionary.
http://developer.apple.com/library/ios/#documentation/NetworkingInternet/Concept
ual/RemoteNotificationsPG/ApplePushService/ApplePushService.html
Original comment by casey.du...@gmail.com
on 9 Mar 2011 at 1:50
Unfortunately, there are some other situations where we need to customise the
payload with something else than 'aps' dictionary. I cannot tell you when we
need this, but this situation exists and is not listed in the docs you are
refererring.
Trust me, there is a need for that, and it only require to implement an empty
constructor....this costs less that 5 lines of code, so less than the whole
discussion here.
Anyway, I've done the change on my own, but just would like to add this to the
public code.
Original comment by david.screve@gmail.com
on 9 Mar 2011 at 7:31
Ok. But Apple will reject your payload if it is missing 'aps'...
Original comment by casey.du...@gmail.com
on 10 Mar 2011 at 1:52
no if I use specific payload configuration....
Original comment by david.screve@gmail.com
on 10 Mar 2011 at 8:14
If you are speaking of mdm, you could have just said so. The existence of it is
not under NDA.
On another note, I do agree that there could be another constructor of some
sorts to handle this. This would indeed make it more versatile.
Original comment by casey.du...@gmail.com
on 24 May 2011 at 8:14
There's no public documentation that speaks about mdm and push notification....
Original comment by david.screve@gmail.com
on 24 May 2011 at 8:20
Sorry, I still don't think you've made the case for adding this feature.
This is what I'm reading for the request of creating an 'Empty Payload'
- for a case that is NDA/undocumented at most extremely unusual
- 6 lines of code are required to make an empty payload
Adding a feature that is easily bypassed and for such an unusual case seems
like it will create confusion later.
AND... what functions will this Payload have (since there isn't an APNS
JSONObject, all the existing functions will be useless... Or do you just want
the 5 lines wrapped into a new class?
Original comment by idb...@pugetworks.com
on 24 May 2011 at 9:09
As per official Apple documentation, the aps sub-dictionary is mandatory. I
too believe that the library should stick to the official specs. If a special
kind of Payload is required for an obscure and undocumented use, I suggest you
create a subclass of Payload and override methods as necessary to fulfil your
specific need. I think you might be able to override the getPayloadAsBytes()
to generate a special-purpose payload for your specific needs.
Reference:
http://developer.apple.com/library/ios/#documentation/NetworkingInternet/Concept
ual/RemoteNotificationsPG/ApplePushService/ApplePushService.html
Original comment by sype...@gmail.com
on 7 Sep 2011 at 3:33
Okay....so many time and so many energy just to reject a 5 lines request
feature...what a waste of time to justify that a user request appear useless
for you even if someone believe it useful...:-(((
Original comment by david.screve@gmail.com
on 7 Sep 2011 at 3:39
Sorry you feel that way David. I believe though that it is important a library
designed to work with a publicly documented standard does make sure that the
standard is respected. Apple's documentation is pretty clear on what a Payload
*must* minimally contain. Since you are working on a project that does not
conform to Apple's public documentation of the Push Notification Service, I
would argue that subclassing Payload is a reasonable solution to a local need.
If some documentation could be found to clarify how, why and following what
different standard a Payload should diverge from the only official requirements
we're aware of at this time, it would help introduce a standard-compliant
variant of Payload.
Doing some further research, I'm wondering if you are trying to use javapns for
Over-the-Air Profile Delivery and Configuration (which seems to be public)?
http://developer.apple.com/library/ios/#documentation/NetworkingInternet/Concept
ual/iPhoneOTAConfiguration/Introduction/Introduction.html%23//apple_ref/doc/uid/
TP40009505-CH1-SW1
Original comment by sype...@gmail.com
on 7 Sep 2011 at 5:03
(re-opening because further discussion could be helpful)
Having finally found some official and public documentation on MDM, I was able
to enhance the library to support both Push Notification and MDM payloads in a
way that I believe meets expectations on both sides.
The Payload class in javapns has been turned into an interface with no
APNS-specific code, and all APNS-specific payload code has been transferred to
a new PushNotificationPayload class that implements Payload. The rest of the
library deals with the Payload interface now, making it possible to pass any
Payload implementation.
Going further with that enhancement, I have created a new "management" package
with Payload implementations for all documented MDM payloads (as far as I can
see). It should now be quite easy to build, configure and send MDM payloads.
The MDM payloads constructors are designed to make sure that mandatory
properties are provided, which optional properties can be set using standard
setters. Not being able to test all this myself and just wanting to implement
this as a proof-of-concept, I didn't go into too much detail when dealing with
more complex sub-dictionaries (such as EAPClientConfiguration), which simply
key-in and return a JSONObject for developers to populate.
If anyone finds this useful or has further comments, please let me know :)
Original comment by sype...@gmail.com
on 9 Sep 2011 at 10:31
Sounds good and interesting !
When I browse to source code, I did not see the changes you are talking about.
Coule you tell me where did you find the public documentation of MDM ?
Original comment by david.screve@gmail.com
on 10 Sep 2011 at 11:13
Sorry, I didn't specify that the changes were committed to the 2.0 branch. If
you browse the source code on-line, go in svn > branches > javapns2 > src >
javapns > notification > management.
As for the documentation, I found it by first searching for "apple mdm payload
documentation" in Google, then clicking the first Apple Discussions thread I
saw listed, and in that thread is a link to on-line Apple documentation on
"Over-the-Air Profile Delivery and Configuration". That documentation refers
and links to the iPhone OS Enterprise Deployment Guide where all MDM payloads
are documented:
http://manuals.info.apple.com/en_US/Enterprise_Deployment_Guide.pdf
Original comment by sype...@gmail.com
on 10 Sep 2011 at 2:42
Okay....by MDM payload, you mean "configuration profle payload" which are
pushed using OTA enrollment. This is not related to anything that could be
called MDM.
Original comment by david.screve@gmail.com
on 10 Sep 2011 at 5:07
I was probably mislead by what I read from the Apple docs, but interestingly
"http://images.apple.com/iphone/business/docs/iPhone_MDM.pdf" lists
configuration profiles and OTA Enrollment as being part of MDM... So one would
assume that configuration profiles are quite directly related to MDM. But
anyway, my point is not to argue about something I clearly don't know much
about, so I'll leave it at that :)
Original comment by sype...@gmail.com
on 10 Sep 2011 at 8:01
Closing as fixed in 2.0 (Beta 3), which allows for custom payloads to be
created (without forcing the 'aps' dictionary that is mandatory in APNS), as
per original request.
Original comment by sype...@gmail.com
on 14 Sep 2011 at 4:11
Original issue reported on code.google.com by
david.screve@gmail.com
on 1 Jan 2011 at 5:10