I would prefer to create my interfaces programatically. Seems as if all the docs on Apple Developer assume you're using Interface Builder. Is it possible to create these interfaces programatically, and if so where do I start learning about how to do this
I thought the relevant document for this, if possible would be in this section: http://developer.apple.com/referencelibrary/Cocoa/idxUserExperience-date.html
I like the question, and I'd also like to know of resources for going IB-less. Usefulness (the "why") is limited only by imagination. Off the top of my head, here are some possible reasons to program UIs explicitly:
Implementing a better Interface Builder.
Programming dynamic UIs, i.e., ones whose structure is not knowable statically (at compile/xcode time).
Implementing the Cocoa back-end of a cross-platform library or language for UIs.
There is a series of blog posts on working without a nib and a recent description by Michael Mucha on cocoa-dev.
I would prefer to create my interfaces programatically.
Why? Interface Builder is easier and faster. You can't write a typo by drag and drop, and you don't get those oh-so-handy Aqua guides when you're typing rectangles by hand.
Don't fight it. Interface Builder is your friend. Let it help you.
If you insist on wasting your own time and energy by writing your UI in code:
Not document-based (generally library-based, like Mail, iTunes, iPhoto): Create a subclass of NSObject, instantiate it, and make it the application's delegate, and in the delegate's applicationDidFinishLaunching: method, create a window, populate it with views, and order it front.
Document-based (like TextEdit, Preview, QuickTime Player): In the makeWindowControllers method in your subclass of NSDocument, create your windows (and populate them with views) and create window controllers for them, making sure to send yourself addWindowController: for each window controller.
As a completely blind developer I can say that IB is not compatible with VoiceOver (the built-in screen-reader on OS X).
This means that without access to robust documentation on using Cocoa without IB I cannot develop apps for OS X / iPhone in Cocoa, which means I (ironically) cannot easily develop apps that are accessible to the blind (and all others) on OS X / iOS.
My current solution, which I would prefer not to use, is Java + SWT, of course this works for OS X, not so much for iOS.
In fact IB becomes totally unusefull when you start to write your own UI classes. Let say that you create your own button that use an skin system based on a plist. Or you create an dinamic toolbar that load and unload items based on user selection.
IB doesn't accept custom UI elements, so more complex UI can't use him. And YES you will want to do more complex things that the UIKit gives you.
Though this is quiet a bit old...
I tried many times to do everything only with programmatically. This is hard, but possible.
Update:
I posted another question for this specific issue: View-based NSOutlineView without NIB?, and now
I believe everything can be done in programmatical way, but it's incredibly hard without consulting from Apple engineers due to lack of information or examples.
Below argument might be off-topic, but I like to note why I strongly prefer programmatically way.
I also prefer programmatic way. Because
Static layout tool cannot handle anything dynamic.
Reproducing same UI state across multiple NIBs is hard. Everything is implicit or hidden. You need to visit all the panels to find parameters. This kind of job is very easy to make mistake - mistake friendly.
Managing consistent state is hard. Because reproducing same look is hard.
Automation impossible. You cannot make auto-generated input form.
Parameter indirection - such as variable element size chosen by user - is not possible.
Aiming small point is a lot harder than hitting finger sized keys at fixed location - funny that this is serious usability issue for developers!
IB sometimes screws. Which means it's compilable, and still working, but when I open the source, it looks broken and extra editing becomes impossible. (you may not experienced this yet, but if XIB file goes complex, this must happen)
It's image based serialization. The concept is good. But the problem is image-base only. IB doesn't keep the source code for clean boot by replaying the source code. Clean boot is very important to guarantee specific running state. Also, we cannot fix the bugs in source-code. Bug s just will be stacked infinitely. This is core reason why we cannot reproduce the equal(not similar looking) UI state in IB.
Of course these stuffs can be solved by post-processing NIB UI, but if we have to configure everything again, there's no reason to use IB at first.
With text code, it's easy to reproducing the same state - just copy the code. Also easy to inspecting and fixing wrong part - because we have full control. But in IB, we have no control on hard-core details.
IB can't be ultimate solution. It's like a Photoshop, but even Photoshop offers text-based scripting facility. GUI is a moving program, and not a static image or graphic. An IB approach is completely wrong even for visual editing of GUI. If you're one of the Apple folks reading this, I beg you to remove whole dependency to IB completely ASAP.
Related
Im new to iPhone development. I come from web-development/design and what bothers me in iPhone development is the unability for custom design... In other words... is there any way I could design my user interface (my view) with webkit so all my UI elemnts would be writen in html/css and logic in objective-c. I was thinking if there is a way I could triger some objective-c code when html button is pressed. Is there any way to do that (lets say via "localhost request" or I dont know) ?
BUT not with phonegap or similar, because then you just start writing your logic in javascript and i dont want that... I want my controller and model to be written in objective-c just the view module in html!
Look into PhoneGap. It has all of the abilities you specify, and can work on Android and other's too (of course you'd need to write the native logic in Java and other languages for that to work though).
The other responders are correct in that efficiency is a big concern, as all of your logic is gated on the Web/native interface. The UIWebView performs a LOT of it's duties on a single thread, and any of your interactions with it must as well.
If you really want to do this, however, there are solutions... Intercepting events from the UIWebView via delegate methods (such as shouldStartLoadWithRequest) that follow a protocol that you define can be used, but I'd suggest either doing everything in JS (trust me, it will actually be faster), or just bite the bullet and learn native iOS development more.
I'm in the process of creating an OSX application to be used by professionals, and want to adopt the dull/gray look of Final Cut Studio and other professional-use applications. I want the interface to be toned down, to be less distracting while trying to create the rich content, probably similar to Apple's rationality, and I think is justification to break away from standard HIG.
I was wondering if anyone has done something similar, and has any pointers or examples.
Thanks :)
The look and feel of Apple's "pro" applications is defined in ProKit, which is a private system framework located in the system PrivateFrameworks folder. ProKit extends several of the AppKit classes such as NSWindow and NSButton with NSProWindow, NSProButton, etc. Because ProKit is private, Apple can change it at any time without notice, so you should always be cautious when using it.
I'm trying to re-write an old image-viewing plugin for the mac. The old version uses QuickDraw (I said it was old) and resources (really really old) and so it doesn't work in Firefox 3.6 (which is why I'm re-writing it)
I know some Objective C, and so I figure I'm going co re-write this in that using new-fangled Mac routines and nibs, etc. However, I don't know how to start. I've got the BasicPlugin example that comes with mozilla source, so I know how to create a plugin with entrypoints, etc. However, I don't know how to create the nib, and how to interface Obj-C with the entrypoints, etc.
Does anyone know of a more advanced sample for mac than BasicPlugin.bundle? (Preferably simple enough that I can just look at it and understand it...)
thanks.
Sadly i don't really know of any good "intermediate" example. However, integrating Obj-C isn't that difficult. Thus, following is a short overview of what needs to be done.
You can use Obj-C and C/C++-sources in the same project, its just recommendable to keep them seperated to some extent. This can for example be done by letting the source file with the entry-points and other NPAPI-interfacing stay plain C or C++ files and e.g. forward calls into the plugin from there.
Opaque pointers help to keep a clean seperation, see e.g. here.
The main changes to your plugin include switching to different drawing and event models. These have to be negotiated in NPP_New(), here is an example for the drawing model. When using Cocoa and to support 64bit enviroments, you need to use the Cocoa event model.
To draw UI elements you should be able to use a NSGraphicsContext from the CGContextRef and then draw an NSView in the context. See also the details provided in this post and its follow-ups.
I've started programming on Mac OS X in Objective-C and decided to create a little card game. At first I create a command line version. If everything works fine I would like to implement a GUI: Nothing big, just a green window with cards which can be dragged and dropped.
Since I don't have any idea about how to do this: What can I use to implement my card game GUI?
Since Objective-C and Cocoa looks like a "bundle" on Mac OS X, is it possible to use Cocoa for this (and how)? If not, what else should I use or is there already sth. like this?
Regards,
inno
Apple has some sample code here that could point you in the right direction.
This is a fine study in MVC.
Your Model (an active game, player and non-player characters, the cards in the game, etc.) will be entirely in Foundation, at least at first. You can add AppKit-dependent properties such as images later, and use the C preprocessor to conditionalize that code if you want to continue maintaining your command-line program.
Your Controllers will also generally be in pure Foundation. I say “Controllers” because you'll have one for both programs (owning the model, responding to user actions, and running the game—that is, dealing cards, enforcing the rules, etc.), one specifically for the command-line program (holding the readline/output loop), and at least one specifically for the GUI program (owning the game window).
In the GUI app, you'll write your Views with AppKit, of course. In the command-line app, you may want to make a View class, separate from the Controllers, to make it easy to radically change the output quickly (even at runtime, if you want to allow that). Of course, that View will not descend from NSView, and will use terminal output instead of graphical drawing.
I recommend keeping the command-line version of the program alive after you make the GUI version, at least for a little while. You'll know you're doing it right when you can maintain both working versions of the program without much fuss, and even find a bug in one version of the program and fix it in both.
I'm a complete Xcode/Objective-C/Cocoa newbie but I'm learning fast and really starting to enjoy getting to grips with a new language, platform and paradigm.
One thing is though, having been using Visual Studio with R# for so long I've kind of been spoiled with the coding tools such as refactorings and completion etc and as far as I can tell Xcode has some fairly limited built in support for this stuff.
On that note, does anyone know if any add-ins or whatever are available for the Xcode environment which add coding helpers such as automatically generating implementation skeletons from a class interface definition etc?
I suspect there aren't but I suppose it can't help to ask.
You sound as if you're looking for three major things: code templates, refactoring tools, and auto-completion.
The good news is that Xcode 3 and later come with superb auto-completion and template support. By default, you have to explicitly request completion by hitting the escape key. (This actually works in all NSTextViews; try it!) If you want to have the completions appear automatically, you can go to Preferences -> Code Sense and set the pop-up to appear automatically after a few seconds. You should find good completions for C and Objective-C code, and pretty good completions for C++.
Xcode also has a solid template/skeleton system that you can use. You can see what templates are available by default by going to Edit -> Insert Text Macro. Of course, you don't want to insert text macros with the mouse; that defeats the point. Instead, you have two options:
Back in Preferences,go to Key Bindings, and then, under Menu Key Bindings, assign a specific shortcut to macros you use often. I personally don't bother doing this, but I know plenty of great Mac devs who do
Use the CompletionPrefix. By default, nearly all of the templates have a special prefix that, if you type and then hit the escape key, will result in the template being inserted. You can use Control-/ to move between the completion fields.
You can see a full list of Xcode's default macros and their associated CompletionPrefixes at Crooked Spin.
You can also add your own macros, or modify the defaults. To do so, edit the file /Developer/Library/Xcode/Specifications/{C,HTML}.xctxtmacro. The syntax should be self-explanatory, if not terribly friendly.
Unfortunately, if you're addicted to R#, you will be disappointed by your refactoring options. Basic refactoring is provided within Xcode through the context menu or by hitting Shift-Apple-J. From there, you can extract and rename methods, promote and demote them through the class hierarchy, and a few other common operations. Unfortunately, neither Xcode nor any third-party utilities offer anything approaching Resharper, so on that front, you're currently out of luck. Thankfully, Apple has already demonstrated versions of Xcode in the works that have vastly improved refactoring capabilities, so hopefully you won't have to wait too long before the situation starts to improve.
I'm excited to say that JetBrains have decided to make a decent IDE for Objective-C coders.
It's called AppCode and it's based on their other tools like RubyMine and Resharper. It's not native Cocoa, but has loads of raw refactoring power.
http://www.jetbrains.com/objc/index.html
I've started using it for my main Objective C project and I'm already in love. It's still in it's infancy, but for code editing and refactoring it already blows Xcode away.
Update
It's now at a totally usable speed. I've switched over to it full time and it still blows my mind how amazing refactoring and coding is compared with Xcode. It just handles so much for you - auto importing, almost infinite customisation. It makes Xcode look like a toy.
Xcode has refactoring for C and Objective-C built in. Just select what you'd like to refactor, choose "Refactor..." from either the menu bar or the contextual menu, and you'll get a window including the available refactorings and a preview area.
Xcode doesn't currently have a public plug-in API; if there are specific types of plug-ins you'd like Apple to enable, file enhancement requests in the Bug Reporter. That way Apple can count and track such requests.
However, there are third-party tools like Accessorizer and mogenerator (the latest release is mogenerator 1.10) that you can use to make various development tasks faster. Accessorizer helps you create accessor methods for your classes, while mogenerator does more advanced code generation for Core Data managed object classes that are modeled using Xcode's modeling tools.
Just so people know, Accessorizer does more than just generate accessors (both 1.0 and properties for 2.0) it also generates Core Data code for persisting non-standard attributes, your NSSet accessors for custom to-many relationships.
In fact, Accessorizer will help provide you with the init, keypath, keyed-archiving, indexed accessors, accessors for unordered collections such as NSSet, copyWithZone, KVO, key-validation, singleton overrides, dealloc, setNilForKey, non-standard attribute persistence (Core Data), locking, headerdoc, convert method to selector, NSUndoManager methods and more.
I found some xtmacro files in Xcode.app package:
/Developer/Applications/Xcode.app/Contents/PlugIns/TextMacros.xctxtmacro/Contents/Resources
Installed Xcode ver. 3.2.5.