Mobile4D versus iSort
Suite à la publication d'une vidéo mettant en scène Mobile4D sur vimeo par le service Marketing de 4D : des interrogations sont remontées sur la mailing-list 4D-forum :
Je suis pas sûr que ça apporte grand chose de plus que iSort...
(http://www.flickr.com/photos/84829874@N00/345635238)
Je reprends dans ce billet le complément d'explications apporté sur la liste de diffusion.
Dans les deux cas, la communication : • repose sur le mécanisme de synchronisation de 4D v12; • échange donc au niveau données (couche relationnelle).
iSort
iSort est une application native, uniquement iOS, qui échange au travers d'un format binaire avec 4D.
pas de possibilité *actuellement* de redistribuer la base de données iSort à synchroniser avec 4D
Mobile4D
Mobile4D est une bibliothèque HTML5, donc en grande partie cross platform, qui échange en format JSON avec 4D par l'URL 4DSYNC.
Pas de possibilité *actuellement* de synchroniser images et binaires avec ce protocole
Contraintes de Mobile4D
Les données sont répliquées sur le mobile suivant le modèle relationnel. A vous de rebâtir la logique métier côté client. Si le modèle change, l'appli client doit changer.
Autre contrainte : le modèle physique est partiellement exposé en JavaScript. Autrement dit : architecture très couplée.
Liens vers d'autres articles en relation avec ce sujet : cf. : • l'article "Mobilisez-vous !" sur mon blog : • une Note Technique sur 4DSYnc écrite, mais pas encore publiée par 4D • l'article "Du Flex dans une application 4D 2004" sur mon blog, introduction à un échange orienté non pas données, mais API. L'architecture décrite fonctionne à l'identique dans le cadre d'applis Web HTML5 (mobiles ou non) et d'applications natives pour mobiles ou desktop. Cette architecture reprend un modèle MVC Server, cf. " MVC : L'immaculé (Motif de) Conception".