Dans le monde Push Notification, un token est un descriptif chiffré et authentifié associé à un device, le fournisseur de notification utilise ce token pour identifier les devices qui doivent recevoir la notification auprès du serveur APNS.
Mais ce n'est peut-être pas de cela qu'il s'agit car il veut "envoyer des notifications à des tokens".
Si je comprends bien FrançoisH veut faire un provider sur un device iOS. Dans le schéma normal, le provider est un serveur auquel l'APNS envoie les tokens des devices qui veulent recevoir les notifications Push. Il faut donc faire un serveur sur un appareil mobile. C'est surprenant mais pourquoi pas ...
La difficulté sera de rendre l'appareil iOS toujours joignable avec une URL définie, et d'authentifier ce "serveur mobile" auprès d'Apple.
Et je ne sais pas comment faire. Je ne sais même pas si c'est possible. Donc je ne réponds pas à la question.
Et donc j'aurais peut-être mieux fait de m'abstenir ...
Si je comprends bien FrançoisH veut faire un provider sur un device iOS. Dans le schéma normal, le provider est un serveur auquel l'APNS envoie les tokens des devices qui veulent recevoir les notifications Push. Il faut donc faire un serveur sur un appareil mobile. C'est surprenant mais pourquoi pas ...
Autant à la limite faire une application iOS "A" qui te permette d'envoyer un message PUSH à certains devices (ou plus exactement à certains utilisateurs de ton application "B"), dont tu connais le token APNS, ça pourquoi pas (et je vois pas trop de restriction, après tout cela consiste juste à envoyer une payload au serveur APNS d'Apple comme le font les codes PHP qu'on voit trainer sur le net ou comme c'est expliqué en détail dans la doc Apple concernant l'APNS). Par exemple ton application iOS "A" te permettrait de choisir parmi une liste de tes utilisateurs (des utilisateurs qui ont installé l'application "B" qui s'est enregistrée avec un token APNS) et de choisir un message à envoyer, et un bouton enverrai la demande de push notif aux serveurs APNS d'Apple pour que les utilisateurs reçoivent une notif.
Ca ça a du sens et c'est pas trop dur, il suffit une fois que tu as la liste des tokens APNS des utilisateurs à qui tu veux envoyer le message d'envoyer la payload décrite dans la doc Apple. Par contre il faut que tu puisses récupérer la liste des tokens de tes utilisateurs, et pour ça il faut à l'idéal un serveur intermédiaire (mais tu en as certainement un) qui enregistre les tokens.
---
Par contre transformer ton device iOS en provider et donc s'attendre à ce que les utilisateurs de l'application "B" envoient leur token directement sur ton device qui servirait de serveur mobile, ça ça n'a pas trop de sens. D'une part parce que ton device mobile devra alors forcément avoir une IP fixe, ce qui est déjà pas facile sur un device mobile y compris avec les proxies de ton opérateur, en plus il faudra que l'application qui fait tourner ton serveur soit constamment lancée, ce qui n'est pas une contrainte réalisable sur iOS (et c'est tant mieux sinon bonjour la baisse de batterie), et en plus il faudrait que ton device soit constamment joignable (pas de coupure réseau) alors qu'un device mobile, étant en mouvement, a toujours des endroits où il ne capte pas. Et enfin il faudrait qu'il soit constamment allumé, jamais en veille.
Bref, un device mobile n'est pas du tout mais alors pas du tout éligible pour faire un serveur qui soit toujours accessible et à une adresse fixe. Ce qui est un prérequis si tu veux que tes utilisateurs qui vont demander un token APNS puis te l'envoyer puisse joindre le serveur quel que soit le moment où ils s'enregistrent.
Il te faut un serveur intermédiaire (hébergé par ton hébergeur web favori de ton choix). C'est lui qui sera tout le temps accessible, allumé, maintenu, accessible à adresse fixe, etc. Et qui enregistrera les tokens de tes utilisateurs.
Après rien ne t'empêche de faire une application iOS qui va dialoguer avec ton serveur via un WebService pour lui demander d'envoyer des notifications push ou de te fournir la liste de tes utilisateurs enregistrés etc, mais ça c'est tout ce qu'il y a de plus classique (un serveur, un webservice, une protection minimale pour ne pas exposer tes données à tout le monde, et basta).
Mais je pense que FrancoisH n'est pas encore très clair sur ce qu'il veut et sur le principe de fonctionnement des Push Notifications et du système APNS (et pour parfaire à cela, rien ne vaut la lecture de la doc concernant les Push Notifications et l'APNS, Programming Guide plutôt détaillé comme tous les autres)
Autant à la limite faire une application iOS "A" qui te permette d'envoyer un message PUSH à certains devices (ou plus exactement à certains utilisateurs de ton application "B"), dont tu connais le token APNS, ça pourquoi pas (et je vois pas trop de restriction, après tout cela consiste juste à envoyer une payload au serveur APNS d'Apple comme le font les codes PHP qu'on voit trainer sur le net ou comme c'est expliqué en détail dans la doc Apple concernant l'APNS). Par exemple ton application iOS "A" te permettrait de choisir parmi une liste de tes utilisateurs (des utilisateurs qui ont installé l'application "B" qui s'est enregistrée avec un token APNS) et de choisir un message à envoyer, et un bouton enverrai la demande de push notif aux serveurs APNS d'Apple pour que les utilisateurs reçoivent une notif.
Ca ça a du sens et c'est pas trop dur, il suffit une fois que tu as la liste des tokens APNS des utilisateurs à qui tu veux envoyer le message d'envoyer la payload décrite dans la doc Apple. Par contre il faut que tu puisses récupérer la liste des tokens de tes utilisateurs, et pour ça il faut à l'idéal un serveur intermédiaire (mais tu en as certainement un) qui enregistre les tokens.
Effectivement, j'ai acces aux token, j'aimerais simplement créé une app "maison" pour envoyer un message a certain utilisateur.
OK donc contrairement à ce que tu as dit plus haut en confirmant la supposition de jpimbert, ce n'est pas un provider mobile que tu veux faire. Juste une appli A qui envoie une notif push à des utilisateurs d'une autre appli B faite également par tes soins...
Si tu veux de l'aide, pense à bien décrire ta demande correctement. Encore plus si tu ne connais pas les bons termes et mélanges les choses, cela ne fait que rendre ton besoin plus difficile à comprendre pour nous... Je suis même pas sûr à ce stade d'avoir correctement compris ce que tu veux, je pense que oui mais cela semble confus de ton côté donc j'ai encore un doute...
Je pense que tu veux te mettre à la place du serveur qui habituellement envoie les demandes d'envoi de notifications push (et pas du serveur qui enregistre les tokens reçus par l'APNS. Dans ton cas ce sont 2 entités différentes.
Ou alors encore mieux (car sans doute même plus simple et plus propre d'ailleurs), faire un serveur provider classique (qui à la fois s'enregistre sur les serveurs APNS et fait relai pour les tokens envoyés par ton appli /cool.png' class='bbc_emoticon' alt='B)' />, et prévoir un WebService pour le "piloter" (un appel WS pour demander la liste des devices/utilisateurs enregistrés, un autre pour demander d'envoyer une notif à une liste de devices, typiquement, tout simplement). Ceci évidemment de façon sécurisée pour éviter à n'importe qui de spammer tes utilisateurs à ta place.
Sans me taper la doc, j'espérais pouvoir être aiguillé. Mais je comprend que ce n'est possiblement pas "commun".
Pourquoi vouloir à tout prix éviter de te taper la doc, alors que justement elle explique en détail et de façon très précise à la fois les bons termes et leur signification (ce qui t'aiderait pour savoir de quoi on parle), le fonctionnement des notifications push dans leur ensemble (ce qui t'aiderait à comprendre où tu veux te placer dans ce système), et comment fonctionne chaque étape (ce qui t'aiderait à comprendre comment implémenter ce que tu veux) y compris avec des exemples très détaillés (ce qui t'aiderait à comprendre les explications)...
Bref, désolé si je suis un peu cru, mais la doc n'est pas faite pour les chiens, et bien au contraire même, puisque la doc Apple de manière générale est très bien détaillée et conçue, surtout les Programming Guides, et expliquent tout en détail, des concepts et du vocabulaire au code et méthodes, exemples à la clé... Je vois vraiment pas l'intérêt de chercher à éviter une doc aussi riche et détaillée contenant toutes les réponses que tu cherches...
Réponses
Mais ce n'est peut-être pas de cela qu'il s'agit car il veut "envoyer des notifications à des tokens".
Si je comprends bien FrançoisH veut faire un provider sur un device iOS. Dans le schéma normal, le provider est un serveur auquel l'APNS envoie les tokens des devices qui veulent recevoir les notifications Push. Il faut donc faire un serveur sur un appareil mobile. C'est surprenant mais pourquoi pas ...
La difficulté sera de rendre l'appareil iOS toujours joignable avec une URL définie, et d'authentifier ce "serveur mobile" auprès d'Apple.
Et je ne sais pas comment faire. Je ne sais même pas si c'est possible. Donc je ne réponds pas à la question.
Et donc j'aurais peut-être mieux fait de m'abstenir ...
C'est cela, désolé de ne pas avoir été clair!
Autant à la limite faire une application iOS "A" qui te permette d'envoyer un message PUSH à certains devices (ou plus exactement à certains utilisateurs de ton application "B"), dont tu connais le token APNS, ça pourquoi pas (et je vois pas trop de restriction, après tout cela consiste juste à envoyer une payload au serveur APNS d'Apple comme le font les codes PHP qu'on voit trainer sur le net ou comme c'est expliqué en détail dans la doc Apple concernant l'APNS). Par exemple ton application iOS "A" te permettrait de choisir parmi une liste de tes utilisateurs (des utilisateurs qui ont installé l'application "B" qui s'est enregistrée avec un token APNS) et de choisir un message à envoyer, et un bouton enverrai la demande de push notif aux serveurs APNS d'Apple pour que les utilisateurs reçoivent une notif.
Ca ça a du sens et c'est pas trop dur, il suffit une fois que tu as la liste des tokens APNS des utilisateurs à qui tu veux envoyer le message d'envoyer la payload décrite dans la doc Apple. Par contre il faut que tu puisses récupérer la liste des tokens de tes utilisateurs, et pour ça il faut à l'idéal un serveur intermédiaire (mais tu en as certainement un) qui enregistre les tokens.
---
Par contre transformer ton device iOS en provider et donc s'attendre à ce que les utilisateurs de l'application "B" envoient leur token directement sur ton device qui servirait de serveur mobile, ça ça n'a pas trop de sens. D'une part parce que ton device mobile devra alors forcément avoir une IP fixe, ce qui est déjà pas facile sur un device mobile y compris avec les proxies de ton opérateur, en plus il faudra que l'application qui fait tourner ton serveur soit constamment lancée, ce qui n'est pas une contrainte réalisable sur iOS (et c'est tant mieux sinon bonjour la baisse de batterie), et en plus il faudrait que ton device soit constamment joignable (pas de coupure réseau) alors qu'un device mobile, étant en mouvement, a toujours des endroits où il ne capte pas. Et enfin il faudrait qu'il soit constamment allumé, jamais en veille.
Bref, un device mobile n'est pas du tout mais alors pas du tout éligible pour faire un serveur qui soit toujours accessible et à une adresse fixe. Ce qui est un prérequis si tu veux que tes utilisateurs qui vont demander un token APNS puis te l'envoyer puisse joindre le serveur quel que soit le moment où ils s'enregistrent.
Il te faut un serveur intermédiaire (hébergé par ton hébergeur web favori de ton choix). C'est lui qui sera tout le temps accessible, allumé, maintenu, accessible à adresse fixe, etc. Et qui enregistrera les tokens de tes utilisateurs.
Après rien ne t'empêche de faire une application iOS qui va dialoguer avec ton serveur via un WebService pour lui demander d'envoyer des notifications push ou de te fournir la liste de tes utilisateurs enregistrés etc, mais ça c'est tout ce qu'il y a de plus classique (un serveur, un webservice, une protection minimale pour ne pas exposer tes données à tout le monde, et basta).
Mais je pense que FrancoisH n'est pas encore très clair sur ce qu'il veut et sur le principe de fonctionnement des Push Notifications et du système APNS (et pour parfaire à cela, rien ne vaut la lecture de la doc concernant les Push Notifications et l'APNS, Programming Guide plutôt détaillé comme tous les autres)
Effectivement, j'ai acces aux token, j'aimerais simplement créé une app "maison" pour envoyer un message a certain utilisateur.
Sans me taper la doc, j'espérais pouvoir être aiguillé. Mais je comprend que ce n'est possiblement pas "commun".
A noter que j'ai trouvé le code d'une app mac qui fait sa, mais elle date de 2 ans et crash. (pushMeBaby) https://github.com/stefanhafeneger/PushMeBaby
Quoi qu'il en soit, merci encore pour votre aide précieuse. Très instructif, comme à l'habitude!
Si tu veux de l'aide, pense à bien décrire ta demande correctement. Encore plus si tu ne connais pas les bons termes et mélanges les choses, cela ne fait que rendre ton besoin plus difficile à comprendre pour nous... Je suis même pas sûr à ce stade d'avoir correctement compris ce que tu veux, je pense que oui mais cela semble confus de ton côté donc j'ai encore un doute...
Je pense que tu veux te mettre à la place du serveur qui habituellement envoie les demandes d'envoi de notifications push (et pas du serveur qui enregistre les tokens reçus par l'APNS. Dans ton cas ce sont 2 entités différentes.
Ou alors encore mieux (car sans doute même plus simple et plus propre d'ailleurs), faire un serveur provider classique (qui à la fois s'enregistre sur les serveurs APNS et fait relai pour les tokens envoyés par ton appli
Pourquoi vouloir à tout prix éviter de te taper la doc, alors que justement elle explique en détail et de façon très précise à la fois les bons termes et leur signification (ce qui t'aiderait pour savoir de quoi on parle), le fonctionnement des notifications push dans leur ensemble (ce qui t'aiderait à comprendre où tu veux te placer dans ce système), et comment fonctionne chaque étape (ce qui t'aiderait à comprendre comment implémenter ce que tu veux) y compris avec des exemples très détaillés (ce qui t'aiderait à comprendre les explications)...
Bref, désolé si je suis un peu cru, mais la doc n'est pas faite pour les chiens, et bien au contraire même, puisque la doc Apple de manière générale est très bien détaillée et conçue, surtout les Programming Guides, et expliquent tout en détail, des concepts et du vocabulaire au code et méthodes, exemples à la clé... Je vois vraiment pas l'intérêt de chercher à éviter une doc aussi riche et détaillée contenant toutes les réponses que tu cherches...