Creating payloads for non-APNS purposes (ex. MDM)

[timmyyu]

Creating payloads for non-APNS purposes (ex. MDM)

[GoogleCodeExporter]

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 [email protected] on 1 Jan 2011 at 11:44

[GoogleCodeExporter]

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 [email protected] on 2 Jan 2011 at 11:13

[GoogleCodeExporter]

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 [email protected] on 3 Jan 2011 at 2:15

[GoogleCodeExporter]

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 [email protected] on 3 Jan 2011 at 9:50

[GoogleCodeExporter]

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 [email protected] on 9 Mar 2011 at 1:50

[GoogleCodeExporter]

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 [email protected] on 9 Mar 2011 at 7:31

[GoogleCodeExporter]

Ok. But Apple will reject your payload if it is missing 'aps'...

Original comment by [email protected] on 10 Mar 2011 at 1:52

[GoogleCodeExporter]

no if I use specific payload configuration....

Original comment by [email protected] on 10 Mar 2011 at 8:14

[GoogleCodeExporter]

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 [email protected] on 24 May 2011 at 8:14

[GoogleCodeExporter]

There's no public documentation that speaks about mdm and push notification....

Original comment by [email protected] on 24 May 2011 at 8:20

[GoogleCodeExporter]

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 [email protected] on 24 May 2011 at 9:09

[GoogleCodeExporter]

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 [email protected] on 7 Sep 2011 at 3:33

• Changed state: WontFix

[GoogleCodeExporter]

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 [email protected] on 7 Sep 2011 at 3:39

[GoogleCodeExporter]

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 [email protected] on 7 Sep 2011 at 5:03

[GoogleCodeExporter]

(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 [email protected] on 9 Sep 2011 at 10:31

• Changed title: Creating payloads for non-APNS purposes (ex. MDM)
• Changed state: Started
• Added labels: Priority-Low, Type-Enhancement
• Removed labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

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 [email protected] on 10 Sep 2011 at 11:13

[GoogleCodeExporter]

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 [email protected] on 10 Sep 2011 at 2:42

[GoogleCodeExporter]

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 [email protected] on 10 Sep 2011 at 5:07

[GoogleCodeExporter]

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 [email protected] on 10 Sep 2011 at 8:01

[GoogleCodeExporter]

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 [email protected] on 14 Sep 2011 at 4:11

• Changed state: Fixed