| french | english |
 |
|
| Créer un compte | |
| 31-10-08 / 23:59 : Boycot de l'ITMS ? (cjed) |
| Le site jaimelesartistes.fr, édité par le Ministère de la Culture et de la Communication, et devant servir à promouvoir la nouvelle loi de riposte graduée, propose une liste de solutions de téléchargement légales. On y trouve en premier les offres des fournisseurs d'accès, puis celles des vendeurs (Fnac, Virgin), puis celles des majors, et enfin une longue liste d'autres solutions, avec en tout dernier l'ITMS d'Apple (noyé en fin de page parmi des solutions anecdotiques, alors qu'il détient 3/4 du marché en ligne aux US, et sans doute entre 30 et 50% en France). Pour rappel ce sont les majors qui avaient imposé à Apple l'ajout de DRMs, et Steve Jobs avait récemment (dans une lettre ouverte) expliqué très clairement pourquoi il est nécessaire de les supprimer (ce qui a été accepté par EMI mais pas encore par le autres majors, alors qu'on semble vouloir désigner les vendeurs en ligne comme responsables). Enfin, comme montré récemment, le filtrage des connexions est impossible techniquement, ce qui rend la nouvelle loi innaplicable (impossible de prouver la nature des échanges), sauf laisser les majors dénoncer sans preuve, ce qui provoquerait on l'espère un scandale. On pourrait alors saisir à nouveau la commission européenne, sachant que la position de la France est isolée et contraire à la réglementation communautaire. Et lorsque le gouvernement évoque Deezer comme solution d'écoute simple financée par la publicité, on se dit que les artistes méritent mieux que ces systèmes de licence globale (ou publicité) extrêmes. On ne peut pas à la fois poursuivre les gens qui téléchargent via les réseaux d'échange, et d'un autre côté proposer gratuitement les mêmes musiques, via des sites sortis de nulle part et possédant soudain le crédit des majors et du gouvernement. Apple avait trouvé depuis plus de 6 ans avec l'ITMS une solution modérée, élégante et pratique, et qui rémunère honnêtement les artistes (lorsqu'ils vendent directement par Apple - sans passer par les majors -), le fameux modèle 70/30 qui fait le succès de l'AppStore (offre des gains intéressants aux créateurs, permettant des prix bas et ainsi l'accès aisé aux consommateurs). Reactions sur Clubics |
| 2 commentaire |
| 29-10-08 / 23:32 : Cappuccino : tutorial Scrapbook Part II (cjed) |
| La seconde partie de tutorial sur Cappuccino, Scrapbook Part II Implementing Drag and Drop, est disponible depuis une semaine. Elle aborde la gestion du glisser-déposer (correspond justement au chapitre que je lis actuellement dans Cocoa Programming... page 760 : protocols informels drag source et drag destination, etc.), les vues collection et scrollables, et l'archivage. |
| Commenter |
| 28-10-08 / 23:29 : Windows 7 copie encore plus OSX (cjed) |
| Microsoft a fourni des précisions sur Windows 7, attendu pour 2010. On est encore une fois surpris des concepts repris de MacOSX (anciens concepts de versions précédentes et concepts de Snow Leopard) : une barre des tâches qui rappelle de plus en plus le Dock, une navigation centralisée via metadata nommée Library qui correspond aux dossiers intelligents de MacOSX, une accélération du système via le GPU (comme avec OpenCL et Grand Central de Snow Leopard mais en moins ambitieux), un nouveau framework pour les animations (inspiré de CoreAnimation ?), la gestion du multi-touch (déjà le cas dans Leopard), etc. Windows 7 devrait fonctionner bien mieux sur des machines peu puissantes (1Ghz, mais c'est déjà le cas pour OSX pour des fréquences encore moindres). |
| Commenter |
| 27-10-08 / 22:23 : Google Earth pour iPhone (cjed) |
| Google Earth est à présent disponible pour iPhone (gratuitement via l'AppStore). Il offre les mêmes fonctions que la version desktop. |
| Commenter |
| 24-10-08 / 00:00 : Livre : The iPhone Developer's Cookbook (cjed) |
 Un livre sur la programmation iPhone (en plus de la documentation d'Apple) sera disponible le 25 octobre : The iPhone Developer's Cookbook: Building Applications with the iPhone SDK. Il est déjà en ligne pour les abonnés Safari Books Online et sera également disponible sur Amazon.fr, au prix de 30 euros. Il contient 384 pages (voir la liste des chapitres et quelques extraits via le lien Safari Books Online. |
| Commenter |
| 23-10-08 / 00:24 : Android Market : déjà un échec ? (cjed) |
| Google aurait supprimé (à posteriori) la plupart des 50 (seulement) applications de son Android market Store. Il n'en resterait plus que 13. En plus de son interface en retard de plusieurs années sur l'AppStore, ce store propose donc un contenu insignifiant. |
| Commenter |
| 18-10-08 / 15:05 : Special Event 14/10 : vidéo dispo (cjed) |
| La keynote du Special Event du 14 octobre est en ligne sur le site Apple (également en HD). |
| Commenter |
| 17-10-08 / 23:38 : Comparatif MacPro / PC sous Windows (cjed) |
| PCMag propose un comparatif du nouveau Mac Pro 2,53 Ghz (sous Windows, via BootCamp) avec 3 autres PC portables (de marque : Dell, HP, Lenovo). Malgré sa fréquence de processeur plus faible le MacPro distance très largement les PC dans les jeux (4 fois le framerate du Lenovo pourtant à 2,8Ghz, et plus de deux fois celui du HP 2,8Ghz pourtant équippé du même chipset vidéo). Dans les tests applicatifs (conversion, rendu) le MacBook Pro affiche des scores très honnêtes pour sa fréquence moindre. |
| Commenter |
| 17-10-08 / 23:25 : Snow Leopard beta2 / Finder en Cocoa (cjed) |
| AppleInsider confirme qu'une seconde beta de Snow Leopard a été envoyée à certains développeurs. Le travail de réécriture des applications système en Cocoa serait bien avancé, et le Finder en ferait également partie ! Enfin une nouvelle option permettrait de démarrer sur des images disque système (sans avoir à les monter ni les restaurer), afin de disposer de différentes configurations (ou systèmes de test, pratique pour les beta). |
| Commenter |
| 14-10-08 / 22:08 : Nouveaux MacBook/MacBook Pro (cjed) |
 Apple a présenté les nouveaux MacBook et MacBook Pro, dont la coque est construite avec un nouveau procédé. Le MacBook embarque un chipset graphique NVIdia GeForce 9400M (256Mo de DDR3 empruntée sur la RAM principale de 2Go) dont les performances sont 6,2 fois meilleures en 3D sous Call Of Duty 4 (comparé au chipset Intel GMA3100 des précédents MacBook) ! Le MacBook Pro utilise le chipset GeForce 9400M en usage courant, et embarque un second processeur graphique, le 9600M GT (1,5 fois plus rapide que le 9400M), avec 256Mo de GDDR3 sur le modèle à 2,4Ghz et 512 Mo de GDDR sur celui à 2,53 Ghz (apporte en plus 4 Go de ram au lieu de 2, le double de mémoire cache, et un disque dur plus grand). Une option processeur à 2,8 Ghz est disponible.Les nouveaux MacBook et MacBook Pro intègrent un trackpad multitouch en verre, de taille plus grande et gérant jusqu'à 4 points de contact simultanés, et l'écran du MacBook est à présent à rétro-éclairage LED. Le MacBook Pro propose un rendu sonore amélioré via une multitude de micro-ouvertures sur les côtés du clavier. Il intègre également un mini-Display port. Le MacBook est à présent dépourvu de port Firewire, limite importante pour une application audio. Le prix débute à 1200 euros pour les MacBook et 1800 euros pour les MacBook Pro. Apple a également annoncé un nouvel écran Cinema Display 24' LED (849 euros), qui permet de recharger un portable et sert de hub USB (contient également des haut-parleurs et une caméra iSight).s |
| 2 commentaire |
| 13-10-08 / 22:05 : MacPro Nehalem /BluRay dans un mois ? (cjed) |
| La sortie des processeurs Intel Nehalem serait prévue le 17 novembre, quelques mois plus tôt que supposé. On devrait donc voir les nouveaux Mac Pro vers la fin de l'année : en plus de connecteurs DHCP et du Blu-Ray, il est probable qu'ils utilisent un nouveau boîtier. Ce devrait donc être la machine idéale, si Apple revoit son prix à la baisse pour le repositionner face aux iMacs et aux portables (les nouveaux MacBook sont attendus à partir de 800$). Le Nehalem propose des accès mémoire doublés (bus dédié pour chaque core, comme sur les G5) et permet ainsi des gains d'un facteur 4 sur des calculs complexes avec un processeur 4 cores. |
| Commenter |
| 09-10-08 / 23:13 : JSCocoa : appel d'Objective-C depuis javascript (cjed) |
 Après Cappuccino, un nouveau projet open-source (développé par un français) promouvant Cocoa vient d'être lancé, JSCocoa. Cette biblitothèque javascript utilise le moteur JavascriptCore (moteur javascript du framework WebKit d'Apple) afin d'appeler du code C et Objective-C d'après du javascript.Contrairement à Cappuccino (qui est une réécriture complète de classes Objective-C en javascript et utilise un compilateur dynamique du code client Objective-J vers du javascript standard), JSCocoa propose une syntaxe purement javascript (donc moins transparente que l'Objective-J - ie moins proche de l'équivalent Objective-C). Cependant JSCocoa reprend certaines notations de Rubby et jQuery pour simplifier la syntaxe. Au final c'est bien de l'Objective-C qui est appelé (contrairement à la solution Cappuccino), via le runtime ObjCRuntime, BridgeSupport et libffi. La solution ne fonctionne donc que sur MacOSX (10.5.5, PPC et Intel), ce qui limite son intérêt comparé à Cappuccino. A moins qu'Apple ne livre un ObjCRuntime pour Windows, mais les classes Cocoa devraient alors être portées (la fameuse YellowBox...), ce qui rendrait le bridge javascript moins utile, comme c'est le cas d'ailleurs déjà pour JSCocoa sur OSX (permet en fait de simplifier le déploiement, via un simple navigateur, et permet l'accessibilité aux fonctions du système, sujet sur lequel Cappuccino pourrait utiliser ce type de bridge). Puisqu'il ne s'agit que d'un bridge, l'installation ne pèse que 1,3Mo (contient un exemple, JSCoreAnimation). JSCocoa permet de charger des NIBs depuis le code javascript, mais les IBOutlet et IBAction doivent y être déclarés manuellement. Finalement JSCocoa n'est qu'une simplification de la procédure présentée il y a quelques mois, à savoir l'appel d'Objective-C depuis une WebView (View de Webkit), au travers d'un WebScriptObject. C'est aussi la troisième solution popularisant Cocoa en quelques mois, sans compter l'UIKit de l'iPhone. |
| Commenter |
| 09-10-08 / 22:39 : Apple : special event le 14 (cjed) |
| Apple a confirmé le special event du 14 octobre, où elle devrait présenter de nouveaux MacBook et MacBook Pro (message The spotlight turns to notebooks), utilisant un nouveau procédé de fabrication et d'assemblage de la coque. |
| Commenter |
| 06-10-08 / 23:23 : iPhone dev ToolChain sur PC / Eclipse CDT (cjed) |
| En mars dernier, on apprenait comment installer le SDK iPhone (APIs cachées à l'époque) et le faire fonctionner sur Windows ou Linux (GCC, etc.), et début septembre on reparlait de l'installation de cet iPhone dev ToolChain. IBM fournit à présent un tutorial pour développer pour iPhone à partir de Eclipse CDT (C Development Tooling), qui passe également par l'utilisation de GCC. |
| Commenter |
| 06-10-08 / 23:12 : iPhone 0S 2.2 Google Street View / résultats (cjed) |
| Selon AppleInsider, la prochaine version 2.2 de l'iPhone OS apporterait entre autres le support de Google Street View. Macnn rapporte qu'Apple aurait vendu plus de 7 millions d'iPhone pour le dernier trimestre (Q4, résultats attendus autour de la dernière semaine d'octobre), l'iPhone aurait pris 17% de parts de marché des smartphones. |
| Commenter |
| 03-10-08 / 00:18 : Une beta de Snow Leopard bientôt ? (cjed) |
| Selon AppleInsider, Apple préparerait une première beta de Snow Leopard, mais pour une diffusion très limitée (pas à l'ensemble des membres ADC). En plus des optimisations drastiques, de Grand Central, OpenCL, de ZFS, de la réduction de la taille utilisée par le sysème (lire cet article) et de QuickTime X, cette version apporterait un nouveau framework multitouch. |
| Commenter |
| 02-10-08 / 23:07 : Cappuccino : TableView / datasource / pagination (cjed) |
| Parmi les sous-classes de CPView actuellement disponibles dans Cappuccino on trouve : CPClipView, CPCollectionView, CPControl, CPFlashView (!), CPProgressIndicator, CPScrollView, CPShadowView, CPTabView, NSCustomView, NSView, _CPWindowView.
Il n'y a pas encore l'équivalent de NSTableView, NSOutlineView ou NSBrowser, mais l'équipe en charge de Cappuccino travaille à l'implémentation d'une CPTableView : "The CPTableView is still under development, it's already in the repository if you want to have a look. After this is finished i think the cappuccino team or someone else will pickup the work on CPBrowser." Il semblerait que la tache ne soit pas aisée du fait de la complexité de ces composants : "CPTableView : needs all of NSTableView and supporting classes. We’re not going to be using NSCell’s though, so we’ll also need to make some decisions on exactly what to do here, at least when straight up NSView replacement isn’t enough." On peut cependant se montrer confiants puisque l'équipe a déjà réussi à produire près de 20 000 lignes de code (AppKit et FoundationKit de Cappuccino). En attendant il est conseillé d'utiliser une CPCollectionView (et CPCollectionViewItem), mais on ne dispose alors pas de header pour les colonnes et il n'est pas possible de les réarranger (déplacer et redimensionner). Une fois ces composants d'affichage hiérarchique disponibles, leur prise en compte pourra être ajoutée dans Nib2Nic, avec la différence qu'ils n'utiliseront apparemment pas de classe pour les cellules (Cell). Pour les applications d'entreprise on utilise habituellement un composant de type table paginée, afin de limiter la taille des données lues (à la manière d'un curseur). En Cocoa les TableView sont inclues dans une ScrollView, et seules les lignes visibles pour une position donnée dans la table (position de l'ascenseur vertical) sont chargées (demandées à l'objet delegate de type datasource). Ainsi lorsqu'on scrolle, la datasource se voit demander les éléments additionnels, mais l'ensemble de la table n'est jamais chargé d'un seul coup (sauf si le nombre de lignes total est inférieur ou égal à la hauteur de la zone visible). Cocoa gère en fait la répartition sur plusieurs pages au moment de l'impression. Lorsque l'implémentation CPTableView sera disponible dans Cappuccino, il suffira dans la méhode - (id)tableView:(CPTableView *)aTableView objectValueForTableColumn:(CPTableColumn *)aTableColumn row:(int)rowIndex de l'objet datasource d'effectuer une requête JSONP vers le serveur, afin de récupérer les données de la ligne demandée (accès en mode curseur). On pourra vouloir implémenter un système de cache pour ne pas avoir à effectuer une requête par ligne à afficher, mais dans ce cas le modèle TableView avec vue scrollable ne conviendra plus, il faudra implémenter une vue paginable (appelera une méthode de type tableView: objectsArrayForTableColumn: page: sur la datasource). Si on veut gérer le tri des colonnes (pris en compte dans Cocoa) on ne pourra plus considérer séparément les colonnes, et la méthode delegate devra donc renvoyer une matrice de valeurs pour la page courante (sera de type tableView: objectsMatrix: forPage: sortingColumn: ascendingOrder:). |
| Commenter |
| 01-10-08 / 23:26 : Apple suspend le NDA autour du dev iPhone (cjed) |
| Apple a annoncé (plus tôt qu'on l'attendait) la suspension du NDA autour du développement iPhone. Les échanges, forums de support et exemples de code devraient donc émerger très vite. La technique d'Apple depuis le début est de libérer par étapes le potentiel de l'iPhone (d'abord développement exclusivement en HTML et javascript, puis Cocoa mais avec NDA, etc.) La prochaine étape devrait être la suppression du verrouillage à l'AppStore (on ne peut toujours pas accéder au contenu de l'appareil). Ainsi Apple suscite l'attente et parvient à générer un sursaut d'intérêt à chaque nouveau débridage. En effet les concurrents n'ont que faire du NDA, puisqu'ils possèdent déjà un compte ADC et assistent aux WWDC ! Le contexte économique (baisse de 20$ de l'action ces derniers-jours, et petite remontée de 8$ ensuite) a peut être incité la firme à jouer cette carte à ce moment, et par là même Apple détourne un peu l'attention des développeurs d'Android. |
| Commenter |
| 01-10-08 / 01:06 : Cappuccino : JSON, JSONP et CPJSONPConnection (cjed) |
| Les applications clientes Cappuccino communiquent avec les serveurs via des requêtes HTTP avec un format d'échange qui est soit du XML (format/schéma propre à définir, on parle de XML-RPC), soit le format standardisé et simple JSON (n'est pas du XML). Le plus souvent les requêtes HTTP sont effectuées depuis du code javascript (AJAX, utilise la classe javascript XMLHttpRequest), afin de ne pas avoir à rafraîchir l'ensemble de la page. Cependant, pour des raisons de sécurité, Ajax (classe XMLHttpRequest) ne permet pas de faire des appels cross-domain, le domaine de l'url appelée via Ajax doit correspondre au même domaine que l'url de la page actuelle (par exemple sur ce site le déroulement des news utilise un appel Ajax vers un fichier php - renvoie le contenu d'une news, qui est ensuite ajouté dynamiquement à une div précédemment cachée -, et ce fichier se trouve sur le même domaine). Pour contourner cette limitation une astuce a été utilisée, référencée JSONP (JSON with padding). Il s'agit d'ajouter dynamiquement dans la page (via DOM) une balise script de type javascript, dont le source pointe vers l'url de traitement située sur l'autre domaine. Dans ce cas précis l'appel cross-domain est permis. Puisqu'on est dans le cadre d'un appel AJAX il faut que la fin du traitement côté serveur (récupération du contenu d'une news, recherche, etc.) déclenche un callback côté client pour que le rafraîchissement puisse avoir lieu (que le client puisse exploiter le résultat de l'appel). La seconde astuce consiste à renvoyer, au lieu du contenu au format JSON (ne produirait aucun résultat car appelé dans le contexte d'une balise script), une instruction javascript d'appel de méthode javascript (le fameux callback), avec en paramètre de cette méthode le résultat calculé côté serveur (au format JSON). Ce sera par exemple myCallBackFunction( { "x": 10, "y": 15} ) si le traitement renvoie un couple de valeurs. Ainsi le résultat de l'appel déclenchera côté client la métode callback javascript (appel possible depuis la balise script), avec le paramètre retour. Afin que le serveur sache qu'elle nom de méthode callback renvoyer dans sa chaîne retour (portion myCallBackFunction), on doit préciser un paramètre additionnel dans l'url d'appel, dont la valeur est le nom de la méthode callback. Exemples : http://search.yahooapis.com/ImageSearchService/V1/imageSearch?appid=YahooDemo &output=json&callback=callBackResult&query=nomRecherché http://www.flickr.com/services/rest/?method=flickr.photos.search&tags=tagRecherché&media=photos&machine_tag_mode=any &format=json&api_key=ca4dd89d3dfaeaf075144c3fdec76756 &jsoncallback=CPJSONPConnectionCallbacks.callbackXX. Le nom du paramètre stockant le nom de la méthode callback varie suivant le service JSONP appelé (ici Yahoo et Flickr), de même que le paramètre précisant le format (json). On simule en fait le fonctionnement de l'API XMLHttpRequest, inutilisable ici pour les raisons de sécurité mentionnées (il faudrait se demander s'il n'est pas risqué de contourner cette limitation au final...) Via le code source de l'application de démo Flickr Photo Demo de Cappuccino, on découvre la classe CPJSONPConnection. On l'instancie (dans la classe AppController dans l'exemple) via les instructions Objective-J (javascript) suivantes : var request = [CPURLRequest requestWithURL:"url du service JSONP"]; (l'url contient notamment le paramère précisant le format json) var connection = [CPJSONPConnection sendRequest: request callback: "jsoncallback" delegate: self]; (pour ce service, Flickr JSONP, le paramètre stockant le nom de la méthode callback est jsoncallback) Dans le code source de CPJSONPConnection on s'aperçoit que la valeur CPJSONPConnectionCallbacks.callbackXX passée comme nom de callback (plus précisement comme valeur du paramètre jsoncallback - ce nom de paramètre est variabilisé dans la classe CPJSONPConnection) dans l'url d'appel de ce service Flickr est mappée sur une fonction javascript (en fait un élément d'un tableau de méthodes callback) définie comme suit (appelle du code Objective-J - javascript) : [_delegate connection:self didReceiveData:data]; [self removeScriptTag]; La méthode connection: didReceiveData est donc appelée (interprétation de la chaîne javascript retournée) au final côté client, sur la classe javascript AppController (car défini comme delegate lors de l'appel de CPJSONPConnection sendRequest: callback: delegate: - on avait passé self). Cette méthode delegate, de signature - (void)connection:(CPJSONPConnection)aConnection didReceiveData:(CPString)data, peut ensuite extraire les informations de la chaîne data (String au format JSON, qui correspond au résultat). Dans le cas d'un appel d'une url sur le même serveur il n'est pas nécessaire de passer par le procédé JSONP, et on peut utiliser la classe XMLHttpRequest, wrappée (masquée) en fait via la classe CPURLConnection (l'appel est bien de type Ajax). On précise l'objet delegate à la création de la CPURLConnection (méthode de classe suivante) : connectionWithRequest:(CPURLRequest)aRequest delegate:(id)aDelegate (L'url passée est construite comme précédemment via un objet CPURLRequest) Ici cependant, puisque l'appel sera réalisé au final par la classe XMLHttpRequest (précisera une méthode callback particulière - mais toujours la même) il n'est pas nécessaire de passer au service métier le nom de la méthode callback en paramètre de l'url (cette information est passée lors de l'utilisation de la classe XMLHttpRequest), et ce dernier renverra dans la chaîne résultat simplement le message JSON (pas besoin d'y préfixer le nom de la méthode callback javascript, on sera dans un cas Ajax classique). Dans l'objet delegate (typiquement l'AppController) il suffit alors d'implémenter la méthode suivante (nom de méthode callback précisée sur l'XMLHttpRequest lorsque l'instance CPURLConnection envoie la requête - méthode start) : -(void)connection:(CPURLConnection)aConnection didReceiveData:(CPString)data Si le retour (String data) est au format JSON (qu'on soit dans un appel JSONP via une CPJSONPConnection, ou bien un appel Ajax standard via CPURLConnection) il est possible de désérialiser simplement cette chaîne en un objet javascript structuré, via la méthode CPJSObjectCreateWithJSON : Exemple : -(void)connection:(CPURLConnection)aConnection didReceiveData:(CPString)data { var myJSObject = CPJSObjectCreateWithJSON(data); ... } Pour une application cliente riche les services métier appelés seront très probablement déployés sur un autre serveur (et autre domaine) que celui servant la page d'interface cliente, et le mécanisme d'appel devra donc être de type JSONP. Si le service côté serveur est implémenté en php, son retour JSON sera de la forme : <?=$_GET['jsoncallback']?>( { "greeting":"Hello from request."} ) Thread sur Cappuccino.com Thread dans un forum Google groups MAJ : see also the CP2JavaWS Cappuccino client to Java remote services bridge, that allows easy call of remote business services, using provided proxy (client-side) and JSON servlet (server-side). It completely hides the CPJSONPConnection and CPURLConnection classes use, manages encoding/decoding and namespace of services methods’s parameters and return, call of a delegate handlers for success response and fail, in the same way (use syntax) as GWT does. |
| Commenter |