L'iPhone le plus cher du monde..!
120 000 euros, c'est le prix de l'iPhone le plus cher du monde proposé par le designer et bijoutier australien Peter Aloisson.Baptisé iPhone Princess Plus, cet iPhone est composé de 318 diamants, soit un total de 17,75 carats placés sur un contour en or blanc 18k.
Et pendant ce temps là, y'en a qui se plaigne du prix de l'iPhone normal ! ...
iPhone : Firmware 2.0 pour très bientôt ?
Le Firmware 2.0 beta distribué par Apple aux développeurs étant une version limitée, instable, au prix de 99$ qui de plus ne permet pas aux utilisateurs d'exploiter toutes les capacités requises de l'iPhone pour une utilisation quotidienne aurait apparemment été hacké par la Dev Team et serait (selon des sources proches) en préparation pour une distribution très prochainement.
Ce nouveau firmware 2.0 serait une version hackée au nom de Pwned et sera distribué au grand public, apparemment ce week end, par la Dev Team embarquerait donc toutes nouveautés qui ont été présenté lors de la dernière Keynote, et qui plus est, serait une version stable et adapté à un usage normal de l'iPhone.
Selon vous, qu'en sera t-il réellement de ce firmware 2.0 annoncé par le Dev Team ?
Ce nouveau firmware 2.0 serait une version hackée au nom de Pwned et sera distribué au grand public, apparemment ce week end, par la Dev Team embarquerait donc toutes nouveautés qui ont été présenté lors de la dernière Keynote, et qui plus est, serait une version stable et adapté à un usage normal de l'iPhone.
Selon vous, qu'en sera t-il réellement de ce firmware 2.0 annoncé par le Dev Team ?
Source: http://www.journaldumac.com/
Un meilleur clavier pour l'iPhone
Vous avez du mal avec le clavier virtuel de l'iPhone ? Alors voici cette protection d'écran qui devrait pouvoir vous aider à mieux faire la distinction au niveau des touches 
Comptez 7,99$ ICI.
Comptez 7,99$ ICI.
Source: http://www.journaldumac.com/
Les premières révélations du SDK
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.
