Portage d'une app.

Réponses

• Céroce Membre, Modérateur

  juillet 2022 #2

  Si l'UI est faite avec SwiftUI, puis-je conserver toute la gestion du dessin en Objective-C ?

  Oui, et pour des raisons de performances, tu seras sans doute encore obligé de te reposer sur Core Graphics.

  Il ne faut pas que tu croies que SwiftUI est une panacée. C'est cool de voir le résultat directement dans Xcode, d'utiliser une syntaxe déclarative et de ne plus se prendre la tête UITableView et cie. Mais globalement, SwiftUI est complexe, nécessite forcément un apprentissage et a des limitations/bugs/contournements/lenteurs. Et si tu fais le calcul, l'IHM n'est pas forcément le plus gros de ton appli.

  Aussi, je dirais qu'à ce stade le choix dépend de ce qu'est iPocketDraw pour toi.

  Si c'est juste un hobby, alors oui, reprogramme tout à partir de zéro et pars sur SwiftUI. Tu vas découvrir plein de choses et faire du développement iOS moderne!

  Mais si ça te rapporte de l'argent et/ou que tu as des clients à satisfaire, alors ce serait une erreur. Parce qu'il te faudra du temps pour tout reprogrammer de zéro. Pendant ce temps, ton appli actuelle sera figée. Et un biais classique est de se dire «oui mais cette fois-ci, je vais faire les choses correctement»; la vérité est que souvent une appli est complexe parce que les problèmes sont subtiles et complexes. En repartant de zéro, tu vas redécouvrir les mêmes problématiques.
  Aussi, je te conseille plutôt de convertir progressivement le code Objective-C en Swift, puis ensuite de passer progressivement l'IHM à SwiftUI. Ça te permettra de continuer à satisfaire tes clients.

  Pour les autres questions, je ne réponds pas, n'ayant pas d'expérience d'une appli iPhone et iPad avec SwiftUI.
• Pyroh Membre

  juillet 2022 #3

  Ça fait maintenant près de deux ans que je fais du SwiftUI et je pense ne pas trop mal me débrouiller.
  J'ai testé ton produit sur iPhone et iPad (en version lite) et ça peut être un bon candidat pour l'utilisation de SwiftUI. Mais avec une grosse réserve cependant (qui va t'arranger).

  Pour ce qui est de déterminer si tu as un iPhone ou iPad SwiftUI a une manière bien à lui de le faire via les size classes stockées dans l'environment. C'est un objet auquel tu accède à l'aide d'un property wrapper et qui contient tout un tas d'informations comme la locale le color scheme utilisé, le Managed Object Context, etc...
  Et cet objet contient deux size classes, la verticale et l'horizontale (réfère toi à ce document, rubrique Device size classes). Ça peut te suffire mais si ça n'est pas le cas tu peux ajouter des propriété à l'environment et y injecter un UIUserInterfaceIdiom ou autre UIDeviceOrientation par exemple. SwiftUI s'adaptera aux changements.

  Ça, ça vaut pour l'UI avec ta myriade de boutons qui seront assez faciles à mettre en place et même à animer. Par contre le canevas j'essaierai même pas pour rire. Du moins pas d'emblée sans connaissance en SwiftUI. Parce que la gestion des events est largement limitée (il faut souvent adapter un UIGestureRecognizer). De plus je ne sais pas comment tu gère le dessin de ton canevas mais il y a fort à parier qu'il n'y ait pas d'équivalent disponible. Tu as bien une vue nommé Canvas qui est l'équivalent d'un drawRect: avec la possibilité de dessiner directement dans un GraphicContext (adaptable en CGContext). Mais aussi d'y dessiner directement d'autres vues SwiftUI comme tu le ferais avec des CGLayer (dans l'idée). Je doute que ça te suffise. Ce qu'il te faut c'est conserver ton canevas existant et l'utiliser via un UIViewRepresentable ou un UIViewControllerRepresentable qui te permettent respectivement d'ajouter des UIView ou UIViewController` à une hiérarchie de vues SwiftUI. Après il faut un peu adapter l'interfaçage entre ta vue et SwiftUI et la complexité peut varier entre "wow c'est fait en trois lignes" et "uhm, peut être que je ferai mieux d'aller élever des chèvres...". Tout dépend de ton architecture de code à la base et des dépendances de la vue que tu cherche à intégrer. Normalement si t'as fait du MVC propre ça devrait aller.

  Tout ça soulève un autre point: le passage à Swift. Je te conseille de commencer par ça parce que SwiftUI, c'est dans le nom, ne fonctionne qu'avec Swift. Tu peux intégrer du code Obj-C et utiliser les classes qui y sont définies mais tu vas vite rencontrer des points de frottement avec l'interaction entre Obj-C et certains concepts propres à Swift qui le rende intéressant. Déjà les struct dont Obj-C ne veut pas entre parler et les enum qui sont tellement puissants en Swift et si limités en Obj-C. Loin de moi l'idée de te dire de tout migrer mais prends le temps de bien analyser et bien intégrer le fait que tu vas jongler entre deux mondes —Swift(UI) et Obj-C— parfois irréconciliables.

  C'est pour ça que mon conseil est avant tout de tester Swift et SwiftUI sur des projets d'entraînement et de suivre les livres et tutos de Hacking with Swift pour bien comprendre comment fonctionne SwiftUI. Je te conseille aussi Thinking in SwiftUI de Chris Eidhof et Florian Kugler qui est le livre qui m'a permis d'arrêter d'essayer d'appliquer mes connaissances Cocoa et UIKit à SwiftUI et à vraiment apprendre son fonctionnement particulier.

  Si t'as des questions on est là 😉
• Eric P. Membre

  juillet 2022 #4

  Merci pour vos retours @Céroce et @Pyroh.

  Le développement n'est pas mon activité principale mais c'est un peu plus qu'un hobby qui me rapporte un peu.
  Je n'ai donc pas trop de contraintes vis-à-vis de mes clients.

  Actuellement, l'architecture est très simple.
  J'ai un UIViewController rattaché à deux fichiers .xib (un pour iPhone et l'autre pour iPad) où sont définis tous les boutons et la UIView du dessin (dessin mis à jour dans drawRect).
  Je n'ai pas de gestures très compliquées : en plus du tap, double tap et drag, j'ai plusieurs long press et une pan gesture et aussi des menus contextuels.
  Puis tout un tas de vues annexes de réglages, choix, etc...

  Je crois que je vais quand même commencer par essayer de refaire mon UI en SwiftUI et plus si affinité.