2017-07-28 5 views
2

My App est comme ceci:canOpenURL réussir, mais openURL échoue, car tel que urlschema

utilisateur entre le numéro de téléphone dans un textField. App l'enregistre. Ensuite, il affiche l'écran du numéro de téléphone dans le détail qui a le bouton "Appel". J'appelle la méthode canOpenURL et si elle réussit, alors je garde mon bouton d'appel activé, sinon je le garde désactivé.

Je crée des URL avec un format comme celui-ci: tel:phone number.

Maintenant, un de mes testeurs a ajouté le numéro de téléphone = '55'. Maintenant, quand j'appelle canOpenURL, alors il obtient le succès, mais quand j'appelle la méthode openURL, il n'apparaît pas le popup pour le numéro de téléphone.

Celui-ci fonctionne parfaitement bien pour d'autres numéros de téléphone, même des numéros de téléphone à 2 chiffres comme = 13, mais pour certains numéros de téléphone spécifiques comme 55,56, il devient défectueux.

REMARQUE: Conformément à l'exigence de mon client, je ne dois pas mettre de validation sur le numéro de téléphone, comme il doit avoir n nombre de caractères ou plus. Donc, s'il vous plaît ne pas fournir des réponses comme ça. J'ai exigé la raison pour laquelle canOpenURL obtient le succès et l'openURL obtenant l'échec.

Répondre

1

La fonction canOpenURL vérifie uniquement si le schéma est valide, c'est-à-dire qu'une application est installée pour gérer l'URL. Il ne dit pas que la ressource est valide, dans votre cas, que le number est valide. Voir https://developer.apple.com/documentation/uikit/uiapplication/1622952-canopenurl

Le problème avec étant invalide est - comme je le vois - causé par la spécification du tel URLScheme dans RFC 2806. J'ai copié les parties pertinentes:

telephone-url   = telephone-scheme ":" 
         telephone-subscriber 
telephone-scheme  = "tel" 
telephone-subscriber = global-phone-number/local-phone-number 
global-phone-number = "+" base-phone-number [isdn-subaddress] 
         [post-dial] *(area-specifier/
         service-provider/future-extension) 
base-phone-number  = 1*phonedigit 
local-phone-number = 1*(phonedigit/dtmf-digit/
         pause-character) [isdn-subaddress] 
         [post-dial] area-specifier 
         *(area-specifier/service-provider/
         future-extension) 
... 
area-specifier  = ";" phone-context-tag "=" phone-context-ident 

Comme je l'ai lu le EBFN, le telephone-subscriper commence toujours avec soit un + ou un caractère 1.

Plus loin, dans 2.5.2 Phone numbers and their scope, le RFC dit:

If a <local-phone-number> is used, an 
<area-specifier> MUST be included as well. 

À mon avis, c'est la raison pour laquelle tel: 55 tombe en panne, mais tel: 13 est ok.

+0

Selon vous, le nombre 25, 29 etc ne devrait pas fonctionner, les nombres commençant par seulement 1 ou 0 ne devraient fonctionner. alors j'ai essayé différents nombres et j'ai trouvé ceci: 1. tous les numéros de téléphone de 3 chiffres fonctionnent, 2. pour le cas des nombres de téléphone de 1 et 2 chiffres, ceux commençant par 0,1 ou 2 fonctionne, d'autres ne fonctionnent pas –

+0

Comme j'interprète le RFC, vous pouvez soit utiliser un * global * num (qui commence par un caractère '+') ou un * local * qui nécessite toujours un * contexte *, c'est-à-dire quelque chose comme '; phone-context =' at la fin de l'URI. Peut-être que seulement Apple sait ce qu'ils ont fait ... –