Projet

• Application mobile avec prise de photo, devis, et commande en ligne
• Evolution avec l'apparition du site internet

Déroulement

• Prototypage très rapide avec Meteor
• Intégration plus délicate
• Ré-orientation du projet avec un site mobile pour sortir le projet plus vite

Risques

• Evolution de Meteor
• Google
• Méconnaissance de l'univers mobile

Boilerplate

• Maison : hébergé sur le github de MeteorLyon

Templating

• Blaze car peu de besoin technique
• Souscription au niveau du template

 

Simple et rapide

Mais

Manque d'outils (helpers, syntaxe and/or...)

Routing

• FlowRouter (pas de souscription du coup)

Google

• getUserMedia sur HTTPS en cours de projet -> obligation d'avoir un serveur avec https
• MediaStream en cours de projet -> caméra front utilisé par défaut
• obligation d'avoir tout en HTTPS quand on fait un POST/GET HTTP depuis du HTTPS (ex. quand le user est sur le site de la banque)

Paiement mobile

• sur site c'est facile, dans le mobile tu galèreras un peu
• peu de retour d'XP sur du Atos SIPS + mobile

 

pourtant j'aurais bien aimé faire du Stripe ou du BrainTree

mdg:camera

• incompatible avec les nouvelles contraintes de Google
• pas assez flexible, simple pour démarrer, mais obligation de le ré-écrire pour en faire ce que l'on veut

 

Du coup faut mettre les mains dedans, et soit en refaire un, soit le modifier

Cordova

• pb de configuration entre client et serveur :
  • meteor run --mobile-server http://myServerIP:myServerPort
  • build --server=http://myServerIP:myServerPort
• nginx en frontal : penser à la redirection des websockets, et on a plus besoin du myServerPort
• debugger : vérifier la variable globale __meteor_runtime_config__ qui contient les variables d'env et notamment DDP_CONNECTION_URI
• android : build facile, mais il ne faut pas oublier de signer l'apk (euh c'est quoi un javaKeyStore ?)
• debug, pas si évident que ça n'en a l'air (euh, pourquoi l'émulateur Android il ne se lance pas ?)

Cordova 2

• emulateur, préférez OSx ou Windows car ils bénéficient de l'accélération intel, du coup l'émulateur est utilisable, sinon... (Donc faites un virtual device sous processeur Intel et pas ARM)
• debug bis, Vive Chrome://inspect (pas avec crosswalk)
• build, bien nettoyer votre repertoire de build avant, car ça peut foirer et vous laisser croire que c'est ok (enfin pas vraiment en fait)
• crosswalk : attention il ne build pas au même endroit que le build traditionnel ! (buildTrad/build/outputs/apk/...

Mutualisation de code

server/client et donc ausi entre les applications mobile/desktop/admin : c'est vraiment top

Packages

• certaines complexité dans la gestion des dépendances (que va t on exposer ? doit on exposer des packages utilisés via imply ?)
• isolement des fonctionnalités, et partage de ces features

Librairies tierces

• c'est vraiment top, mais ça demande un brin d'apprentissage
  • useraccounts : customisez l'authentification,
  • autoform : simplifiez-vous les formulaires,
  • simple-schema : sécurisez vos modèles,
  • collections-helpers : enrichissez vos collections,
  • mizzao:autocomplete : galérez bien
  • yogiben:admin : un back-office en une matinée
  • ...

HTML5 : Apple n'est pas ton ami

Le déploiement,
c'est laborieux :

• passer de node 0.10.x à 0.12.x : bcrypt pose problème
• nginx en frontal, ça passe presque, si on oublie pas de transférer aussi les websockets
• supervisor c'est cool mais des fois ça bloque à la mise en place
• en fait les variables d'environnement c'est pas cool (c'est mon sys-admin qui dit ça)
• finalement un sys-admin dans l'équipe c'est cool, du coup maintenant on a des scripts de déploiement et il nous reste plus qu'à générer les confs supervisor à la volée
• il nous reste la surveillance à mettre en place 
• ReplicaSet : documentation non mise à jour pour MongoLab (base admin et local pour le RS)