Les 25 et 26 janvier 2013, se sont tenus les FirefoxOS App Days, un hackathon pas comme les autres.
Sommaire
- FirefoxOS, problématiques et enjeux
- Déroulement du hackathon
- FirefoxOS, les smartphones
- FirefoxOS, l'OS
- FirefoxOS, l'internet des applications
Ce Vendredi 25 janvier 2013 et Samedi 26 janvier, le FirefoxOS App Days a été hébergé à l'ÉPITA du Kremlin-Bicêtre, ainsi que dans 23 autres villes du monde.
FirefoxOS, problématiques et enjeux
À première vue, on ne peut pas dire que FirefoxOS arrive dans un contexte facile. Les concurrents sont là depuis longtemps, bien installés, leur applications sont matures et leur réputation forte. Le marché est segmenté efficacement et possède ses grande marques repères : IPhone, Samsung, HTC. Comment réellement vouloir s'aventurer dans un marché aussi verrouillé ? Pire ! Le système se dit orienté web et interopérabilité.
Ce système n'apporte donc pour seule nouveauté de proposer ce qui sera accessible ailleurs de toute façon ?
Et puis, de toute façon, la situation actuelle de Mozilla ne semble pas reluisante : Firefox est en déclin apparent, bien qu'ayant la force technique, il lui manque la force commerciale.
Et que dire de la dépendance à Google et Microsoft ? En effet, les ressources de Mozilla dépendent principalement des partenariats autour du moteur de recherche par défaut sur le navigateur (catégorie Royalties du rapport financier, page 3 en haut).
À tout cela, Tristan Nitot nous a répondu : Learn, Hack, Celebrate (diaporama de l'ouverture du Hackathon).
L'objectif de la Mozilla Fondation n'est pas d'écraser ses concurrents, mais d'ouvrir de nouveaux marchés. Les smartphones iPhone et Android sont aujourd'hui tellement lourds et fermés que le seul moyen de se distinguer est de sortir des monstres mobiles de plus en plus puissants et hors de prix !
Ce n'est pas ce que nous voulons pour demain.
Demain, développer une application mobile sera aussi simple qu'un index.html et son manifeste JSON. Demain, personnaliser son téléphone du début à la fin sera aussi simple que du CSS. Enfin, demain et grâce au Web ouvert, faire une application mobile cross-plateforme ne sera plus un problème coûteux.
Tels sont les enjeux et les défis que FirefoxOS résout.
Déroulement du hackathon
Vendredi 25 janvier, l’amphithéâtre est rempli. Ce sont donc 300 personnes qui se sont déplacées pour l'évènement.
Développeurs jeunes, d'autres moins jeunes, la moyenne d'âge tournait aux alentours de 30 ans.
Chacun d'entre eux s'est vu offrir une clef USB contenant quelques ressources pour commencer, des autocollants, un sac Mozilla et des tickets repas en abondance.
Puis s'enchaînent les conférences. Vivantes, techniques, claires, les développeurs se voient donner un aperçu des possibilités de FirefoxOS. C'est intéressant, les ressources sont nombreuses, ça n'a pas l'air trop dur, enthousiasme général.
Enfin, coding-time pour tous. Parmi l'équipe FirefoxOS, 8 sont parisiens, et 5 sont présents aujourd'hui. Les discussions sont animées et souvent techniques, mais pas toujours. Chacun partage ses connaissances et Kazé rappelle l'existence des TupperVim pour les Vim users parisiens.
À la fin de la journée, ce ne sont pas moins de 37 démonstrations qui ont été effectuées ! Todo-List, notes rapides, listes de courses, jeux, guide TV, gestionnaire comptes en lignes et bien d'autres. Un florilège d'application qui fait monter Paris comme Hackathon le plus réussi parmi les 23 autres villes participantes, une réussite éclatante.
Bravo au staff, c'est grâce à cet encadrement hors-pair que tout ceci était possible. La logistique comme les avis techniques étaient au top, quoi de mieux pour rendre un dev heureux et efficace ?
FirefoxOS, les smartphones
FirefoxOS, comme tous les autres OS embarqués, a des contraintes matérielles et des smartphones de référence. Et là aussi il trouve le moyen de se démarquer.
En effet, les smartphones prévus pour FirefoxOS sont extraordinairement économiques ! D'une developper preview commandée en petit volume aux alentours de 160€, pour un lancement sur le marché aux environs de 100$. On parlait même en off d'un objectif à terme aux environs de 20$ au Brésil. Inimaginable !
Aussi invraisemblable que cela puisse paraître, le smartphone FirefoxOS est exceptionnellement fluide. L'auteur en a eu plusieurs entre les mains, a joué et développé avec et peut vous assurer que c'en est bluffant.
Les activités sur lesquelles le téléphone grincera les dents seront, sans surprise, toutes celles touchant au rendu 3D. Aucun reproche à faire à ce smartphone, donc. Les smartphones que nous avons manipulés n'étaient pas des Peak (Spécifications du Peak).
La clef de voûte de ces performances est l'intégration de Gecko en tant que moteur de rendu associé aux moteurs JavaScript haute performance de Firefox (les tests montrent que IonMonkey, le dernier compilateur JIT de Firefox apporte une grande amélioration des performances).
L'expérience a montré que ces technologies sont capables de faire des rendus beaux, fluides, sans gros hacks (même s' il y a toujours un hack pour faire mieux—JulienW), tout ça se nourrissant des langages simples et accessibles que sont HTML, CSS et JS.
FirefoxOS, l'OS
Les application fournies par Mozilla sont au nombre de 19. Elles s'articulent autour de Gaia, l'UI de Mozilla qui fournit thèmes, icones, et bibliothèques d'applications essentielles au système.
Le dossier apps/ contient sans surprise les applications et le dossier shared/ les ressources statiques system-wide (styles CSS, JavaScript commun, et traductions d'idiomes généraux comme les dates).
Une application est représentée par son manifeste, un fichier JSON détaillant noms, icônes, sites et mail de support et son fichier index.html, racine de l'application.
L'arborescence de l'application est laissée libre, mais les bonnes pratiques étant les mêmes que pour un site, les dossiers styles/ et js/ sont généralement présents.
À partir de là, tout se comporte comme une page visitée par un navigateur (ce qui est en fait le cas), et tout est dramatiquement simple. C'est sûrement là l'une des clefs du succès du hackathon : la simplicité d'accès de la plateforme.
Un simulateur de FirefoxOS a été développé pour l'occasion. Bien que jeune, il se révèle très pratique pour ceux qui ne possèdent pas de téléphone flashé.
On notera cependant que l'équipe nous a conseillé de tester sous Firefox nightly (qui s'est révélé à la fois rapide et stable) et de redimensionner la taille de la page avec la Vue Adaptative. Le simulateur étant assez instable, il servait plutôt à l'installation.
Pour en savoir plus, je vous conseille la lecture du wiki du hackathon.
FirefoxOS, l'internet des applications
Les technologies mises en place par l'équipe de Mozilla permettent de faire votre propre marché d'applications en 3 lignes de JavaScript. Chaque application étant basiquement un fichier JSON et un zip groupant les différents fichiers nécessaires.
C'est un retour à la simplicité qui se met en branle. En fournissant des WebAPI à la pelle sur des langages simples et accessibles, Mozilla enclenche sans aucun doute la prochaine phase du développement logiciel. Celui qui par nature ne permet pas de licence coûteuse, mais autorise la review. Le développement qui ne nécessite pas de SDK pour démarrer, ni de plateforme de développement spécifique et se base sur des technologies standardisées sans brevets.
Enfin, Mozilla donne aussi l'accès à un marché énorme pour les développeurs. Rendez vous compte : tous les Firefox, tous les smartphones à bas coût (FirefoxOS et Tizen, on parlait d'un marché de 10 millions d'utilisateurs à moyen terme) et enfin tous les Firefox pour Android.
C'est un tour de force, à tout point de vue. Car on peut imaginer que FirefoxOS permettra de diversifier les sources de revenu de la Mozilla Foundation via son expertise et de nouveaux partenariats. On notera aussi que FirefoxOS ne se place pas sur le même segment de marché que l'UbuntuPhone (qui vise des smartphones quad-cores) et évite ainsi l’écueil d'une concurrence entre organisations libres. Assurément, ces téléphones ont de l'avenir !
Sur ce, l'auteur s'en va demander à postuler chez Mozilla Paris…
Aller plus loin
- Page officielle de FirefoxOS (529 clics)
- MarketPlace officiel de Mozilla (172 clics)
# Erreur sur le modèle du téléphone
Posté par padenot . Évalué à 10.
Non, les téléphones que vous avez eu entre les mains n'étaient pas des Peak. En comparaison, les Peaks auront un CPU double coeur dont la fréquence sera 1.5 fois plus élevée (800MHz et un seul coeur pour le modèle de ce weekend). Le Peak disposera de 512Mo de RAM (contre 256 pour le téléphone de ce weekend), et d'un GPU vraisemblablement bien plus véloce (nécessaire puisque l'écran sera beaucoup plus grand et la résolution bien plus élevée).
Je pense qu'on peut comparer les téléphones de ce weekend (un ZTE Kis) à un téléphone Android d'il y a deux ou trois ans, en terme de matériel. La réactivité vient pour une grande partie du fait que l'équipe en charge du rendu graphique ("gfx") a su tirer parti du GPU du téléphone. Il est relativement peu puissant, mais fait toute la différence.
Les appareils Geeksphone ne seront disponibles qu'en février, et nous même les développeurs Mozilla n'y avons pas accès pour le moment.
[^] # Re: Erreur sur le modèle du téléphone
Posté par rootix . Évalué à 1.
J'ai corrigé l'article et mis un lien vers ton commentaire.
[^] # Re: Erreur sur le modèle du téléphone
Posté par mackwic . Évalué à 2.
Arf, la couleur m'aura trompé. Et puis il aurait été logique que pour la démo, vous preniez les machines les plus puissantes à portée de main.
Chapeau les artistes !
[^] # Re: Erreur sur le modèle du téléphone
Posté par moimael . Évalué à 1. Dernière modification le 30 janvier 2013 à 23:23.
Pour avoir eu la chance d'un avoir un offert par Mozilla, je peut confirmer que c'est bien un Turkcell MaxiPlus 5 (nom de code unagi). Les mises à jours de FirefoxOS sur le téléphone sont très régulières (environ une tous les deux jours) et les progrès fait sur les performances et la correction de bugs à chaque version sont bluffants !
Par contre il semblerait qu'il possède 512 de ram et pas 256 comme je lis sur certains commentaires.
[^] # Re: Erreur sur le modèle du téléphone
Posté par padenot . Évalué à 1.
Sur mon Unagi:
Le téléphone à bien 512Mo de RAM, mais le kernel est trafiqué pour n'en utiliser 190Mo environ, afin de pouvoir être certain de pouvoir faire tourner la chose sur des configuration modestes (et donc peu onéreuses).
# Le téléphone était...
Posté par Julien Wajsberg . Évalué à 5.
Non pas un Geeksphone Peak mais un ZTE : http://www.nfcworld.com/nfc-devices/zte-turkcell-maxiplus5/
C'est, je pense, le smartphone le plus lent que je n'ai jamais eu entre les mains. Ce qui laisse augurer du meilleur lorsque Firefox OS tournera sur des smartphones un peu moins entrée de gamme :-)
[^] # Re: Le téléphone était...
Posté par Maclag . Évalué à 5.
Pas de boussole sur le Peak?
Raaah! Pourtant c'est vraiment pas le composant le plus cher à sourcer!
On généralise même les combos G-cell+boussole!
[^] # Re: Le téléphone était...
Posté par NanoTech . Évalué à 1.
C'est un MSM7225A basé sur un Cortex-A5 à 800 Mhz.
Même si en 2013 c'est l'entrée de gamme, c'est quand même un appareil sur lequel Android tourne sans ralentissement.
Donc, c'est un peu exagéré de parler de "monstre" pour Android.
Tous les téléphones sont surpuissant de nos jours. Il ne faut pas croire que l'on a besoin d'un Quadri-coeur Cortex-A9 pour faire tourner Android!
[^] # Re: Le téléphone était...
Posté par padenot . Évalué à 1.
C'est faux de dire qu'Android tourne sans ralentissement dessus. Une phrase du type "Android 2.3 tourne de manière utilisable dessus" serait déjà plus correcte. Les nombreux tests/revues que tu peux trouver sur internet sont formels, c'est pas cher, ça fait le job, mais ça tourne pas du tout sans ralentissement (OOM killer à foison, saisie de texte non fluide, pas à 60fps tout le temps, etc.).
Firefox OS non plus ne tourne pas sans ralentissement sur cet appareil, d'ailleurs.
# Firefao, l'enfer du jeu
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Les applications les plus populaires les plus rentables sur mobile sont les jeux, si le rendu 3D n'est pas performant, ça va être un handicap majeur.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Firefao, l'enfer du jeu
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 0.
Les problèmes de rendu 3D, ce n'est pas la faute à Firefox OS, mais au téléphone. Gecko reposant sur WebGL (donc openGL) pour tout ce qui est 3D.
Et puis tous les jeux ne sont pas en 3D…
[^] # Re: Firefao, l'enfer du jeu
Posté par devnewton 🍺 (site web personnel) . Évalué à 7.
Malheureusement aujourd'hui beaucoup de jeux 2D utilisent OpenGL, faute de mieux.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Firefao, l'enfer du jeu
Posté par Yoric . Évalué à 1.
Canvas marche très bien sur FirefoxOS :)
[^] # Re: Firefao, l'enfer du jeu
Posté par Wawet76 . Évalué à 1.
J'ai un téléphone qui fait partie des best-sellers, le haut de gamme d'il y a 18 mois : un Galaxy S2.
Bah les jeux en 3D, je les évites comme la peste. Le téléphone chauffe à mort et en 2h la batterie est à plat.
En ce qui me concerne, je préférais que mon téléphone ne supporte explicitement pas la 3D et qu'il ai une meilleure autonomie.
[^] # Re: Firefao, l'enfer du jeu
Posté par padenot . Évalué à 4.
Tu peux desactiver WebGL dans Gecko (via une pref). Je recommande chaudement de ne pas le faire, WebGL peut avoir bon nombre de cas d'utilisation dans des applications qui n'utilisent pas la 3d, pour accelérer le dessin. Oui, je suis d'accord, Gecko devrait le faire tout seul et c'est un hack (qu'on évite d'utiliser dans Gaia), mais en attendant qu'on optimise notre pipeline pour tous les cas d'utilisation possible et inimaginable de html css et js (autant dire que ça fait pas mal), c'est une optimisation possible.
# Aussi simple que du CSS
Posté par Antoine . Évalué à 8.
Demain, personnaliser son téléphone du début à la fin sera aussi simple que du CSS
tout ça se nourrissant des langages simples et accessibles que sont HTML, CSS et JS
C'est beau comme la Pravda. CSS, c'est le langage si simple et accessible qu'aujourd'hui tout le monde préfère utiliser des surcouches (bootstrap, etc.).
Enfin bref, je salue l'écriture de cette dépêche agréablement dénuée de toute distance critique.
[^] # Re: Aussi simple que du CSS
Posté par Guillaume Denry (site web personnel) . Évalué à 8.
Accessible, CSS l'est assurément, et documenté.
"Simple", ok, ça peut devenir compliqué mais d'une part, non, tout le monde n'utilise pas des surcouches à CSS, d'autres part, ces surcouches pondent du CSS/HTML en sortie donc y'a pas vraiment de contradictions ; on garde un format universel, qu'on peut concevoir de façon "haut niveau" avec des toolkits.
[^] # Re: Aussi simple que du CSS
Posté par flagos . Évalué à 9. Dernière modification le 28 janvier 2013 à 10:11.
Tant mieux, ces mêmes personnes (qui ne sont pas tout le monde) pourront utiliser ces mêmes surcouches. C'est bien mieux que tout réinventer dans son coin.
[^] # Re: Aussi simple que du CSS
Posté par mackwic . Évalué à 4.
CSS est simple. Trop simple, puisqu'il lui manque variables, arithmétique, et autres fonctions, mais c'est un autre souci.
Ce qui est complexe, c'est le design, et c'est pour ça que les devs se tournent vers des designs pré-engineerés comme bootstrap.
# Accès sockets
Posté par Larry Cow . Évalué à 3.
Tiens, 'tite question vu que j'ai pas pu aller au Hackaton, et que vous avez l'air au courant par ici : c'est possible pour une appli FFOS de se connecter à autre chose que du HTTP ou du WebSocket?
Typiquement, un client mail - j'ai vu qu'il y en avait eu sur le simulateur, mais pas possible de le connecter à mon IMAP - pourra-t-il se connecter à un IMAP lambda, ou bien lui faudra-t-il systématiquement du code côté serveur pour faire la liaison entre le monde web et le "vrai" monde?
[^] # Re: Accès sockets
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 3.
Oui c'est possible : https://bugzilla.mozilla.org/show_bug.cgi?id=733573
mais d'après https://wiki.mozilla.org/WebAPI/ cela n'est réservé qu'aux applis "certifiées" (donc celles fournies avec le téléphone). Possible que ce soit étendue aux applis privilégiées (vérifiées par les gens du marketplace).
D'une manière générale, voir cette page pour connaitre toutes les nouvelles API
[^] # Re: Accès sockets
Posté par Larry Cow . Évalué à 2.
Merci. Et grmbl.
[^] # Re: Accès sockets
Posté par nerbrume . Évalué à 5.
Vraiment ?
Si j'ai bien compris, si je veux faire une appli "native", ou aller jouer avec le FS, ou le /dev, je ne pourrais pas, sauf si une API spécifique existe ? Ca me semble sacrement emmerdant, et pour le coup, ca ressemble à de l'enfermement.
Ou alors j'ai mal compris.
[^] # Re: Accès sockets
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
Pour le dev, peut être, pour l'utilisateur, certainement pas. Tu voudrais donc que n'importe quelle appli web puisse accéder à ton FS, /dev et cie ?
brrr…
non, à de la sécurité.
Question de point de vue je présume…
[^] # Re: Accès sockets
Posté par NanoTech . Évalué à 6.
C'est le même argument avancé par Microsoft quand il veut interdire l'accès à la l'API Win32 de Windows 8 sur ARM.
Au final sur téléphone, toutes les plateforme (Windows/Android/iOS/Bada/BlackBerry) sont fermées.
importe quelle appli web puisse accéder à ton FS, /dev et cie ?
[^] # Re: Accès sockets
Posté par padenot . Évalué à 3.
Un des buts du projet est de montrer que la plateform Web est tout à fait capable de rivaliser avec les applications natives pour la plupart des applications (bien évidemment pas toutes, on manque de temps et il faut faire des choix si on veut sortir un truc un jour).
Si tu veux écrire une application mais que tu ne peux pas, de mon point de vue, c'est qu'il faudrait qu'on expose une API pour te laisser écrire ton programme.
Sur les autres OS mobiles, de la même manière, tu n'es pas root (bien que dans certains cas, tu puisses le devenir, les utilisateurs de ton application ne le seront pas par défaut), des fois tu n'as pas accès au FS, et tu es fortement encouragé à passer par leurs API. Mais avec le temps, toutes les API nécessaires sont disponibles.
Tu peux tout à fait, par contre, tester ce que tu veux: il est relativement aisé d'écrire une API dans Gecko, flasher ton propre build, pour peu que tu te renseignes un peu avant et que tu aimes bien parler sur IRC (peu de gens refuseront de t'aider, et encore, ça serait probablement par manque de temps). Tu auras alors du levier pour convaincre les personnes d'investir leur temps dans ton API (pour faire des revues de code, nécessaire pour faire rentrer un patch, ou des revues de sécurité, etc.).
Un OS correct ne se fait pas en un jour, et c'est tout à fait avec des cas d'utilisations qu'on avait pas prévu qu'on fera quelque chose de qualité.
[^] # Re: Accès sockets
Posté par Spack . Évalué à 5.
[TROLL]
Et pourquoi pas écrire de vrais applications qui ont déjà toutes les APIs qu'il faut plutôt que de faire du Web un nouveau système d'exploitation ?
[/TROLL]
[^] # Re: Accès sockets
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Et puis quoi encore? Une vraie distribution avec des applis natives? Quelle idée!
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Accès sockets
Posté par padenot . Évalué à -1. Dernière modification le 28 janvier 2013 à 16:16.
Parce qu'il y a beaucoup de gens (je parle des nombreux développeurs qui font du web) qui sont très heureux de pas avoir à apprendre un nouveau langage, des framework, des IDE et plein d'autres choses pour faire des applications. Aussi, tu deviens cross-platform/device facilement, tu as pas mal de sécu qui est géré pour toi. Les gens qui n'aiment pas ça pourront aller voir d'autre plateformes qui leur plairont plus, je suppose.
Perso, j'aime beaucoup le C, et j'ai aucun souci pour faire plein de trucs avec, mais la plupart des gens n'ont pas envie de se frapper des segfaults ou de la manipulation de mémoire manuelle pour faire leurs applications mobiles.
Et aussi, on est Mozilla, et on aime bien le web et on pense sincèrement que c'est une technologie viable pour les mobiles, qui nous sortirait des environnements non-compatibles de la concurrence.
[^] # Re: Accès sockets
Posté par maboiteaspam . Évalué à 1.
Je ne vois pas cela comme de l'enfermement, mais de la consolidation.
A un moment, tel service expose telles fonctionnalités.
Cela permet de rendre l'ui universelle à tout support qui implémente le service.
L’intérêt est que chaque plateforme peut implémenter différemment le service, mode caméléon, en offrant la même signature.
Si je prends l'exemple d'un système de fichier, l'utilisateur n'en à que faire de savoir que c'est le system active directory qui l'empêche d'écrire ici, ou tel droit unix.
Il ne peut pas écrire, point à la ligne, il n'en demande pas plus.
Le reste d'espace d'affichage disponible devrait être réservé à proposer un outils de rapport de bogues simplifié mais précis pour facilites le support auprès des équipes techniques plutôt qu'à afficher les détails de ces querelles de techniciens.
[^] # Re: Accès sockets
Posté par Xavier Combelle (site web personnel) . Évalué à 2.
d'après https://wiki.mozilla.org/WebAPI/Security/TCPSocket ce sera possible pour les applis privilégié d'être client sur tous les ports et serveur sur les port >= 1024 pour les applications classiques le problème c'est:
*Inherent threats: Malicious apps attacking internal systems (firewall bypass), local device access
*Threat severity: High
# Doublon, pardon
Posté par Wawet76 . Évalué à 0. Dernière modification le 28 janvier 2013 à 10:49.
Commentaire supprimé
# Une autre imprécision
Posté par padenot . Évalué à 7.
Je pense qu'un lecteur pourrait croire qu'IonMonkey est utilisé dans Firefox OS. Il n'en est rien. En effet, IonMonkey dépend d'une autre fonctionnalité des moteurs javascript présent dans Firefox, appelée Type Inference (TI, pour inférence de types). TI est monolithique, cela voulant dire qu'on ne peut l'activer que pour une programme, pas pour, disons, une fonction d'un programme Javascript. L'empreinte mémoire est alors vraiment importante, et la mémoire disponible sur les téléphones visées (qui ont 256Mo de ram, un peu plus d'une centaine disponible pour les programmes utilisateurs) est trop faible.
L'équipe Javascript travaille aussi à augmenter les performances, avec un autre projet qui fonctionnera à priori sur Firefox OS (mais qui améliorera aussi les performances sur desktop et android), en écrivant un baseline compiler. Comme toujours, on peut suivre l'avancement de ce projet sur le bug 805241 1.
# géniale.
Posté par maboiteaspam . Évalué à 2.
Dans cette phrase on parle d'applications, via un store, est ce que dans un des cartons de ces merveilles il y aurait la même idée de packaging, mais pour un site web au sens plus classique du terme.
C'est sensiblement la même chose en terme technique, mais pour l'utilisateur et l'annonceur c'est différent.
Dans un cas l'utilisateur sait ce qu'il cherche, et utilise le store pour le concrétiser.
Dans l'autre cas, l'utilisateur ne sait pas, demande à son moteur de recherche et clique sur un lien de résultat.
C'est dans ce second cas que ma question se pose.
Les raisons ? Améliorer l'expérience utilisateur en évitant autant que possible les rounds trips liés aux assets au prix d'un temps de chargement initial plus élevé afin de ne préserver les rounds trips futurs qu'aux seuls données dynamiques et non pas au chargement des composants d'affichages (images, js, css ect).
Par la suite pourrait on imaginer fournir un gzip pré-compilé et soulager le cpu ? C'est peut être déjà le cas pour les applications du store.
Pour l'annonceur, comme je le disais, c'est différent, mais il trouvera toujours un moyen de promouvoir son produit. Donc, je ne m'en fais pas trop.
[^] # Re: géniale.
Posté par padenot . Évalué à 3.
Oui, c'est la beauté des OpenWebApp. Tu peux simplement avoir un site web, qui dispose d'un fichier "manifest.webapp", et hop, ça te fait une application. Tu peux aussi proposer un zip, ou envoyer ton app sur le store. Tu peux aussi créer ton propre store.
L'avantage d'aller sur le store Mozilla, pour l'instant, c'est que c'est le seul qui peut faire des revues de code, et donc accorder des permissions avancées aux applications.
Je pense que tu serais interessé par les slides de julienw 1, qui expliquent comment appcache fonctionne, appcache étant la technologie qui gère la persistence des assets dans les navigateurs, et qui est très utilisé dans Firefox OS.
[^] # Re: géniale.
Posté par Larry Cow . Évalué à 3.
Moui. C'est un peu contraire aux objectifs affichés, ça, non? Ne serait-il pas mieux de permettre un "mode développeur" (un peu ce que propose Android avec les applications hors-Store) qui permette d'autoriser manuellement les choses à une application?
[^] # Re: géniale.
Posté par padenot . Évalué à 1.
Laisse nous une petite minute :-).
Une sorte de "mode développeur" est une chose vraiment importante à avoir, et on s'en est rendu compte lors de ces App Days (pas qu'on ne le savait pas, mais on pensait pas que c'était autant handicapant). On a proposé des hacks aux gens pour qu'ils puissent bosser, mais il me semble qu'une personne a quelque chose de plus générique, ça devrait arriver bientôt.
[^] # Re: géniale.
Posté par Larry Cow . Évalué à 2.
Oh, mais je vous laisse toutes les minutes que vous voulez. C'est juste que je suis les futurs Geeksphones de près, et que je suis assez curieux de savoir ce qu'on pourra (ou pas) faire dessus.
[^] # Re: géniale.
Posté par maboiteaspam . Évalué à 1.
Ou alors faudrait prendre le meilleur des deux.
Ne pas popufiés l'application d'alertes, mais rendre ces droits configurables par l'utilisateur.
Les éléments de l'application requérant ces droits aurait pour comportement de se désactiver lorsque le droit n'est pas obtenu, vice-et-versa.
Comme cela on s'évite les popups et on continue de proposer un éventail de service àlacarte.
Enfin, je me dis aussi que ce trucs des popups pour obtenir des droits à beaucoup de sens quand tu développes des applications qui ne proposent que des exploitations de ces droits.
Pour un site marchand qui veut proposer ces produits, la géolocalisation tu ne la demande que lorsque l'utilisateur souhaite trouver le magasin le plus proche, où le point de réception du colis. Enfin bref un truc que tu peux toujours remplacer par un bon vieux formulaire.
Pour l'aspect sécurité…. A qui je fais confiance, à qui je ne fais pas confiance.
Cela passera probablement par un tiers de confiance, type modèle ssl.
[^] # Re: géniale.
Posté par padenot . Évalué à 2.
À un moment on faisait comme ça, mais plus maintenant, je sais plus pourquoi. Enfin, pour être précis, et si tu as regardé les slides, on pouvait configurer ce qu'on appelle les permissions implicites, pour autoriser une appli à faire un truc, dans les settings. Mais plus maintenant, je sais pas pourquoi (on arrive aux limites de ce que je sais sur FirefoxOS, je bosse pas dessus au jour le jour).
[^] # Re: géniale.
Posté par maboiteaspam . Évalué à 1.
Hello,
effectivement, C’était vraiment très intéressant <link>.
Pour ceux qui veulent une introduction rapide il faut
parcourir les slides (dans github ça fonctionne aussi)
parcourir http://www.html5rocks.com/en/tutorials/appcache/beginner/
Lorsqu'il dit en slide6,
Sais tu ce à quoi il fait référence ?
Le système de fallback ou une invalidation du cache de l'app ?
[^] # Re: géniale.
Posté par mackwic . Évalué à 2. Dernière modification le 28 janvier 2013 à 18:36.
Encore autre réponse. AppCache permet de spécifier des ressources à chercher par le réseau, dans ce cas, si la requête HTTP renvoie un 30x (redirection), alors c'est une erreur.
Edit: AppCache était un peu relou à utiliser, on a plutôt joué avec une version asynchrone de LocalStorage, en fait un wrapper au dessus de IndexedDB.
Ca marchait bien.
[^] # Re: géniale.
Posté par maboiteaspam . Évalué à 1. Dernière modification le 28 janvier 2013 à 14:21.
Par ailleurs existe t'il un moyen simple de rester compatible avec des vieux browsers (genre ie8. pour ne pas en citer d'autres…) tout en gardant cette base de développement ?
J'imagines que puisqu'il est peu probable que microsoft implémente cette techno dans ses bijoux de familles, la solution passerait par un serveur capable d’interpréter le manifest afin de faire office de mock up. Cela permettrait de proposer une expérience utilisateur dégradé avec un coût d’entretien nul.
Le rêve.. Resterait plus qu'à gérer manuellement la partie animation afin de garder une expérience agréable pour ces ancêtres.
[^] # Re: géniale.
Posté par Yoric . Évalué à 2.
J'ai une appli FF OS que je suis en train de rendre compatible avec IE8. Donc oui :)
Toutes les techniques habituelles sur le web pour ce genre de choses restent valables avec Firefox OS. Dans le cas de mon application, il y a pas mal de détection de fonctionnalités au début, et de la définition de fonctions de secours, pour remplacer tout ce qui manque sur les vieux navigateurs.
[^] # Re: géniale.
Posté par maboiteaspam . Évalué à 1.
tu en as trop dis ou pas assez ;-°)
Peut on en voir plus ?
[^] # Re: géniale.
Posté par NanoTech . Évalué à 2.
Pour compliquer la compatibilité, l'API de Tizen est différente (mais similaire en fonctions) de celle de Firefox OS.
J'espère qu'ils finiront par converger.
# IndexedDB
Posté par maboiteaspam . Évalué à 1. Dernière modification le 28 janvier 2013 à 16:32.
Au sujet d'indexed DB, je peux voir les exemples sur mozilla
https://developer.mozilla.org/en-US/docs/IndexedDB/Using_IndexedDB
C'est un peu brut. Ça pique un peu les yeux.
Connaissez vous une couche a knockout ou consors pour profiter des joies d'indexeddb à
bas coûtssans efforts ?[^] # Re: IndexedDB
Posté par padenot . Évalué à 1.
https://github.com/mozilla-b2g/gaia/blob/master/shared/js/async_storage.js. Moins flexible, mais plus facile.
# Bétatest
Posté par steph1978 . Évalué à 2.
Je peux l'installer facilement sur mon vieux HTC Desire ?
Il a tout ce qu'il faut il me semble: monocoeur, 256MB de RAM :)
[^] # Re: Bétatest
Posté par padenot . Évalué à 2.
Non. Pas facilement, voir pas du tout tout court.
Il te faudrait:
- Une ROM ICS
- De grosses compétences en C et en programmation noyau pour faire/porter des drivers
- De bonnes grosses compétences en Gecko pour faire des workarounds pour les bugs desdits drivers
- Que le GPU soit assez bien
[^] # Re: Bétatest
Posté par steph1978 . Évalué à 3.
ok, fais comme si j'avais rien dit :)
# FirefoxOS travaille-t'il avec Tizen ?
Posté par kadalka . Évalué à -1. Dernière modification le 29 janvier 2013 à 11:56.
FirefoxOS travaille-t'il avec Tizen ?
[^] # Re: FirefoxOS travaille-t'il avec Tizen ?
Posté par mackwic . Évalué à 2.
Officiellement non, mais j'ai cru comprendre que y'a des contacts.
# Installable sur d'autres smarphones ?
Posté par Veehem . Évalué à 1.
Bonjour quelqu'un pourrait expliquer pourquoi on ne pourrait pas rooter un androidphone et installer FirefoxOS dessus
[^] # Re: Installable sur d'autres smarphones ?
Posté par claudex . Évalué à 3.
Parce qu'il manque pas mal de pilote et qu'il faut peut-être adapter la chaîne de démarrage.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Installable sur d'autres smarphones ?
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
Comme dit la réponse précédente, il faut un noyau linux adapté. Mozilla ne travaille pour le moment que sur un nombre limité de téléphones. Comme tu le vois, flasher un Nexus S ou un Galaxy SII, c'est possible.
Et il y a d'autres hackers qui sont en train de porter Firefox OS sur d'autres téléphones.
Et pour ceux qui sont intéressé pour un portage, voici une petite doc
# réalité augmenté
Posté par galereman . Évalué à 1.
Est-ce que FFOS sera capable de faire tourner correctement des applications de réalité augmentée? Je pense par exemple à un application qui permettrait voir les constellations (c'est à dire ses étoiles, les traits qui les relient et son nom) sur son écran en l'orientant la nuit vers une partie du ciel.
[^] # Re: réalité augmenté
Posté par mackwic . Évalué à 2.
L'API donne accès à la caméra, donc j'ai envie de dire oui.
[^] # Re: réalité augmenté
Posté par galereman . Évalué à 0.
Et en terme de performance ?
[^] # Re: réalité augmenté
Posté par mackwic . Évalué à 2.
C'est un peu tot pour savoir. D'un coté les smartphones prévus sont ridiculement petits, d'un autre FFOS tournait de façon ridiculement fluide.
Et puis de toute façon ca tournera dans Firefox Android, donc sur un Galaxy S42 ça tournera toujours ! ;-)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.