title | author | translator | category | excerpt | hiddenlang | status | ||
---|---|---|---|---|---|---|---|---|
iOS 12 |
Mattt |
Vincent Pradeilles |
Chez NSHipster, nous nous intéressons aux détails : les petits (et parfois _méconnus_ ?) changements qui, cumulés, peuvent avoir un impact certain sur notre travail de tous les jours. Pour fêter la sortie cette semaine d'iOS 12, nous vous partageons quelques pépites que nous avons trouvées en épluchant les nouvelles API.
|
|
Si vous avez suivi la Keynote WWDC de cette année, vous savez déjà tout sur les principales fonctionnalités d'iOS 12 : Siri Shortcuts, ARKit 2, et Core ML 2 --- sans compter l'annonce explosive de la tant attendue passerelle entre iOS et Mac, sous le nom de code « Marzipan ».
Et si vous vous avez regardé la session Platforms State of the Union, vous êtes au courant des nouveautés moins prestigieuses, mais cependant tout aussi intéressantes, comme les vues personnalisables pour les notifications, ainsi que les nouveaux frameworks pour gérer les appels réseaux et le language naturel.
Mais chez NSHipster, nous nous intéressons aux détails : les petits (et souvent méconnus) changements qui, cumulés, peuvent avoir un impact certain sur notre travail de tous les jours. Cette année les notes de version d' iOS 12 et de Foundation présentent plusieurs de ces changements, cependant ils ne racontent pas toute l'histoire. Pour en savoir davantage, il faut aller chercher plus loin.
Pour fêter la sortie cette semaine d'iOS 12, nous vous partageons ce que nous avons trouvé après avoir épluché les différences d'API entre iOS 11.4 et 12. (Prudence, toutefois, car plusieurs d'entre-elles restent non-documentées).
Connaissez-vous Fast Lane pour iOS ? Non, pas ce fastlane. Ni celui-ci, non plus, IOS.
Fast Lane (ou bien est-ce Fastlane ?) est un mécanisme permettant de prioriser le traffic Wi-Fi selon le contenu transporté, tel que de l'audio, de la vidéo, ou des données d'arrière-plan. Il s'agit d'une technologie spécifique aux routeurs Cisco, (qui font transiter, à peu près, la moitié du trafic internet mondial), qui encapsule plusieurs standards Wi-Fi, tels que : 802.11r pour l'itinérance rapide, 802.11k pour l'itinérance assistée, et 802.11v pour la configuration sans-fil.
Grâce à un partenariat entre Apple et Cisco annoncé en 2015, les développeurs iOS peuvent désormais adhérer à cette technologie en déclarant la qualité de service souhaitée par leurs appels réseau (néanmoins, de nombreuses API de haut niveau s'occupent automatiquement de le faire à leur place).
Nouveau dans iOS 12,
les objets de type URLRequest
peuvent maintenant définir la valeur de leur propriété networkServiceType
comme étant NSURLNetworkServiceTypeResponsiveData
de manière
à prioriser favorablement les requêtes sensibles au temps de réponse :
import Foundation
let url = URL(string: "https://example.com/checkout")!
var request = URLRequest(url: url)
request.httpMethod = "POST"
request.networkServiceType = .responsiveData // Prioritize
URLSession.shared.dataTask(with: request) {
(data, response, error) in
// ...
}
Cette option est pour le moment non-documentée, mais le conseil des ingénieurs présentant la session WWDC 2018 714: « Optimizing Your App for Today’s Internet » est d'utiliser cette fonctionnalité à bon escient, seulement dans des cas de figure où le temps de réponse est critique. L'example qu'ils fournissent est celui de la validation de commande sur une app d'e-commerce, mais il peut s'extrapoler à d'autres situations.
Une des interrogations historiques suite à la WWDC 2018
était la nouvelle propriété ndefMessagePayload
ajoutée à NSUserActivity
.
À l'époque, les ingénieurs d'Apple ne fournissaient pas plus de précisions que : « no comment ».
Mais tout est devenu plus clairs avec les annonces, la semaine dernière, des iPhones XS, XS Max et XR. Ces appareils gèrent la lecture en arrière-plan des tags NFC, et si vous faites tourner iOS 12 sur cette dernière génération d'iPhone, vous serez capable --- entre-autres --- de lancer une app, de démarrer un appel téléphonique ou d'ouvrir une URL suite au scan d'un tag NFC compatible. Aucune configuration additionnelle n'est requise. Pour éviter une activation accidentelle, cela ne fonctionne que si l'iPhone est déverrouillé et ne se trouve pas en mode avion, entrain de prendre une photo ou bien en train de faire un paiement via Apple Pay.
Avec cette intégration NFC, Apple espère réaliser les promesses faites au sujet des iBeacons BLE en 2013, en offrant une interface plus fluide que le scan explicite d'un tag physique (une pratique répandue en Chine, mais largement méconnue du reste du monde).
Le cas d'utilisation le plus médiatisé pour illustrer les technologies NFC et iBeacon est celui de la visite de musée, où il est possible d'obtenir des informations supplémentaires sur une exposition en passant son téléphone près d'une plaque descriptive.
Activer ce type de fonctionnalité dans une app requiert un entitlement, la déclaration d'un domaine associé, et quelques autres configurations, en plus de l'implémentation des API requises. Fort heureusement, Apple propose une documentation complète de ce processus, qui inclut un projet démo et un article.
Le framework Contacts a été ajouté dans iOS 9 et macOS El Capitan comme une modernisation de son vieillissant prédécesseur AddressBook.
Jusqu'à récemment,
les contacts ne pouvaient être requêtés que par leur nom
ou leur identifiant.
Avec iOS 12, il est désormais possible d'utiliser les méthodes de classe predicateForContacts(matching:)
,
et predicateForContacts(matchingEmailAddress:)
de CNContact
pour construire des prédicats permettant de les requêter à partir de numéros de téléphones
ou d'adresses e-mail.
Par exemple,
si l'on souhaite récupérer les noms et prénoms de tous les contacts ayant
un certain numéro de téléphone et une certaine adresse e-mail,
nous pouvons créer une CNContactFetchRequest
,
construire un prédicat composé de type « ET » à partir de prédicats atomiques,
puis fournir ce prédicat à la méthode enumerateContacts(with:)
que l'on appellera sur le CNContactStore
courant:
import Contacts
let phoneNumber = CNPhoneNumber(stringValue: "+1 555 555 1234")
let phoneNumberPredicate = CNContact.predicateForContacts(matching: phoneNumber)
let emailPredicate = CNContact.predicateForContacts(matchingEmailAddress: "johnny@example.com")
var fetchRequest = CNContactFetchRequest(keysToFetch: [
CNContactGivenNameKey as CNKeyDescriptor,
CNContactFamilyNameKey as CNKeyDescriptor
])
fetchRequest.predicate =
NSCompoundPredicate(andPredicateWithSubpredicates: [
phoneNumberPredicate,
emailPredicate
])
let store = CNContactStore()
try store.enumerateContacts(with: fetchRequest) { (contact, _) in
// ...
}
Les iPads sont particulièrement populaires parmi les pilotes,
qui les utilisent à des fins de navigation et de préparation de vol.
Si vous travaillez sur une app destinée à ce type d'utilisateur,
vous serez ravis d'apprendre que, depuis iOS 12, CLLocationManager
a quelque chose de nouveau en stock juste pour vous.
Sa propriété activityType
existe depuis quelque temps, mais reste une option de configuration de CLLocationManager
quelque peu méconnue.
Si vous utilisez ce gestionnaire de localisation pour suivre les changements de position au cours du temps,
une optimisation facile à réaliser est d'indiquer quel est le mode de déplacement supposé de vos utilisateurs.
Jusqu'à maintenant, les modes de déplacement possibles étaient strictement terrestres:
voiture,
marche / course / vélo,
autre.
Mais sur iOS 12, il est possible de choisir le mode de déplacement
en vol
afin de laisser libre champ aux algorithmes de suivi de mouvements les plus appropriés à ce cas de figure !
import CoreLocation
let manager = CLLocationManager()
manager.activityType = .airborne // ✈️
Avez-vous déjà souhaité détecter si un device iOS était posé à plat,
tout en répugnant à devoir tester deux conditions pour y parvenir ?
Bonne nouvelle, iOS 12 introduit une nouvelle propriété isFlat
juste pour ce cas de figure!
import UIKit
// iOS 12+
UIDevice.current.orientation.isFlat
// iOS <= 11.4
UIDevice.current.orientation == .faceUp ||
UIDevice.current.orientation == .faceDown
Apple fait de considérables efforts pour rendre la saisie de données aussi agréable que possible. Malgré cela, les faits sont là: saisir du texte sur un clavier tactile sera toujours en deçà de ce qu'un véritable clavier physique peut offrir (exception faite, peut-être, du dernier MacBook).
Pour réduire d'autant que possible cette corvée,
iOS 10 a introduit la propriété textContentType
pour les composants implémentant le procotol UITextInputTraits
---
c'est à dire UITextField
and UITextView
.
En lui fournissant une des valeurs possibles,
il est possible de déclarer quelle catégorie d'information est attendue,
ce qui permet en retour que certaines d'entre-elles, comme les noms ou
adresses, puissent être automatiquement remplies en fonction des
informations de l'utilisateur courant.
iOS 12 et tvOS 12 vont plus loin dans cette approche en ajoutant deux nouveaux types de contenu:
UITextContentTypeNewPassword
et
UITextContentTypeOneTimeCode
.
Lorsque .newPassword
est spécifié, ainsi que les règles syntaxiques associées via la propriété passwordRules
,
le système sera alors capable de générer automatiquement un nouveau mot de passe satisfaisant les contraintes syntaxiques.
textField.textContentType = .newPassword
textField.passwordRules = .init(descriptor:
"allowed: ascii-printable; minlength: 8;"
)
Lorsque .oneTimeCode
est spécifié,
le champ de texte sera capable d'automatiquement suggérer
le code à usage unique qui aura été précédemment reçu par SMS.
textField.textContentType = .oneTimeCode
C'est tout pour ce tour d'horizon des nouvelles API d'iOS 12. Bien entendu, iOS 12 est une grosse mise à jour, vous pouvez donc vous attendre à ce que nous explorions en détails de nombreuses autres nouvelles API dans les semaines à venir.
Vous avez des suggestions sur nos prochains contenus ? Contactez-nous sur Twitter !