Hi Chan, The data you sent from the payload is upto the the mobile app developer to decide. He may do whatever with the payload. APNS is a push notification service when it comes to normal push. This is very useful when the app is when closed. Eg: you can news alerts, social networking friend activity statuses etc. through this. Yes there are lot of chat apps which uses APNS. Again its upto the developer. There is no restriction saying that you cannot develop a chat app with APNS. Again this acts like an offline chat which will be notified to the user.
You are thinking intems of MDM push which is totally a different architecture. You cannot request the device to fetch data in normal push. Its just a message sent to your phone. Aslong as you dont run any background services (background services are only allowed to be used only if its necessary). In Apps you cannot send any instructions to the server or pull data out of it other than the background service scenario I mentioned above. Only place you may do is when the user tap that notification where it will trigger an listener callback. In that you can read the entire data payload and do whatever you want. Yes push notifications are not guaranteed delivery and it should not be. You don't send critical information on that. If you do so that again a wrong architecture decision. This is merely for sending notification when the app is closed which can be directly sent to the device itself and this and again that doesn't mean that the developer can do any processing by looking at the payload. Regards, Dilshan On Thu, Mar 27, 2014 at 1:46 PM, Chan <[email protected]> wrote: > > > > On Thu, Mar 27, 2014 at 12:59 PM, Dilshan Edirisuriya <[email protected]>wrote: > >> Hi, >> >> Your overall proposed architecture on the APNS looks good for me. Here >> are my comments on this. >> >> ================ >> This is the basic connector. Users are allowed to configure the connector >> with one or more device tokens and other push notification fields such as >> alert, badge and sound. >> >> Usage : This functionality only works fine when the number of devices is >> static. When it is dynamic then additional manual effort is needed to edit >> the device tokens in the connector configuration. >> ================ >> >> >> IMO you cannot add any device tokens to the configuration. Device token >> is generated when the device is registering in the APNS. This token can be >> differ if you delete the app and reinstall. So the generation of this token >> is not guaranteed. Hence as you have suggested there needs to be a REST >> feed which consumes this identifier and save it in somewhere else if there >> is a device token generation at the device end. I believe this should not >> be a function in ESB to store these things. Just route the device token >> along with a some user id through ESB to the external system and ask the >> external system to save it. They way the save is up to them based on their >> implementation at device end. Allow them to use the payload which can be >> sent from the device end. >> >> >> ================ >> >> >> 1) There should be a way of adding an entity for each app the that entity >> will contain an app id and APN certificates. When the devices send self >> registration requests these device tokens too will be persisted in the app >> entity. >> >> *Problem* - *Whats the best way of persisting these info in ESB and is >> there any custom schema based forms to capture information like the app id >> and certificate info ?* >> >> >> ================ >> >> Please see my above comments. In any means I don't think this needs to be >> saved in ESB. Just delegate that to the external party by allowing it to be >> routed through ESB. Also if a user has multiple devices there will be >> multiple tokens. >> >> ================ >> >> >> Candidates for the client library are JavaPNS 2.2 [3] and java-apns [4]. >> >> ================ >> >> Only use the notnoop java-apns. We have discussed this earlier. Other >> library you cannot ship according to its license. Later yes you can have >> push io or urban airship. But these things are introduce for the purpose of >> ease since with less configurations you can enable support for multiple >> platforms. If you implement connectors for major mobile platforms like iOS, >> Android, Windows, BB then I dont see a clear reason to support them since >> those are just push services which also uses the underline platform push >> technologies. If you implement so any user can make use of the services >> through the ESB connector. >> >> >> Commenting on Chans comments. >> >> ================ >> >> Also there is a known misconception about usage of Push Notifications. >> Push Notification itself will not have data (there is an exception for >> this) - push notification is a signal for the iOS device to contact a >> provider to get new data that's available (it's called Send-to-Sync by >> GCM). I think we need to re-think the whole picture when it comes to Push >> Notifications. >> >> ============== >> >> Chan you are talking about MDM push notifications here. MDM push >> notifications are something different than the normal push notifications. >> In MDM it just uses push technology to wake up the device allowing it to >> communicate with the registered MDM server. The purpose of the normal push >> is to send notifications directly to the device. So this involves a >> payload. You can set badges, sounds, priority etc. to this. >> > > IMO that is incorrect. Apps should never depend on the data that's coming > on the payload. The payload should only be used to send data that is > immediately useful. MDM push and normal push are conceptually the same. > Also Push Notifications is not a notification service (even though Chat > applications sometimes use APNS for this) it's a notification service > requesting the device to fetch data. This reason for this is because push > notifications are not guaranteed to be delivered (opposite of ESB > messages). > > > >> >> >> =============== >> >> >> Shall we make the apns connectivity part in a way that is abstract to the >> connector? In the EMM product - we use apns (app push & mdm push) - it >> would better if we can leverage a single component through out the >> platform. >> >> ============= >> >> Yes we have implemented this in EMM. That supports both normal push >> notifications and mdm push notifications. Yes I will make this an orbit >> bundle so you can use this directly. >> >> Regards, >> >> Dilshan >> >> >> <https://github.com/notnoop/java-apns> >> >> Dilshan Edirisuriya >> Senior Software Engineer - WSO2 >> Mob: + 94 777878905 >> http://wso2.com/ >> > > Cheers~ > > > > -- > Chan (Dulitha Wijewantha) > Software Engineer - Mobile Development > WSO2Mobile > Lean.Enterprise.Mobileware > * ~Email [email protected] <[email protected]>* > * ~Mobile +94712112165 <%2B94712112165>* > * ~Website dulitha.me <http://dulitha.me>* > * ~Twitter @dulitharw <https://twitter.com/dulitharw>* > *~SO @chan <http://stackoverflow.com/users/813471/chan>* > -- Dilshan Edirisuriya Senior Software Engineer - WSO2 Mob: + 94 777878905 http://wso2.com/
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
