Du moins, si vous êtes un développeur iPhone. Comme vous le savez, c’est plutôt cool de développer sur iPhone mais par expérience, mieux vaut ne pas se cantonner à un seul environnement et je ne peux que conseiller aux développeurs iPhone de s’intéresser aussi aux autres plates-formes.
Microsoft l’a bien compris et a mis en ligne un document technique ICI pour vous donner une petite étude de cas du comment que c’est facile de passer de l’iPhone vers Windows Mobile.
C’est assez drôle de voir la stratégie de Microsoft qui la joue profil bas. En effet, au lieu d’attaquer frontalement l’AppStore, Microsoft essaie plutôt de séduire la communauté iPhone, ce qui n’est pas plus mal ! Seul le temps nous dira si ça a été la bonne stratégie ou pas, mais je salue l’initiative.
via intomobile
Le Journal du Geek
D3m3t05
6 août, 2009, 11:18 #1Et vas y que jte pique des devs….
les méthodes de des societées me dégoute de plus en plus (Apple et Google inclus!)
pizz
6 août, 2009, 11:21 #2ahah génial
j’adore la critique du fait que l’iphone soit pas multitache, marrant quand on sait à quel point c’est daubé la gestion des process sous windows mobile
ZARk
6 août, 2009, 11:24 #3Bah non, c’est pas pour « piquer » des devs.
l’iphone a permis a pas mal de « nouveaux » devs d’emerger.
Microsoft leur rappelle que developper pour WM n’est pas beaucoup plus compliqué.
Un argument que je vois pas mal autour de moi pour l’achat d’un iphone est le nombre de ses petites applications fun et gratuites (sabre laser, etc..).
Ce genre d’applications n’existe pas sur un « windows phone ». Les devs sont plus pro/serieux, et les applications fatalement aussi. Et puis il manque un equivalent AppStore.
Perso je suis « anti » iphone. Un telephone a ce prix la merite d’etre multi-tache. Mais il est vrai que la communauté autour est forte et c’est un tres tres gros argument.
Perso je developpe en .NET mais je n’ai jamais testé ca sous WM.
Je prefere developper pour Android
Thordax
6 août, 2009, 11:32 #4Toujours la même technique lancée par Microsoft, en même temps, on mise sur notre image de marque, on va tenter de récupérer ce qu’il y a de mieux chez les concurrents et faire pareil, et on va serrer les fesses pour voir si ça passe :mrgreen:
NICK
6 août, 2009, 11:41 #5d’abord il est archi faux de dire que l’iphone n’est pas multi tâches. L’application mail par exemple tourne en tache de fond pour récupérer les mails pendant qu’on fait autre chose. Apple a bridé le multi tâche pour les développeurs afin d’économiser la batterie de l’appareil.
Ensuite l’initiative est bien mais en réalité porter une application iphone sur windows mobile s’avère plus compliqué que ce que Microsoft veut bien laisser entendre.
Heran
6 août, 2009, 11:41 #6Bien sûr que c’est une bonne initiative, puisque le Journal de l’Anti Apple le dit.
NICK
6 août, 2009, 11:44 #7sois pas aigri Heran, il y a pas que des anti apple sur ce site, ils ont juste souvent une plus grande gueule…
b0wh
6 août, 2009, 11:51 #8C’est moi ou Windows fait du tout bon en ce moment ? Windows Seven qui, d’après les échos, n’a pas l’air si mal que ça, le Zune HD qui a l’air plutôt bien, etc..
Bruce
6 août, 2009, 11:52 #9« Apple a bridé le multi tâche pour les développeurs afin d’économiser la batterie de l’appareil. »
Fausse excuse. 1 ou 10 process ne consomment pas plus de batterie. C’est juste pour éviter des éventuels plantages et blocages en tâche de fond. Et aussi pour garder la main mise sur les applications.
seth
6 août, 2009, 11:59 #10on trouve de quoi créer des application facilement sur Iphone, grâce au succès de ce téléphone, alors que sur windows mobile…
faire son jeu sur Shiva, Unity, etc…et se contenter d’une plate-forme pour vendre, quand on peut tous les avoir à moindre frais, pourquoi hésiter?
Microsoft a raison, faciliter la tache des développeurs est une bonne chose
développer sous symbian, et se limiter aux symbianphone, c’est dommage, autant envisager le marché le plus intéressant
Microsoft crée un lien qui manquait, et ça va aider les développeurs à vendre leur travail, tant mieux pour eux, mais ça ne plaira pas Apple qui préfère garder l’exclusivité d’une appli
baramuse
6 août, 2009, 12:10 #11@zark et Bruce :
1 ou 10 processus ne consomment absolument pas les mêmes ressources..
si tu as 10 processus qui ne cessent de demander ce qu’il se passe ou un seul, evidement que le CPU est bien plus sollicité!
Le systeme du push-notification est fait dans ce sens, il n’y a qu’un seul processus qui se charge de reveiller les autres pour leur dire qu’ils ont des trucs qui pourraient les interesser…
donc 1 SEUL processus qui tourne en tache de fond = moins de CPU/mémoire/acces = plus de batterie !
Et concernant la fonction Ipod ou téléphonie qui elles peuvent tout a fait fonctionner en meme temps que d’autres applis, c’est aussi parcequ’elles ont du hardware dédié.
Le système PALMOS 5 qui, a mon avis, n’a pas a rougir face a android, macosX mobile, WebOs etc, était architecturé de la meme facon… les applications « s’endormaient » et se « reveillaient » mais ne tournaient jamais en permanence…
Evidement le modèle de programmation est plus complexe, mais aussi bien plus élégant…
enfin pour ce qui est de transformer des appli iphone d’objective C a du .net ca me fait doucement rire… j’aimerai bien voir ce qu’ils arrivent a convertir a pars « Hello world! » ^^
NICK
6 août, 2009, 12:14 #12@ Bruce : « 1 ou 10 process ne consomment pas plus de batterie. », t’es vraiment sûr de toi sur ce coup ? Je serais intéressé de connaître tes sources. Déjà certaines applis usent la batterie beaucoup plus vite que d’autres alors pourquoi 10 en même temps ne consommeraient-elles pas plus qu’une seule ?
Heran
6 août, 2009, 12:19 #13Mon commentaire que personne ne lira :
C’est pas le nombre de process qui va influer sur la batterie, mais ce qu’ils font. 10 process de petites applis basiques genre un bloc note, un calendrier, des trucs comme ça, ça va surtout prendre de la RAM mais ça ne tapera pas dans le CPU. Mais il suffit de je sais pas moi, 3 process qui utilise beaucoup le CPU, et là oui la batterie va se faire violer.
NICK
6 août, 2009, 12:25 #14Mais si on te lit Heran, sois pas parano comme ça…
Frol
6 août, 2009, 12:27 #15huuum j’adore ces sociétés qui préférent prendre les améliorations des autres plutôt que de créer quelque chose.
C’est vraiment trop lamentable qu’ils fassent quelque chose d’original pour changer une fois…
Nonepse
6 août, 2009, 12:28 #16« Comme vous le savez, c’est plutôt cool de développer sur iPhone »
C’est une blague ou quoi ?
Je developpe pour iPhone dans une boite d’outsourcing et je m’interresse de pres a Windows Mobile a titre perso.
Quel torture de developper en Objective-C (alors que je viens du monde du C / C++)
Je prefere de bien loin le .NET sous WM …
tefze1
6 août, 2009, 12:32 #17Sauf que Microsoft ne dit pas « Dev sur WM c’est mieux »
Ils cherchent juste a montrer que faire des applications mutliplateforme, c’est pas super hardcore.
Suffit qu’Android rentre dans le moule (palm aussi) et on aura l’application qu’on veut, sur la plateforme qu’on veut
Le Phasme
6 août, 2009, 12:32 #18la méthode est étrange (venez amis de la pomme, venez développer chez nous !), mais il est vrai que les dev ne devraient pas se contenté d’une seul plateforme, et l’initiative de Krosoft pour une conversion OSX > Windows est finalement bénéfique.
D’autant plus que je suis persuadé, et ce malgré tout ce que certain peuvent pensé de Windows Mobile, que Krosoft finira par imposé son store, donc autant s’y mettre tout de suite pour être dans la course.
tiopie
6 août, 2009, 12:36 #19@b0wh
comme tu dis ca a l’air plutot bien….comme le canada dry mais au final tu es toujours deçu….
inthepockets.com
6 août, 2009, 13:29 #20J’ai eu la « chance » de programmer un peu sur toutes les machines depuis 30 ans, j’ai fait un où plusieurs jeux sur chaque plateforme.
Mon classement du plus facile au plus difficile:
01) Apple IPhone ( Avec XCODE et OpenGL ES )
)
02) Apple MacOSX ( XCode et OpenGL )
03) Fujitsu FM-Towns ( 1989, C et assembleur 80386 avec déjà le cédérom et une CG top , un machine de fou, rotation hard, 800 sprites de à l’écran etc etc )
04) Sharp X68000 ( 1990, machine de dingue , 100% en C et trés trés rapide )
05) XBOX 360 ( C++ avec XNA et le la version gratuite de VC2005, avec une manette filaire USB , on peut même se passer de la XBOX pendant le développement )
06) Windows ( En C++ avec VC6 et DirectX )
07) Linux ( En C++ avec OpenGL )
08) Smartphone Windows ( Avec VC3 et en C++, le problème se sont les tailles d’écrans différents les touches etc etc )
09) PDA Windows ( Avec VC3 et en C++ , avant 2003 , c’était plus prise de tête avec les arms, mips etc )
10) Sony PSP ( Avec CodeWarrior en C++, plus facile si vous utilisé un « moteur » … mais pas tous les moteurs )
11) Nintendo DS ( Les limites de la ram vidéo et plein petite truc bien prise de tête … et l’attente de validation de Nintendo…..)
12) Nokia Symbian ( Programmation en C++ contrairement a la plupart des téléphones de l’époque sous Java J2ME )
13) Sony PSOne ( Les limites de mémoire vidéo )
14) Nec PCEngine ( Assez dur de faire un jeu « nextgen » en assembleur 6502.. et oui 8bits, c’est le proccesseur qui est 16 bit )
15) Téléphone J2ME ( La prise de tête total, avec des bugs dans chaque téléphone, la variété des espaves ram et ram vidéo, les inversions de touche… une horreur )
16) Doja Phone( Le Doja la limite de 32000 octet pour le code et les graphisme télécharger depuis le serveur a coup de 10 bloc de 10000 octets )
17) Commodore 64 ( Assembleur 6510, les sprites hard ça aide, héritage du Vic20 )
18) MacOS 1.0 a 6.0 ( En C…Rien a voir avec MacOSX )
19) Amiga ( Assembleur et C… Pas aussi rapide que l’on peut croire, mais la premiére fois ou un circuit vidéo à son propre langage… a l’image des cartes vidéo moderne )
20) Atari ST ( Assembleur 68000/C , les plans graphiques séparé , pas de vrai circuit vidéo comme dans un Commodore 64… contrairement aux idées reçues )
21) Nintendo GameBoy ( En assembleur Z80… a les banques de mémoires…. et les limites des sprites… )
22) MSX 1 ( En assembleur Z80 , rapide avec en plus des sprites hards… )
23) Thomson MO/TO ( En assembleur 6809, les couleurs faisaient 8×1 et les pixels 1×1 comme pour beaucoup de jeux, cela « bavaient » , mais moins que le Spectrum qui avait des blocs de couleurs de 8X8 )
24) Sinclair Spectrum ( En assembleur Z80, la ram vidéo en 3 morceaux et chaque morceaux en sous bloc de 8 lignes.. en fait un mode texte … qui servait de faux écran haute résolution )
25) Amstrad 664 et autres ( En Z80, comme pour le spectrum , la ram vidéo était en « désordre » par rapport à l’affichage… une bonne table d’indexation et on n’avait un écran linéaire…. )
26) Atari VCS ( Assembleur 6502… 128 octets de ram ! 4096 octets pour le jeu et UN OCTET de ram vidéo… il fallait taper les octets a la vitesse du déplacement du spot dans un unique registre.. mais il y avait 2 sprites monochrome et 2 sprites de tir )
27) Phillips VG5000 ( Vraiment limité…. trés limité )
28) L’Exelvision ( Plus on utilisait de l’espace mémoire pour le code du jeu, et plus la résolution de l’écran graphique demandé par le programmeur devait être petit… une demi écran.. partage de la ram et de la ram vidéo version trés limité… sauf dans le cas d’un jeu sur cartouche )
29) Windows DOS en CGA/EGA ( En 8086, avec les plan graphiques )
30) Oric 1 ( Assembleur 6502, sympa mais un couleur d’encre de fond par ligne c’etait juste… plus simple de faire les jeux en mode « caractère » , on redéfinissaient les caractères pour faire des « morceaux » de monstres )
31) Sharp PC 1211 ( Super sympa et simple mais pas acces a l’assembleur et pas de mode graphique, contrairement au Casio FX702P, machine arrivé 2 ans plus tard )
32) Texas Instrument 57 ( 50 pas de programme , et pas de mémoire permanente , donc si on coupe la machine, on perd le programme… mais un élastique et une gomme, pouvaient aider
33) Alice 64 ( En assembleur 6803, la partie graphique est une horreur )
Voila voila …normalement plus ça va plus les choses sont simples… enfin en théorie….
Galork
6 août, 2009, 13:48 #21Très bonne initiative de la part de Microsoft, de un ça permet de retrouver les applis sur plusieurs plateformes (il y a qu’à voir comment un linuxien est malheureux quand une bonne appli existe uniquement sur windows) et de deux d’un point de vue marketing c’est très bon (pour ceux qui imaginent encore que le monde est gentil tout plein, retournez chez les bisounours, une entreprise en premier lieu elle fait du fric, pas de la charité!)
thipyt
6 août, 2009, 14:47 #22« pour ceux qui imaginent encore que le monde est gentil tout plein, retournez chez les bisounours, une entreprise en premier lieu elle fait du fric, pas de la charité! »
Lol, la phrase bateau placée là sans le moindre intérêt !
KCd
6 août, 2009, 15:51 #23evoir éditer un tel guide alors que cet iphone a été annoncé comme voué à l’échec par le président de Microsoft , c’est quand même une sacrée déconvenue !!
http://www.youtube.com/watch?v=C5oGaZIKYvo
Petite précision: Pour développer, ils indiquent qu’il faut visual studio pro 2008 (ou 2005). Le 2008 est quand même à 1099 euros.
Et certains se plaignent de l’abonnement 99 euros par an pour placer son appli sur l’app store. Rien que le ticket d’entrée chez krosoft vaut 11 ans d’abonnement…. :mrgreen:
Guitou
6 août, 2009, 16:08 #24@inthepockets.com, tu es le papy de la programmation ou quoi? 8O
C’est impressionnant l’experience…
Microsoft mange la pomme après l’avoir laissé murir! Normal non? :mrgreen:
pizz
6 août, 2009, 16:13 #25@inthepocket.com
et android dans tout ca
inthepockets.com
6 août, 2009, 17:08 #26Android c’est sympa mais le SDK sous Mac, est loin trés loin de valoir celui du Mac.
En plus pour Android comme pour le développement sous MS Mobile, il faut prendre en compte tous les tailles d’affichage
Le développement sous « IPhone », permet une compatibilité avec 40/50 millions d’IPhone / IPod Touch.
Quand on développe sur MS Mobile, il faut avoir 5 où 10 téléphone. ( J’ai 2 téléphone MS Mobile )
Pour le Symbian, il faut avoir 3 où 4 téléphone, il y a des « surprises » , j’ai 2 téléphone Symbian.
Quand on fait du J2ME MIDP 1/2 il faut faire le jeux pour 17 téléphones puis faire 200 versions et aprés le jeu part en inde et le jeux est testé sur 1000 téléphones…. différents .
Que se soit les nouveaux OS comme Android où le reste, vous vous trouvez avec une quantité de spécifications différentes qui rendent les projets lourds.
ET UNE CHOSE IMPORTANTE L’ARGENT !
Se qui rapporte le plus pour un développeur c’est la Nintendo DS où la WII , aprés vient la PSP.
L’IPhone rapporte de l’argent si vous avez pas mal de jeu dans votre « catalogue »
Par an on me propose 8 projet sur DS / WII ou autres, 1 où 2 sur IPhone , 0 sur les autres plateformes.
C’est l’argent qui fait que vous passez à une plateforme où à une autre.
Attention, je parle du cas où c’est votre « métier ».
Même si c’est une passion de s’éclater avec une machine où autre c’est l’aspect financier qui à son mot à dire. Car le matériel coûte cher, si vous devez acheter 10 téléphones MS Mobile de différentes marques , vous allez voir….
Et les petits studios qui font du développement sous MS Mobile et autres ont une quantité de matériel assez « costaud ».
De toute maniére il faut une journée pour apprendre une nouvelle plateforme, sauf, pour les consoles, qui sont plus « chiante », mais que se soit, MS Mobile, Iphone , Andoid , Black Berry où Palm Pré , cela ne prend pas de temps.
Rien ne sera pas aussi compliqué que de faire un jeux sur console en assembleur… aujourd’hui c’est trés trés facile , surtout avec toutes l’information et les SDKs
Se qui rend les projets, longs c’est la relation humaine entre tous les acteurs d’un projet.
Il y aussi la GBA
, c’est aussi une super machine.
Galork
6 août, 2009, 17:12 #27« Lol, la phrase bateau placée là sans le moindre intérêt ! »
Lol, la phrase bateau placée là sans le moindre intérêt!
C’était pour répondre à ceux qui t’expliquent que ouin ouin les méthodes commerciales elles ne servent pas à sauver la misère du monde.
inthepockets.com
6 août, 2009, 17:20 #28Les outils Windows Mobile coute plus de 1000 HT , le SDK est gratuit sur Mac, et on ne dépense les 79 euros seulement aprés avoir finie un développement, on dépense pas d’argent AVANT.
Et pour Apple vous n’avez besoin soit d’un IPhone… sur MS Mobile vous devez avoir 4 où 8 téléphones. Pour tester les différentes résolution d’écran et les différentes API
Samsung fournis un SDK et une API a ajouter au SDK MS Mobile
Les HTC ont leurs propres API au niveau de la caméra….
LG fournis aussi son SDK + une API a ajouter au SDK MS Mobile
Pour maitriser le park complet des MS Mobile, cela demande plus de travail.
Voilà pourquoi parfoit il faut mieux faire des jeux sur IPhone ou sur console de jeux que sur PC où sur MS Mobile où sur les OS « nouveaux » , a cause la diversité du matériel et des APIs.
Guitou > Je suis pas encore un Papy, mais j’ai commencé trés jeune… mais j’espére faire encore se taf pour 30 ans.
Nick
6 août, 2009, 17:55 #29enfin du commentaire intéressant sur ce site. Ca nous change de ceux qui connaissent tout sur tout mais disent bêtise sur bêtise, merci beaucoup inthepockets
DENIDVICO
6 août, 2009, 18:24 #30Frol : « huuum j’adore ces sociétés qui préférent prendre les améliorations des autres plutôt que de créer quelque chose.
C’est vraiment trop lamentable qu’ils fassent quelque chose d’original pour changer une fois… »
C’est pas bien de taper sur Apple comme ça, ils ont le droit de voler si ils veulent.
Marquis de Sade
6 août, 2009, 19:33 #31inthepockets.com, t’es qu’un petit frimeur. TI57? C’est pour les nuls. Et tu trouves ça difficile? HP29C, en voilà une pour faire des jeux, des vrais.
Marquis de Sade
6 août, 2009, 19:47 #32J’ai parcouru rapidement le doc microsoft. Il y est écrit (je traduis), finalement, « le gros de l’effort de portage consiste à passer de l’objective-C à C#, qui sont deux langages du style java ».
Mort de rire. Le gros du boulot consiste à réécrire le code. Y a-t-il un Lapalisse anglo-saxon? Et objective-C c’est comme du java. Bien entendu. Et Vista a connu un énorme succès commercial aussi, grâce à la marmotte intégrée qui plie le papier alu.
Moi, je n’appelle pas ça du portage. Quand on change de langage, d’OS, de librairies, et qu’on ne garde que les jolis dessins de l’IHM, j’appelle ça une réécriture.
inthepockets.com
6 août, 2009, 20:15 #33La TI57 etait « difficile » car on perdrait le programme que l’on avait « taper » a la main, lorsque que l’on pressait « off »….
Chaqu’un à son opinion sur la difficulté d’une machine où d’une autre. Vous trouvez la HP29C difficile pas moi !
Il n’y aucun rapport entre le développement d’un jeu sur une calculette surtout comme la HP29 comparer au développement d’un jeu de plus 128 000 ligne de code entiérement en assembleur sur NecPC Engine cédérom et qui est commandé par Mr Nec lui même. ( J’aurais pu dire la meme chose pour le FM Towns ou le X68000 , la VCS 2600, la GameBoy etc etc )
Merci pour votre humour
Windows Mobile France
7 août, 2009, 03:11 #34Chaque plateforme a ces avantages et inconvénients.
Si vous voulez polémiquer sur quelle est la meilleure et pourquoi ya le forum officiel de la communauté WM France:
http://www.wmfrance.com/forum
et pour les aficionados de Windows Mobile: http://www.wmfrance.com/
Capitus
7 août, 2009, 03:30 #35Microsoft fait ce qu’Apple ne sait pas faire :mrgreen:
Chacun joue sur son terrain^^
miammiam
7 août, 2009, 11:55 #36@inthepockets.com
android n’a que des res hvga pour l’instant il me semble…
de plus pour ms tout les tel annoncés compatible 6.5 sont du wvga…ce qui va devenir la norme…
inthepockets.com
7 août, 2009, 12:16 #37Android est multi-constructeur, se qui rend dans tous les cas le développement plus « délicat » que un OS qui est propriétaires. Car il y a souvent des différences notables aux niveaux du hardware et chaque constructeur veux faire de la surenchère , taille d’écran, touche plus où moins nombreuses , où des versions « low cost » qui sont alors, trés différentes du but initial.
Mais ce n’est pas grave, il faut attendre de 2 à 3 ans aprés la sortie d’un os pour voir sont « avenir ».
Plus il y a d’OS et de problèmes plus j’ai du travail !
Nono313
7 août, 2009, 21:54 #38Je suis pas spécialement fan de Microsoft et encore moins d’Apple, mais je dois dire que pour une fois M$ a eu une bonne idée.
Reste a voir si les développeurs vont s’y mettre.
Quitte à développer sur plusieurs plate-forme, il faudrait faire la même chose pour des mobiles comme BlackBerryOS, WabOS (Palm Pre) ou encore Android