Swift, les Bindings et les Key Value *

Swift ne fait pas vraiment la part belle aux bindings, on se retrouve avec plein de code relatif aux NSObject, ça plante (oui, bêta, tout ça, mais bon), etc...


 


La doc dit que ça viendra plus tard mais j'ai quelques doutes vis-à -vis de ce que j'ai lu à  gauche à  droite...


Alors je vous demande vous qui avez certainement plus eu le temps de vous tenir au jus ces 2 dernières semaines. Apple va-t-elle(il?) favoriser le modèle iOS où les bindings ne sont pas ou laisser un support chimérique d'une époque qu'on va forcer à  être révolue ? (ou mettre en place en tout nouveau système super pratique et iOS compliant en prime ? Oui, je sais :( )


 


Parce que si le binding n'a plus la cote j'avoue que je vais devoir réapprendre à  coder en Cocoa (je dev pas iOS) c'est comment la vie sans bindings ?


 


PS: ça ressemble à  de l'auto-flagélation parce que rien ne m'oblige à  passer à  Swift. Mais j'aimerai lui donner sa chance y'a 2/3 trucs que j'apprécie particulièrement dans ce langage et j'ai un bon feeling à  son égard :)   


Réponses

  • AliGatorAliGator Membre, Modérateur
    Pas de bindings prévus à  la connaissance. Mais toujours du KVO et des observeurs + lisibles et apposés aux propriétés (willSet/didSet).
  • yoannyoann Membre

    Si le KVO est là , je ne comprend pas pourquoi les bindings ne sont pas là ...


     


    C'est juste impossible de créer une application Mac sans les bindings...


  • AliGatorAliGator Membre, Modérateur
    Alors attention je corrige mon propos : pas de bindings prévus à  ma connaissance... sur iOS


    Autrement dit l'arrivée de Swift ne va rien changer sur ce point pour iOS.


    Pour OSX j'en sais rien car je n'ai pas regardé. Ceci dit ça ne m'étonnerai pas que ça jarte car, yoann, pour implémenter les bindings il faut du KVO certes mais il faut aussi du KVC, ce qu'il n'y a pas (encore?) dans Swift.
  • yoannyoann Membre

    Ils ont mis KVO sans KVC dans Swift ?!


  • AliGatorAliGator Membre, Modérateur
    Bah dans l'optique de sécurité de code oui

    Il me semble. Enfin à  vérifier quand même.
  • PyrohPyroh Membre

    C'est bien ce que je craignais... 


    Il me semble que le KVO est là  que quand on subclass NSObject, je l'utilise mais je trouve ça cracra... De même que j'utilise les bindings avec du mal dans un projet Swift + Storyboard sous 10.10 (un bonheur). Un cas d'école qui me prend 10 minutes à  faire en Obj-C + Xib (standard quoi) m'a pris plus d'une heure en Swift + Storyboard et c'était pas la barrière de la langue ou Xcode 6 qui est encore aux fraises le plus gros soucis.


    Le cas d'école dont je parle est simple : 1 pack de 3 slider + 1 colorwell je vous laisse imaginer la suite  ;). Au final : ça rame et je ne pense pas que ça soit à  cause du status de bêta (possible cela dit mais j'en doute).


     


    Alors quoi ? On abandonne le KVO à  l'ancienne ? Parce qu'honnêtement je vois pas l'intérêt d'un KVO pareil si les bindings n'existent plus.


     


    D'ailleurs comment on ferai sans bindings ? J'ai jamais codé sans  :)  Le paradigme MVC me paraà®t un peu nébuleux quand il s'agit de connecter des vues au modèle... (il me paraà®t nébuleux tout court d'ailleurs...)


     


    Je vais relire la doc d'Apple sur le sujet et apprendre à  faire sans (ça tombe bien je suis en vacances. J'ai bien fais de reprendre des études, tien  :P ). Si quelqu'un à  de la saine lecture sur le sujet à  me conseiller je suis preneur (blog, PDF, livres, tablettes en cire, etc...), anglais ou français (avec préférence pour l'anglais).


     


    Je suis quand même un peu triste  :(


  • yoannyoann Membre

    Coder sous Mac sans les binding c'est des centaines et des centaines de ligne de code inutile et répétitive pour mettre à  jour l'UI en cas de changement (qui peuvent être bien plus complexe que sur iOS) et propager les entrées utilisateurs avec éventuellement un traitement dessus.


     


    Franchement, je ne vois pas comment les gros logiciels peuvent faire sans. Au delà  du coté ligne de code à  écrire en plus par rapport à  avant, il y a le coté complexité et répétitivité de ces actions. C'est un coup à  introduire des bug en masse ça.


  • PyrohPyroh Membre

    Coder sous Mac sans les binding c'est des centaines et des centaines de ligne de code inutile et répétitive pour mettre à  jour l'UI en cas de changement (qui peuvent être bien plus complexe que sur iOS) et propager les entrées utilisateurs avec éventuellement un traitement dessus.

     

    Franchement, je ne vois pas comment les gros logiciels peuvent faire sans. Au delà  du coté ligne de code à  écrire en plus par rapport à  avant, il y a le coté complexité et répétitivité de ces actions. C'est un coup à  introduire des bug en masse ça.



    ça devrait pas mais ça me rassure de lire ça.


    Je vois mal Apple mettre au rebus les NSArrayController, NSDictionnaryController et les autres bubulles vertes de Xcode. J'espère vraiment que l'implémentation est en cours et que ça sera un grand frère de KVO/KVC mais en plus souple.


  • AlakAlak Membre

    Pour un peu plus d'info :


     


    Voici un petit lien https://github.com/Mantle/Mantle/issues/342 (le mec en a discuté avec un ingé d'apple a la WWDC)


  • Uhm c'est pas vraiment une bonne nouvelle ça...


    Merci pour l'info  :)


  • CéroceCéroce Membre, Modérateur
    juin 2014 modifié #12

    Je vois mal Apple mettre au rebus les NSArrayController, NSDictionnaryController et les autres bubulles vertes de Xcode.

    Il faut être clair, le Mac n'est vraiment pas la priorité d'Apple " il n'y a qu'à  voir sa part dans le chiffre d'affaires d'Apple. À mon avis, le plan d'Apple, à  moyen terme, c'est de laisser en l'état: les bindings fonctionnent, on ne touche à  rien. Créer ses propres contrôles compatibles bindings est peut-être impossible à  faire en Swift; eh bien, continuez à  les écrire en ObjC, et faites le reste de votre appli en Swift.

    Pour l'instant, Apple a pris la route qui lui donne le moins de travail, mais il est permis de rêver qu'Apple inventera un système similaire aux bindings sous iOS " qui serait utile sur iPad " et que le Mac en hérite un beau jour.

    Je dois dire que j'ai une relation paradoxale avec les bindings: je les utilise beaucoup, mais je déplore leur complexité, et la difficulté à  les déboguer. J'en ai eu encore un exemple rien que cette après-midi. Une version plus légère, basée sur Swift et des concepts plus modernes ne serait pas du luxe.


  • Il faut être clair, le Mac n'est vraiment pas la priorité d'Apple " il n'y a qu'à  voir sa part dans le chiffre d'affaires d'Apple. À mon avis, le plan d'Apple, à  moyen terme, c'est de laisser en l'état: les bindings fonctionnent, on ne touche à  rien. Créer ses propres contrôles compatibles bindings est peut-être impossible à  faire en Swift; eh bien, continuez à  les écrire en ObjC, et faites le reste de votre appli en Swift.


    Pour l'instant, Apple a pris la route qui lui donne le moins de travail, mais il est permis de rêver qu'Apple inventera un système similaire aux bindings sous iOS " qui serait utile sur iPad " et que le Mac en hérite un beau jour.


    Je dois dire que j'ai une relation paradoxale avec les bindings: je les utilise beaucoup, mais je déplore leur complexité, et la difficulté à  les déboguer. J'en ai eu encore un exemple rien que cette après-midi. Une version plus légère, basée sur Swift et des concepts plus modernes ne serait pas du luxe.




     


    Le problème de cette réflexion de "c'est une petite part de marché le Mac" c'est qu'elle n'est vrai qu'à  court terme. Pour être en contact privilégier avec les entreprises, je peux le dire, la demande augmente réellement et il va bien falloir être capable de sortir des applications métier un jour où l'autre.


     


    Sinon pour les bindings je suis d'accords, c'est chiant à  déboguer mais ça fait gagner tellement de temps que je me force à  relire trois ou quatre fois les config que je fais pour éviter les problèmes et en profiter au max. Une fois qu'on a l'habitude de cette gymnastique, le temps perdu en débug est bien ridicule en regard au temps gagné.

  • Faut pas exagerer, on peut tout a fait faire une appli sans bindings.

    Pendant des annees, Windows n'a pas eu de Bindings, le web n'a pas de bindings...


    Cependant, je suis pour un systeme de binding rénové car je n'ai jamais rien compris au systeme de cocoa.

    Il faudrait prendre exemple sur WPF où les bindings sont plus simple en premiere approche.



    Autant on peut se faire son propre systeme d'observer avec les willSet, didSet (on perd quand meme la capacite d'observer les classes tierces), autant il va etre difficile de faire son propre systeme de binding sans un minimum de reflection permettant de se connecter aux propriétés via une chaà®ne de caractère.

    Il existe deja un object reflect non documenté donc je pense qu'on pourra le faire dans une version future.


  • Faut pas exagerer, on peut tout a fait faire une appli sans bindings.

    Pendant des annees, Windows n'a pas eu de Bindings, le web n'a pas de bindings...


    Cependant, je suis pour un systeme de binding rénové car je n'ai jamais rien compris au systeme de cocoa.

    Il faudrait prendre exemple sur WPF où les bindings sont plus simple en premiere approche.


     




     


     


    Bien sur on peut faire une application Mac sans bindings, c'est juste une perte monumentale de temps pour absolument 0 gains.


     


    Les bindings Cocoa sont simple pourtant, je ne vois pas comment on peut faire plus simple en fait. Tu dis qu'est-ce que tu veux connecter à  quoi et éventuellement quel adaptateur tu veux mettre entre... Pas compliqué.


     


    Quand au web, vous savez ce que j'en pense. Une techno qui n'est pas foutu de fournir un framework capable de faire de l'UI consistante et réutilisable pour de l'applicatif (car on parle d'application ici, pas de site, c'est pas du tout la même chose) n'est pas intéressante.


     


    Tous les dev qui se retrouve à  faire des applications métier en web finissent toujours pas réinventer la même chose, leur propre table view, leur propre menubar, etc.


     


    Il y a les framework de la communauté c'est sur, mais lequel prendre ? Il y en a un milliard et demi qui font tous a peut près la même chose, qui dont forcément tous mieux que les autres et qui, selon la période, sont à  la mode ou non. Aucune cohérence, aucune stabilité, aucun engagement dans le temps.


     


    Tant que le W3C n'aura pas imposé un framework permettant de faire proprement de l'applicatif intégré au look du client final, le web ne sera pas, à  mes yeux, une techno sérieuse pour de l'app métier.


     


    Je crois que l'exemple parfait c'est VMware vCenter Web Client. Ils ont voulu remplacé une app Windows only par un truc web pour que ça marche de partout. Bilan des opération : ça marche en flash.

  • AliGatorAliGator Membre, Modérateur
    C'est marrant quand tu décris les technos Web pour faire des apps (point de vue que je partage totalement) on a l'impression que tu décris le monde Java :-P
  • AliGatorAliGator Membre, Modérateur
    Et sinon quelqu'un a déjà  essayé ReactiveCocoa ?
  • CéroceCéroce Membre, Modérateur
    juin 2014 modifié #18

    Les bindings Cocoa sont simple pourtant, je ne vois pas comment on peut faire plus simple en fait. Tu dis qu'est-ce que tu veux connecter à  quoi et éventuellement quel adaptateur tu veux mettre entre... Pas compliqué.

    Je ne peux pas être d'accord. Les bindings s'appuient sur trois pièces technologiques:
    - le Key-Value Coding
    - le Key-Value Observing
    - le Key-Value Binding

    Chacune de ces technos est illustrée par un guide, comportant des tas de détails de fonctionnement. Les technos ne s'imbriquent pas si bien que ça; il y a des choses qu'il semble possible de faire, mais en pratique non, et vice-versa, sauf qu'on le sait rarement avant d'avoir essayé.

    Je te donne un exemple tout simple, que j'ai vu hier: j'ai une liste qui s'affiche dans une table (NSTableView bindée sur un NSArrayController). Je veux qu'un bouton soit actif seulement si j'ai une ligne sélectionnée. Dis-moi spontanément, sur quoi binder button.enabled ? J'ai essayé 4 possibilités, à  chaque fois sans succès (et je relance l'appli à  chaque fois...), avant d'aller chercher sur le web la solution.


  • Je te donne un exemple tout simple, que j'ai vu hier: j'ai une liste qui s'affiche dans une table (NSTableView bindée sur un NSArrayController). Je veux qu'un bouton soit actif seulement si j'ai une ligne sélectionnée. Dis-moi spontanément, sur quoi binder button.enabled ? J'ai essayé 4 possibilités, à  chaque fois sans succès (et je relance l'appli à  chaque fois...), avant d'aller chercher sur le web la solution.




     


    Sans chercher sur le web je ferais un bind sur le selectedIndexes avec un NSValueTransformer qui convertir le set en BOOL s'il y a un objet ou plus.



  • Et sinon quelqu'un a déjà  essayé ReactiveCocoa ?




     


    Je m'en suis servir sur un projet avec un collègue. C'est le collègue qui maitrise, pas moi, mais ça a l'air pas mal et particulièrement puissant. Par contre la courbe d'apprentissage est hard. J'ai pas encore tout compris des possibilités du truc perso.

  • AliGatorAliGator Membre, Modérateur
    Ouais moi la syntaxe me rebute un peu pour l'instant du coup ça m'a pas encore donné l'envie de m'y essayer, pourtant bcp de monde en parle...
  • C'est un peu du déterrage, mais je la sentais venir l'iOSisation du Mac. Pour tout dire, mon premier choc quand j'ai suivi un cours iOS ça a été l'absence des bindings. Ma question a été "vous faites comment?".


     


    Et puis j'ai jeté un coup d'oeil à  leur code et j'ai compris. Ca ne faisait pas rêver. Il y a des gens qui adorent littéralement pisser du code répétitif, comme si ça les rassurait. Bon, ce n'étaient peut-être pas de bons exemples, remarquez. La notion de MVC leur était aussi étrangère que les bindings...  ???




  • Sans chercher sur le web je ferais un bind sur le selectedIndexes avec un NSValueTransformer qui convertir le set en BOOL s'il y a un objet ou plus.




     


    Merci mille fois Yoann pour ton coup de pouce. Cela fait un bout de temps que je cherche un moyen de binder sur l'existence ou non d'une sélection.


     


    ça m'ouvre de nouveaux horizons...


     


    Définition du NSValueTransformer qu'on peut utiliser dans le binding (ça marche)



    @implementation TF_TestValueTransformer

    + (Class)transformedValueClass { return [NSNumber class]; }
    + (BOOL)allowsReverseTransformation { return NO; }
    - (id)transformedValue:(id)value {
    if (value==nil) {
    return nil;
    } else {
    return [NSNumber numberWithBool:[(NSIndexSet *)value count]>2];
    }
    }



  •  


    Merci mille fois Yoann pour ton coup de pouce. Cela fait un bout de temps que je cherche un moyen de binder sur l'existence ou non d'une sélection.


     


    ça m'ouvre de nouveaux horizons...


     


    Définition du NSValueTransformer qu'on peut utiliser dans le binding (ça marche)



    @implementation TF_TestValueTransformer

    + (Class)transformedValueClass { return [NSNumber class]; }
    + (BOOL)allowsReverseTransformation { return NO; }
    - (id)transformedValue:(id)value {
    if (value==nil) {
    return nil;
    } else {
    return [NSNumber numberWithBool:[(NSIndexSet *)value count]>2];
    }
    }




     


    Bah faut demander ^^


     


    C'est facile les binding :-)

  • Je n'ai pas tester directement ReactiveCocoa, mais la programmation Reactive m'interesse beaucoup. Et j'ai déjà  essayé le framework RXJava sur Android (l'équivalent de ReactiveCocoa mais en Java).


     


    Et je doit dire que j'adore le concept.


     




    Ouais moi la syntaxe me rebute un peu pour l'instant du coup ça m'a pas encore donné l'envie de m'y essayer, pourtant bcp de monde en parle...




     


    Qu'entends-tu par syntaxe ? Qu'est qui te rebute exactement ?


    Tu veux parler du sucre syntaxique qui ressemble à  ça: 



    RAC(self.imageView, image) = ...

  • AliGatorAliGator Membre, Modérateur
    En bref rien que le fait de repasser à  un DSL basé sur de la prog fonctionnelle plutôt qu'objet je trouve pas ça sexy.

    On n'a plus la syntaxe pointée, on a une syntaxe fonctionnelle avec comme dans ton exemple "RAC(self.imageView, image) = ...". Pourquoi pas "self.imageView.image.signal = ..." ou un truc comme ça ?

    Bon j'avoue aussi que je ne me suis pas encore assez penché sur la programmation Reactive pour l'instant, donc les concepts de signal & co ne sont pas encore totalement assimilés pour moi (j'ai juste regardé à  quoi ça ressemblait et le principe de base, mais pas encore eu l'occasion de creuser et encore moins de le tester en vrai) donc ça joue sans doute aussi, mais bon quand même j'ai l'impression de revenir à  du fonctionnel là  où l'OOP est roi, comme quand on fait du CoreFoundation en plein milieu d'un code Objective-C ou Swift qui est tout en OOP, ça fait un peu tâche dans l'ensemble du code ^^
Connectez-vous ou Inscrivez-vous pour répondre.