Programmation iPhone en C#
Draken
Membre
Novell viens d'annoncer une extension à XCode permettant de programmer en C# sur l'iPhone. Et même de distribuer les applications c# sur l'AppStore !
C'est basé sur Mono, une implémentation libre du framework .Net de Microsoft pour linux.
http://www.presence-pc.com/actualite/Novell-MonoTouch-36417/
Seulement 399$/an pour les amateurs et 999$/an pour les entreprises ! Cet outil qui ne tourne que un Mac Intel, est censé permettre à un développeur Pc de travailler sur iPhone sans avoir a apprendre l'Objective-C.
C'est basé sur Mono, une implémentation libre du framework .Net de Microsoft pour linux.
http://www.presence-pc.com/actualite/Novell-MonoTouch-36417/
Seulement 399$/an pour les amateurs et 999$/an pour les entreprises ! Cet outil qui ne tourne que un Mac Intel, est censé permettre à un développeur Pc de travailler sur iPhone sans avoir a apprendre l'Objective-C.
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Etant donné que sur iPhone on ne peut créer des frameworks maison et on ne peut utiliser de librairies dynamiques (pour éviter que des petits malins utilisent cette technique pour charger du code qui n'aurait pu être validé par Apple j'imagine) mais que des statiques (ou bien les frameworks Apple évidemment), et étant donné que j'imagine qu'il y a un précompilateur C# -> C pour générer les binaires distribuables sur l'AppStore... c'est un peu l'usine à gaz.
Et en plus on risque de ne pas avoir toutes les possibilités offertes par l'aspect dynamique du language Objective-C (introspection, @optional @protocols, ...) j'imagine.
Alors quand je lis "L'éditeur affirme que MonoTouch permet de réduire la taille d'une application écrite en Objective-C puisque le C# demande moins de code.", je me marre (d'autant que c'est vrai dans certains cas mais pas dans d'autres, ça dépend vraiment du contexte, enfin de la chose à faire et du code pour le faire... et d'autant qu'à côté de ça doit certainement y avoir des limitations et choses réalisables en ObjC irréalisables en C#)
Alors bon, la chose est une très bonne idée pour qui un développeur connaissant le C# et n'ayant jamais touché l'Objective-C voudrait éviter d'apprendre ce nouveau langage... Mais ça reste qu'une solution de portage pour ceux qui ne veulent pas s'y mettre... et $399 pour ça, c'est pas donné je trouve !
Après, on verra si ça décolle, et si ça donne des applis sympas... Pour les C#-iens c'est sans doute une très bonne nouvelle, mais de là à ce que ça soit utilisé en réalité malgré les inconvénients de prix & co...
A-t-on une réelle idée de ce qui est "couvert" par Mono car je vois bien le coup du "sauf ci... sauf ça.." Pis.. développer pour iPhone avec en C#/.Net, ça ressemble à punition non :-) ?
http://monotouch.net/Documentation
Alors là , quel beau code, simple, concis, avec des noms de fonctions clairs, j'en rêverais presque
C'est sur que ca va pousser des gens à coder en C# pour iPhne :fouf): :crackboom:-
Venant de C#.Net, je ne toucherais pas à ce truc, pour toutes les raisons énoncées. Et parce que le code est vraiment moche, faut le dire.
(mon patron m'a proposé de bosser avec ça, il est fou lui, je préfère continuer à apprendre ObjC)
Quand on développe, je pense que c'est plutôt motivant de se plonger dans qqchose de nouveau, même s'il faut un temps d'adaptation. Vouloir se contenter d'apprendre un truc une fois et le ressortir à toutes les sauces, c'est pas terrible...
C'est aussi peu constructif que si on nous proposait de faire l'inverse (du .NET en Objective-C) je trouve.
A la limite (et encore, pour un contexte ordi et non mobile) faire une passerelle qui permet, dans les rares cas où on en aurait besoin, d'appeler des méthodes d'un framework avec un autre langage, comme on peut appeler des méthodes d'une librairies C depuis Java par exemple... tant que c'est une utilisation ponctuelle pour des cas justement comme utiliser une librairie spécifique dont on n'a pas d'API dispo dans le langage qu'on utilise, donc on se fait une passerelle, un peu lourde à utiliser côté syntaxe, mais jouable pour nos besoins... Mais après le but de cette passerelle dans ce cas c'est pas de coder toute l'appli par ce biais, juste d'utiliser les qques fonctions de cette librairie qu'on a pas en Java mais qu'en C. D'autant que dans ce cas (et d'ailleurs zoc l'a bien montré avec son lien vers la doc de MonoTouch) la syntaxe n'est pas forcément simple à utiliser voire plutôt alambiquée, à cause de l'aspect "passerelle"... Donc pour une ou 2 fonctions d'une lib ok, pour toute une appli... gloups !
Sinon pour le Garbage Collector, je trouve (comme beaucoup ici d'ailleurs) que c'est plutôt une mauvaise chose qu'une bonne. Certes pour les débutants ça facilite les choses car "on peut se foutre de la gestion de la mémoire, on laisse trainer nos objets ils seront bien ramassés un jour tout seul, pas besoin de se tracasser". Sauf que ça c'est vite dit, et surtout ne nous laisse aucun contrôle sur la gestion de la mémoire et les potentiels pics mémoire... Et sur un device mobile (comme l'iPhone), c'est une très mauvaise chose et peut mener à une saturation mémoire (imagine un pic, certes temporaire mais existant quand même, car tu déclares bcp de gros objets à un moment, même si tu les détruits peu après... bah il faudra attendre le passage du ramasse-miettes pour que la mémoire redescende...). Et ça donne de très mauvaises habitudes.
C'est un peu comme si tu disais "boarf je peux balancer ma canette de soda vide par terre, et jeter mon chewing-gum et mon emballage de bouffe n'importe où, c'est pas grave y'a les responsables avec leurs pics qui passent derrière pour ramasser les déchets qui trainent" au lieu de dire "bon je vais mettre ça à la poubelle" :P
Pour moi le GC est une mauvaise habitude, qui permet au programmeur débutant de ne pas avoir à se soucier de la mémoire mais ne lui apprend donc pas les bonnes bases de ce côté... Ce qui mène potentiellement à des surprises plus tard ;D
Et ça s'explique donc tout à fait que ça ne soit pas adapté à des devices mobiles (comme l'iPhone donc) où la gestion de la mémoire est un élément important de par les ressources disponibles limitées (et l'absence de swap sur disque comme il y a sur les ordis et sous OSX)
Si c'est pour réaliser après avoir dépensé les $399 qu'en fait y'a plein d'APIs qui ne sont pas disponibles (car pas encore portées dans MonoTouch... ou car Apple les a mis à jour et que MonoTouch n'a pas encore eu le temps de réagir avec une mise à jour de leur côté...) et plein de subtilités d'Objective-C qui ne sont pas traduisibles en C# nous obligeant à des gymnastiques capilotractées... et donc au final être limité...
++
(cela ne mérite pas plus long comme commentaire)
L'avantage que je vois est pour une boite qui dev en .net, par exemple dans ma boite on pourrait proposer un petit truc de monitoring par exemple, alors que je vois mal mon boss se lancer dans du dev dans un autre language "inconnu"
Changer de language n'est pas impossible. C'est en général le chef de projet qui soumet cette idée avec les avantages et inconvénients.
Je ne suis pas très pour ce genre de chose. C# (même si je l'ai jamais utilisé) ne m'attire que très peu. Obj-C et QT me vont très bien :P
Surtout qu'a part les gens s'interessant au mac, peu connaissent cocoa/obj-c, et c'est le genre de truc qui refroidit pas mal en entreprise.
Et c'est là qu'ils appellent des auto-entrepeneurs pour leur faire des appli ::) Youpi alors!
Ils sont marrants chez Novell. En plus de pas être à jours sur .Net, je vois pas comment en plus ils pourraient être à jour sur l'iPhone SDK, enfin j'dis ça mais j'dis rien :(renaud):