Je ne sais pas pour les autres mais dans l'ensemble il est important de comprendre ce qu'il se passe derrière. Un bon développeur ne code pas à l'aveugle, et croire que ce genre d'outils peut vous abstenir de ce travail, est une douce illusion.
Cependant, OpenFL fait du bon boulot et ne nous oblige pas à mettre les mains dedans, enfin pas au début.
Il est très facile d'ajouter à votre projet OpenFL des extensions natives en fonction des plateforme ciblée. http://blog.zame-dev.org/openfl-extension-in-10-steps/
Sur un de nos projets on a fait le contraire. On a utilisé NME, l'API à l'origine d'OpenFL, pour faire un widget natif de notre module de dessin. Les développeurs codent leurs applications mobiles en Java, Swift, ou ce qu'ils veulent, et intègrent notre widget comme si de rien n'était. Nous n'avons qu'on code à maintenir pour faire évoluer notre module pour toutes les plateformes.
[^] # Re: et pourquoi pas ?
Posté par David Mouton (site web personnel) . En réponse à la dépêche OpenFL 4.0. Évalué à 2.
Je ne sais pas pour les autres mais dans l'ensemble il est important de comprendre ce qu'il se passe derrière. Un bon développeur ne code pas à l'aveugle, et croire que ce genre d'outils peut vous abstenir de ce travail, est une douce illusion.
Cependant, OpenFL fait du bon boulot et ne nous oblige pas à mettre les mains dedans, enfin pas au début.
Il est très facile d'ajouter à votre projet OpenFL des extensions natives en fonction des plateforme ciblée.
http://blog.zame-dev.org/openfl-extension-in-10-steps/
Sur un de nos projets on a fait le contraire. On a utilisé NME, l'API à l'origine d'OpenFL, pour faire un widget natif de notre module de dessin. Les développeurs codent leurs applications mobiles en Java, Swift, ou ce qu'ils veulent, et intègrent notre widget comme si de rien n'était. Nous n'avons qu'on code à maintenir pour faire évoluer notre module pour toutes les plateformes.
J’espère avoir répondu à vos questions.