 | Zend_Mobile_Push |
Zend Framework: Zend_Mobile_Push Component Proposal
| Proposed Component Name | Zend_Mobile_Push |
|---|---|
| Developer Notes | http://framework.zend.com/wiki/display/ZFDEV/Zend_Mobile_Push |
| Proposers | Mike Willbanks |
| Zend Liaison | TBD |
| Revision | 1.1 - 28 November 2011: Initial Draft. (wiki revision: 7) |
Table of Contents
1. Overview
Zend_Mobile_Push is a component for implementing push notifications for the 3 major push notification platforms (Apple (Apns), Google (C2dm), and Microsoft (Mpns). The actual implementation is based on mostly abstraction.
2. References
Specifications / Implementation Guides
Other Implementations
APNS
C2DM
MPNS
3. Component Requirements, Constraints, and Acceptance Criteria
- This component will implement base interfaces along with an abstract class to attempt to bundle common behaviors
- This component will implement the current specifications for APNS, C2DM and MPNS.
- This component will throw exceptions that should be caught (InvalidAuth, InvalidToken, etc)
- This component will not handle the storage of tokens or ID's (no implementation of a persistent storage state).
- This component will not attempt to handle re-connections or exponential back off.
- This component will not provide a server component that runs in the background.
- This component will not interface with a logger.
4. Dependencies on Other Framework Components
Zend_Http_Client - for implementation of sending messages to C2DM and MPNS.
Zend_Filter_Alpha - for filtering out dynamic text to ensure alpha characters.
Zend_Loader - for dynamically loading exception classes based on responses.
5. Theory of Operation
The operation of this component is very simple. It is based simply off of interfaces and abstract classes to implement the server and messages. All common operations have been stated there. The instances of each type of message does not make sense in the context of an abstract factory or a factory at all since each must be implemented in a specific way. Each individual instance must be explicitly stated such as "new Zend_Mobile_Push_C2dm()" including the type of message "new Zend_Mobile_Push_Message_C2dm".
Generally an instance of the client will be created followed by a message that will be passed to the send method of the client. Every attempt was made to standardize some of the handling of each individual item.
6. Milestones / Tasks
- Milestone 1: Finish proposal and architectural description. [Done]
- Milestone 2: Working prototype. [Done]
- Milestone 3: Unit tests exist, work, and are checked into github. [Partially Done]
- Milestone 4: Refinements [Not Done]
- Milestone 5: Initial documentation exists. [Not Done]
7. Class Index
- Zend_Mobile_Exception
- Zend_Mobile_Push_Exception
- Zend_Mobile_Push_Exception_MessageTooBig
- Zend_Mobile_Push_Exception_InvalidRegistration
- Zend_Mobile_Push_Exception_InvalidToken
- Zend_Mobile_Push_Exception_DeviceQuotaExceeded
- Zend_Mobile_Push_Exception_NotRegistered
- Zend_Mobile_Push_Exception_MissingCollapseKey
- Zend_Mobile_Push_Exception_InvalidAuthToken
- Zend_Mobile_Push_Exception_InvalidTopic
- Zend_Mobile_Push_Exception_ServerUnavailable
- Zend_Mobile_Push_Exception_MismatchSenderId
- Zend_Mobile_Push_Exception_QuotaExceeded
- Zend_Mobile_Push_Exception_MissingRegistration
- Zend_Mobile_Push_Apns
- Zend_Mobile_Push_C2dm
- Zend_Mobile_Push_Mpns
- Zend_Mobile_Push_Message_Exception
- Zend_Mobile_Push_Message_Mpns_Tile
- Zend_Mobile_Push_Message_Mpns_Raw
- Zend_Mobile_Push_Message_Mpns_Toast
- Zend_Mobile_Push_Message_Apns
- Zend_Mobile_Push_Message_C2dm
- Zend_Mobile_Push_Message_Mpns
- Zend_Mobile_Push_Message_Interface
- Zend_Mobile_Push_Message_Abstract
- Zend_Mobile_Push_Interface
- Zend_Mobile_Push_Abstract
8. Use Cases
| UC-01 |
|---|
Sending an APNS Message
| UC-02 |
|---|
Feedback of an APNS Message
| UC-03 |
|---|
Sending a C2DM Message
| UC-04 |
|---|
Sending a MPNS Raw Message
| UC-05 |
|---|
Sending a MPNS Toast Message
| UC-06 |
|---|
Sending a MPNS Tile Message
6 Comments
comments.show.hideNov 28, 2011
Pieter Kokx
Right now, you don't exactly specify what Zend_Mobile_Push will definitely not do. This makes it a bit open-ended.
Looking to the different use-cases for APNS, C2DM and MPNS, I get the feeling that the API's are very different from each other. I think it is better to either split them up in multiple components, or try to come with a more unified API that makes it easier to switch to a different platform.
Nov 28, 2011
Mike Willbanks
Hi Pieter,
I've updated what it will not do; however, it is open for what people think it should not do. I've stated a few items that I believe would not be in there.
The API's are extremely different. There are some slight similarities but for the most part they are vastly different in the implementation. Which is the reason there is no abstract factory. I had originally started going down the route of separation but when talking with Matthew he felt it might be a better idea to keep them bundled together.
The API's are as unified as they are going to get. Unfortunately since the API's are so substantially different in their requirements there is really no way to make them so much more similar. So at this point they almost operate such that they are different components but share the following:
Clients: share a common interface
Messages: share 2 common methods: set/getId and set/getToken and a internal validate method that is rather light but meant to ensure that the minimums are met.
Thanks for the feedback.
Nov 30, 2011
Matthew Weier O'Phinney
I see a lot of setters/accessors in the messages, and I'm wondering if that should be abstracted as Options classes, or, at the very least, have a way to set them en masse via a setOptions() method. Using an Options class would allow you to share the same configuration between multiple message instances, and thus reduce some boilerplate in userland code.
Otherwise, the design looks reasonable.
Nov 30, 2011
Mike Willbanks
Matthew,
Any examples of how you might think these option classes should work? For example:
The drawback to this being when looping through a series of messages; which is a fairly common use case.
Without the options could do a setOptions(array())
Both seem reasonable and the first likely gives another layer of abstraction and makes the message not as fat but then we just moved the fatness out a bit since the data items will likely still need to be checked in one way or another (which would then be the responsibility of the options classes). Only example I could find of this in zf1 was some of the WindowsAzure configuration but I didn't trace it down to where it implemented any level of validation of what was coming in.
Feb 27, 2012
Rob Allen
Zend_Mobile_Push is accepted for development for ZF 1.12.
For inclusion in ZF 1.12, it must have code, documentation and unit tests completed by 23rd March 2012.
Mar 20, 2012
Juan Felipe Alvarez Saldarriaga
Wow, nice component! +1
.