Bonjour,
Afin de réaliser une application rails disponible hors-ligne et
synchronisable avec le mode en-ligne, j’ai repéré les technologies
suivantes:
Quelqu’un a-t-il déjà expérimenté l’une d’entre elles ou a un quelconque
commentaire à faire dessus?
Merci!
Thomas
C’est un choix tout à fait personnel, mais je me dirigerais vers
Google Gears sans trop d’hésitation.
Le 30 avril 2009 11:49, Thomas [email protected] a écrit :
Afin de réaliser une application rails disponible hors-ligne et
synchronisable avec le mode en-ligne, j’ai repéré les technologies
suivantes:
- Joyent Slingshot (documentation très pauvre, projet laissé à
l’abandon, pas réussi à tester sous windows)- Google Gears
- Adobe Flex/AIR
Désolé je n’ai expérimenté aucune d’entre elles, mais ne peut-on pas
ajouter aussi
?
Ceci dit, ça ne fait qu’ajouter du choix sans te donner les arguments
permettant de le faire (le choix)… Désolé
–
Yannick F.
Secrétaire RubyFrance
http://rubyfrance.org
Yannick F. a écrit :
permettant de le faire (le choix)… Désolé
Oui, ces vrai, j’ai aussi regardé ces technos, mais je ne les aurais pas
indiquées sur ce forum car pour le coup, elles n’ont à ma connaissance
aucun rapport avec Rails. Et puis dans mon cas j’aurais un problème de
compétence à combler en plus.
Le 30 avr. 09 à 11:49, Thomas a écrit :
Il y a aussi la base de donnée HTML 5 :
http://webkit.org/misc/DatabaseExample.html
Par contre je ne crois pas que ça gère la synchronisation.
Arthur Pétry a écrit :
Il y a aussi la base de donnée HTML 5 :
http://webkit.org/misc/DatabaseExample.htmlPar contre je ne crois pas que ça gère la synchronisation.
Sympa, faudra voir ce que donne ce projet dans le futur, mais pour
l’instant
ça ne va pas faire l’affaire pour mon problème.
Merci quand même!
Thomas
Nous avons développé la première version d’une application “offline”
avec Google Gears (et Rails) il y a plus d’un an et nous avons lancé
une “version 2” de cette application web il y a 2 mois.
Mes conclusions : on avait choisi Google Gears parce que c’était bien
dans l’esprit web (qui est un monde “plastique”) et on ne s’est pas
trompé. De plus, en 1 an, la technologie a continué d’évoluer dans le
bon sens.
Par contre, Rails ne fait pas grand chose dans l’histoire, puisque
dèslors que l’application est Offline, c’est du pur HTML/CSS/Javascript.
Dans ce cadre là, ce n’est plus vraiment une appli Rails, mais
plutôtune appli Javascript. Et donc, vaut mieux savoir coder (proprement) en
Javascript avec un framework qui va bien.
++
yk
PS : malheureusement, je n’ai ni screenshot, ni screencast de l’appli,
mais ça devrait venir prochainement…
Le 30 avril 2009 11:49, Thomas [email protected] a écrit :
Google Gears a l’air prometteur mais je ne sais pas s’il est
production-ready:
En fait Joyent Slingshot correspond exactement à mon besoin, mais comme
je disais la documentation est très pauvre, le projet paraît laissé à
l’abandon, et je n’ai pas réussi à le faire marcher sous windows.
Zaphod B. a écrit :
Le 30 avril 2009 14:58, Yann KLIS [email protected] a écrit :
Par contre, Rails ne fait pas grand chose dans l’histoire, puisque dès
lors que l’application est Offline, c’est du pur HTML/CSS/Javascript.
Dans ce cadre là, ce n’est plus vraiment une appli Rails, mais plutôt
une appli Javascript. Et donc, vaut mieux savoir coder (proprement) en
Javascript avec un framework qui va bien.
Et j’ajoute, même si cela va de soit, avec des Test Unitaire (comme
http://www.jsunit.net/ par exemple).
Finalement GoogleGear c’est du Xul non ? Il faudrait que je regarde
tiens…
–
Yannick F.
Secretaire RubyFrance
http://rubyfrance.org
Intéressant.
C’est ce que j’avais cru comprendre en lisant la doc de Google Gears.
Visiblement il garde des les pages de l’appli en cache et on doit coder
les appels à la base de données en javascript avec leur API. Donc ça
reviendrait à coder deux fois l’appli, une fois en Rails pur pour le
mode on-line et une fois en javascript pour le mode off-line. Et l’outil
WorkerPool permet de synchroniser les données en tâche de fond. C’est
bien ça?
Pour le javascript, je me débrouille avec la librairie prototype.
J’espère que ce sera suffisant. Et j’ai ma bible à côté de moi “Bien
développer pour le Web 2.0” de Christophe P…
Ce qui est dommage, est que la solution Joyent Slingshot paraît parfaite
pour ce type de besoin: ça sert à embarquer l’appli Rails dans une appli
Windows ou Mac, en mode offline on bascule en local en sauvant les
données dans sqlite3 et en on-line on part sur le web. Un système de
synchro entre models Rails (basé sur les champs created_at et
updated_at) est embarqué dans l’appli afin de synchroniser les données.
Si quelqu’un a deux minutes et veut bien essayer le tuto de l’appli de
base avec Slingshot sur Windows, ça pourrait être sympa 
. Ca me
permettrait de voir si je ne suis pas un idiot de base qui n’arrive pas
à comprendre une (pseudo) doc…
https://dev.joyent.com/projects/slingshot/wiki/BasicApp
En tous cas merci pour ce retour d’expérience avec Google Gears, je
crois que je vais me plonger un peu plus dedans ces prochains jours.
Thomas
Yann KLIS a écrit :
Ben le truc c’est qu’il faut intégrer un navigateur web dans
l’application bureau. Je pensais même recoder Slingshot en Java pour
faire ça … (je n’ai toujours pas abandonné l’idée en fait)
Avec Shoes il faudrait coder deux fois l’appli, une fois en Shoes (pour
le local), une fois en Rails (pour le web), plus l’algo de
synchronisation.
Avec un système tout simple en Java sur le Desktop, qui contient:
Tony C. a écrit :
2009/4/30 Thomas [email protected]
Ben le truc c’est qu’il faut intégrer un navigateur web dans
l’application bureau. Je pensais même recoder Slingshot en Java pour
faire ça … (je n’ai toujours pas abandonné l’idée en fait)
C’est plutôt facile à faire puisqu’en fait je l’ai déjà fait pour un
client.
J’ai créé une app JRuby+Qt Jambi avec un Webkit. Pour l’app web elle est
sur
un serveur (avec une db mysql) et packagé (avec une db sqlite3) avec
l’app
comme avec slingshot.
C’est multiplateforme et ce n’est qu’une grosse dizaine de ligne (le
code de
l’appli, pas le code pour la sync qui est un plus long). Et c’est aussi
possible de le faire avec SWT (qui a un widget Browser).
Le plus lourd serait de coder l’algorithme de synchronisation.
C’est pas si lourd que ça. Tu fais une API JSON ou XML qui envoie et
reçoit
les données puis en fonction ajoute/modifie/supprime les données. Un peu
comme un diff en fait.
–
Nicolas Mérouze
http://www.yeastymobs.com
Tu peux peut-être regarder de ce côté là :
C’est avec Merb mais ça doit s’adapter à Rails
Le 30 avril 2009 15:13, Yannick F. [email protected] a écrit :
Finalement GoogleGear c’est du Xul non ? Il faudrait que je regarde
tiens…
Si l’on parle bien du XUL de Mozilla, non : XUL est un langage de
description d’interface, c’est un langage de balises, comparable à HTML.
Par
contre si on parle de la plateforme des outils Mozilla globalement,
anciennement XPFE (maintenant ça doit s’appeler “mozilla toolkit” ou un
truc
de ce genre), il y a peut-être dans le tas quelque chose qui s’en
rapproche
(?). Voir ici pour un diagramme daté de courant 2007:
http://people.mozilla.com/~schrep/theMozillaPlatform.png
–
Jean-Baptiste
Nicolas Mérouze a écrit :
C’est plutôt facile à faire puisqu’en fait je l’ai déjà fait pour un
client. J’ai créé une app JRuby+Qt Jambi avec un Webkit. Pour l’app
web elle est sur un serveur (avec une db mysql) et packagé (avec une
db sqlite3) avec l’app comme avec slingshot.C’est multiplateforme et ce n’est qu’une grosse dizaine de ligne (le
code de l’appli, pas le code pour la sync qui est un plus long). Et
c’est aussi possible de le faire avec SWT (qui a un widget Browser).
Oui ben tu vois c’est ce sur quoi je me dirigeais, c’est super d’avoir
un retour d’expérience là-dessus. Finalement Google Gears, bien que
prévu pour ce genre de cas, semble s’avérer plus lourd à mettre en place.Le plus lourd serait de coder l'algorithme de synchronisation.C’est pas si lourd que ça. Tu fais une API JSON ou XML qui envoie et
reçoit les données puis en fonction ajoute/modifie/supprime les
données. Un peu comme un diff en fait.
Ok donc une synchro basée sur une API REST.
Comment tu gère le système de clés primaires (par défaut) de Rails?
Exemple: un enregistrement sera stocké en local avec l’ID 5 alors que
lorsqu’il sera envoyé au serveur, il aura l’ID 8 car d’autres
utilisateurs auront stocké des enregistrement entre temps. Comment ça
gère les associations?
Et dans ton cas, est-ce que tu synchronisait toute la base ou seulement
une partie?
En tous cas merci de ton retour, et si tu as des snippets je suis
preneur 
Thomas
Tony C. a écrit :
Tu peux peut-être regarder de ce côté là :
O'Reilly Media - Technology and Business Training
C’est avec Merb mais ça doit s’adapter à Rails
Cool! Ca a l’air sympa. Quand j’aurais le temps je ferai ce tuto.
2009/4/30 Thomas [email protected]
Comment tu gère le système de clés primaires (par défaut) de Rails?
Exemple: un enregistrement sera stocké en local avec l’ID 5 alors que
lorsqu’il sera envoyé au serveur, il aura l’ID 8 car d’autres
utilisateurs auront stocké des enregistrement entre temps. Comment ça
gère les associations?
J’utilise des uuid comme clés primaires, comme ça pas de conflits. C’est
plus le système par défaut mais il n’y a pas vraiment d’autres
solutions.
Et dans ton cas, est-ce que tu synchronisait toute la base ou seulement
une partie?
Il y a bien trop de données pour synchroniser toute la base, je récupère
les
données qui ont une date updated_at plus récente que la date de la
dernière
synchro.
En tous cas merci de ton retour, et si tu as des snippets je suis preneur
Je ne peux rien te montrer et si je le pouvais ce n’est pas réellement
intéressant.
Pour l’application vu que nokia a arrêté le dev de Qt Jambi et que je ne
sais pas s’il va y avoir qq1 qui le reprendra, je te conseillerais
d’aller
plutôt du côté de SWT, il y a plein d’exemples Java sur le site qui sont
très facilement adaptable pour JRuby. Ensuite tu peux packagé ton app
SWT et
ton app Rails avec jruby-complete et toutes les gems nécessaires (voir
le
blog de nick sieger pour jruby-complete + gems).
–
Nicolas Mérouze
http://www.yeastymobs.com
Nicolas Mérouze a écrit :
J’utilise des uuid comme clés primaires, comme ça pas de conflits.
C’est plus le système par défaut mais il n’y a pas vraiment d’autres
solutions.
Ah oui effectivement.
date de la dernière synchro.
En fait je parlais des données les plus récentes de l’ensemble des
modèles (le schéma entier, quoi). Ce qui fait qu’en local on a une copie
conforme de la base du serveur, même si on ne réécrase pas tout à chaque
fois. C’est bien ça?
ne sais pas s’il va y avoir qq1 qui le reprendra, je te conseillerais
d’aller plutôt du côté de SWT, il y a plein d’exemples Java sur le
site qui sont très facilement adaptable pour JRuby. Ensuite tu peux
packagé ton app SWT et ton app Rails avec jruby-complete et toutes les
gems nécessaires (voir le blog de nick sieger pour jruby-complete + gems).
Super conseil! Thanks a lot man!
Thomas
2009/4/30 Thomas [email protected]
En fait je parlais des données les plus récentes de l’ensemble des
modèles (le schéma entier, quoi). Ce qui fait qu’en local on a une copie
conforme de la base du serveur, même si on ne réécrase pas tout à chaque
fois. C’est bien ça?
Oui c’est bien ça.
–
Nicolas Mérouze
http://www.yeastymobs.com
Et celà ne serait pas possible avec Shoes?
Une base de donnée locale sqlite et synchronisation avec un serveur en
mode connecté
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs