(Re)passer au développement Mac

Réponses

• Flo Membre

  mai 2011 04:50 modifié #2

  Quelques (modestes) petits éléments de réponse :
  
  

  
  En venant du dev iOS où on est habitué à  1 xib pour 1 fenêtre (en gros), quelle sont les bonnes démarches et habitudes à  prendre sur Mac? (il y aura donc beaucoup moins de nibs mais quelle est la meilleure approche aunivau de la construction du programme)
  

  
  
  Personnellement je respecte cette pratique aussi sur Mac OS. Elle permet de structurer plus facilement les différentes vues de son application et économise de la mémoire si on prends soin de ne charger les xib qu'au bon moment. Respecter cette méthode est moins critique que sur iOS mais ça n'en reste pas moins une bonne habitude 
  
  Pour charger/décharger les vues c'est le bon vieux couple NSWindowController/NSViewController qui est encore à  l'honneur. Il suffit de passer le nom du xib dans le constructeur et d'avoir déclaré le bon controller comme File Owner et fait les bons linkages des éléments graphiques. Ces controllers sont responsables de la gestion mémoire des éléments de haut niveau dans les xib. Petite subtilité, si je ne me trompe pas, il faut insérer le NSViewController dans la Responder Chain à  la main (ce qui ne doit pas être le cas sous iOS).
  
  Personnellement, pour une appli mono-fenêtre je créer la fenêtre principale et le main menu dans le xib géré par l'instance principale de NSApplication. Je donne souvent le rôle de NSWindowController à  mon appDelegate (le délégué de NSApplication qui implémente NSApplicationDelegate). Ce dernier charge et décharge les différentes vues / sheet en créant à  la volée des NSViewController destinés de la gestion de ces dernières.
  
  Pour les applis destinées à  gérer plus de fenêtres il vaut mieux choisir une architecture Document Based même si je ne m'y suis jamais vraiment risqué ^^. Le support de Core Data/bindings c'est amélioré dans les dernières version de OS X mais certains comportements restent obscurs quand on souhaite faire des choses plus "complexes".
  
  En te souhaitant un bon retour parmi le clan des irréductibles qui résistent encore et toujours à  l'envahisseur
• Draken Membre

  mai 2011 mai 2011 modifié #3

  Muqaddar, sale traà®tre. Le peuple iosien aura ta peau !
  
  [size=14pt]Delenda Carthagosx[/size] !
  
• Céroce Membre, Modérateur

  mai 2011 04:50 modifié #4

  dans 1304626449:

  
  Je suppose qu'on programme pour être compatible 10.5 minimum aujourd'hui. 10.6 only doit être prématuré?
  

  
  Je vends toujours PortraiMatic sur mon site web en précisant bien qu'il est plutôt conseillé de l'acheter sur le Mac App Store si on dispose de Mac OS 10.6. Aujourd'hui,  seules 10% des ventes se font sur le site web: ça inclut les gens sous 10.5 mais aussi ceux qui ne veulent pas acheter sur le MAS pour des raisons politiques, philosophiques, religieuses, etc.
  
  Pour une nouvelle appli, la question ne se pose pas pour moi: c'est le MAS seulement, c'est trop de travail pour vendre sur son site web, parce qu'il faut mettre en place un système de paiement et un système d'envoi des clefs de débridage. Au niveau de l'appli, il faudrait prévoir un écran d'accueil, et vérifier que les clefs sont valides. Tout ça pour seulement 10% de clientèle aujourd'hui, taux qui ne peut que diminuer.
  
  

  dans 1304626449:

  
  Quid de la compilation en 32 ou 64 bits ? Que font les utilisateurs de ce forum ?
  

  
  Il me semble que le MAS t'impose de faire une appli 32/64 bits. Pour mon appli, ce ne fut qu'un réglage de build à  changer, je n'ai pas modifié mon code du tout.
  
  

  dans 1304626449:

  
  En venant du dev iOS où on est habitué à  1 xib pour 1 fenêtre (en gros), quelle sont les bonnes démarches et habitudes à  prendre sur Mac?
  

  
  Sur Mac, une application moderne utilise plusieurs NSViewControllers, et un XIB pour chaque.
  Pour moi, la grosse différence est la façon dont on opère les liens entre les modèles et les vues. Autant sous iOS on va utiliser la délégation, le KVO voire les notifications pour prendre en compte les changements du modèle, autant sur Mac on va utiliser les bindings.
  
  L'autre grosse différence est que la personnalisation de l'IHM est compliquée sur Mac. ça demande souvent un gros travail de rétro-ingénérie. J'ai fait le choix de n'utiliser que des contrôles standard. En fouillant un peu leurs réglages et en codant quelques NSViews personnalisées simples, on arrive à  avoir quelque chose qui a de la gueule, sans exploser les temps de dév.
• Flo Membre

  mai 2011 04:50 modifié #5

  
  L'autre grosse différence est que la personnalisation de l'IHM est compliquée sur Mac. ça demande souvent un gros travail de rétro-ingénérie. J'ai fait le choix de n'utiliser que des contrôles standard. En fouillant un peu leurs réglages et en codant quelques NSViews personnalisées simples, on arrive à  avoir quelque chose qui a de la gueule, sans exploser les temps de dév.
  

  
  
  C'est vrai, mais il y a des gens qui parfois, se sont déjà  pris la tête pour toi et publient des classes (Sidebar à  la iTunes par exemple avec des images et des badges) voire des framework (le plus connu étant BWToolKit) le plus souvent sous licence BSD donc facilement réutilisable dans une appli commerciale.
  
  Sinon j'offre une (vraie) tournée générale (sans perrier citron  :P) pour le retour de Muqaddar à  la civilisation !  
• muqaddar Administrateur

  mai 2011 04:50 modifié #6

  Salut Flo et Céroce,
  
  En fait, je me disais, dans le cas d'une application monofenêtre avec 4  blocs avec des fonctionnalités différentes par exemple, vous instancierez quand-même 4 NSViewControllers et leurs XIBS (pour séparer les morceaux de vues et leurs contrôles)... mais dans ce cas, comment faites-vous pour ajouter la vue1 du XIB du NSViewController 2 à  la fenêtre principale du NSViewController1 (ou de appdelegate) ? Quelle est la bonne méthode ?
  
  @flo
  
  

  Pour charger/décharger les vues c'est le bon vieux couple NSWindowController/NSViewController qui est encore à  l'honneur. Il suffit de passer le nom du xib dans le constructeur et d'avoir déclaré le bon controller comme File Owner et fait les bons linkages des éléments graphiques. Ces controllers sont responsables de la gestion mémoire des éléments de haut niveau dans les xib.

  
  
  La réponse semble être là . Je vais me pencher dessus rapidement. Je vais ressortir un vieux projet.
  Tout a l'air de se gérer dans IB.
  
  @Céroce
  Pour le MAS, c'est vrai qu'aujourd'hui on peut se poser la question de ne passer que par lui.
  
  Merci à  vous pour les autres réponses.
  
  

  dans 1304666366:

  
  Sinon j'offre une (vraie) tournée générale (sans perrier citron  :P) pour le retour de Muqaddar à  la civilisation !  
  

  
  
  Je prépare un retour mais je ne sais pas quand exactement. Je pense aller déterrer des vieux projets, ça m'évitera de poser des questions basiques... c'est un peu déroutant en venant du monde iOS.
• Flo Membre

  mai 2011 04:50 modifié #7

  
  La réponse semble être là . Je vais me pencher dessus rapidement. Je vais ressortir un vieux projet.
  Tout a l'air de se gérer dans IB.
  

  
  
  Je te conseille cet exemple de projet fait par Apple (pour une fois  ) : http://developer.apple.com/library/mac/#samplecode/SourceView/Introduction/Intro.html
  
  Il démontre le chargement/déchargement/switch à  l'aide de NSWindowController et NSViewController et de plusieurs xib.
  Il s'agit d'un petit exemple de pseudo finder avec des fonctionnalités d'exemple spécifiques pas trop mal foutu  xd
• muqaddar Administrateur

  mai 2011 04:50 modifié #8

  Excellent exemple.
  Il va m'apprendre ce que je cherche à  comprendre. Merci !
• Céroce Membre, Modérateur

  mai 2011 04:50 modifié #9

  dans 1304666952:

  
  En fait, je me disais, dans le cas d'une application monofenêtre avec 4  blocs avec des fonctionnalités différentes par exemple, vous instancierez quand-même 4 NSViewControllers et leurs XIBS (pour séparer les morceaux de vues et leurs contrôles)... mais dans ce cas, comment faites-vous pour ajouter la vue1 du XIB du NSViewController 2 à  la fenêtre principale du NSViewController1 (ou de appdelegate) ?
  

  
  On ajoute la vue à  la fenêtre par un simple addSubview:.
  Souvent, j'utilise une NSView vide qui me sert à  délimiter l'emplacement de la sous-vue, et qui est bien pratique pour gérer l'autosizing.
• wisky Membre

  mai 2011 mai 2011 modifié #10

  Pour ma part, je ne diffuse que sur le Mac AppStore quand Apple veux bien valider l'application. Ce qui se révèle parfois complexe (j'ai une app très spécifique).
  Si non, je diffuse gratuitement sur mon site web ou pour faire payer, je n'ai pas encore fait de choix. Mais je penche plus pour le système de l'activation en ligne.
  
  Pour ce qui est de la gestions des vues, tout a été dit. Parfois, et pour m'éviter du code, je n'utilise que le xib MainMenu. Tout est dedans car l'app est mono fenêtre ou elle n'utilise pas beaucoup de fenêtre (2-3 max).
  Compilation 32/64 obligatoire (pour moi) et pour 10.5 uniquement si le projet a été débuté dessus. Maintenant que j'ai 10.6 sur mon MBA je ne développe plus pour les PowerPC (même si mon ordi principal est encore un bon vieux G5 2x2,5GHz). Hé, je suis le mouvement !
  
  Sinon, le bouquin de Hillegass est une superbe base pour revenir et coder sur Mac
• System

  mai 2011 04:50 modifié #11

  Moi le seul truc qui me fait vraiment ch*er sur Mac c'est que si on veut faire un truc aussi joli et animé que sur l'iPhone, il faut activer les layers. Or, l'activation des layers = surplus de consommation mémoire.. vraiment.
  Y'a que Twitter, dans le genre, qui ne consomme quasiment rien.. J'aimerai bien voir son code à  Loren.. Tsss ces anciens de chez Apple
• Céroce Membre, Modérateur

  mai 2011 04:50 modifié #12

  dans 1304850081:

  
  Or, l'activation des layers = surplus de consommation mémoire.. vraiment.
  

  
  Et désactivation du lissage des sous-pixels... le texte devient moche d'un seul coup.
  Par exemple, observez bien l'écran où on tape le mot de passe dans OS X. Quand on tape le mot de passe, le texte est bien lissé. Dès qu'il s'anime, le texte devient plus grossier. C'est parce que la fenêtre passe en mode "Core Animation".
• wisky Membre

  mai 2011 04:50 modifié #13

  dans 1304923143:

  
  

  dans 1304850081:

  
  Or, l'activation des layers = surplus de consommation mémoire.. vraiment.
  

  
  Et désactivation du lissage des sous-pixels... le texte devient moche d'un seul coup.
  Par exemple, observez bien l'écran où on tape le mot de passe dans OS X. Quand on tape le mot de passe, le texte est bien lissé. Dès qu'il s'anime, le texte devient plus grossier. C'est parce que la fenêtre passe en mode "Core Animation".
  

  
  Bien sur et CoreAnimation ne travail pas directement avec la fenêtre mais avec son image écran. Peu remarque ce genre de chose. Il faut travailler avec pour s'en rendre compte
• Céroce Membre, Modérateur

  mai 2011 04:50 modifié #14

  Non, la différence est que quand on active Core Animation pour une vue ou une fenêtre (qu'on active sa "layer" comme dit plus haut par Louka), le dessin ne se fait plus dans un contexte graphique standard mais dans une CGLayer qui ne gère pas le lissage des sous-pixels. Sous iOS, on dessine toujours dans une layer et les sous-pixels ne sont jamais lissés. C'était nécessaire pour permettre la rotation de l'écran.