Quelles compétences sont nécessaires pour créer une application iOS? Rapport Yandex

Un développeur mobile doit avoir un ensemble clair de compétences. Vous devez en parler dans le cadre de tâches spécifiques qui surviennent lors de la création et de la publication de l'application. Arthur Antonov travaille en tant que développeur iOS dans le département de traduction automatique de Yandex. Dans son rapport destiné aux étudiants et aux débutants, Arthur a expliqué ce qu'un développeur doit être capable de faire pour créer un logiciel mobile moderne.


- Il existe deux applications mobiles dans notre département: Yandex.Translate et Yandex.Keyboard. Dans Translator, nous avons beaucoup de technologies sophistiquées, par exemple la saisie vocale, la reconnaissance de texte par photo, la traduction de texte à l'aide de réseaux de neurones. Un autre défi consiste à maintenir cette fonctionnalité hors ligne. Autrement dit, cette fonctionnalité fonctionnera pour vous même sans Internet.



Le clavier est une classe d'applications distincte; il y a des exigences distinctes pour sa vitesse et la qualité de l'application elle-même. La correction automatique en russe fonctionne pour nous: elle aide l'utilisateur, mais ne le dérange pas. Entrée vocale, entrée par balayage.





Une autre fonctionnalité intéressante est la grille dynamique: elle essaie de prédire la prochaine lettre et, en fonction de cela, change le tabson. Autrement dit, il est plus facile d'entrer dans une lettre plus probable.



À l'école, j'étais engagé dans des programmes sportifs. Mais quand je suis entré à l'université, il m'a semblé que c'était un peu ennuyeux, je voulais développer des programmes pour les gens ordinaires, et il est souhaitable qu'ils soient disponibles toujours et partout. J'ai donc décidé de choisir le développement mobile. Mais les applications mobiles ont de multiples facettes, et la plus grande question qui se pose avant moi est de savoir par où commencer.

Internet regorge désormais de cours en ligne, de tutoriels, de livres sur divers sujets et la tête explose. On ne sait pas par où commencer. Par conséquent, dans mon rapport, je voudrais vous aider à construire votre parcours d'apprentissage pour devenir développeur mobile. Ce qui vaut la peine d'être étudié au début, l'étude de ce qui peut être reporté.



Après avoir analysé mon travail pendant plusieurs années, j'ai identifié plusieurs compétences clés qui sont nécessaires pour résoudre la plupart des problèmes. Ce sont des compétences fondamentales et des compétences dites de boîte à outils. Ils ne sont pas nécessaires lors du développement d'applications mobiles, mais si vous les possédez, votre vie deviendra plus facile et la qualité de vos applications sera bien meilleure.

Puisqu'une théorie sans pratique est morte, nous étudierons les compétences en utilisant l'exemple d'une version simplifiée de Yandex.Translator. Une fois le projet terminé, tout ce que vous voyez est un écran blanc.

Revivons notre application en utilisant l'interface utilisateur.





Il existe deux façons classiques de créer une interface: un éditeur graphique et du code. C'est l'un de leurs sujets hollywoodiens dans le développement mobile. Il y a des adeptes du développement dans un éditeur graphique, et quelqu'un ne reconnaît rien sauf du code. Mais je vous conseille d'essayer les deux méthodes. Vous les rencontrerez certainement, et en plus, personne ne vous interdit de combiner des approches, par exemple, des choses simples à faire dans un éditeur graphique et des choses complexes déjà dans le code.



Et récemment, les développeurs iOS ont un nouveau cadre SwiftUI qui essaie de combiner ces deux approches. Autrement dit, lors de la modification dans un éditeur graphique, votre code change et vice versa. Peut-être que lorsque ce cadre se généralisera, tous les différends tomberont dans l'oubli.

Malheureusement, SwiftUI n'est disponible qu'à partir d'iOS 13, il ne peut donc pas être utilisé jusqu'à présent dans de grands projets.



L'éditeur graphique a une interface très simple. Nous prenons des composants prêts à l'emploi, les faisons glisser sur un écran virtuel et voyons immédiatement ce que nous obtenons. Pour cette raison, il est très rapide de créer des composants d'interface utilisateur simples. Nous pouvons également redimensionner l'écran virtuel pour différents appareils et tester notre interface sans lancer l'application.





D'un autre côté, nous avons une conception d'interface dans le code. Lorsque vous développez une interface dans votre code, la bibliothèque UIKit vous sera utile et vous utiliserez de petits blocs de construction appelés UIView. Les objets UIView correspondent grosso modo aux composants que vous avez affichés à l'écran. Et tout comme dans un éditeur graphique, vous disposez de sous-classes prédéfinies pour les composants couramment utilisés, tels que les boutons et le texte.

Lors du développement en code, il est très important de comprendre que d'autres UIViews peuvent créer UIView en eux-mêmes, c'est-à-dire que vous pouvez créer des interfaces de toute complexité. En conséquence, vous obtenez le soi-disant arbre. Il est plus facile de modifier à partir du code. Autrement dit, si vous avez une interface utilisateur très dynamique, il peut être utile de l'écrire dans le code et il vous sera plus facile de la modifier plus tard.



Voyons quel code peut être écrit pour notre traducteur.

Nous avons d'abord défini la couleur d'arrière-plan sur jaune. Ensuite, nous ajoutons un champ de saisie où l'utilisateur entre le texte en anglais. Ensuite, nous ajoutons un séparateur pour la beauté et, enfin, ajoutons un champ de sortie, tout en interdisant à l'utilisateur de le modifier.

Nous avons une interface utilisateur prête, mais l'application est encore plutôt inutile. Il ne résout pas la tâche principale de l'utilisateur - la traduction du texte.

Ajoutons cette fonctionnalité. Les capacités de la plate-forme SDK nous aideront.



Les SDK de plate-forme sont un ensemble d'outils et de bibliothèques pour créer des applications mobiles qui nous sont fournis par Apple et, par conséquent, Google.

Actuellement, le SDK possède de nombreuses bibliothèques de bas niveau pour interagir avec le système d'exploitation, et vous pouvez implémenter presque n'importe quelle idée d'une application mobile sans trop d'effort.

Les bibliothèques que vous utiliserez dépendent des spécificités de votre application. Par exemple, si nous voulons créer une caméra, vous aurez probablement besoin de deux bibliothèques: AVFoundation pour travailler avec la caméra et CoreImage pour le traitement d'image.

Par conséquent, à ce stade, il n'est pas nécessaire de mémoriser toutes les bibliothèques, c'est tout simplement impossible. Plus important est la capacité de trouver les bons outils. Et malheureusement, la documentation officielle ne documente pas toujours entièrement les fonctionnalités. Parfois, vous trouvez des choses intéressantes, par exemple, sur un blog ou sur le twitter d'un autre développeur. Cela vaut la peine de suivre le champ d'information.

Alors, de quoi avons-nous besoin du SDK pour notre traducteur?



Notre traducteur est une application client-serveur classique: nous faisons une demande au serveur et obtenons une réponse. Ensuite, nous le transformons et le montrons à l'utilisateur. Le cadre de la Fondation nous aidera dans cette tâche. Il contient des abstractions pratiques pour résoudre les tâches quotidiennes.

Nous en prendrons la classe URLSession, c'est la classe pour travailler avec le serveur en utilisant le protocole http, et JSONSerialization, c'est la classe qui nous aide à convertir des objets au format JSON.



Voyons donc quel code nous devons écrire pour cette fonctionnalité. À gauche se trouve une méthode qui est exécutée chaque fois que l'entrée utilisateur est modifiée. Nous créons d'abord une URL avec l'adresse du serveur de traduction et faisons une demande. De plus, après avoir reçu la réponse, nous l'analysons à partir du format JSON, nous en obtenons le texte souhaité, c'est-à-dire le texte de traduction. Et la dernière étape - nous disons que dans le champ de saisie, vous devez définir la réponse reçue.

Voyons voir ce que nous avons. L'utilisateur entre bonjour et «bonjour» apparaît:



Mais "bonjour" est apparu en quelque sorte pendant longtemps, cela ne ressemblait pas à des retards de réseau. Pour la fiabilité, comparons avec le frère aîné:

Ouvrir GIF

Dans les deux applications, nous saisissons le texte bonjour et constatons que la traduction est déjà apparue plusieurs fois sur le vrai traducteur. Sur notre traducteur, la traduction apparaît avec un gros coup.

Pour résoudre ce problème, nous devons nous familiariser avec le modèle multithreading dans les applications mobiles.



Tout comme le bureau, les applications mobiles s'exécutent dans un environnement multithread. Mais il y a une limitation importante. Une application mobile a un thread principal ou un soi-disant thread d'interface utilisateur. Et toute opération avec l'interface utilisateur, toute modification de l'interface utilisateur doit se produire dans ce thread principal. Si vous voulez changer la couleur du bouton ou le déplacer - tout devrait être dans le flux d'interface utilisateur.

D'un autre côté, toutes les interactions avec les utilisateurs nous parviennent également sur le fil principal. Autrement dit, l'utilisateur a cliqué sur un bouton - nous avons reçu un message dans le fil principal. Nous avons changé le texte, comme dans notre cas - nous l'avons également dans le fil principal. Puisqu'il n'y a qu'un seul flux et que toutes les actions avec l'interface utilisateur y ont lieu, il est très important de s'en occuper et de faire le moins de calcul possible, sinon vous courez le risque d'être dans une situation où vous traitez une action utilisateur pendant une longue période et vous avez une file d'attente d'autres actions utilisateur. Ensuite, tout commence à geler.

Pour cette raison, de nombreuses bibliothèques système s'exécutent par défaut sur un flux d'arrière-plan. Par exemple, un trajet vers le réseau prend en moyenne 100 à 500 millisecondes. C'est une opération assez coûteuse pour le flux principal, donc toute interaction avec le réseau a lieu sur le flux d'arrière-plan.

Et encore une fois, cela crée des problèmes pour nous, car si nous utilisons par inadvertance le résultat obtenu du serveur immédiatement pour changer l'interface utilisateur, cela peut entraîner un ou des plantages.

Rappelons notre dernière ligne:

self.textOutputView.text = translation

Dans celui-ci, nous avons pris le résultat du serveur et l'avons placé dans le champ de sortie. Ainsi, nous avons violé la première règle - nous n'avons pas modifié l'interface utilisateur du thread principal. La bibliothèque standard Grand Central Dispatch aidera à résoudre ce problème. Cela nous aide assez facilement à passer au thread principal et à effectuer cette action sur le thread principal.

DispatchQueue.main.async {
  self.textOutputView.text = translation
}

Voyons ce que nous avons obtenu avec l'application à la fin.



L'utilisateur entre du texte et nous constatons que la traduction se produit presque instantanément. Hourra! Nous avons vaincu ce problème. Mais, avant de publier l'application, parlons d'un autre sujet important - l'architecture.

Malheureusement, sur le projet en cours je ne pourrai pas vous démontrer l'importance de l'architecture, elle est encore très petite.



Mais, je vous assure, l'architecture n'est pas née d'une vie meilleure, pas du fait que les développeurs n'ont rien à faire et qu'ils écrivent des abstractions pour qu'ils ne soient pas licenciés. L'architecture est la réponse aux défis du développement mobile.

Le principal de ces problèmes est l'évolutivité. Lorsque votre application devient trop volumineuse et dispose de fonctionnalités différentes, il est important qu'elle soit facile à comprendre, à développer et à déboguer. Sinon, tout ajout de fonctionnalités modifiera toutes les anciennes. Et le risque que nous ayons des bugs augmente.

N'attendez pas que votre application se développe. Déjà au stade initial, vous pouvez apprendre les pratiques de base de création de logiciels qui fonctionnent également pour les applications mobiles, telles que SOLID, les modèles de gangs de quatre.

L'architecture des applications mobiles a ses spécificités: leurs composants globaux ou de grande taille sont construits selon des modèles architecturaux qui disent à un niveau élevé quels objets doivent appartenir à quelle couche. Les plus populaires sont MVC, MVP et MVVM.

Et n'oublions pas qu'en réalité l'architecture n'est pas une solution miracle. Il est nécessaire de prendre en compte les spécificités du projet. Si vous tirez une sorte d'architecture sur votre projet avec des larmes aux yeux, peut-être que quelque chose s'est mal passé.

Lorsque vous étudiez la théorie, cela vous semblera terriblement compliqué. Mais en fait, lorsque vous travaillez dans un projet avec une bonne architecture, vous serez content car il est devenu plus facile pour vous d'écrire du code. Vous savez quoi et où ajouter pour avoir une fonctionnalité. C'est pourquoi, à ce stade, afin de bien connaître l'architecture, je vous conseille de travailler ou de faire un stage dans un grand projet. Si vous n’avez pas une telle opportunité, alors maintenant de nombreuses entreprises mettent leurs projets en open source: Wikipedia, Firefox. Et personne ne vous interdit d'aller au GitHub et d'y voir.

Donc, notre application est prête. Mettons-le dans le domaine public afin que les utilisateurs puissent le télécharger.



Dans la plupart des cas, les utilisateurs obtiennent des applications de Google Play et de l'App Store. Mais avant d'ajouter l'application au Store, nous devons la signer. Cela est dû au fait que les systèmes d'exploitation exécutent des applications uniquement à partir de développeurs de confiance. Ainsi, sur les plateformes mobiles, nous avons beaucoup moins d'applications et de virus malveillants, car seuls les développeurs de confiance ont accès au travail sur les appareils mobiles.

Pour ce faire, vous devez émettre un certificat de développeur. Il s'agit en fait d'une petite bureaucratie et, heureusement, il est automatisé dans les dernières versions de Xcode.

Vous devez également prendre des captures d'écran pour votre application et votre description. Les deux dernières étapes ne doivent pas être négligées, car la page de votre application est sa publicité. S'il n'est pas brillant, alors tout notre développement a probablement été vain, car personne ne téléchargera l'application.

L'application a été téléchargée, parlons maintenant de quelques compétences supplémentaires qui peuvent vous simplifier la vie et améliorer la qualité des applications.

La compétence que vous utiliserez le plus souvent est le débogage.



La principale méthode de débogage est le bon vieux console.log ou printf. Il a beaucoup de noms, mais la signification est la même. En cas de problème, nous ajoutons des variables de journalisation et d'impression. Mais malheureusement, cette méthode présente également des inconvénients critiques.

Le premier des inconvénients est de changer le code source. Il y a des bogues qui disparaissent lorsque vous ajoutez printf. Et vous supprimez printf - ressuscitez. Ces bogues ont même un nom distinct - heisenbug.

La deuxième conséquence est que vous devez recompiler votre application et l'exécuter à nouveau. Dans les grands projets, cela peut prendre quelques minutes, et si vous devez attendre une minute lors de l'ajout de chaque nouveau journal, vous passerez au total beaucoup de temps.

Et le dernier inconvénient le plus critique de printf - malheureusement, cela n'aide pas pour tous les bogues.

Un exemple de pratique personnelle. Lors du développement de l'intégration du clavier, les événements suivants se sont produits:



Dans le clavier système ci-dessous, au lieu des icônes de globe et de microphone du système, certains identificateurs sont apparus. Déboguer ce bug, je me sentais comme ceci:



Comment une application peut-elle casser un clavier système?! Il s'est avéré que c'était possible.



Lors de l'enquête sur le bogue, les connaissances du débogueur m'ont beaucoup aidé. En particulier, définir un point d'arrêt pour appeler certaines fonctions. Voir le débogueur, où nous pouvons regarder notre interface utilisateur et voir qui a quelle classe et quel état.

Lorsque j'ai profité de ces deux premiers points, il s'est avéré que le problème était dans la bibliothèque UIKit. Les développeurs iOS le connaissent et savent qu'il n'a pas de code open source. Mais lorsque vous connaissez l'assembleur, n'importe quelle bibliothèque devient open source pour vous, donc les petites bases de l'assembleur peuvent être utiles.

Il y a aussi la soi-disant compétence de l'ingénierie inverse. Parfois, cela peut être assez ennuyeux, parfois c'est intéressant - une histoire de détective où vous étudiez comment un composant est connecté à un autre, comment tout est fait à l'intérieur de la bibliothèque. En conséquence, il s'est avéré que le problème était lié à l'exécution du langage Objective-C.

La prochaine compétence importante consiste à optimiser nos applications.



Les appareils mobiles ont des ressources limitées, il y a donc souvent un problème de performances. Lors du développement, nous devons penser à des choses comme la consommation du processeur. Le plus souvent, c'est la complexité du code que vous écrivez. Vitesse de rendu, mémoire et trafic réseau, car la plupart des utilisateurs sont plus susceptibles d'utiliser votre application sur le trafic mobile. Respectons les utilisateurs et ce sera peut-être réciproque.

Le cinquième point est la batterie, il découle des quatre premiers.

La chose la plus importante lors de l'optimisation des applications est d'identifier les zones à problèmes. Si vous ne comptez que sur vos hypothèses, il est probable que vous perdrez beaucoup de temps et que vous n'obtiendrez pas trop de bénéfices. Cela aidera les outils de la plateforme. Ils incluent un profileur - un programme qui vous montre où dans votre code le programme passe le plus de temps. Autrement dit, vous verrez la méthode dans laquelle votre programme se bloque le plus souvent, et vous trouverez très probablement la raison du gel.

Connaître les algorithmes et les structures de données vous aidera à trouver une solution plus efficace. De plus, la connaissance du multithreading peut aider ici. Il existe désormais des processeurs multicœurs sur les appareils mobiles, et en parallélisant le problème sur plusieurs threads, vous obtenez une légère augmentation de n fois des performances.

Parfois, il arrive que les deux premiers points, malheureusement, n'aident pas. Ensuite, vous serez aidé en comprenant le fonctionnement du système d'exploitation et en connaissant les appels système, tels que la carte mémoire (mmap). Dans notre cas, les claviers iOS tiers ont une limitation de la consommation de RAM - 52 mégaoctets. Autrement dit, nous voulons ajouter des fonctionnalités, faire une belle interface utilisateur, mais sont limités à 52 mégaoctets. Que faire avec cela n'est pas clair.

Lors de l'ajout d'une autre fonctionnalité, cela s'est produit. Nous avons souvent commencé à dépasser cette limite et nous ne savions pas quoi en faire. En conséquence, l'appel système de carte mémoire est venu à la rescousse. Nous avons pris un fichier avec un dictionnaire, d'où nous obtenons tous les indices, et avons commencé à appeler la carte mémoire. Ainsi, nous travaillons avec une partie du fichier sans le charger complètement dans la RAM.

Le dernier problème fréquemment rencontré est l'heure de début. Ici, je peux vous conseiller de lire ce qui se passe avant que votre code ne commence à fonctionner. En particulier, sur les liens statiques et dynamiques.



La dernière compétence utile est l'intégration continue ou l'automatisation des tâches ennuyeuses.

Personne n'aime faire des tâches ennuyeuses, nous les automatisons donc. Le plus souvent, la chose la plus simple est de créer l'application pour chaque validation que vous effectuez, et plus vous construisez l'application, plus vite vous pouvez trouver le problème. Si vous avez des tests, exécutez-les également.

Comme je l'ai dit, la publication est associée à une petite bureaucratie, elle est donc également très automatisée, et vous pouvez publier l'assembly dans le magasin bêta pour chaque demande de pool afin que les testeurs puissent le tester. Vous pouvez également automatiser la génération de captures d'écran pour l'App Store, afin de ne pas les faire manuellement.

Pour toutes les compétences énumérées, j'ai rassemblé du matériel utile.qui aidera dans leur étude. Il contient également le code source d'une version simplifiée du traducteur. Merci de votre attention, j'espère que vous avez un peu plus clair quoi étudier pour commencer votre voyage.

Source: https://habr.com/ru/post/undefined/


All Articles