Comment puis-je créer Cacao interfaces sans Interface Builder?

Je préfère créer mes interfaces en programmant. Me semble que si tous les docs sur l'Apple Developer supposons que vous êtes en utilisant l'Interface Builder. Est-il possible de créer ces interfaces par programmation, et si oui, où dois-je commencer à apprendre sur la façon de le faire

Je pensais que le document pertinent pour ce, si possible, serait dans cette section: http://developer.apple.com/referencelibrary/Cocoa/idxUserExperience-date.html

  • "Je préfère créer mes interfaces en programmant" +1 pour ce faire, vous rock.
InformationsquelleAutor Bjorn Tipling | 2009-04-04
  1. 23

    Je préfère créer mes interfaces en programmant.

    Pourquoi? Interface Builder est plus facile et plus rapide. Vous ne pouvez pas écrire une faute de frappe par glisser-déposer, et vous n'obtenez pas ces oh-so-pratique de l'Aqua guides lorsque vous êtes en train de saisir des rectangles à la main.

    Ne pas lutter contre elle. Interface Builder est votre ami. Laisser vous aider.

    Si vous insister de perdre votre temps et d'énergie de la rédaction de votre INTERFACE utilisateur dans le code:

    Pas basés sur des documents (généralement bibliothèque de base, comme le Mail, iTunes, iPhoto): Créer une sous-classe NSObject, instancier et d'en faire la demande à son délégué, et le délégué du applicationDidFinishLaunching: méthode, créer une fenêtre, de le remplir avec des points de vue, et de l'ordre de l'avant.

    Basés sur des documents (comme TextEdit, Aperçu, de QuickTime Player): Dans le makeWindowControllers méthode dans votre sous-classe de NSDocument, créer votre windows (et les remplir avec des points de vue) et de créer une fenêtre de contrôleurs pour eux, faire en sorte d'envoyer vous-même addWindowController: pour chaque fenêtre contrôleur.

    • Amen. J'ai utilisé pour être que "tout écrire moi-même" état d'esprit. Ensuite, j'ai appris ce que signifiait pour respecter les délais du projet. C'est une véritable révélation.
    • J'ai le triple. Fait intéressant, j'ai eu un peu de développeurs venant du monde Java récemment également dire qu'ils préfèrent le code de l'interface d'eux-mêmes... droit jusqu'à ce qu'ils ont compris que l'IB ne génère pas de code et de ne pas en avoir besoin. Suppose que l'IDE généré code swing vraiment chouette 🙂
    • "Vous ne pouvez pas écrire une faute de frappe par glisser-déposer" en fait, j'ai découvert, vous pouvez.. j'ai causé bizarre à l'application de s'écraser erreurs par accidentellement glisser sur la mauvaise prise ou de liaison. Interface Builder est correct, mais il n'est pas infaillible (pour ne pas dire la création d'interfaces à la main est mieux, mais si rien d'autre ne les erreurs dans ObjC sont un peu plus évident..)
    • btw, Apple évite d'utiliser de l'IB trop: lapcatsoftware.com/blog/2008/10/20/...
    • yairchu: Hein? Ce lien n'apparaît pas à l'appui de votre demande. Soin d'expliquer davantage?
    • Je serais volontiers utilisation de l'IB si ce n'était pas si terrible à comprendre. Certes, j'essaie d'apprendre par moi-même - mais il me semble contre-intuitif. En fait Xcode lui-même semble juste comme un horrible IDE. Je suis juste utilisé pour Visual Studio, je pense.
    • Interface Builder est fantastique... tant que vous ne jamais s'attendre à l'application que vous êtes en train de créer pour s'exécuter sur un produit Apple. Si vous voulez une application qui s'exécute de la même manière sur d'autres plates-formes, puis à l'aide de l'IB est la façon de perdre du temps.
    • Tout le code de l'interface que vous écrivez dans le Cacao ou Cocoa Touch ne fonctionne pas partout ailleurs, soit. Si vous utilisez un framework cross plate-forme comme Qt, alors oui, vous ne pouvez pas utiliser des plumes.
    • droit, ou si vous souhaitez écrire votre propre croix-plate-forme de code en C++ qui utilise Objective-C(++) juste pour l'interface de Cacao. En général je suis d'accord que si vous souhaitez créer des applications Mac, à l'aide de l'IB est généralement la meilleure approche, mais il y a aussi de nombreux scénarios où ne pas l'utiliser serait la meilleure approche.
    • Le n ° 1 de raison de ne pas utiliser de l'IB n'est pas tout le monde est le Cacao. Si votre cible inclut Windows ou Unix, tout travail que vous faites avec Mac outils de a à faire à nouveau de toute façon. La 2e raison est que tous les projets sont nouveaux. Le minimum de l'étape de continuer à utiliser le code existant shoudln pas commencer avec le remplacement de l'intégralité de l'INTERFACE utilisateur.
    • Toute l'INTERFACE utilisateur que vous écrivez dans le Cacao, le code n'est pas destiné à être partagé avec toutes les autres plateformes de toute façon. Vous avez certainement ne pas utiliser de l'IB à rendre un non-Cacao de l'interface, mais ce n'était pas la question. Comme pour le #2, je suis d'accord avec vous sur ce point.
    • Mon sentiment est que IB est très utile si vous développez une application qui utilise beaucoup de contrôles standard, surtout si vous il est nécessaire de ré-organiser les contrôles dans le cadre de la conception/dev processus. Il commence à obtenir de la manière de moi quand j'ai beaucoup de contrôles personnalisés ou dans les cas où les contrôles standard sont déplacés ou cachés deviennent visibles dans le cadre de la conception de l'INTERFACE utilisateur.
    • Ad "Document de base" - s'il vous plaît regardez ma question est stackoverflow.com/questions/10373304/... - je suis désolé de poser cette façon mais j'ai été incapable de trouver votre contact.
    • vous ne pouvez pas fusionner plume de...
    • Aveugles, les développeurs ne peuvent pas utiliser Xcode.
    • Très bon point. Austin Seraphin a touché un peu de temps sur son blog: behindthecurtain.nous/2012/10/04/rubymotion-roches behindthecurtain.nous/2013/01/10/rubymotion-et-accessibilité behindthecurtain.nous/2013/04/17/inspectez-2013
    • Ce n'ai pas la réponse à la question des personnes à tous. Juste parce que vous pensez que vous ne devriez pas écrire votre propre code ne veut pas dire que les autres sont d'un avis différent. Dans de nombreuses situations, vous pourriez avoir besoin de plus de contrôle sur votre INTERFACE utilisateur de l'interface builder vous donne et il n'est tout simplement pas possible d'obtenir exactement ce que vous voulez avec elle. Aussi, de savoir comment la couche d'INTERFACE utilisateur fonctionne parce que vous avez la main codé tout ça va vous aider dans la compréhension de la manière dont l'IB travaille. Semblable à un programmeur C ayant une certaine expérience/connaissance de la façon dont le matériel fonctionne réellement ou d'un programmeur Java ayant une expérience avec le C++.
    • ne pas répondre à la question des personnes à tous.” Sauf pour les deux derniers paragraphes, où j'y ai répondu.
    • Hosey Temps pour moi de mettre mon pied dans ma bouche. Il ne mentionner brièvement l'approche générale pour la création d'applications à interface graphique sans IB.
    • "Ne fais pas cela" n'est pas une réponse à la question. Laisser la politique de pourquoi quelqu'un devrait ou ne devrait pas faire quelque chose à une autre question, à moins que c'est dangereux.

    InformationsquelleAutor Peter Hosey
  2. 36

    J'aime la question, et j'aimerais aussi savoir de ressources pour aller de l'IB-moins. De l'utilité (le "pourquoi") est limitée que par l'imagination. Sur le dessus de ma tête, voici quelques raisons possibles du programme de l'Isu explicitement:

    • Mise en œuvre d'une meilleure Interface Builder.
    • De programmation dynamique de l'Isu, c'est à dire, ceux dont la structure n'est pas connaissable de manière statique (à la compilation/xcode temps).
    • La mise en œuvre du Cacao, dans le back-end d'une croix-plate-forme de bibliothèque ou de la langue de l'Isu.

    Il y a une série de billets de blog sur de travail sans une plume et une description récente de Michael Mucha sur le cacao-dev.

    • J'aime la question de trop. En fait, je me demande comment l'on a accepté la réponse est fondamentalement que votre un idiot si vous voulez faire de cette façon. Je suis juste allé xib-moins pour une application iOS (ce tutoriel a beaucoup aidé: vimeo.com/3363949 ) et je suis maintenant à la recherche de faire de même sur le bureau.
    • Voici une mise à jour du lien vers le blog depuis le lien ci-dessus prend juste la page principale: lapcatsoftware.com/blog/2007/05/16/working-without-a-nib-part-1
    • Merci, @MattB. J'ai mis à jour ma réponse à inclure l'URL directe que vous avez trouvé.
    InformationsquelleAutor Conal
  3. 19

    Complètement aveugle développeur, je peux dire que l'IB n'est pas compatible avec VoiceOver (le haut-lecteur d'écran sous mac OS X).

    Cela signifie que, sans accès à la solide documentation sur l'utilisation de Cacao sans IB je ne peux pas développer des applications pour OS X /iPhone dans le Cacao, ce qui signifie que j' (ironiquement) ne peut pas développer facilement des applications qui sont accessibles aux aveugles (et tous les autres) sur OS X /iOS.

    Ma solution actuelle, que je préfère ne pas utiliser, est Java + SWT, bien sûr, cela fonctionne pour OS X, pas tellement pour iOS.

    • Je pense que la documentation est là. Ce n'est pas dans le howto qui suce. :/
    • Wow, je suis en admiration!
    • Pour iOS, il y a eu un certain succès à l'aide de tasse de thé de construire de l'Isu (Austin Seraphin au moins l'a utilisé avec succès). github.com/rubymotion/teacup
    InformationsquelleAutor Everett Zufelt
  4. 4

    En fait de l'IB devient totalement inutiles lorsque vous commencez à écrire vos propres classes de l'INTERFACE utilisateur. Disons que vous créer votre propre bouton qui utilisent une peau système basé sur un fichier plist. Ou vous créer une dynamique de la barre d'outils de charger et décharger les éléments de base de la sélection de l'utilisateur.

    IB n'accepte pas les éléments d'INTERFACE utilisateur personnalisés, de manière plus complexe de l'INTERFACE utilisateur ne peut pas l'utiliser. Et OUI, vous voulez faire des choses plus complexes que la UIKit vous donne.

    • Vous pouvez certainement créer votre propre IB éléments. developer.apple.com/mac/library/documentation/DeveloperTools/...
    • La lumière au bout du tunnel!! Les œuvres de l'IB sur iPhone trop?
    • Nice post sur ce sujet: cocoawithlove.com/2009/07/... . Et je ne suis pas encore sûr, mais cette technique ne fonctionne pas sur iPhone encore. 🙁
    • Vous pouvez utiliser IB_DESIGNABLE et IBInspectable maintenant à partir de Xcode 6. IB_DESIGNABLE signifie que votre vue personnalisée sera rendu au bureau de l'IB et IBInspectable sur une propriété signifie que vous pouvez définir la valeur de la propriété de l'IB.
    InformationsquelleAutor Paulo
  5. 3

    Bien que cela se calme un peu vieux...
    J'ai essayé plusieurs fois de le faire tout seul avec de la programmation. C'est difficile, mais possible.

    Mise à jour:
    J'ai posté une autre question pour ce problème spécifique: Selon la vue NSOutlineView sans PLUME?, et maintenant
    Je crois que tout peut être fait de manière programmatique, mais c'est incroyablement dur sans la consultation d'Apple ingénieurs en raison du manque des informations ou des exemples.

    Ci-dessous argument pourrait être hors-sujet, mais je tiens à noter pourquoi je préfère par programmation façon.

    Je préfère aussi par programme. Parce que

    • Statique de la mise en page de l'outil ne peut pas gérer quoi que ce soit dynamique.
    • Reproduction même INTERFACE utilisateur de l'état à travers de multiples Pointes est dur. Tout est implicite ou cachée. Vous avez besoin de visiter tous les panneaux de trouver paramètres. Ce genre de travail est très facile de faire l'erreur - erreur amical.
    • La gestion cohérente de l'état est dur. Parce que de reproduire le même look est dur.
    • Automatisation impossible. Vous ne pouvez pas faire de l'auto-générés formulaire de saisie.
    • Paramètre indirection comme la variable taille de l'élément choisi par l'utilisateur n'est pas possible.
    • Visant petit point est beaucoup plus difficile que de frapper le doigt touches de taille à emplacement fixe - c'est drôle que ce grave problème de convivialité pour les développeurs!
    • IB parfois vis. Ce qui signifie qu'il est compilable, et travaille encore, mais quand j'ai ouvert la source, il semble cassé et de supplémentaires de montage devient impossible. (vous ne pouvez pas vécu cela, mais si XIB fichier passe complexe, ce qui doit arriver)
    • C'est de l'image en fonction de sérialisation. Le concept est bon. Mais le problème, c'est l'image de la base de seulement. L'IB ne garde pas le code source pour nettoyer le démarrage, en relisant le code source. Nettoyer le démarrage est très important pour garantir spécifique de l'état. Aussi, nous ne pouvons pas corriger les bugs dans le code source. Bug juste à empiler à l'infini. C'est la raison principale pourquoi nous ne pouvons pas reproduire le l'égalité des(pas semblable à la recherche) de l'INTERFACE utilisateur de l'état de l'IB.

    Bien sûr, ces étoffes peuvent être résolus par le post-traitement PLUME de l'INTERFACE utilisateur, mais si nous avons de tout configurer nouveau, il n'y a pas de raison d'utiliser de l'IB au premier abord.

    Avec le texte du code, il est facile de reproduire le même état, il suffit de copier le code. Aussi facile à inspecter et à la fixation de mal partie - parce que nous avons le plein contrôle. Mais de l'IB, nous n'avons aucun contrôle sur le noyau dur de détails.

    De l'IB ne peut pas être la solution ultime. C'est comme un Photoshop, mais même Photoshop propose de texte à base de script. GUI est un déplacement de programme, et non pas une image statique ou graphique. Un IB approche est complètement faux, même pour l'édition visuelle de l'interface graphique. Si vous êtes l'une des Apple des gens de cette lecture, je vous prie de supprimer toute dépendance à l'IB complètement dès que possible.

    InformationsquelleAutor Eonil