Malheureusement, ça n'est utile que quand on gère toute la chaà®ne, ce qui est souvent le cas pour les projets persos (à la FoodReporter ou Vinicava), dans ce cas faut partir avec Helios.io dès le début mais ça peut être très puissant...
Par contre pour les cas que je rencontre le plus souvent de faire une application iOS pour un client qui a déjà une partie serveur, malheureusement ça ne sera pas d'une grande utilité. Le problème avec ce genre de cas (malheureusement trop fréquent à moins de faire ses propres produits et d'être éditeur) étant que soit la partie serveur est déjà faite et ne va pas coller avec Helios.io, soit pire encore en plus d'être faite elle ne respecte pas les standards (API qui se dit RESTful mais qui est stateful avec des cookies, ou API pas consistente qui renvoie des JSON non uniformes selon les WebServices, et j'en passe), et là on voudrait bien pouvoir utiliser Helios.io ou même RESTKit ou autre, mais impossible tellement c'est le boxon côté serveur chez le client...
Du coup j'ai bien peur de ne pas avoir souvent l'occasion d'utiliser ce framework
J'étais aux CocoaHead Lyon hier soir. J'ai bcp aimé rencontrer ce fameux Mattt. Bon orateur, clairement mordu de technos et fier de nous montrer Helios.
Mais bon, voilà quoi. Je me suis rendu compte que le gars faisait finalement une tournée pour présenter son truc. Je pensais qu'il allait nous parler de Ruby, de technos précises sur lesquelles il s'était penché mais en fait non. Il nous a fait une demo de helios... Ca m'a un peu frustrer.
Mais bon, maintenant que j'ai fini de raler, voilà ce que j'ai compris :
=> basé entièrement sur Ruby et PostGreSql
=> on install la partie serveur pour une appli en 2 lignes de commandes à peu près.
=> on démarre son projet d'appli cliente
=> on link l'appli cliente avec l'appli serveur Helios
Et hop, c'est magique ! Chaque fois que vous définissez une entité dans Coredata : boum, le serveur est au courant.
Chaque fois que vous insérez une donnée, boum, le serveur est au courant.
Ca gère donc les datas+synchro, les notifs, les achats inApps et ça fait tout plein de stats sur l'utilisation de l'appli.
Tout cela est en beta. Et la scéance de live coding qu'il nous a proposé était certes impressionnante (il connait toutes les classes par coeur et utilise plein de snippets XCode ^^) mais lors de la compilation/run, ça a craché... Et il n'a pas su trouver d'où ça venait (un bon vieux crash boite noire à la core data).
Mattt nous a dit ne pas utiliser InterfaceBuilder car c'est pour les débutants
Encore moins StoryBoard. Pour lui, Apple fait ça juste pour attirer les débutants. Mais ça reste boite noire et ça l'effraie.
Pourtant, il utilise CoreData (qui reste quand meme boite noire pour moi) et nous propose sa boite noire à lui côté serveur :-)
Bon normal qu'il ait confiance en ce qu'il fait.
Maintenant, perso, je ne me vois pas utiliser helios...
Cela ne me gêne pas qu'il parle essentiellement de ses technos car il fait du gratuit open source... Donc je n'y vois pas de pub.
Je n'ai pas réussi à savoir si c'était possible d'utilise SQLite (sur iOS) avec Helios côté serveur (quitte à utiliser AFNetworking pour communiquer). Et si ça présente même un intérêt. Ou bien si Helios ne vaut le coup que si on utilise CoreData.
Mattt nous a dit ne pas utiliser InterfaceBuilder car c'est pour les débutants
Encore moins StoryBoard. Pour lui, Apple fait ça juste pour attirer les débutants. Mais ça reste boite noire et ça l'effraie.
Bizarre...
J'aurais tendance à dire, qu'une fois passé ce stade de débutant, IB fait gagner du temps. Je mélange code et IB (selon l'envie et ce qu'il y a à paramétrer, mais essaye de respecter une certaine logique dans ces variations pour chaque application).
Pour IB je suis de l'avis de Larme. Ca fait gagner un max de temps et ça n'est pas vraiment boite noire puisque c'est juste un xml qui est généré.
Pour Helios j'ai tenté l'install et ... ca foire ^^ J'ai ouvert une issue mais les réponses ne m'aide pas vraiment.
On parlais de Parse mais au final je pense avoir trouvé un service vraiment pas mal : Stackmob. Le nombre de call API est illimité, le stockage se fait via un S3 perso donc les coups sont super bas. Le SDK est un peu plus complexe que Parse mais j'ai l'impression que les contraintes sont moins fortes. Avec Parse si on dépasse 1Go de datas, il faut direct payer 200 dol/mois. Avec un S3 je pense vraiment pas qu'on atteint cette somme.
Sinon moi je trouve que les xibs et storyboard sont vraiment pratique si ils sont utilisé intelligemment et pas pour n'importe quoi.
ça fait gagner du temps, mais aussi de la lisibilité dans le code. Et au fond ça colle assez bien au modèle MVC.
Car quand je tombe parfois sur un -loadView ou -viewDidLoad où toute la hiérarchie de views est créée alors que visiblement ça aurait pu être fait dans un xib, je vois pas l'intérêt.
Pour IB je suis de l'avis de Larme. Ca fait gagner un max de temps et ça n'est pas vraiment boite noire puisque c'est juste un xml qui est généré.
Pour Helios j'ai tenté l'install et ... ca foire ^^ J'ai ouvert une issue mais les réponses ne m'aide pas vraiment.
On parlais de Parse mais au final je pense avoir trouvé un service vraiment pas mal : Stackmob. Le nombre de call API est illimité, le stockage se fait via un S3 perso donc les coups sont super bas. Le SDK est un peu plus complexe que Parse mais j'ai l'impression que les contraintes sont moins fortes. Avec Parse si on dépasse 1Go de datas, il faut direct payer 200 dol/mois. Avec un S3 je pense vraiment pas qu'on atteint cette somme.
Y'a Azure aussi, de Microsoft, si je me rappelle bien du LiveCode iOS du début d'année...
Je viens de regarder sommairement les prix d'Amazon S3 et d'Azure. Le grand fleuve semble moins cher que le ciel bleu, du moins pour le téléchargements de données.
Dans le cas qui m'intéresse, la facture est d'environ 1.300 $ HT pour 19 To par mois.
Je viens de regarder sommairement les prix d'Amazon S3 et d'Azure. Le grand fleuve semble moins cher que le ciel bleu, du moins pour le téléchargements de données.
Dans le cas qui m'intéresse, la facture est d'environ 1.300 $ HT pour 19 To par mois.
Rectification : c'est 1.750 $ HT pour un transfert de 19 To en fait !
Réponses
Faut que je regarde ça ! Intéressant.
Il faut faire attention à tout: la synchronisation peut vite virer en cauchemar, surtout quand c'est dans les 2 sens.
En fait, c'est un "mini-parse" qu'on peut installer sur notre propre serveur d'après ce que j'ai compris.
Parse est un outil tout-prêt payant.
Là , il s'agit de configurer son propre serveur gratuit.
Parse gère aussi les in-app je crois.
Oui Helios.io a l'air intéressant !
Malheureusement, ça n'est utile que quand on gère toute la chaà®ne, ce qui est souvent le cas pour les projets persos (à la FoodReporter ou Vinicava), dans ce cas faut partir avec Helios.io dès le début mais ça peut être très puissant...
Par contre pour les cas que je rencontre le plus souvent de faire une application iOS pour un client qui a déjà une partie serveur, malheureusement ça ne sera pas d'une grande utilité. Le problème avec ce genre de cas (malheureusement trop fréquent à moins de faire ses propres produits et d'être éditeur) étant que soit la partie serveur est déjà faite et ne va pas coller avec Helios.io, soit pire encore en plus d'être faite elle ne respecte pas les standards (API qui se dit RESTful mais qui est stateful avec des cookies, ou API pas consistente qui renvoie des JSON non uniformes selon les WebServices, et j'en passe), et là on voudrait bien pouvoir utiliser Helios.io ou même RESTKit ou autre, mais impossible tellement c'est le boxon côté serveur chez le client...
Du coup j'ai bien peur de ne pas avoir souvent l'occasion d'utiliser ce framework
Hello,
J'étais aux CocoaHead Lyon hier soir. J'ai bcp aimé rencontrer ce fameux Mattt. Bon orateur, clairement mordu de technos et fier de nous montrer Helios.
Mais bon, voilà quoi. Je me suis rendu compte que le gars faisait finalement une tournée pour présenter son truc. Je pensais qu'il allait nous parler de Ruby, de technos précises sur lesquelles il s'était penché mais en fait non. Il nous a fait une demo de helios... Ca m'a un peu frustrer.
Mais bon, maintenant que j'ai fini de raler, voilà ce que j'ai compris :
=> basé entièrement sur Ruby et PostGreSql
=> on install la partie serveur pour une appli en 2 lignes de commandes à peu près.
=> on démarre son projet d'appli cliente
=> on link l'appli cliente avec l'appli serveur Helios
Et hop, c'est magique ! Chaque fois que vous définissez une entité dans Coredata : boum, le serveur est au courant.
Chaque fois que vous insérez une donnée, boum, le serveur est au courant.
Ca gère donc les datas+synchro, les notifs, les achats inApps et ça fait tout plein de stats sur l'utilisation de l'appli.
Tout cela est en beta. Et la scéance de live coding qu'il nous a proposé était certes impressionnante (il connait toutes les classes par coeur et utilise plein de snippets XCode ^^) mais lors de la compilation/run, ça a craché... Et il n'a pas su trouver d'où ça venait (un bon vieux crash boite noire à la core data).
Mattt nous a dit ne pas utiliser InterfaceBuilder car c'est pour les débutants
Encore moins StoryBoard. Pour lui, Apple fait ça juste pour attirer les débutants. Mais ça reste boite noire et ça l'effraie.
Pourtant, il utilise CoreData (qui reste quand meme boite noire pour moi) et nous propose sa boite noire à lui côté serveur :-)
Bon normal qu'il ait confiance en ce qu'il fait.
Maintenant, perso, je ne me vois pas utiliser helios...
Merci pour ton retour LeChatNoir.
Cela ne me gêne pas qu'il parle essentiellement de ses technos car il fait du gratuit open source... Donc je n'y vois pas de pub.
Je n'ai pas réussi à savoir si c'était possible d'utilise SQLite (sur iOS) avec Helios côté serveur (quitte à utiliser AFNetworking pour communiquer). Et si ça présente même un intérêt. Ou bien si Helios ne vaut le coup que si on utilise CoreData.
Bizarre...
J'aurais tendance à dire, qu'une fois passé ce stade de débutant, IB fait gagner du temps. Je mélange code et IB (selon l'envie et ce qu'il y a à paramétrer, mais essaye de respecter une certaine logique dans ces variations pour chaque application).
La programmation objet c'est boà®te noire :-)
Merci pour ton retour LeChatNoir.
Pour IB je suis de l'avis de Larme. Ca fait gagner un max de temps et ça n'est pas vraiment boite noire puisque c'est juste un xml qui est généré.
Pour Helios j'ai tenté l'install et ... ca foire ^^ J'ai ouvert une issue mais les réponses ne m'aide pas vraiment.
On parlais de Parse mais au final je pense avoir trouvé un service vraiment pas mal : Stackmob. Le nombre de call API est illimité, le stockage se fait via un S3 perso donc les coups sont super bas. Le SDK est un peu plus complexe que Parse mais j'ai l'impression que les contraintes sont moins fortes. Avec Parse si on dépasse 1Go de datas, il faut direct payer 200 dol/mois. Avec un S3 je pense vraiment pas qu'on atteint cette somme.
C'est pas super ça si y'a trop de coups bas... :P
Sinon moi je trouve que les xibs et storyboard sont vraiment pratique si ils sont utilisé intelligemment et pas pour n'importe quoi.
ça fait gagner du temps, mais aussi de la lisibilité dans le code. Et au fond ça colle assez bien au modèle MVC.
Car quand je tombe parfois sur un -loadView ou -viewDidLoad où toute la hiérarchie de views est créée alors que visiblement ça aurait pu être fait dans un xib, je vois pas l'intérêt.
Y'a Azure aussi, de Microsoft, si je me rappelle bien du LiveCode iOS du début d'année...
Dans le cas qui m'intéresse, la facture est d'environ 1.300 $ HT pour 19 To par mois.
Ouai et puis 'crosoft quoi ^^
bon, pour les xib, c'était sans doute un peu de provoc' aussi
Il a l'air assez drôle comme gars 
Rectification : c'est 1.750 $ HT pour un transfert de 19 To en fait !
Pour mon app je tablerai sur du 10 Go max d'images à stocker si ça fonctionne bien donc en dessous des 100 $/mois
Moi je pais entre 3$ et 5$ par mois pour Vinicava.
Je vous joins le relevé de mars.
19 To de traffic ? Tu refais un AppStore Draken ?
Et quelqu'un a déjà utilisé parse en version gratuite? Doit on rapidement passer à l'offre payante?
Oui, mais en mieux. Avec du verre et du marbre partout !
Non ! Johnny a dit stop au skeumorphisme, non ?