This is the length in byte of the returned message.

Ok, this is not obvious from the comment. Please clarify that in the code.

ditto

The idea was to provide to the APNS class a string, in the way it is made now,
it even has the payloao length packed with.

sure, and? What's that got to do with passing by reference or not?

The message will not be sent cause the token doesn't match the criterias.

which will produce an error that the user later can check for, rather than eating it silently, right?

See the push method, it sets an error message when there is no destination to push to.

If you provide a token with invalid size, APNS will answer that the payload has an invalid size
which is not more convenient than refusing the token and then returning error while trying to push.


public function push()
    {
        if($this->device_token === NULL)
        {
            $this->result = 'No destination provided.';
            $this->response_code = '-1';
            return FALSE;
        }
        $data = $this->push_header.$token.$payload;

        $write = $this->stream_socket_client->write($data);

        return $this->parse_result($write) ;
    }

I like better Olivier idea here, but I would make the error something like: "Invalid or no destination provided" since it can be both.
We could also set $this->device_token to FALSE when it's invalid and NULL when it's not set, so we can differentiate both cases and provide a better error message

My point is that we need to have the post error handling anyway. If we want pre error handling we need to write extra code for something that's already handled in the post checks.
The only downside I can see be doing the check post pushing is that a failed push somehow still counts for the quota (of there is one).

But with the post error handling you don't know if the destination was invalid or the message, there is no way to provide meaningful errors after pushing

The whole point of this rewrite was that we /can/ do that.
If you see the return value constants at the beginning you see one that says:

The APNS status code 5, Invalid token size.

If I didn't understand Olivier wrong, he can't determine if the error was 5, 6 or 7 after pushing, he gets the same error with the three of them, so he needs to check for this upfront.

I doubt that. What I can imagine is that if all three of them or any combination of two of them happen, one takes precedence over the others. That's fine though and common practice.

I propose this then:

    public function push()
    {
        if($this->device_token === NULL)
        {
            $this->result = 'Invalid token size.';
            $this->response_code = '5';
            return FALSE;
        }
        $data = $this->push_header.$token.$payload;

        $write = $this->stream_socket_client->write($data);

        return $this->parse_result($write) ;
    }

Quoting olivier: If you provide a token with invalid size, APNS will answer that the payload has an invalid size
Which means that you can't know if the payload, the token, or the topic had an invalid size without the pre checks. Also if a wrong push request affects the quota, I would like to prevent those.

Fair enough, so why didn't olivier answer that /here/ in the first place....
Anyway, if that is the behaviour from APNS, then we need unit tests checking that behaviour and making sure our work-arounds are functional.
Otherwise someone (read: me) may come along in a year or so, see unnecessary code and remove it.

Maybe his explanation was not detailed enough, I got it just with that sentence I quoted before... (Ok, and the cigarette we just smoked :P)

Argh, silly me, I must have overread this statement before. My point with the unit tests remains though

It is part of the interace

The Push Notification Interface? Hmm, ok, in that case it's fine.

name changed to $push_written

still weird. I'd use "push_sent".

Will be done so

Method removed

method renamed to set_endpoint, interface updated as well

A good idea by itself, I think the namespace Push is good enough...
Just let me know

PubSub could be a generic naming and it is also a design pattern :)
IMHO from the point that we are pushing notifications it matches, even if we push to a specific device (subscribed) or broadcasting to all connected.