RubyMotion
muqaddar
Administrateur
Connectez-vous ou Inscrivez-vous pour répondre.
muqaddar
Administrateur
Réponses
Mais j'trouve ça cool toutes ces passerelles, tant qu'elles sont bien utilisées, évidemment.
Bon pour programmer sur iOS, je préfère tout de même utiliser directement Xcode.
Mais Ruby est vraiment très efficace pour des applications web. Et c'est vrai que de passer d'Objective-C à Ruby est assez facile avec une sémantique identique.
Donc, après, je ne sais trop comment ça marche sous le capot, voire par ici pour un peu de code:
http://arstechnica.com/business/news/2012/05/exclusive-building-ruby-ios-applications-with-rubymotion.ars/2
Bonjour , désolé pour ce up mais je me lance en parallèle sur Rubymotion et une voie plus classique avec Swift. Je viens de Rails et donc ça me parle Rubymotion , on peut utiliser les xib avec Rubymotion même si ce n'est pas la voie privilégiée (http://www.synbioz.com/blog/rubymotion_et_interface_builder) , il y a aussi pas mal de gem ou carrément le pack Redpotion pour faire abstraction au max de Cococa mais pour l'instant je ne vais pas encore trop tester ça .
Cette année motion-game doit être intégré à Rubymotion pour faire claire on va dire que c'est une surcouche à Cocosx-2d en Ruby et vous ferez des jeux multiplateformes avec un seul code , c'est prometteur pour les démos que j'en ai vu .
Le seul intérêt que ça pouvait avoir, c'est de permettre à qqn sachant faire du Ruby mais pas d'Objective-C de faire des programmes Cocoa (iOS/OSX), plutôt que d'apprendre Objective-C qui n'est pas simple à appréhender et est très différent du Ruby que ces gens connaissent.
Mais maintenant que Swift est sorti, stable, et vu que sa syntaxe est très proche (et inspirée, sur pas mal de points) de Ruby, ça vaut largement + le coup pour un développeur Ruby d'apprendre Swift (et pour le coup "apprendre" est un bien grand mot, car qui sait faire du Ruby va très vite savoir s'adapter à Swift) et de développer des applications Cocoa en Swift, que d'utiliser RubyMotion.
Non seulement parce que ça va lui permettre d'utiliser les outils natifs, sans avoir à se poser la question d'éventuelles spécificités de RubyMotion par rapport à du développement natif sous Xcode (genre les risques du style "attention cette API a une signature un peu différente en Ruby qu'en ObjC du coup ne pas se fier à la doc officielle d'Apple à la lettre pour ce cas particulier", etc), mais en plus ça permet de profiter du type-safety qu'offre Swift et que n'offre pas Ruby.
J'aime beaucoup Ruby, je le pratique assez souvent pour des écrire des scripts simples comme très évolués, et pour le boulot que je fais sur CocoaPods qui est écrit en Ruby. Mais ce qui me gène le plus sur Ruby c'est son tapage faible, puisqu'on ne peut pas savoir quel est le type de paramètre attendu par une fonction rien qu'en regardant sa signature (il faut juste espérer que la fonction est bien documentée, façon RDoc ou YARD, et que cette documentation indique le type des paramètres et surtout est à jour, ce qui d'expérience n'est pas toujours le cas...). Du coup on perd un temps fou quand on ne connait pas une API, on est obligé de fouiller partout dans la doc pour savoir quel type d'objet on est sensé passer à telle fonction pour être sûr que ça plante pas à l'exécution.
Alors qu'avec Swift, l'auto-complétion nous indique tout de suite le bon type et de toute façon si on utilise le mauvais c'est dès la compilation qu'on est averti, pas seulement plus tard si on a la chance de passer précisément dans cette partie du code et voir que ça plante (bon, au moins, ça force d'autant plus à faire des tests unitaires / specs en Ruby où c'est inimaginable de s'en passer)
Du coup, il ne reste vraiment plus aucun intérêt à mon sens à RubyMotion. Le temps passé à apprendre Swift connaissant Ruby va être très court, et les avantages et le temps gagné en comparaison (typage fort donc APIs plus claires et beaucoup moins de temps passé sur du debug au Runtime, pas de spécificités / exceptions dû au fait qu'on utilise du bridging, etc) est considérable et très vite amorti.
Pour moi l'intérêt est de pouvoir faire du multi plateforme , de ne pas se voir imposer Xcode (ça compte pour certains) , de développer d'une façon "rails" , avec certaines gems s'abstraire de Cocoa . Je suis d'accord avec les avantages de swift mais ils peuvent pour certains devs venus du web représenter une contrainte supplémentaire (je pense à tout ce qui concerne le typage en tout cas j'ai entendu cet argument) .
Pour conclure je dirais que l'on instaure une concurrence entre ces deux écosystèmes alors qu'elle n'a pas forcément lieu d'être.
http://www.rubymotion.com/news/2015/09/03/announcing-rubymotion-4-0-free-cross-platform-games-watchos-2-0.htmlExcellente nouvelle qui redonne un intérêt certain à Rubymotion