I'm a fan of Xcode's new storyboarding, but I'm annoyed it won't work on iOS4. I understand why it won't work, because it relies on new classes added to the iOS5 framework. However, it would be cool to be able to port a storyboard back to iOS4 somehow. A tool that outputted xib files for the individual stories, and code generation for segues.
If anyone knows of anyone else doing something in this area, I'd be interested in using it, since my app needs to support iOS4, but I'd like to move forward with Storyboarding. Can i have my cake and eat it too?
Nope you cant. Ended up gutting the storyboarding and going back to individual xibs.
Related
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!
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
I am working with my first tabbed application in xcode. I am just testing with some stuff since I'm relatively new to programming. I am just using the 2 views already put into the template. I am putting a slider into the first view and am going to attach it to a text box with numbers. But that isn't the problem! This is probably really stupid and simple, but when i run the application just to see the stuff on the simulator, it is just showing a black screen. NO CLUE WHY! But its killing me and would love some help!
You are not suppose to make connections in AppDelegate. You should use a ViewController for each class. I.E. FirstViewController, SecondViewController. AppDelegate is usually only used for calling save/restore messages.
You are getting the error because the storyboard view is assuming you are assigning it to the correct view. When you create the storyboard say you named it TestApp. Then, you should have a few classes. TestAppDelegate, TestAppDelegateFirstViewController, TestAppDelegateSecondViewController. Or something along those lines. FirstViewController should connect to the first view on the tab view. The Second should attach to the second.
AppDelegate is almost never used for UI. I would suggest you find a book on the matter. I'll suggest "iOS Programming. The Big Nerd Ranch Guide". It helped me a lot when I started.
Photo Exmaple:
I did end up starting a new project. Weird that the black screen showed up.. not really sure why that error was popping up.. I'm not really that knowledgable about the different errors and bugs that a program can have yet! Getting closer though!
Can anyone help with Xcode 4.2 and the new tabbed application project? With Xcode 4.2, i create a new tabbed bar application, and it works as desired. However, it seems that instead of creating a new window and main.xib file that contains the tabviewcontroller, it sets everything in code within the appDelegate.
its easy to work with the tabbarcontroller via code and i have no problems setting up other tab items, however, i feel that my iOS development skills (they are new) are missing something as i would NOT even know if it was still possible to work with the tabviewcontroller graphically now in the way this project template has been setup.
Is there a way to work with the tabviewcontroller graphically? would i have to create a new main.xib file and link everything up to that? i'm still not strong enough in my skills to work out all the minute details but if that is the path that people suggest, i will look into it and try to figure it out.
I only want to work this out so i can fully understand whats going on now with Xcode 4.2, I have no unrelenting desire to only work with the tab bar controller graphically, but am curios as to why i cannot find it (or if i should)... just trying to get my head around how these things should be working.
You should use the Single-View Application template.
HEre you can add graphically that control
I'm getting back in to Cocoa development on the Mac after a long stint doing iPhone work. My previous experience with Cocoa on the Mac has just been dinky little tools. I'm looking to build something serious.
Looking at a modern Cocoa application like iPhoto (or Mail or Things or....) many apps use the Single-Window, Source-List based approach. I'm trying to wrap my head around that as best I can because it seems to provide a good experience. However, I'm having a little trouble. Here's how I think it should look, but I'm wondering how others are doing it, and what's really the best way:
Starting point of the app is an AppDelegate object which, after launching, creates a Window[Controller?] from a nib, along with setting up its data (from, say CoreData)
WindowController loads a window which essentially just has an NSSplitView in it.
Left side of the splitview has an NSTableView or NSOutlineView which is set to have the SourceList style.
Right side has the main content of the app, depending on which item of the table view is selected.
I would assume somewhere (where?) there are NSViewControllers managing each of the different views which will appear in the right side (think how iPhoto has All Photos, Events, Faces, Places, etc. and I imagine they could all appear in different nibs... is this correct?).
Those view controllers are probably bound to the source list on the left.. how does that work (source list is backed by an NSArrayController of NSViewControllers maybe?).
Anyway, those are my thoughts, am I completely off-base or...? I've looked around the web, found this post here, and I've looked at some Apple source code but I can't seem to wrap my head around it. Any guidance would be welcome.
Breaking the views up into separate nibs is mainly good if you're going to swap out some views for others, since you can load them lazily. And yes, in a modern app, you would use NSViewController, or perhaps KTViewController from KTUIKit (see the posts she co-wrote about NSViewController)
Don't just go running into the arms of the source list, however. A single-window interface can be good for simple apps, but it can quickly become unwieldy when you have many things going on, as they may be better served by breaking them into separate windows; iTunes and Xcode both provide many examples of this (especially the latter, since you can switch it between SWI and MWI).
You need to think about whether a multiple-window or single-window interface would be better for your app. There is no one answer for all apps; it depends entirely on your app, and what you want it to do, and how you want it to lookâyou (plus the rest of your team, if you have one) are the only one who can answer this question. You may want to do some paper prototyping to do quick experiments in each direction so that you can hold at least fake examples of both UIs up against each other.
One easy way to get a feel for the way nibs are split up is to just go into the iPhoto directory and start opening up nibs
If you want to explore a little more into the class structure you can try browsing around using F-Script