Hi, Accordingly to apple's documentation (Quality of Service) [1], APNs will try to deliver the notification but if the device is offline, the notification is stored for a limited period of time and once the device is online, it is delivered. In-addition to that, only one recent notification can for a particular application is stored. if there are multiple notifications when the device is offline, then only the last notification is kept and all others are discharged. APNs is mainly used to notify the user that a new messages are available for the app. Once the user opens the app, the device can communicate with our server to get the messages. In iOS 7 onwards, apple provides silent push notification (no sound or alert message), which can be used to trigger background task (within a certain time). The main thing to note here is that silent push notifications are rate-limited.
[1] - https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/ApplePushService.html#//apple_ref/doc/uid/TP40008194-CH100-SW4 On Thu, Mar 27, 2014 at 10:18 PM, Chan <[email protected]> wrote: > Here is my take on the use-case. The ESB generates notifications based on > messages passed to the ESB. ESB triggers an APNS call to the device. The > point I am trying to make with Push Notifications is this - once the ESB > sends the message to the APNS - ESB has not track of it. APNS may or may > not contact the mobile app. First notification is sent to the device with > data. It doesn't get delivered. Second notification is made to the apns. It > gets delivered. CXO opens up the mobile app based on the second push > notification. He cannot see the 1st notification because it's depending on > APNS payload for data (Bad design). > > What we need is an MB model -where messages are stored in the server side > and ESB connector only sends send-to-sync messages to the device. Device > contacts MB to get the messages. > > Cheers~ > > > On Thu, Mar 27, 2014 at 8:54 PM, Rushmin Fernando <[email protected]>wrote: > >> Hi Dilshan, >> >> Good point. >> >> IMO the most prominent use case is pushing notifications to the devices >> which are registered for a specific app id. >> >> e.g. CXOs have a dashboard app installed. Based on some properties of >> messages to the ESB (business need) CXOs should get notified. Any CXO can >> have more than one device. Since they have this app installed each and >> every device get registered under the app id in whatever the system we are >> going to build/integrate with the connector. So when a notification is >> published to specific app id, all the devices under that app id get >> notified. >> >> I don't see taking 'users' in to the account as a part of the essential >> complexity in this point. It would provide more personalized push >> notifications indeed. But I think its out of our scope in this point. >> >> WDYT ? >> >> >> >> On Thu, Mar 27, 2014 at 4:48 PM, Dilshan Edirisuriya <[email protected]>wrote: >> >>> Hi Rushmin, >>> >>> Yes handling device token is out of our business I guess. As long as you >>> use it for dev purposes I believe it should be fine. Regarding the token >>> its based on the device. Each iOS application is bounded with an >>> application identifier. This can be wildcard application identifier as >>> well. You enable push notification to this app id from the iOS developer >>> portal. So overall for each person download the app from App Store or your >>> private app store is entitled for this APNS service. Next thing we need a >>> way to identify the device individually. Early days what we did was to >>> fetch the device Universal Device Identifier what we call as UDID or MAC >>> address of the devices (based on iOS versions). Now all are deprecated. >>> Hence there is no way to get a proper device identity at the server end >>> (FYI if you are using MDM you can get the UDID, MAC etc.). Then the better >>> solution would be to link these devices to the user. Let say there is user >>> A with his iPhone X and iPad Y. When the access the APNS server through his >>> X and Y devices there will be 2 token generated by APNS. Hence when the >>> server needs to send push notifications to the user A server should be wise >>> enough to send the message both to X and Y devices by looking at the >>> devices of User. Inorder to identify the app itself you will need that >>> application identifier or similar configured in the ESB as you have >>> mentioned above. >>> >>> To reply on the EMM integration yes we have done both the normal push >>> and MDM push. This APNS component need to be a orbit bundle which can be >>> used by any product when necessary. I will do that part so you can use it. >>> >>> @Chan The scenario is to accommodate the users who need to make use of >>> APNS through ESB. If APNS is not guaranteed delivery then there is nothing >>> can be done from ESB end. This is just a way to offer the same service as a >>> connector. The developer who does this aware that it is not guaranteed >>> delivery and will work accordingly. Regarding the delivery theactual data >>> its based on the data set. There is a limitation to this data size. Its >>> used for notifying the user in most occasions. Even how Facebook uses is to >>> notify the user and ask the user to open the app to get the rest of the >>> updates. But this doesnt mean that you cannot go beyond that and use it as >>> a feature like a push notification chat by restricting the data length to >>> max limit. There are plenty of apps which does this. The major difference >>> of this with MDM push is that MDM push connects to the server automatically >>> when the device is wokenup whereas in this user has to tap the notification >>> and open the app to get the updates. >>> >>> >>> Regards, >>> >>> Dilshan >>> >>> >>> >>> On Thu, Mar 27, 2014 at 2:40 PM, Chan <[email protected]> wrote: >>> >>>> Let me be more clear into what I am saying. Push Notifications are sent >>>> from server to the device notifying that there is a message available. >>>> That' the general architecture pattern of usage and violating that >>>> architecture pattern will break Guaranteed Delivery. If someone used the >>>> APNS connector believing that the messages sent via the ESB connector is >>>> going to be definitely delivered by APNS - it will break his whole >>>> application. Let's not let people shoot themselves in the foot. >>>> >>>> I agree that there are edge cases of push notifications being used to >>>> deliver actual data but that's not the real use of it. For example when >>>> some comment on a Facebook photo of mine - iPhone shows a notification on >>>> the lock screen stating the name of the user who wrote the comment. When I >>>> click on the Facebook app - it connects to the Facebook server to actually >>>> get the new updates. This can be experimented while putting the phone to >>>> air plane mode and going to Facebook app. >>>> >>>> As for Rushmin's comments - I agree there is a configuration that is >>>> needed. For example usage - I want to send a push notification to an app - >>>> I will contact the ESB and give him the APNS certs and ids needed. >>>> Afterwards I will send notifications based on user and device (prior to >>>> this user's device has to be registered to receive notifications as well). >>>> EMM hasn't generalized this bit of registration since we already have a >>>> device registration. We need to clearly think from the use case perspective >>>> to understand the actual problem. @Rushmin can you list down few use cases >>>> of the APNS connector for ESB? End to end use cases that address the >>>> devices registration as well. >>>> >>>> (For the record I am not thinking of MDM push because there is no >>>> conceptual difference between MDM push and APP push). >>>> >>>> Cheers~ >>>> >>>> >>>> On Thu, Mar 27, 2014 at 2:30 PM, Rushmin Fernando <[email protected]>wrote: >>>> >>>>> Hi Chan and Dilshan, >>>>> >>>>> Thank you for your feedback. Please find my comments inline. >>>>> >>>>> >>>>> 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. >>>>>> >>>>> >>>>> I agree with this. Configuring the connector with device tokens is not >>>>> a idea for prod use. But I made it a milestone as it would help to test >>>>> the >>>>> combination of ESB APN connector component wiring and APN service >>>>> connectivity. But its not production grade for sure :-) >>>>> >>>>> Initially I was thinking of having no dependencies like external >>>>> storage systems since the connector is not core part of the ESB. But I >>>>> agree with the point that we should maintain the consistency among our >>>>> products and not replicate functionality. To be honest my preference is >>>>> having an adapter for a vendor like Push IO and Urban Airship, so that >>>>> we don't need to manage devices tokens at all. >>>>> >>>>> >>>>>> >>>>>> ================ >>>>>> >>>>>> >>>>>> 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. >>>>>> >>>>>> ================ >>>>>> >>>>>> >>>>> Please see the above comment for not saving device tokens in ESB. >>>>> >>>>> I dont get "Also if a user has multiple devices there will be >>>>> multiple tokens. " part. AFAIK APN clients are app id based rather >>>>> than being user based. >>>>> >>>>> As a reply to Chan's commment on this : APN are app based. So only >>>>> storing device tokens is not enough. Users should be able to create and >>>>> entry, give it an id( may be the bundle id of the app), upload app >>>>> specific >>>>> APN certificates using a UI and then use the app id to send the self >>>>> registration request using iOS. Does EMM support this ? >>>>> >>>>> >>>>> >>>>>> >>>>>> 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. >>>>>> >>>>>> >>>>>> >>>>> Noted the licensing part :-) We are yet to decide the app/device info >>>>> storage part. >>>>> >>>>> >>>>>> 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. >>>>>> >>>>>> >>>>>> >>>>> Both statements are correct. APNs do support a small payload along >>>>> with notification attributes such as badge, sound and alert. So its up to >>>>> the user to use it as a data (very small data chunks) or as a trigger. >>>>> >>>>> >>>>> >>>>>> =============== >>>>>> >>>>>> >>>>>> 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. >>>>>> >>>>>> >>>>> +1 for this. I'll have a look at EMM to get an idea. >>>>> >>>>> >>>>>> Regards, >>>>>> >>>>>> Dilshan >>>>>> >>>>>> >>>>>> <https://github.com/notnoop/java-apns> >>>>>> >>>>>> Dilshan Edirisuriya >>>>>> Senior Software Engineer - WSO2 >>>>>> Mob: + 94 777878905 >>>>>> http://wso2.com/ >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Rushmin Fernando >>>>> Technical Lead >>>>> Mobile : +94772310855 >>>>> >>>> >>>> >>>> >>>> -- >>>> 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/ >>> >> >> >> >> -- >> Rushmin Fernando >> Technical Lead >> Mobile : +94772310855 >> > > > > -- > 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>* > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Niranjan Karunanandham* Senior Software Engineer - WSO2 Inc. WSO2 Inc.: http://www.wso2.com M: +94 777 749 661 <http:///>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
