24 septembre 2021

[ad_1]

À faire et à ne pas faire pour les développeurs : comment créer des applications qui séduisent les voyageurs

Par VP 19 mai 2011 Actualités & Culture

Par Travis Winfrey, responsable du développement mobile

VP a récemment annoncé que nous prenons en charge plus de 330 applications orientées clients et entreprises. Nous avons pensé qu’il pourrait être utile de partager une poignée de conseils que nous avons trouvés utiles dans l’écriture de notre propre trio d’applications, pour vous aider à utiliser efficacement l’API VP dans votre client mobile.

Faites en sorte que votre application soit aussi réactive et sensible au réseau que possible. Plus vos utilisateurs peuvent obtenir leurs données rapidement, plus ils seront satisfaits. De plus, l’efficacité du réseau se transforme en efficacité énergétique, un autre objectif qui plaît aux clients. Comme ils le disent dans les directives Android, “supposez que le réseau est lent” et rappelez-vous que les performances du réseau sur un appareil physique seront toujours pires que celles que vous aurez sur un émulateur.

  • Faire utilisez /modified_since/timestamp. Chaque réponse de notre serveur est horodatée, par exemple 1259029173. Cette valeur opaque peut être soumise à nouveau lors de votre prochaine requête avec /modified_since. Vous n’obtiendrez que les objets liés à votre demande lorsqu’ils auront changé depuis cet horodatage. Cette petite modification accélère considérablement les mises à jour de votre client, car il n’aura pas à traiter des informations inchangées. Si votre client gère les données de voyage et les données de suivi des points (voyageurs fréquents), suivez ceux avec des valeurs d’horodatage distinctes.
  • Faire utilisez JSON au lieu de XML avec VP. Beaucoup de gens se tournent d’abord vers XML, car il existe une prise en charge native dans de nombreuses bibliothèques clientes, et c’est le format par défaut pour l’API. Ajoutez simplement /format/json à vos requêtes, et vous profiterez immédiatement d’un volume de données 30 % plus petit en moyenne. Il n’y a pas de différence de temps de traitement, mais vos clients paieront un lourd tribut lorsque ces données arriveront sur leur téléphone via un protocole réseau lent comme EDGE. Les voyageurs en général vont faire face à des réseaux plus sommaires qu’un non-voyageur. Il existe des dizaines de bibliothèques du domaine public pour JSON. Il est facile d’écrire des analyseurs à descente récursive ou des analyseurs à accès séquentiel similaires à SAX en utilisant ces bibliothèques.
  • Faire demander des données compressées. Nos données au format JSON peuvent être compressées à 80-90% avec gzip. Ajoutez simplement “gzip” dans l’en-tête “Accept-Encoding” de vos demandes sortantes.
  • Faire éviter les allers-retours multiples. Lorsque vous avez des temps de ping élevés, ce qui est souvent le cas pour les utilisateurs mobiles, vous souhaitez minimiser les allers-retours effectués vers nos serveurs API, d’autant plus que votre téléphone doit configurer une session HTTPS complète pour chaque requête. Si votre client a besoin de tous les objets VP, vous pouvez utiliser “/list/trip/include_objects/true” comme requête de base. Cet appel renvoie toutes les données de niveau de trajet, de profil et d’objet en une seule fois.
  • Faire envisagez d’utiliser /exclude_types/weather — les objets météo sont présents pour chaque jour d’un voyage. Au moment où j’écris, nous ne fournissons que des données météorologiques orientées historiquement, ce qui n’est pas utile pour un utilisateur mobile qui est actuellement en voyage. Si vous n’utilisez pas ces données, ne les demandez pas. Les données météo peuvent représenter 20 à 40 % des données du trajet + profil + objet dans la réponse de nos serveurs.
  • Faire ajouter un user-agent significatif à vos demandes. Nous préférerions le format AppName/versionNumber.
Ne vous attendez pas à des données dans tous les domaines. VP dispose d’un modèle de données riche qui couvre toutes les informations que nous voyons régulièrement dans les confirmations. Si nos serveurs peuvent extraire des informations d’une confirmation, nous nous ferons un plaisir d’insérer ces données dans l’objet approprié. Cependant, les données ne sont pas toujours là. Référez-vous toujours à notre schéma XML, où nous sommes très clairs sur les champs qui seront et ne seront pas présents pour un objet.

Comment cela se déroulerait-il en pratique ? Eh bien, les confirmations de croisière et de train sont connues pour être maigres, sans adresse ni numéro de téléphone. Si vous supposez que certaines données « doivent être présentes » lorsque vous les affichez ou les combinez pour l’affichage, vous risquez alors des plantages ou d’afficher des valeurs malheureuses telles que « (null) 43 » à vos clients. Même s’il est « logique » qu’une valeur soit présente, il se peut que nous ne l’ayons pas encore disponible. Vos clients doivent être robustes face à toutes les omissions possibles dans les domaines.

Ne vous attendez pas à des données dans un format particulier. Encore une fois, nos serveurs extraient les informations des confirmations, qui contiennent une variété étonnamment large de formats.

  • Les numéros de téléphone peuvent avoir un numéro de téléphone international généralement utilisable, par exemple, +1-212-555-1212 ou ils peuvent être dans l’un des nombreux formats téléphoniques régionaux.
  • Les adresses peuvent être dans un format géolocalisable ou non.
  • Toutes les valeurs contenant des coûts réels ont des valeurs telles que « 300 » ou « 300 USD » ou « 300 USD ». Il est préférable de ne pas préfixer ou suffixer une valeur de coût.

Il est concevable que VP standardise ces détails de niveau inférieur à l’avenir, car chacun représente un petit barrage routier pour un utilisateur qui pourrait ne pas savoir comment naviguer dans les conventions locales.

Ne vous attendez pas à des données en anglais. Nous publions les données des voyageurs en UTF-8, et nous avons une couverture extrêmement large dans les sources non anglaises de confirmations de voyage. Vous devez toujours utiliser les types de caractères et les fonctions de chaîne appropriés pour des données entièrement internationalisées.

Ne vous attendez pas à des temps sur vos objets. De toute évidence, les heures exactes sont cruciales pour l’horaire de travail d’un voyageur, mais nous n’avons pas toujours les données. Les hôtels n’indiquent généralement pas d’heure d’enregistrement sur leurs confirmations, en supposant que le voyageur sache qu’il est généralement 15 heures. Cela se produit environ 2% du temps pour les hôtels, en fait. Les objets comme Notes ont rarement des heures, même lorsqu’ils contiennent des critiques de restaurants ou des notes pour des réunions.

La règle de tri que nous suivons sur le site Web de VP peut être utile pour copier :

  1. Les éléments sans date sont affichés en dernier. Les gens mettent parfois des notes sans date sur un voyage, généralement des critiques.
  2. Les éléments avec des dates mais aucune heure sont affichés en premier ce jour-là.
  3. Les activités d’hôtel et de voiture le même jour doivent être affichées dans le bon ordre lorsqu’il n’y a pas de temps sur l’objet. Les voitures doivent être récupérées avant de pouvoir être déposées et vous ne pouvez pas vérifier avant de vous enregistrer.
  4. Les heures sont converties en un fuseau horaire avant le tri. Les heures que nous envoyons dans l’API auront presque toujours des fuseaux horaires.
  5. Enfin, les objets de trajet sont triés avec l’heure ou l’heure de début de chaque objet comme clé primaire et l’heure de fin comme clé secondaire.

Reconnaître les utilisateurs Pro. VP est un modèle freemium, avec de nombreux clients qui visionnent des publicités et de nombreux clients par abonnement. Du point de vue du développement d’API, la principale chose qu’un utilisateur Pro montre à votre client est beaucoup plus de données pour les voyages et les informations sur les voyageurs fréquents.

Par exemple, considérons un segment aérien, où au lieu de simplement l’heure prévue pour le départ ou l’arrivée, un utilisateur Pro aura également les dernières heures estimées, ainsi que les informations les plus récentes sur la porte et le terminal.

Ici, nous avons extrait ce qu’un utilisateur gratuit pourrait voir dans son flux de données et le comparons à ce qu’un utilisateur professionnel pourrait voir. (Il s’agit d’une vue hautement compressée des données réelles. Les informations de fuseau horaire et d’autres informations en double ont été omises ou combinées, pour des raisons d’espace) :

“StartDateTime”: “2011-03-30 07:30:00”,
“EndDateTime”: “2011-03-30 11:00:00”,

En revanche, le flux de données de l’utilisateur Pro inclura ces détails supplémentaires, montrant un vol gravement retardé et davantage d’informations sur les terminaux et les portes. Considérez toutes les possibilités lors de l’utilisation de ces valeurs. Si vous affichez des escales, par exemple, vous devez utiliser les temps estimés, car ce sont les valeurs les plus connues pour ce vol.

“Statut”: {
« dernière_modification » : « 1301508689 »,
« statut_vol » : « 401 »,
« terminal_départ » : « 4 »,
“porte_depart”: “B25”,
“ScheduledDepartureDateTime”: “2011-03-30 07:30:00”,
“EstimatedDepartureDateTime”: “2011-03-30 08:45:00”,
« arrivée_terminal » : « je »,
« porte_arrivée » : « A8 »,
« ScheduledArrivalDateTime » : « 2011-03-30 11:00:00 »
“EstimatedArrivalDateTime”: “2011-03-30 12:10:00”
},
}

Nous ne pouvons pas être des experts dans tous les domaines couverts par vos nombreuses applications actuelles et futures. Personnellement, j’attends avec impatience les applications qui me permettront de visualiser mes voyages à l’avance, jusqu’aux sympathiques barmans. nos utilisateurs se comportent et comment tirer le meilleur parti de notre API dans un environnement mobile.

Bien entendu, ce conseil n’est spécifique qu’à notre API. Apple et Android ont abordé des problèmes de performances générales ailleurs. Dans les prochains articles, j’aborderai des aspects moins évidents de notre contenu API et comment nos clients utilisent généralement nos services pour stocker leurs données de voyageur.

Si vous trouvez cela utile, veuillez faire partager avec d’autres développeurs de votre réseau.

Pour plus d’informations, rendez-vous sur https://tripit.wpengine.com/developer. Vous pouvez également nous rejoindre sur notre forum des développeurs.



[ad_2]