J'ai besoin de Quelques pensées jusqu'à présent:
3 Réponses :
Pourriez-vous avoir l'application sur une URL au premier lancement hébergé par serveur qui redirigeait l'utilisateur dans Safari et comparer les adresses IP, l'heure, la version iOS, etc. pour obtenir au moins une correspondance approximative? Si une correspondance approximative est insuffisante, vous pouvez, lorsque vous voyez une correspondance approximative, demandez à votre application Open Safari pour confirmer leur identification via Cookie.
Je ne comprends pas la partie de la cookie ...? Safari ne peut pas accéder aux cookies à partir d'une application, ils sont des bacs à sander ...
Vous pouvez confirmer leur identité en cochant un cookie (dans Safari) qui a été défini lorsque l'utilisateur visite d'abord le site. Cela vous permettrait de déterminer quel contexte ils devraient avoir et vous laisser refaire les rediriger vers l'application (via URL schéma) avec le contexte correct.
En outre, l'iOS 6 n'a-t-il pas quelque chose comme ça? Ils ont annoncé une manière de lancer une application (ou de l'App Store) d'un site Web et de transmettre des informations contextuelles, n'est-ce pas?
@Jesserusak vous avez une ref?
@Lukemcnedice Oui, ils sont appelés Application intelligente Bannières
@Jesserusak: Cela ne transmet que les informations de contexte à une application déjà installée. Vous pouvez déjà faire cela avec des URI personnalisées.
@ user102008 La principale raison pour laquelle je pense que les bannières de l'application intelligente sont meilleures, c'est qu'elles offrent de l'installer si vous n'avez pas l'application; Je ne connais aucun moyen de détecter si l'utilisateur dispose d'une application installée dans une vue Web sans leur montrer une erreur laide.
Je suggérerais une de ces deux options:
ou
Passez le jeton de contexte à l'application immédiatement via un schéma d'URL en enregistrant votre application en tant que gestionnaire de protocole, voir plus d'infos ici
manière suggérée:
Il n'y a pas de meilleure pratique pour le partage directement des données entre Safari et une application natale directement et qu'il n'est tout simplement pas destiné à le faire. Tous les cookies et les stockages sont de la boite de sable pour chaque application et safari a son propre bac à sable.
Laisser votre serveur faire le travail via des comptes d'utilisateurs est la meilleure et la meilleure façon propre i.m.o. C'est pourquoi vous avez des comptes d'utilisateurs. Si vous n'avez pas essayé le gestionnaire de protocole pour lire des URL spécifiques, cela pourrait également être fait pratique, je pense.
Idée cool. Je me demande si l'utilisateur aurait une expérience utilisateur médiocre en rebondissant entre Safari et l'application native quand ils l'ont ouverte pour la première fois?
Bien sûr, ce ne serait pas une expérience d'utilisateur supérieure et semble un peu déroutant, mais je ne peux pas penser à une meilleure façon si vous souhaitez vraiment éviter un processus d'inscription pour l'utilisateur. Cependant, étant donné que vous envoyez déjà une sorte de jeton à un utilisateur par courrier électronique, dans un sens qui signifie que vous avez un processus d'inscription de toute façon et que vous pourriez assurer que vous pouvez aller jusqu'au bout. Regardez des applications comme WhatsApp ou des jeux comme Wordfeud - les deux processus d'enregistrement rapides qui ne leur rendent pas moins populaires.
TechCrunch a signalé que cette méthode provoque maintenant rejeté des applications par Apple.
Oui, pour éviter les abus d'annonces, il semble. L'intention n'est ici pas sur la publicité, mais une partie du processus d'enregistrement. Si cela est clair à Apple, il peut toujours être autorisé. Ou peut-être pas - si Apple veut décourager tous les "Safari Flip-Flopping", AD ou non. Cependant, il n'y a aucun moyen d'être sûr, sauf essayer =)
Vous introduisez également une vulnérabilité de sécurité en supposant que l'application prétendant être, YourAppname: // contextToken = 12345678 est en fait votre application et non un acteur malveillant essayant de voler votre session ... Lien universel est une bonne solution de contournement.
Il est facile d'envoyer des messages entre un UIWebView et votre langue maternelle en utilisant WebviewjavascriptBridge .
Dans votre cas, cependant, la suggestion de la réponse acceptée d'utiliser un système d'URL personnalisé (directement à partir d'un courrier électronique à l'application, post-installer) constitue le plus de sens.
Allez-vous lancer l'application depuis le navigateur? Ou l'application va-t-elle simplement être ouverte plus tard par l'utilisateur?
@Jesserusak - C'est un peu compliqué, mais ce qui se passe est que l'utilisateur est envoyé par courrier électronique une URL avec un "jeton de contexte" unique. Ils ouvrent cela dans Safari. Cela les redirige ensuite vers l'Apple App Store pour télécharger l'application. Une fois que l'application est téléchargée, nous devons connaître ce «jeton de contexte» original. Aujourd'hui, nous venons d'envoyer à l'utilisateur un SMS avec une URL personnalisée que nous gérons dans l'application et d'analyser le jeton de contexte de cela, mais ce n'est pas un comportement souhaitable. Nous recherchons une meilleure façon de passer ce contexte et de vous débarrasser du message SMS.