Discussion :

[MohamedChaawa]

Adobe a décidé de ne plus proposer Flash Player sur le Google Play Store et du même coup ne réalisera plus de mise à jour.

Plus la peine de chercher Flash Player sur le Google Play Store, il n'existe plus. Il renonce au développement de son lecteur multimédia sur les smartphones sous Android. D'ailleurs, l'éditeur n'avait pas prévu de versions certifiées pour Android 4.1 Jelly Bean. Il ne l'avait même pas testé sur cette mouture.

"Flash Player ne sera plus mis à jour pour les nouvelles configurations. Flash Player ne sera plus pris en charge sur les versions d'Android supérieures à 4.0.x", indique l'éditeur sur son blog officiel. Adobe précise toutefois qu'il maintiendra les correctifs concernant les failles de sécurité pour les appareils disposant toujours de Flash Player.

Il reste donc accessible sur Google Play pour les utilisateurs qui l'ont déjà installé. Aussi, les adeptes de ce plug-in peuvent toujours se le procurer, via un navigateur Internet.

L'avenir est dans le HTML5

La fin de Flash sur Android marque un tournant dans le monde des OS pour mobile. Ce lecteur multimédia a longtemps été un argument de vente pour le système d'exploitation de Google par rapport à iOS. En 2010, le fondateur d'Apple, Steve Jobs avait en effet publié une lettre ouverte, dans laquelle il exprimait ses réticences envers Flash. "Nous ne passons pas de temps sur une technologie dépassée", avait-il lancé, en comparant Flash aux disquettes.

Il accusait notamment le plug-in d'être trop gourmand en mémoire, de provoquer des failles de sécurité et de faire planter les Macs. Le défunt patron de la marque à la pomme avait alors opté pour la solution HTML5. Mais aujourd'hui même Adobe considère que c'est une meilleure technologie pour son avenir : "[HTML5] est la meilleure solution pour créer et déployer du contenu dans le navigateur à travers des plateformes mobiles".

Ce qui ne signifie pas pour autant la mort de Flash Player. L'éditeur souhaite effectivement poursuivre le développement de Flash sur les ordinateurs. Il se concentrera notamment sur les jeux vidéo sur navigateur et la distribution de contenus multimédias à la demande, comme les VOD par exemple.

[Paul TOTH]

tout le monde disait que la concurrence aller tuer Flash...mais en fait Adobe le fait tout seul.

cet abandon concerne-t-il aussi Air ?

[sybil]

cet abandon concerne-t-il aussi Air ?

c'est de l'air.

[psychadelic]

HTML5 / Canvas / Javascript monte en puissance, il y a même un jeu de Mario qui commence à y pointer le bout du nez.

Pour moi les jours de la galaxie Flash commencent à être comptés, ou alors expliquez moi quel peut être l’intérêt de tout développer en double ses applis sachant que HTML5 suffit aux « deux » mondes, et qu’elle n’a ni besoin de plugg_in pour fonctionner, et que cela « retire » un chainon pour les failles de sécurité qui seront, de toutes façons, gérés par les browsers ( et beaucoup mieux que ne l’a fait Adobe).

[Paul TOTH]

HTML5 / Canvas / Javascript monte en puissance, il y a même un jeu de Mario qui commence à y pointer le bout du nez.

même Mario ? alors là je n'ai plus rien à dire

Pour moi les jours de la galaxie Flash commencent à être comptés, ou alors expliquez moi quel peut être l’intérêt de tout développer en double ses applis sachant que HTML5 suffit aux « deux » mondes, et qu’elle n’a ni besoin de plugg_in pour fonctionner, et que cela « retire » un chainon pour les failles de sécurité qui seront, de toutes façons, gérés par les browsers ( et beaucoup mieux que ne l’a fait Adobe).

c'est amusant je trouve que Flash répond mieux à ces objections

la même implémentation du lecteur sur toutes les plateformes, et donc un seul développement au lieu d'une version IE, une version Chrome, une version FF, une version Opera...

une seule source de faille avec une seule mise à jour (sauf Chrome qui contient son propre player) au lieu de multiples navigateurs et multiples mise à jours.

Maintenant Flash n'est pas une finalité, et ActionScript n'est pas la panacée...pas plus que JavaScript et HTML5, je pense qu'il y a de la place pour un nouveau mode de fonctionnement (Native Client ?), mais il faut qu'il parvienne à se répandre aussi bien que l'a fait Flash. C'est à mon avis là la grande réussite de Flash, son taux de pénétration, loin devant Silverlight, et sans doute de HTML5 et Java aujourd'hui.

[pmithrandir]

Ce que l'on gagne en sécurité, je pense qu'on le perd aussi.
Par exemple, flash avait accés aux fichiers locaux sur le PC.

Sauf que si on ne voulait pas que ca arrive, il suffisait de ne pas installer flash, sur des PC d'entreprise par exemple, et le problème était simplment régler.

Maintenant, avec les nouveaux navigateurs, on a cette porte qui est ouverte, en esperant que les sandbox soient efficaces.

Je pense que certains administrateurs auraient préféré la solution du flash...

[psychadelic]

Oui, même Mario http://www.jeux-en-html5.fr/jeu/infinite-mario

Sinon l'un des gros problèmes du Flash, c'est pour le référencement...

[MiaowZedong]

Ce que l'on gagne en sécurité, je pense qu'on le perd aussi.
Par exemple, flash avait accés aux fichiers locaux sur le PC.

Sauf que si on ne voulait pas que ca arrive, il suffisait de ne pas installer flash, sur des PC d'entreprise par exemple, et le problème était simplment régler.

Maintenant, avec les nouveaux navigateurs, on a cette porte qui est ouverte, en esperant que les sandbox soient efficaces.

Je pense que certains administrateurs auraient préféré la solution du flash...

Il faut installer des plugins pour désactiver le JavaScript, ce qui en plus est gênant vis-à-vis des usages légitimes de celui-ci. La tendance à remplacer l'OS par le navigateur me semble mauvaise à de multiples niveaux (ajout d'une couche d'abstraction supplémentaire qui nuit aux performances, gestion beaucoup moins sophistisquée de la sécurité, etc).

[Loceka]

Autant je déteste flash dans les sites HTML (ou pire, un site complètement en flash), autant je trouve qu'il s'était développé toute une communauté autour des jeux en flash qui était vraiment bien, et je doute qu'on puisse arriver aux mêmes résultats en HTML5 (jeux en 3D, etc.).

C'est le seul usage de flash que j'apprécie, mais sa disparition va laisser un manque...

[pmithrandir]

Il faut installer des plugins pour désactiver le JavaScript, ce qui en plus est gênant vis-à-vis des usages légitimes de celui-ci. La tendance à remplacer l'OS par le navigateur me semble mauvaise à de multiples niveaux (ajout d'une couche d'abstraction supplémentaire qui nuit aux performances, gestion beaucoup moins sophistisquée de la sécurité, etc).

Sur firefox, dans les option il y a une checkbox pour le desactiver. Dasn about:config on peut presque tout configurer.
Dans une politique générale d'entreprise, on peut largement sécuriser les configs navigateur.

[Paul TOTH]

Sur firefox, dans les option il y a une checkbox pour le desactiver. Dasn about:config on peut presque tout configurer.
Dans une politique générale d'entreprise, on peut largement sécuriser les configs navigateur.

à condition de replacer le navigateur dans sa fonction première, la consultation d'Hyper Texte.

car un site sans JS aujourd'hui c'est assez rare.

[Médinoc]

Peut-on faire des animations de ce type, ou du genre des Happy Tree Friends, en HTML5?
Ou est-ce un truc pour lequel Flash n'a pas encore de remplaçant?

[unknow0]

Peut-on faire des animations de ce type, ou du genre des Happy Tree Friends, en HTML5?
Ou est-ce un truc pour lequel Flash n'a pas encore de remplaçant?

pour la premiere animation je pence que oui mais sa risque d'etre lourd (comme l'anim flash quoi xd).
Pour les htf oui c'est plus que faisable, j'avais vu une animation du meme genre en html5 mais pas moyen de remetre la main dessus ><

[Médinoc]

...Ce qui est adapté aux applications, mais pas à Internet.

[Paul TOTH]

...Ce qui est adapté aux applications, mais pas à Internet.

encore faudrait-il définir ce que tu appelles "Internet"

de plus en plus de sites web s'orientent vers des lecteurs sur mobile, c'est sans doute du HTML et du HTTP mais ça ne tourne plus dans un navigateur. Tu gardes donc un afficheur HTML et tout le code Javascript est remplacé par du natif qui est libre de gérer des sessions, des données privées sans stocker ça sur le serveur ou dans un cookie (ou dans une base local HTML5), tu peux en profiter pour demander accès au carnet d'adresse, tu peux remonter des infos d'usage, de pratique, mieux que n'importe quel webservice.

[_skip]

Je me demande si ça ne posera aucun problème le fait que l'utilisateur puisse changer ce qu'il veut avec un éditeur de texte dans le code JS. Genre rajouter un x50 dans la fonction qui affiche le score de son jeu favori.

[Paul TOTH]

Je me demande si ça ne posera aucun problème le fait que l'utilisateur puisse changer ce qu'il veut avec un éditeur de texte dans le code JS. Genre rajouter un x50 dans la fonction qui affiche le score de son jeu favori.

ça restera côté client.

par contre je ne sais pas s'il est prévu quelque chose en matière de protection du code dans HTML5 ?

[MiaowZedong]

ça restera côté client.

Et s'il le fait avant la fonction AJAX qui envoie les résultats au serveur, qu'il execute la page avec ses modifs et refait une partie avec score x50?

[Paul TOTH]

Et s'il le fait avant la fonction AJAX qui envoie les résultats au serveur, qu'il execute la page avec ses modifs et refait une partie avec score x50?

c'est que c'est mal codé un serveur web ne peut pas faire confiance au client d'ailleurs on est amené à coder un contrôle de saisie Javascript pour avoir un client fluide qui ne passe pas son temps à solliciter le serveur, puis un contrôle côté serveur pour valider réellement les données.

c'est ce que je disais plus haut, l'application native peut exploiter HTTP pour transporter des infos vers un WebService tout en gérant le code client de façon plus sécurisée.

Dans le cas d'un jeu AJAX, le client doit solliciter le serveur pour chaque opération susceptible d'être falsifiée, comme un jet de dé par exemple.

[MiaowZedong]

c'est que c'est mal codé un serveur web ne peut pas faire confiance au client d'ailleurs on est amené à coder un contrôle de saisie Javascript pour avoir un client fluide qui ne passe pas son temps à solliciter le serveur, puis un contrôle côté serveur pour valider réellement les données.

c'est ce que je disais plus haut, l'application native peut exploiter HTTP pour transporter des infos vers un WebService tout en gérant le code client de façon plus sécurisée.

Dans le cas d'un jeu AJAX, le client doit solliciter le serveur pour chaque opération susceptible d'être falsifiée, comme un jet de dé par exemple.

Oui, mais il faut aussi que le serveur valide quel nombre de dés lancer, quel bonus leur appliquer....pour un jeu très simple ça peut aller, pour un jeu un peu complexe tu auras un nombre immense de requêtes AJAX pour au final faire très, très peu de choses côté client.

D'où l'intérêt de pouvoir envoyer au client un executable binaire, beaucoup plus dur d'accès