.Net pour écrire une application iPhone

273 € par an faut déjà faire une app. qui a du succès pour dire qu'on veux faire du benef.

Gnééé... Il m'a fallu 5 relectures pour comprendre cette phrase un poil trop alambiquée.


Lol. Juste, gros lol. La longueur du code a RIEN à voir avec la taille du programme une fois compilé oO... Surtout si on prend en compte le fait que leur compilateur a des chances d'être moins bien optimisé que celui d'Apple (qui a quand même supervisé l'ensemble du projet, aussi bien matériel que logiciel, depuis le départ).

A moins qu'ils ne parlent de la taille de l'exécutable ? Ce qui m'étonnerait quand même vachement.

En plus, 273€ pour la personal Edition, c'est quand même quasi 200€ de plus que la license Apple pour le SDK iPhone.

Le .NET spa du binaire, c'est un truc bâtard, un langage intermédiaire, comme le Java. Et ce 'code' est recompilé à la volée lors de l'exécution, en gros.
Et vu que le principe, c'est de constamment faire appel au framework (qui prend de la place d'ntrée), y'a des chances que les programmes soient plus petits, en effet.

En tout cas, ça m'étonne qu'Apple soit d'accord avec ça.

Si j'ai bien compris justement, ce SDK "dispose aussi d’un compilateur croisé capable de traduire les exécutables et librairies en applications natives capables d’être distribuées sur l’AppStore" : Apple prohibant la compilation à la volée, le workaround choisi ici est de transposer le bytecode (ou équivalent .net) en exécutable compilé pour l'archi ARM de l'iPhone ?

1/ Donner du pognon à Novell.
2/ Obtenir un code pourri, lent et pas adapté à l'interface de l'iPhone.
3/ Le rejet de son appli par Apple à cause du point n°2.
4/ L'impossibilité de suivre les évolutions d'iPhone OS (car il faudra attendre que Novell sorte une nouvelle version adaptée de sa moulinette, payante ?).
5/ Du temps perdu à faire avec les bugs de l'usine à gaz de Novell, qui d'ailleurs est basée sur Mono, seulement compatible avec les vieilles versions de .net.

Mais qu'est-ce que ça donne envie ! ou pas...



Tu sais, on a pas besoin d'eux, on a déjà des applis (plus de 75000+). Et on est très content d'Objective C et Cocoa. C'est génial d'avoir une vraie communauté qui parle la même "langue".
Jouer les mères Theresa pour les devs .net, non. S'ils ont fait le choix de développer sur des plate-formes qui n'intéressent plus le public et suivi aveuglément MS, tant pis pour eux.
Ils ont qu'à se former à un autre langage c'est pas compliqué (surtout quand il est bon). C'est même à ça qu'on reconnaît un bon développeur: il sait s'adapter.
Alors débarquer avec leur vieille "chienlit logicielle"... non, je crois pas qu'Apple accepte ça.



Alors ça c'est eux qui le disent... et j'irais pas risquer 400 à 4000$ pour le vérifier.



Ah oui ? T'as vu ça où ?

Je crois que t'as pas dû comprendre un truc: on est plus à l'époque de grand-papa où il fallait pisser des milliers de lignes de code car il fallait tout faire à la main et réinventer la roue quasiment systématiquement.
Cocoa c'est une API ultra riche, en s'appuyant dessus on a finalement pas tant que ça de code à ajouter.
Et c'est un peu pareil chez tout le monde, donc faut pas croire que l'on va se retrouver avec des différences importantes (si on compare deux langages modernes, quels qu'ils soient). Novell prend vraiment les développeurs pour des idiots en disant cela...

Quand à dire que .net fait mieux non... ou alors on attend les exemples.

Tiens voilà un exemple (mais qui va pas dans le sens de Novell ): comparons les "List" du C# avec les "NSArray" d'Objective C... parce que là MS a un sacré retard: la List du C# ne peut contenir qu'un seul et même type d'objet (par exemple une chaîne). Tandis que les array d'Objective C peuvent contenir simultanément n'importe quel type d'objet (une chaîne, un nombre, ...). Ça et le typage dynamique, ceux qui développent un peu comprendrons l'avance d'Objective C.
C'est là où donc le C# va te donner du fil à retordre à vouloir réinventer la roue. Combien de ligne de code pour refaire "pareil" qu'en Objective C ?

Et c'est comme ça pour plein de trucs... Le seul avantage théorique de .net c'est la gestion de mémoire qui est "automatique". L'objective C2 d'Apple le fait, mais ils ne l'ont pas implémenté dans l'iPhone. Pourquoi ? Parce que les mécanismes de surveillance de la mémoire consomment des ressources. Sur un ordinateur traditionnel, gavé de MHz et de Go, c'est peanuts, mais sur un smartphone c'est une autre histoire.
Je sens que ça va être fabuleux ces applis en C#...

OK ch'uis mal réveillé.
Effectivement, là y'a même plus l'intérêt du .NET grâce à Apple, ça devient du 100% compilé et limité à une archi.

Y'a moins de lignes de code parce que .NET c'est beau c'est propre alors que l'Objective C c'est du gros caca des années 80.
C'est ça qu'il a dû vouloir dire. Enfin quoi que mon argument d'avant tienne encore à moitié.


Edit : merde, grillé, je répondais à Pluies.

Oui, sauf qu'il faut quand-même la payer en plus pour accéder à l'AppStore d'Apple. Le kit de Novell nécessite d'ailleurs toujours Xcode et donc un Mac.
Bref ça n'est absolument pas une économie.
Le seul intérêt théorique ça serait qu'un dev n'ai pas à réapprendre un nouveau langage. Sauf qu'au final ça prendra pas plus de temps que de se battre avec les incompatibilités de la bidouille de Novell... Et plus le projet que tu veux développer est important, plus ça deviendra critique.

Apple a pas le choix. 1) C'est virtuellement indétectable pour eux si une appli a été conçu via MonoTouch ou autre car au final tu as un binaire Arm et la licence d'utilisation de l'iphone n'est pas violée.

2) Apple a pas le choix. Le nombre de dev C#/.NET est largement supérieur au nombre de dev Objective-C.

3) Le code généré par C# puis compilé en instructions arm est tout aussi rapide que du code Objective-C compilé en instructions arm.

J'attends des sources/bench pour juger de ça. Actuellement, Apple, via LLVM et Clang, dispose de compilateurs vraiment très puissants. Attendre de Novell qu'ils sortent un truc comparable à partir de .net, qui n'est pas pensé pour une utilisation compilée, me semble difficile (pas impossible... Mais difficile quand même ).


Si j'ai bien compris aussi ; les devs .net doivent quand même utiliser les fonctions Apple pour créer l'interface graphique... Donc il y a quand même un apprentissage à prévoir.

Mono est Open Source. Si MonoTouch est basé sur Mono il devrait être Open Source. Ou au moins une partie MonoTouch devrait l'être.
Je me trompe ?

FireBird > à mon avis, y'a des gros bouts opensource dedans oui.

Sinon, LVM, les frameworks Apple sont tellement à la ramasse par rapport à Java et .NET que .
Dans quelques années, Apple va faire un 180 sur la question, ça va être marrant d'ailleurs.
Et pour des tableaux de types différents : http://dotnetperls.com/object-array

Oui c'est sur, wait & see. Par contre les mecs de Mono sont vraiment très bon, donc attention à ça. Après, rien n'empêche de compiler du code CIL (le bytecode .NET) pour une architecture donnée. Ca a été prévu puisque Microsoft fait la même chose avec Bartok, je vois pas ou est le problème.

Sinon est-ce que Objective-C utilise par défaut LLVM et Clang pour générer du code iphone via le sdk officiel Apple ?

Apple l'a fait pour les processeur intel, alors oui pourquoi pas un jour décidement d'adopter .NET via mono et de contribuer à ce projet open-source, en déplaise à certain..

Ah !

Oui ça me paraissait en effet très curieux, voir tenir de la science-fiction, qu'on puisse arriver à reprendre une appli .net venue par exemple d'un smartphone WM, qu'on la passe à la moulinette, et qu'on se retrouve avec une appli avec le look&fell iPhone.

Si les devs doivent utiliser directement les API d'Apple, là ça me semble déjà plus faisable. Mais comme tu le dis il a forcément de l'apprentissage car les API de l'iPhone sont assez riches.

La seule chose donc que permet de faire le kit de Novell c'est de ne pas apprendre l'Objective C. Alors que pourtant ça c'est pas grand chose comparé à la découverte des API d'Apple.

Bref, tout ça me semble fort peu utile...




Sauf que pour la validation de l'appli tu dois fournir l'exécutable... et le source. Va donc pas falloir longtemps aux gens d'Apple pour voir la supercherie.
Autre petit détail: on s'en plaindra ou pas, mais Apple se réserve le droit de pas accepter ton appli pour tout motif qu'elle aura décidée. Rare sont les fois où elle en est arrivée là, mais ça lui permettra d'éviter ce genre de surprise.

Bref, Apple a le choix...




Tu veux que je te dise ? Ils s'en balancent totalement !

Je vois pas Apple reculer sous prétexte qu'il existe de la concurrence, sinon ils n'auraient jamais rien sorti de toute leur histoire.

Et question concurrence, y'a peut-être plus de devs C# (ou n'importe quel autre tech MS) qu'Objective C, mais ce que je vois c'est qu'en un an Apple a déjà plus d'appli sur son Store qu'il s'en est créé sous WM en près d'une décennie.

Donc crois-moi que les devs ça les dérange pas du tout de migrer vers une autre plate-forme si il y a quelque chose à gagner à l'arrivée. Ils n'ont pas tes états d'âme... Et le langage de programmation c'est vraiment pas un problème.




OK, mais sur quoi tu te bases pour affirmer ça ?

Parce que rien que le fait d'intégrer un garbage collector a déjà de quoi de faire diminuer largement les perfs... car on le rappelle on parle de smartphones, pas de gros ordinateurs.




Je suis d'accord sur le côté inutile de l'usine à gaz Novell.

Mais non ObjC c'est pas caca et vieux. Ça fait même tout un tas de trucs dont le C# est encore incapable (ou promis pour plus tard, si, si, juré). C'est un langage facile à lire (rien que la façon dont on décrit les paramètres dans les méthodes, c'est fabuleux) et à apprendre. C'est d'ailleurs avec celui-ci que Tim Berners Lee a conçu le premier navigateur web, et ce en fort peu de temps.

Novell veut juste vendre sa soupe, mais il se ridiculise avec ses arguments à deux balles sur Objective C.

Oui. Mono est distribué selon les termes de la LGPL (Lesser General Public License). Contrairement à la GPL, on est pas obligé de rendre open-source un projet basé sur un projet LGPL. A la base, ça permettait d'intégrer des librairies open-source dans un projet propriétaire ; maintenant ça s'est répandu un peu au delà des simples librairies.



Xcode utilise encore GCC par défaut sous Snow Leopard (sans LLVM apparemment) pour les applis OS X, donc je pense pas que ça soit utilisé pour les applis iPhone (pas sûr du tout cependant). Clang est quand même le compilateur recommandé.

Non-non, je voulais pas dire Apple qui adapte .NET. Non franchement, ça ça serait un peu énorme.
Je voulais dire Apple qui se décide à adopter un langage moderne, sans pointeurs, à la Java/Python/.NET.

L'Objective C c'est mignon mais voilà quoi. Et ça fait quoi déjà que C# sait pas faire, LVM ?
Non mais sans rire, instruis-moi.

Ah elle est bien bonne celle-là !

Y'a de plus en plus de devs Mac et iPhone, et Apple complète ses API chaque année (en prenant soin d'ailleurs de virer les vieilleries, chose que ses concurrents ne font pas trop, tant pis pour eux). Chez Apple on est pas stupide au point de changer ce qui plaît aux devs... surtout quand les ventes suivent.

Java a montré ses limites, d'ailleurs sous Android il est maintenant possible de s'en passer pour du bon vieux C/C++, seul capable d'assurer des performances décentes dans les jeux par exemple.
J'ose espérer que le Zune emploiera du code compilé...




T'es comiques toi...

Tout ce que tu me montres c'est un bon vieux tableau de pointeurs comme en C (on peut d'ailleurs le faire aussi en objective C)... Ça n'a rien de dynamique (vachement pratique pour ajouter/enlever des données !). Essaye de me refaire ça avec "List" qu'on rigole.

Tiens essayes plutôt un truc de ce genre:


Explication: non seulement je peux créer un tableau dynamique et y mettre n'importe quoi dedans, mais je peux appeler la même méthode (length) quel que soit le type d'objet stocké dedans.
Imagine un peu la galère pour refaire quelque chose de ce genre avec un langage pas adapté...

C'est assez amusant de voir LVM (qui n'est absolument pas un devellopeur, je le connais personellement ) deviser longuement pour nous expliquer le non-intérêt d'une solution proposé par Novell (qui comme on le sait, a beaucoup moins d'expérience que LVM en matière de développement)

Tu sais les pointeurs ça peut parfois être utile. L'objective C a ceci d'intéressant et qu'il est par dessus le C, donc laisse l'utilisateur libre de faire du code un peu bas niveau (à coups de pointeurs sur des chaînes C par exemple si ça l'amuse), ou au contraire de faire tout par les objets de haut niveau (style NSArray ou NSString), et pourquoi pas même mixer les deux.
Dire on "supprime les pointeurs" c'est stupide, c'est dire adieu à du code rapide. Y'en a pourtant besoin parfois !
Apple au contraire t'offre une grande liberté avec à l'Objective C.




Regarde mon message précédent...

Moi par contre "petitmulot" ça me dit rien du tout. Donc monsieur petitmytho il a intérêt à pas continuer ce petit jeu, car, c'est rare, mais j'irais vite signaler ça au modo...




Alors que toi en une ligne tu gobes le blabla publicitaire sans broncher...

J'ai jamais dit que j'avais plus d'expérience ou moins d'expérience que quiconque. D'ailleurs c'est quoi la tienne dans le domaine ?

... Je suis outré. Touche pas à mes pointeurs. x(


Plus sérieusement, tu peux très bien coder sous Mac sans Objective-C. Le Java passe très bien (au prix d'une machine virtuelle souvent à la bourre de l'officielle de Sun), Python sur Mac est bien foutu à ce que j'ai entendu, et sinon tu peux aussi voir du côté de MacRuby, dont les performances sont, parait-il -non je n'ai malheureusement pas encore d'expérience avec MacRuby- excellentes.

Oui enfin t'es conscient que les devs Apple sont là pas grâce à ObjC mais grâce au succès de l'iPhone hein...





Je suis pas pro-Java (loin de là), mais Java en entreprise et en école d'info c'est tout simplement énorme.
Sinon, le Zune fonctionnera avec XNA, donc forcément c'est du .NET hein. Le principe c'est que .NET est réellement en train de devenir multi-plateforme, alors qu'au début, c'est un peu que Windows. Pour de vrais jeux, effectivement, C/C++ c'est pas près de partir, par contre, pour les jeux bidons mobiles, mouais, je suis pas sur que ce soit impératif... A voir.





OK. Je suis à peu près sur qu'on peut faire ce que tu dis en C# avec un List