Après l'excitation de l'annonce du SDK la semaine dernière, les développeurs ont enfin pu se mettre au travail et découvrir la plate-forme de développement. Ils ont d'abord été acheter un Mac (ça c'est nouveau pour un dev smile ), puis ont téléchargé les 2 Go du SDK.
Au cours de la keynote, il a été présenté un client AIM sur iPhone parmi les fonctionnalités annoncées du firmware 2.0, mais tout n'est pas si simple et les développeurs découvrent peu à peu les entrailles de l'appareil et avec les premières limitations qui leur seront imposées.
Il apparait en effet que les applications tierces ne seront pas autorisées à continuer à s'exécuter en arrière plan. Tant qu'une application est ouverte et visible, elle est en cours d'exécution, mais dès qu'on appuie à nouveau sur le bouton Home, l'application quitte pour revenir au SpringBoard. Le système est donc monotâche pour les applications lancées, ce qui rend un client de messagerie instantanée difficile à mettre en oeuvre.
Cela évite évidemment une surcharge mémoire comme a pu le connaître Windows Mobile à ses débuts lorsque l'on avait ouvert trop d'applications en mémoire, mais connaissant la puissance qu'héberge l'iPhone sous son capot, on est un peu étonné que le système soit bridé à ce niveau par le constructeur.
On imagine que la volonté première d'Apple a été de privilégier la réactivité de sons sytème embarqué pour ne pas par exemple se retrouver avec un jeu qui continuerait à s'exécuter en tache de fond prenant une quantité non négligeable de CPU et de mémoire au détriment des fonctions de bases prioritaires que sont la téléphonie et les SMS. Mais encore une fois, la machine semble pourtant avoir assez de puissance pour le gérer et ce ne serait donc pas une limitation technique mais volontairement implantée par Apple.
Autre point important, l'étude des guides de programmation mis à disposition pour les développeurs révèle également que dans ce type de configuration, le runtime Java de Sun ne saurait s'exécuter convenablement dans la mesure ou une application tierce n'est pas autorisée à lancer un autre exécutable.
Il est évidemment toujours possible de faire tourner un daemon pour protéger l'exécution d'une tâche en mémoire même lorsque l'application qui y accède se ferme, mais il n'est pas encore expliqué dans les documentations mises à disposition si cela est possible.
Les développeurs vont donc devoir se creuser un peu pour chercher des parades et astuces permettant de protéger l'exécution de leurs programmes.
Au cours de la keynote, il a été présenté un client AIM sur iPhone parmi les fonctionnalités annoncées du firmware 2.0, mais tout n'est pas si simple et les développeurs découvrent peu à peu les entrailles de l'appareil et avec les premières limitations qui leur seront imposées.
Il apparait en effet que les applications tierces ne seront pas autorisées à continuer à s'exécuter en arrière plan. Tant qu'une application est ouverte et visible, elle est en cours d'exécution, mais dès qu'on appuie à nouveau sur le bouton Home, l'application quitte pour revenir au SpringBoard. Le système est donc monotâche pour les applications lancées, ce qui rend un client de messagerie instantanée difficile à mettre en oeuvre.
Cela évite évidemment une surcharge mémoire comme a pu le connaître Windows Mobile à ses débuts lorsque l'on avait ouvert trop d'applications en mémoire, mais connaissant la puissance qu'héberge l'iPhone sous son capot, on est un peu étonné que le système soit bridé à ce niveau par le constructeur.
On imagine que la volonté première d'Apple a été de privilégier la réactivité de sons sytème embarqué pour ne pas par exemple se retrouver avec un jeu qui continuerait à s'exécuter en tache de fond prenant une quantité non négligeable de CPU et de mémoire au détriment des fonctions de bases prioritaires que sont la téléphonie et les SMS. Mais encore une fois, la machine semble pourtant avoir assez de puissance pour le gérer et ce ne serait donc pas une limitation technique mais volontairement implantée par Apple.
Autre point important, l'étude des guides de programmation mis à disposition pour les développeurs révèle également que dans ce type de configuration, le runtime Java de Sun ne saurait s'exécuter convenablement dans la mesure ou une application tierce n'est pas autorisée à lancer un autre exécutable.
Il est évidemment toujours possible de faire tourner un daemon pour protéger l'exécution d'une tâche en mémoire même lorsque l'application qui y accède se ferme, mais il n'est pas encore expliqué dans les documentations mises à disposition si cela est possible.
Les développeurs vont donc devoir se creuser un peu pour chercher des parades et astuces permettant de protéger l'exécution de leurs programmes.
0 commentaires