I am deciding whether to use or not XIB files in my solution. In previous versions of monotouch and Interface Builder, i chose to go xib-less but now with xcode 4 integration, IB seems more user friendly, and the fact that all the UIViewController/UIView class templates in Monotouch create a xib file. Also, most of the new monotouch tutorials and examples suggest that we use IB.
Can someone point me in the right direction ? Are there any situations in which is best not to use XIB files ?
XIB files can still be slow to load if you put too much content in them that needs to be loaded at startup. I generally avoid XIB files because they do not do much in terms of improving my developer experience.
That said, with iOS 5, they introduced Storyboards which allow you to design your application flow from a single place and it will then break down the storyboards into XIB files that have been tuned to only load what you need per screen.
Storyboards in my opinion do bring significant value that you did not really get with XIB files and are worth using.
Related
In older versions, it was a "Use Storyboards" button when creating a Cocoa app that determines whether to create a storyboard file or a xib one, but now I can't find it.
Because it isn't there. It is superfluous. Just make your Cocoa project and get started. If you then want to make a xib, make one. If you want to make another storyboard, make one.
If you want to write an application that uses no storyboards at all but uses a main nib as in the old days, then make an Application xib file or a MainMenu xib file and point the target's Main Interface setting at it, and delete the default storyboard. (I just wrote an application that works that way, and it was no trouble at all. Just watch out because a modern xib has "Prefer coder" turned on by default, which may come as a surprise to an old AppKit fogie like myself.)
This is a best-practices question.
When one makes a new Swift application for OSX, it builds a Main.storyboard and places that physically in the Base.lproj folder, but logically within the app's main "group".
I decided to separate different parts of the UI into different storyboards, so I added a Document.storyboard and Preferences.storyboard.
In retrospect it's not clear if this was the correct way to do this - for items that consist of a single window or view, should I use storyboards or just use XIBs? I've read the Apple documents but I'm not clear on the practical differences. Are storyboards "replacing" XIBs, are they the new hotness that I should use from now on?
Now I will be expanding the project with additional views, specifically a series of sheets used for editing certain features of the document. Should I put these all in a single storyboard, one XIB, or individual XIBs? Is there any strong reason to select one over the others?
And finally, when I added my storyboards, it placed them in the root of the project folder. Should these really be moved to Base.lprog?
This is something I've been thinking about, too. I've recently gotten into OS X development, so I'll share my amateur view of XIBs vs storyboards. To those of you that are more familiar with this, feel free to correct me if I'm mistaken.
Interface Builder inside Xcode seems to do a pretty good job of allowing you to put a skeleton in place, but doesn't always provide all the necessary customization options for a view. When using storyboards, I frequently end up with projects that are half visually based, and half code. It's like working on a cyborg.
Nibs/Xibs suffer from the same problem, but they don't even try to implement transitions. From what I can tell, they represent single windows, views, or menu items. This makes them simpler and more modular. You get to write the code that handles the wiring of them together, and, at first, it may seem like more trouble, but it actually feels like a benefit to me because of the level of control gained. Storyboards can do a lot of this for you, but I personally tend to prefer having it all together in the code.
The ideal solution, to me, would be for Apple to implement a more abstract form of user interface design: where each window (or iOS view, depending on the platform) was contained in a nib, and a Storyboard was only a transition mapping between the nibs. For example: You create all your windows and menus, and then use the storyboard to connect them all, but the storyboard can't edit any of the views details, only transitions and connections.
That being said, I'm quickly getting to the point where I prefer nibs and do all the other coding myself. If nothing else, I'm becoming a better programmer for it. Hope this helps!
What is advantage and disadvantage not using storyboard and xib.
I am building an application without using storyboard and xib, what happen if project is build programatically.
Storyboards dont only speed up development, but they also help identify UX issues and get an overview of the current UX of an application.
Software should be built with the future in mind and the storyboard allows an entry point into the project for other developers or designers, as well as yourself, if you for some reason left the project for a while.
Having everything in code or even xib files wastes time, even great documentation is slower to process that a visual layout of the apps UI.
Xibs on their own can cause design issues.
For performance, storyboards are optimized.
Overall as the name suggests, its the visual story or flow for your app. You should also split different functionality of your app into different storyboards e.g. if you have a side menu that loads different view stacks, use different storyboards as needed.
Obviously its not 1 or the other with storyboards and code, it depends on the situation, you might even use a xib here and there. Software is dynamic and new ideas come about, not all have fixed solutions, that would be boring.
Just last week I decided to dive into the world of Swift and Xcode development, and as of yesterday I am actively working on a new application. I have a lot of experience with Java Swing, but working with that is obviously a lot different than working with Apple's fancy interface builders and storyboards.
I am trying to develop a single-window application that has many different views that can be navigated by buttons. I tried to wrap my head around the way the storyboard works, but even after all my reading of the documentation I don't know really what I'm doing - I'm so used to working in hard code. It came to the point where I wrote my app's entire network layer just to avoid working with the interface.
Basically I have a set of different NSViewControllers, each with references to a few of their components (buttons, labels, etc) and I want certain buttons to be able to change the current view controller (preferably with a segue animation) to a different one. How can I approach this? I would guess that this isn't hard to achieve, but I am lost. Any help would be appreciated!
Let me know if I need to submit any code - I do have the basic classes written but nothing relating to this.
Thanks,
-Aidan
Can we use multiple separate views and integrate/call them on main view within a cocoa project?
Currently we are dropping all of our sub views and IB controls into a single view and making changes in IB is becoming unamageble now. When working on IB in xCode, it consumes 2.4 GB of memory. Please suggest a better strategy to organize IB views and controls.
Yes. Absolutely. There are lots of examples of using several nib or xib files together. I suggest you check out the sample code at developer.apple.com.