TImaniac a écrit 6420 commentaires

utilisez notre techno et nos outils plutôt que ceux des autres Tu peux très bien utiliser d'autres outils, la seule contrainte est qu'ils ciblent non plus la machine "physique" mais la machine virtuelle. Il n'y a donc aucun enfermement particulier de ce côté là, plutôt des contraintes supplémentaires.

pourtant Google propose aussi de faire du natif. Mais comme pour Windows Phone, tu ne peux pas pour autant te passer du SDK ciblant la machine virtuelle. Et Google dit clairement que ce le NDK n'est pas là pour une question d'ouverture/compatibilité mais juste pour des portions de code où les performances sont critiques. Tu n'as d'ailleurs pas accès à toutes les fonctionnalités du SDK standard à travers le NDK. Google prévient clairement que le code compilé contre le NDK ne peut tourner que sur ARM, bref, c'est perdre la portabilité.

Surtout qu'ils filent gratos leurs outils de dev dans le contexte du dev Windows Phone (Visual Studio, Expression Blend). Clairement l'objectif est d'ajouter une couche d'abstraction entre l'application et l'OS/Matériel : portabilité, sécurité, etc.

C'est tout l'interêt d'un SDK multi-plateforme : développer une fois, et le SDK fait l'adaptation.
Le SDK fait l'adaptation technique et tente tant bien que mal de faire l'adaptation graphique (intégration contrôles natifs par exemple). L'adaptation ergonomique est très moyenne, et c'est pas la faute du SDK. Qt comme la plupart des frameworks graphiques ne sont pas d'assez haut niveau pour pouvoir faire abstraction des différences ergonomiques : c'est au développeur de faire les bons choix ou de faire l'adaptation. C'est pas pour rien que chaque plateforme a ses guidelines destinées aux concepteurs d'interface.
Il suffit de lancer Konqueror sous Gnome ou Nautilus sous KDE pour comprendre qu'il y a un problème.
Mais prenons un exemple concrêt, si quelqu'un est motiver pour compiler et lancer un konqueror sur un Android de base (Nexus One, HTC Desire) et de voir le résultat.

Alors voila, reste plus qu'à râler vers les bonnes personnes (ton fournisseur du téléphone) pour qu'elle n'ait pas une API à lui uniquement et qui coûte cher pour les développeurs.
Ah parcque pour toi il faudrait que tous les environnements soient identiques techniquement pour simplifier ta vie de développeur ?
Je suis moi même développeur, mais désolé, j'essai de penser avant tout aux utilisateurs, et il est important qu'ils aient le choix, si possible entre des choses radicalement différentes tant qu'à faire. Et c'est au développeur de s'adapter pour lui proposer des applications qui s'intègre correctement.
Mais notes que le développeur il fait ce qu'il veut hin, il peut pondre des applis moches et pas intégrées sur l'Android market, Google s'en tape royale. Mais qu'il vienne pas s'étonner que son appli reçoit des critiques négatives.

Désolé, autant pour moi. Personne ne se plaint. Je suis donc pleinement satisfait de devoir changer mes habitudes. Pourquoi je donne mon avis tient d'ailleur ? Visiblement c'est plus pertinent de dire des contre-vérités que d'essayer de soulever des questions.

Et voilà encore un exemple typique de problème ergonomique pour l'utilisateur : avant d'ajouter une nouvelle syntaxe wiki, c'était pas plus urgent d'essayer d'être compatible avec la syntaxe existante ?

<i>Pas la peine d'en rajouter sur la fragmentation d'Android. C'est aussi ce qui fait sa richesse. (et la fragmentation matérielle</i> Qui te parle de fragmentation matérielle ? On parle ici de soft. Je parle d'IHM, d'ergo : forcé de constater que beaucoup trop d'applis Android sont des repompes de leur équivalent iPhone. D'autres applis sont de simples conteneurs "web", l'interface derrière étant du HTML classique. Ce n'est évidemment pas le cas de toutes les applis, mais globalement on tombe sur tout et n'importe quoi, et au final les 3/4 des applis ont une ergonomie à chier.

<i>Franchement, quoi faire d'autre qu'applaudir des deux mains ?</i> Par utilisateurs, tu penses Sony, HTC. Moi par utilisateurs, je penses monsieur tout le monde. Forcé de constater que ce n'est absolument pas les mêmes objectifs pour chacun, donc non, on peut faire autre chose qu'applaudir des 2 mains. HTC Sense est l'exemple typique : un truc "sexy" pensé pour s'afficher sur des affiches géantes dans le métro. Pour l'utilisateur : des applis redondantes, avec une interface et un comportement différent, des mises à jour d'OS qui se font attendre. Quelle valeur ajoutée pour le consommateur ?

C'est effectivement sympa pour les développeurs... Maintenant est-ce vraiment sympa pour les utilisateurs ? Rien de plus ennuyeux pour les utilisateurs que de se retrouver avec des applications qui ne respectent pas les guidelines graphiques et ergonomiques de la plateforme qu'ils utilisent. Au mieux une skin va donner l'apparence visuel d'une appli Android mais nous auront toujours le droit à des différentes ergonomiques qui vont en rebuter plus d'un. C'est d'autant plus vrai dans le monde mobile : un utilisateur choisi un téléphone notamment en fonction du look&feel. Les interfaces Android sont déjà suffisament fragmentées, pas la peine d'en rajouter !

. Mais sous WP7 et IOS on a pas le droit d'installer des logiciels GPL
Si si, tu as non seulement le droit, mais en plus tu peux.
Tu vas là : http://create.msdn.com/en-US/
Tu t'inscrits, tu t'acquittes des 99€, tu enregistres ton téléphone, et hop tu peux déployer toutes les applications que tu veux dessus sans passer par le store et ses conditions draconiennes.

Et tu fais quoi maintenant ?

Quand on a un conducteur incapable de conduire proprement, on ne remplace pas la voiture, on forme le conducteur (ou on le change). Ce ne semble pas être l'avis de Nokia.
Je veux bien croire que les comparaisons sont pas définition foireuses, mais alors cell- là l'est particulièrement :
1. Ils ont remplacé l'ancien chauffeur.
2. Ils ne remplacent pas du tout la voiture : le chauffeur va sur le siège passager et invite un ami pour conduire à sa place. Un ami qui a eu les mêmes problèmes, au même moment, mais qui lui, vient d'avoir son permis. Toujours probatoire on est d'accord.

Moi j'ai une critique : une appli WP7 ne peut pas jouer avec les sockets :-(

je sens que je vais retourner porter SimCity sur TI92, tiens.
Trop tard je l'ai déjà fait :)

Windows Phone 7 n'a pas été "jailbreaké" au sens iPhone (patch de l'OS pour y faire tout et n'importe quoi) : un programme permet juste de débloquer le téléphone pour y installer des applis customs, déblocage technique strictement identique à ce que propose officiellement Microsoft en payant 79€ (compte développeur).
Microsoft semble ouvert à ce mode de déploiement "privé" puisqu'il n'impact à priori pas la plateforme.
Ca reste cependant à confirmer puisque c'est la porte ouverte à un concurrent du marketplace.

j’émet l’hypothèse que HTML5 va de toute façon supplanter Flash
Pour moi ce n'est aussi qu'une hypothèse. En tout cas un objectif.
Je pensais que Mozilla avait le même, et forcé de constaté que bien qu'annoncant fierement préférer un HTML5 + webM ou HTML5 + Theora, ce qu'ils poussent concrêtement, c'est un HTML5 + flash à la place d'un HTML5 + H264.
En gros à vouloir mieux, ils poussent le moins bien, ce qui me pousse à croire qu'il n'y a derrière tout celà aucune volontée d'aider à l'interopérabilité pour les utilisateurs mais juste un positionnement politique.
On retrouve le même raisonnement politique côté Google, mais eux c'est en phase avec leurs objectifs, qui sont avant tout commerciaux (contrer Apple/Microsoft et mettre la pression sur le MPEG-LA).

A l'heure actuelle, ce n'est tout simplement pas possible : la plateforme de dev proposée par Windows Phone n'autorise pas le développement en code natif, out Qt donc.
Il reste évidemment la possibilité que Microsoft ouvre une porte privée pour Nokia : c'envisageable techniquement, mais c'est à mon avis pas le souhait de Microsoft, qui a basé sa plateforme sur la cohérence visuel, une process de validation basé sur un environnement technique précis et une volontée affichée de faire abstraction de la plateforme matérielle.
Bref, c'est effectivement difficile de l'affirmer, m'enfin on peut parier à 10 contre 1 que Qt ne sera pas porté :)

On s'inquiète pour le future des vidéos. En bloquant h264, on pense aider les futurs développeurs web.
Si pour vous aider les développeurs c'est les inciter à continuer d'utiliser Flash... non parcque faut pas rêver, c'est pas webM qui va s'imposer auprès d'un un Apple ou un Microsoft.
Si vous pensiez vraiment aux développeurs, vous seriez pragmatique : il faut mieux un standard, même patent-inside que pas de standard du tout, ce qui pousse à utiliser les solutions à base de plugin actuel (Flash).

Je me réponds à moi même : Google ne joue-t-il tout simplement pas là une simple partie de bluff ? Son objectif ne serait-il tout simplement pas que MPEG-LA ouvre encore un peu plus H264 suite à cette annonce ? MPEG-LA a déjà lâché du leste récemment... c'est une façon de faire encore un peu plus pression dessus...
Et si ça arrive, Google restera là encore une fois pragmatique et changera une nouvelle fois son fusil d'épaule.

Euh... Elles font exactement la même chose (codec video).
Oui mais non :)
H264 n'est qu'un codec video, supporté par Flash d'ailleur.
Non la concurrence c'est plutôt Flash vs HTML5 (avec notamment la balise video).

Le scénario 1/ les présentations vidéo n'est toujours pas élimité pour moi : la balise video HTML5 est beaucoup trop limité par rapport à Flash : faire du streaming video "grand public", c'est faire du streaming adaptatif avec des serveurs géographiquement localisés (akamaï & co). Côté HTML5 c'est pas encore ça, que ce soit au niveau des possibilité du langage lui-même que des outils.

Faire du streaming video "grand public", çcoûte cher, il faut rentabiliser, et même Google ne peut pas se permettre de le faire "gratuit" : c'est pas pour rien qu'ils ont introduit la publicité en surimpression dans les pubs. Techniquement il est possible de le faire en HTML5, mais il est aussi techniquement possible de faire très simplement un script qui désactive la pub (un futur plugin populaire en perspective) : que va choisir Google ? Virer Flash et prendre le risque d'avoir moins de pub visualisées ?

Mon avis est que Google est pragmatique : leur objectif n'est pas de tuer Flash : il est intégré par défaut, que ce soit sur Chrome, Android ou ChromeOS. Leur objectif est de ne pas dépendre de H264 pour des raisons probablement politique/marketing et techniques.
Mon petit doigt me dit qu'ils vont surtout pousser le support WebM dans Flash.

Bref, t'aura un codec libre et toujours du Flash :(

Comme quoi ils sont bien complémentaires et pas directement opposés.

En même temps, quand ça concorde avec la promotion de formats libres, ça serait dommage de bouder son plaisir.
Attention, sa "liberté" est toute relative : clairement WebM empiète sur le marché du consortium MPEG-LA. Comment va réagir ce dernier avec son porte-feuille de brevets qui est ouvertement commercialisé ? Google l'a-t-il épluché en entier afin de prendre toutes les précautions nécessaire avec WebM ?

Non parcque si on se retrouve avec le même problème, WebM sera aussi "libre" que x264 par exemple, bref ca fera juste une alternative, ce qui est toujours bien on est d'accord.

De plus, comment vont réagir les constructeurs qui fournissent des implémentations "hard" de codecs ? Vont-ils obtenir des garanties de la part de Google ? Lui faire confiance aveuglement sans garanties ? Ou au contraire ne pas prendre de risque à court terme ?

Maintenant qu'il n'y a plus de navigateur pour Windows "alternatif" avec H.264
Ca déjà été dit par ici, mais y'a un plugin pour Firefox :
http://port25.technet.com/archive/2010/12/15/html5-video-and(...)
Mais bon c'est pas par défaut, ce qui change tout.
Clairement, Google fait dans le politique sur ce coup là, bien joué. Reste à voir si celà va avoir un effet concrêt sur les formats vidéos adoptés, ou à l'inverse si celà va juste amoindrir encore un peu plus l'intérêt de la balise video au plus grand bonheur d'Adobe.
Wait&See.

Si l'entreprise coule, que sa cote en bourse tombe à 0 et est retirée du marché, si l'actionnaire a tout perdu :)

Ben ca dépend, moi j'ai pas de téléphone portable et entre 10 et 15€ de hors forfait en appelant des portables depuis mon fixe : donc oui, moi je me réjouis :-)

Ca devrait mieux faire passer la pilule de 20%, ça ?
C'est pas 20% pour le même service hein. Si ca t'intéresse pas, va voir ailleurs, rien ne t'en empêche, de quoi tu te plains ?

Oué j'avais pas vu le "non dégroupé".
Effectivement tu passes à 35,98.
Mais bon ça reste le moins cher en non dégroupé.

toujours loin de quelque dizaines, numerama troll encore ?
quelques dizaines... par FAI.
Ce qui est en accord avec une fourchette de 200 à 300 mails par jour.