Skip to end of metadata
Go to start of metadata

<ac:macro ac:name="info"><ac:parameter ac:name="title">Zend_Mobile_Push</ac:parameter></ac:macro>

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[

Zend Framework: Zend_Mobile_Push Component Proposal

Proposed Component Name Zend_Mobile_Push
Developer Notes
Proposers Mike Willbanks
Zend Liaison TBD
Revision 1.1 - 28 November 2011: Initial Draft. (wiki revision: 8)

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




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


Sending an APNS Message


Feedback of an APNS Message


Sending a C2DM Message


Sending a MPNS Raw Message


Sending a MPNS Toast Message


Sending a MPNS Tile Message

9. Class Skeletons




Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Nov 28, 2011

    <p>Right now, you don't exactly specify what Zend_Mobile_Push will definitely <strong>not</strong> do. This makes it a bit open-ended.</p>

    <p>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.</p>

    1. Nov 28, 2011

      <p>Hi Pieter,</p>

      <p>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.</p>

      <p>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.</p>

      <p>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:</p>

      <p>Clients: share a common interface<br />
      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.</p>

      <p>Thanks for the feedback.</p>

  2. Nov 30, 2011

    <p>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.</p>

    <p>Otherwise, the design looks reasonable.</p>

    1. Nov 30, 2011


      <p>Any examples of how you might think these option classes should work? For example:</p>
      <li>Getters and setters exist here</li>
      <li>Constructor can take all arguments and call internal methods</li>
      <li>Has a few methods get/set/clearOptions</li>

      <p>The drawback to this being when looping through a series of messages; which is a fairly common use case.</p>

      <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
      $apns = new Zend_Mobile_Push_Apns();
      $message = new Zend_Mobile_Push_Message_Apns();
      $options = new Zend_Mobile_Push_Message_Apns_Options(...);
      foreach ($token as $t) {

      <p>Without the options could do a setOptions(array())</p>
      <li>Calls the internal methods when it finds a method that exists</li>
      <li>If method does not exist; just sets an option for the key / value pair.</li>

      <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
      $apns = new Zend_Mobile_Push_Apns();
      $message = new Zend_Mobile_Push_Message_Apns();
      foreach ($token as $t) {

      <p>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 <em>fatness</em> 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.</p>

  3. Feb 27, 2012

    <ac:macro ac:name="note"><ac:parameter ac:name="title">CR Team Comments</ac:parameter><ac:rich-text-body>
    <p>Zend_Mobile_Push is accepted for development for ZF 1.12.</p>

    <p>For inclusion in ZF 1.12, it must have code, documentation and unit tests completed by 23rd March 2012.</p></ac:rich-text-body></ac:macro>

  4. Mar 20, 2012

    <p>Wow, nice component! +1 <ac:emoticon ac:name="laugh" />.</p>

  5. Aug 14, 2012

    <p>Regarding APNS there need to be a way of specifying that the APNS sandbox should be used - required for development.</p>

    1. Aug 14, 2012

      <p>Ah, I've just looked at the source in more detail and note that you have already done this</p>