I'm new to Objective-C, Cocoa, Xcode and Interface Builder. I've got some C background in the past, as well as a fair amount of RealBASIC experience.
I'm working through Mark and LaMarche's iPhone 3 Dev book and I'm really just sort of stunned about how tedious some things are. Maybe someone can shed some light on this for me. My question really is, why does the process for seemingly simple actions involve such a complicated number of steps? Is there a benefit to the complexity which I'll come to love later? Or is it just a brute fact that is unavoidable?
For example, in RealBASIC, if I want a slider's value displayed in a text box, I simply add:
myTextBox.text = mySlider.value
to the slider's Changed event. I can program this in well under 1 minute.
In Xcode/Interface Builder, I have to physically type a declaration for both the text box and the slider, then type a property/outlet declaration for each as well, then create a method declaration and implementation for the ValueChanged even, then set up a (relatively) complicated typecast of the slider's integer value into an NSString using initWithFormat. I then have to return to Interface Builder to link up the controls with the control and method outlets I typed in. I don't see how this can be done in much less than 10 minutes. Maybe 5.
So, what's the benefit of this? Why doesn't Interface Builder automatically create, or at least suggest, control declarations and #property statements, as well as method declarations and implementations? Why can't double-clicking a slider in IB offer you a list of events and offer to automatically insert a skeleton method into your .h and .m file? And why does IB even have to be a separate application?
I'm willing to accept that some of this is my unfamiliarity with all things Xcode, but is this really as efficient as the development environment can be?
My apologies if this is a dead-horse, flame-bait topic with opposing sides on full aggro. If so, please just say "yes, that it is" and move on.
Thanks,
-Rob
A lot of the reasons behind the way IB works will become more clear as you get used to the MVC paradigm.
Once you start using Cocoa Bindings, which update your model when the UI changes and vice versa, you should see an enormous productivity improvement.
I too used to think that Xcode and Interface Builder were unnecessarily complicated, until I worked through a book on both (specifically, Beginning iPhone Development: Exploring the iPhone SDK).
If you're serious about working with Xcode and Interface Builder and are as confused as I was when I started, I highly recommend picking up a book like the one I used. Granted, that was for iPhone development, but I think there is another book by the same publisher (or author) that is straight Mac programming.
Once you work through it and understand what is going on behind the scenes it starts to make a lot more sense. In some ways I prefer IB to things like Expression Blend or XAML for WPF programming in .NET.
Give a book a try and see if it helps :-)
Good luck!
Related
I'm looking for a grid view / table view / spreadsheet-type control for Cocoa and can't seem to find anything that's in any reasonable state.
I've tried using NSTableView but it's not really meant to be a single cell control.
NSCollectionView doesn't seem to be right either.
Any ideas?
While Matt Ball's spreadsheet view (https://github.com/mattball/mbtablegrid/, mentioned above) is several years old, it does still compile on El Capitan. It must be easier as a starting point than working from scratch. There are several forks of the repository, most notable this one that does seem to be actively developed:
https://github.com/pixelspark/mbtablegrid
It seems like it would be better for those interested to pool contributions than create something new!
We now have NSGridView, which is most likely what any future person reading this will want to use.
I've inherited a project that uses ~100 Xcode storyboard scenes. Trying to add to this project has been a nightmare for the following reasons:
My machine (late 2011 Macbook Pro 13inch with non-SSD drive 16GB running 10.8 + XCode 4.4) crawls to a halt on storyboards. In some cases I'll move a scene and it will take 10 seconds to update its position.
When I modify a scene (create a segue between two scenes, etc) in some cases all the scenes disappear. I have to do a "select all" on the sidebar to get them back.
Navigating a specific storyboard scene is absolutely frustrating. There's no apparent way to sort the storyboard scenes by name.
The filter feature below the scenes sidebar kind of lets me find the scene I'm looking for, but has the frustrating side effect of filtering out the attributes (segues, views, etc) of the specific scene I'm looking for. So if I need to modify the "add_new_guy" segue for "Person View Controller", and I type "Person" in the filter, I get the Person View Controller sans the add_new_guy segue. If I delete the text in the filter to make the segue appear, I'm taken back to the top of the scene list and (most likely) away from the Person View Controller at the other end of it. I end up scrolling all the way down the scene list manually looking for the specific scene I want to change.
I've spent hours googling solutions and nothing useful has appeared. Any suggestions on how to improve the storyboards situation or pointers to things in XCode I've stupidly overlooked?
Disclaimers:
a) I am well aware that moving to nibs would solve the problem and 100 storyboard scenes is nuts, but I've inherited the code and I'm expected to do storyboards for at least the next year.
b) I'm aware that it's possible to split out the project into several storyboards. I might look into this if I have time.
c) I've heard that some problems may be caused by having two storyboards open at once, which I've tried to avoid as much as possible.
d) Filing a bug with Apple's regarding storyboards is already on my to-do list.
First, work on splitting your storyboard up into smaller storyboards. I would recommend a maximum of 4-5 view controllers per storyboard. It will be a giant headache at first, just work on it over time. Take a look at RBStoryboardLink, which allows you to connect them "by allowing 'pseudo-segues' between UIStoryboards. These segues can be built without leaving Interface Builder and without writing any extra code". This will give you:
The ability to make abstract super classes in storyboards for very similar view controllers
Smaller, more manageable files that don't bring your computer to a halt
Fewer merge conflicts when working as part of a team (assuming your project is under version control)
Second, tell your boss to immediately purchase you a new, way better development computer. They'll make back the $3-$4k in more efficient development time in a matter of days. (Or, if this is contract work… buy a new one yourself.)
And, please indulge my slightly off-topic comment.
Regarding this statement:
I'm expected to do storyboards for at least the next year
Work expectations are always negotiable. Your boss likely thinks "switching from storyboards to code will cost more time than it will save." If this isn't true, say so.
I've done quite a bit of Cocoa programming, both on OS X and iOS, and I've gained quite a bit of experience on what works, and what doesn't, with regards to how things generally fit together. However, there are still a lot of aspects of Cocoa architecture that aren't quite clear, and I'm wondering if there may be some sort of guide/book/etc. explaining how some of those things work.
For example, one I've come across recently:
Setting up a NSViewController and binding its 'representedObject' to the 'selection' of a NSArrayController, then binding UI elements to that representedObject, doesn't work. Why not? What's the best way to handle that situation? I ended up setting the NSArrayController as its representedObject but that seems off - is that a bad design?
There are a lot of other small things as well that I've wondered about in the past - things like how best to set up custom views. (I actually used to create a blank NSView in Interface Builder, then create my custom view in code and set it as the subview of that view!) Cocoa is incredibly flexible, and there are a lot of ways to accomplish the same thing, but clearly some of them, like that, can cause problems down the road.
There are a lot of reference materials on the Apple developer site that I haven't had the time to go through, and I'm sure a lot of this is covered in various documents, but sometimes a third-party resource can be helpful and can also bring up situations that aren't covered in the main documentation. Any thoughts?
I don't know if it answers your specific questions or not, but Cocoa Design Patterns by Buck and Yacktman is good on why experienced Cocoa developers do things a particular way.
Originally, I wanted to ask how to create user interfaces with cocoa programmatically, i.e. without using interface builder. But it seems that someone else has already asked this question and the answers didn't help me.
So I'll ask a different question, that I hope will indirectly help me answer the previous question. Here it is:
(QUESTION_START)
How do I create an Objective C class that is equivalent in functionality with the BoxLayout class in Java? (Just click the link, the image on that page says everything you need to know about BoxLayout.)
(QUESTION_END)
Any help in the right direction will be appreciated!
There are a few sub tasks that are connected with the question, e.g.
"How do I ask a user interface element (e.g. a button) how large it wants to be" (before it has been drawn to the screen). To draw it on the screen you have to already know its size, don't you? Obviously, the interface builder application has figured out a way to do this.
I know that many Cocoa developers think it's a stupid idea to even try what I want to do. Let me tell you: I know the reasoning behind that opinion. Right now, laying out controls without interface builder sucks, because there is nothing that comes even close to a layout manager in cocoa. But if you think my question is stupid, please DONT answer. The whole internet is full of explanations why you would never want to create UIs with code in cocoa.
Thanks!
Answering your first question is kind of difficult and fairly involved, so I'm going to dive into your subquestion first:
How do I ask a user interface element (e.g. a button) how large it wants to be?
When you create a UI element, you tell it how big it should be (as well as where it should be) via its initWithFrame: constructor; or you can set its frame later via its setFrame: method. It will then draw itself into that space. You can get an element's frame via its frame method.
With that in mind, a BoxLayout class would, hypothetically, be a controller of some sort in which you could add UI elements, and then the BoxLayout controller would arrange them in a grid (or whatever) on an NSView of some sort.
I know you weren't looking for answers that questions motives, but given the complexity of a BoxLayout class vs. laying out the interface in IB, it seems relevant to ask why you want to do this.
I'm trying to create a very simple selection list widget based on NSOutlineView. However, I'm having a hard time figuring out how to display an icon and a label right next to it, which is really the expected behavior in all the mainstream implementations of that kind of widget out there (iTunes, mail, Finder,...).
So far I am just binding two separate cells, but then when I'm expanding the tree, the icon cell grows larger and a gap appears between the icon and its accompanying label. I know I can probably overcome this problem by extending NSCell and provide a custom class, but as what I'm trying to achieve is really the standard thing, I can't be resigned to accept that there isn't a simpler solution.
Candide
Sadly, there isn't a 'text and icon' cell that you can just use, fresh out of the box as you would like. However, when I was working on a project, I found that Apple released some sample code that implements this, since it is such a common idiom.
This can be found here, specifically ImageAndTextCell.h/m
It can help teach you about UI customization by reading through this example, but scratching that, just dropping the ImageAndTextCell straight into your project should do just fine.
You need to create ImageAndTextcell to combine text and icon..
you can create ImageAndTextcell like this Sample Project