Related
I've been developing everything with xib files because we needed to suport iOS4.
Now we are finally supporting only iOS5 and iOS6, so I decided to give storyboards a try, so everything is fine and easy, but I have found myself doing a lot of code like this:
-(void)prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender {
if ([segue.identifier isEqualToString:#"AddPlayer"]) { //Ugly
UINavigationController * navigationController = segue.destinationViewController;
PlayerDetailViewController * playerDetailsViewController = [navigationController viewControllers][0]; //Super Ugly
playerDetailsViewController.delegate = self;
}
}
I don't know about you guys, but I found this code very ugly and error prone.
Is there a better way for working with Storyboards? Should I got back to xib files?
I worked with Storyboards quite a lot in the last app we built where I work and yeah, I agree the boilerplate code gets pretty annoying after some time, but as far as I know using prepareForSegue is the only way to pass parameters when using segues.
You can't assign properties/delegates on a custom view controller from the Storyboard itself.
Would I go back to using XIB's if I only target iOS 5 & 6? It
depends.
If I had to build a small - medium app (not too many views and not a lot of cross-navigation between them) I would definitely use Storyboards. But when you have a lot of views and a lot of back and forth navigation between them, it really gets complicated to keep the Storyboard nice and tidy, and it feels like you are forcing yourself to use something that actually isn't the best.
On the other hand I feel Storyboards make it much easier to get a feel of the flow and general look of the app when starting from scratch, and you can even use them to create mock-ups that will actually look like the real thing.
So in essence it boils down to what your needs are when starting a project.
EDIT:
Another thing to take into account: if you use SVN/Git or any other VCS to work with a team, Storyboard file conflicts are a total bitch.
I agree that is an ugly code and to smooth my vision I created a macro:
#define WhenSegueIdentifierDo(segueIdentifier, block) if([segue.identifier isEqualToString:segueIdentifier]) block();
And in my prepareForSegue:
WhenSegueIdentifierDo(kModalVC1ToVC2, ^
{
//code
});
WhenSegueIdentifierDo(kModalVC1ToVC3, ^
{
//code
});
I also use constants instead of hardcoded strings (although I cannot use them on storyboard) to keep it more beautiful. I also use a convention: k + type of transition + origin view controller name + to + destination view controller name.
You could also use
navigationController.topViewController
instead of
[navigationController viewControllers][0];
Just my 2 cents...
That's just the nature of the beast. Objective-C using Cocoa conventions produces - (hopefully) self documenting, albeit, verbose code. Looking at your example, I have no problems determining your intention.
Now, if you wanted to make it pretty, you could encapsulate all this into a macro so that it would be condensed to one line. While it may be prettier to behold, it would certainly add unnecessary complexity in maintaing the beast. The end user isn't going care how pretty the code is -- unless it prevents adding new features.
As for discussing storyboards ... they are certainly different but having used them now for six months, I do appreciate having all my nibs in one centralized place instead of spending the time to look for individual files. It's much easier for me to find things by visual layouts, then parsing camel cased file names. That's just me.
My advice, give them time. In a few months if you find them inhibiting your workflow, then by all means, go back to individual nibs. They aren't going anywhere. At least for awhile.
Just my two cents. Good luck!
Thank you for reading this.
These are my first steps in the iPhone Ipad app programming.
In order to learn from scratch (and because I know my app would need dynamic views), I decided not to use Interface Builder.
My question is(regarding the fact that I don't use IB): how would one use Views and Controllers?
I think I understand the MVC concept as it is repeated over and over again in the tutorials I follow, but after the "MVC explanation" part, nothing is made to make it clear "on the field" and closer to the real world (Earth being Xcode here).
Worse, sometimes it seems that some tutorials mix these two concepts up and use one word to say the other.
I read around here a lot of questions (and answers of course) based on the matter but I still don't get it. Sometimes it's too generic, sometimes it's too specific (for me at least).
For what I think I understood, the UIView is the static View when the View Controller is the logic which links the View to the data and those 3 concepts must be separated.
This separation, while a bit clearer with the use of Interface Builder seems to get quite blurry when you code everything as it becomes a virtual soup.
Technically, should I create a specific ".h" and ".m" file for each View AND ALSO for each associated Controller?
If I understand the MVC pattern, it's seems that I should but when I follow tutorials (without IB) it is never the case, view and controllers are created and manipulated within the same implementation files.
Any high level (I'm a noob, don't forget) but still applicable explanation of the use and best practices?
Let's say I want to create a simple app with a green view I can swipe to get to a red view.
I know for sure that I would need at least an:
xxxappDelegate.h
xxxappDelegate.m
xxxView.h
xxxView.m
What else?
1)Where should I put the the second view (along with the first one in "xxxView" or should I create another class h and m file?)?
2) What would the controller(s) do, for that kind of application? In which files would they be created and in which files would they be invoked and how would they "control" the related view?
3) Mainly, regarding to MVC pattern and the fact that there would be no IB, how would you organize that app?
I know it's a lot if you go into the details and code but that's not the point here.
Thank you. This - as simple as it seems - would be of a great help and is not as easily found in tutorials as you might think.
I understand the tutorials I read but they are so particular. As soon as I try to create something on my own which is not a "Hello World" screen, I realize that something is missing, logic wise.
Thank you very much for your help.
Sorry, but I can't get past your first paragraph. If you don't use Interface Builder, you are not going to be a successful iOS programmer. It's that simple. The best advice I've ever read about this is in this Aaron Hillegass interview:
Experienced Cocoa programmers put a lot of the smarts of their application in the NIB file. As a result, their project has a lot less code. Programmers who have spent a few years working in Visual Studio get freaked out. They ask me stuff like, "Can I write Cocoa apps without using Interface Builder? I like to see the code. Maybe I can just explicitly create my windows and the views that go on it?"
It is difficult to explain how the NIB file (and a few other scary ideas) create leverage. It is that leverage that enables one guy in his basement to compete with a team of engineers at Microsoft or Adobe. It is like I showed a chain saw to a early American colonist, and he said, "Can I cut down the tree without starting the engine? I don't like the noise. Maybe I can just bang it against the tree?"
Yes, it's hard to generalize after reading specific tutorials, but you will learn. I thought the learning curve was insurmountable when I first started, but if I can become a programmer that gets paid to write Cocoa software, you can too. Just keep reading and practicing. Don't fight the tools--use them.
Early:
In order to learn from scratch (and because I know my app would need
dynamic views), I decided not to use Interface Builder.
Later:
As soon as I try to create something on my own which is not a "Hello
World" screen, I realize that something is missing, logic wise.
I think what is missing logic wise is that you have accepted your assumption that Interface Builder was a crutch and that to learn "from scratch" you had to avoid using it. You are trying to learn the MVC design pattern but you are not willing to use the tools that have been designed to support it.
In Apple's own documentation they discuss the fact that sometimes there is value in having combined roles—Model Controllers and View Controllers—and that is worth reading, as it may explain some of the code examples you're reviewing. But my primary advice would be: before assuming you know better than the people who built the tools, trying using them the way they recommend. It might be an eye-opener.
Additions later:
OK, so to try and actually answer your questions...
1)Where should I put the the second view (along with the first one in
"xxxView" or should I create another class h and m file?)?
If I am understanding correctly and the two views you are thinking of here are the red and the blue displays to the user, you wouldn't have a second view—what you would do, whether in IB or in code—is to have an element in your view on which you changed a colour property... This would be done programmatically whether you were setting up the parent view in IB or in code.
2) What would the controller(s) do, for that kind of application? In
which files would they be created and in which files would they be
invoked and how would they "control" the related view?
There would be a view controller that would implement the gesture support, and would provide a method for changing the colour of the item in the view between blue and red when that swipe gesture was successfully received. I would have a ViewController.h and and ViewController.m. I think if you were implementing the View entirely in code, it would be implemented in the ViewController.m rather than having a separate View.m. (If you were using IB, you would have a ViewController.h, ViewController.m and ViewController.xib, with the latter providing the basic setup of the view elements and layers.)
You would create a ViewController instance in your AppDelegate.
3) Mainly, regarding to MVC pattern and the fact that there would be
no IB, how would you organize that app?
As above.
If you really insist on going without IB (and I agree 100% with SSteve) then in addition to the files you list you will also want to use a UIViewController. Now, it is important to know that you only need to create header and implementation files when you are adding or changing default behavior.
In you case, the view can probably just be a generic UIView, so you wouldn't need the files. What you would do is subclass UIViewController, and put the swipe logic there. In the swipe logic code you would probably just change the background color of the view.
You would instantiate the view controller in the delegate (in this case anyway) and create the view in the view controller's loadView method. That is required since you won't be using IB.
Personally though, I think that IB does a great job of encouraging proper MVC patterns, and if you are just starting then you should go with IB.
In practice you mostly do not make classes for views, unless they need to do custom drawing or display.
For lightweight configuration of views, that is often done in the viewController's viewDidLoad (or I guess in your case loadView) method.
Yes it's a good idea to keep model and view separated, but that's also balanced with the equally good idea to reduce the amount of code that exists. The less code that is written, the fewer bugs you will have.
Since you are just starting out at this point I would absolutely start by using ARC, and using IB - even though I'm sure you're tired of hearing that from everyone, I'll give you an alternate take. Less code means fewer bugs. And the fact that so many experienced developers are telling you to use it should be a giant clue about what a productive path forward is. I mean, are you doing this to build applications or learn every corner of the UIView class?
To speak to your code example, you do not need the UIView custom class. Just create use a UIViewController's main view as a container view, place a UIView inside with the background set to red. On swipe (using a gesture recognizer attached to the container view) call the UIVew method to swap in a new green-background UIView for the existing red view, you can even define the transition style.
Or create a scroll view in the container view, set up the red and green view inside the scroll view, set the content size and enable paging on the scrollview.
Or create a custom UIView class as you had, listen for touch events and slowly adjust two subview positions to follow the drag action.
Or use an OpenGL backed view, and based on the gesture recognizer pan the scene you are observing with two triangles for a green rectangle and two triangles for a red rectangle.
I want to decide if it is better to use XIBs or to designs my views completely using code.
So far I have read that when you design your views on interface builder they are pre-built, so even if they use more memory the user feels everything is faster.
People say doing everything using code is harder but I find it to be just as easy, so I want to know if anyone has experienced some real speed gains when using nibs.
What have been your experiences, advice, etc?
Thanks!
You should be able to do both -- there are times when building a view programmatically is better/easier, and times when using a .xib is better/easier. Even if you only ever do things one way, you'll run into code that does it the other, and you'll need to be able to deal with that.
If you don't know how to use IB, then building your views in code is certainly easier. That is why you should learn to use IB. Once you understand IB, it's way, way faster to put together most of the view-based UI your app will likely need. IB helps you line things up, center objects, align base lines, connect controls to their targets and actions, etc. I think it's safe to say that everyone who uses IB effectively experiences "real speed gains when using nibs."
You should know how to use both. Performance differences between the two are negligible and should not be the reason that you choose one or the other.
Many people who are new to iOS development have the misconception that nibs (.xib files) are inferior to programmatically creating your UI and that if you use IB you're not a good iOS developer. That view is 100% wrong. IB is created by Apple and in use by Apple's developers to create their own Mac OS X and iOS apps. If IB (as a tool) is good enough to be used by some of the best developers in the world, it's probably good enough for most of us.
In practice I have found that a combination of the two usually fits the bill.
In my own apps I find that .xibs are great for laying out the basics of your views quickly and they allow you to iterate very quickly while giving you a preview of what your view will look like. It's also much easier to use auto layout in a .xib file.
Then when you need to do more advanced things like add fancy animations or move views around that is what IBOutlets are for. Anything that you put into a nib can be referenced through an IBOutlet. This allows you do then programmatically make your view come to life.
Lastly, you should fully understand what a nib (.xib) is doing automagically for you. You should understand what happens when a .xib's objects are unfrozen. There are many resources on the internet to understand .xib files better.
Also, learn how to use .xibs in an encapsulated way. For example, .xibs are crazy useful for things like prototype cells and they allow you to keep your code base modular (much more so than storyboards). Also, you will require less UI code in your view controllers.
Lastly, I always say that people should think of IB/.xibs like jQuery. It's going to save you a lot of time but the best developers still know how to do everything in javascript if they have to.
Good luck and have fun!
TL;DR version
Performance is not a consideration when deciding to use .xibs or not.
Use .xibs because they give you a preview of the view you are creating and they allow you to quickly iterate
In practice most apps will use a combination of both. You will programmatically add animations or move views around but the .xibs will be a starting point
Understand fully what happens when the objects in a .xib are unfrozen
You'll be more productive but be sure you fully understand what is happening behind the scenes.
I would always use XIB files unless there was a reason not to. This allows your views to be maintained easily in the future.
Some reasons for creating the views programmatically might be:
A control needs to be resized,
repositioned or otherwise altered
depending on something else
Controls
need to be added or removed
dynamically
There may be more reasons but there are not too many.
If you programmatically create views when there is no need you make it a lot more difficult for other developers to try to figure out what the view will look like and to change it.
If you build your views programmatically, you have control over the loading of elements. e.g. you could use lazy loading, and load secondary buttons, subviews, etc. a fraction of a second after the more important elements, allowing the key parts of the UI to come up faster. You could even animate some elements into position.
If you use IB, you get guides as to proper element spacings and positioning, but you could always copy the coordinates from IB into code if you aren't changing the design that often.
For simple UI elements, you will end up with more lines of code to maintain if you create them programatically.
IB and NIBs do a lot to optimise loading/unloading of views, but it is largely oriented to minimising memory usage vs. perceived speed for the user. For example, lazy loading if anything might make the app UI slightly slower, but it should make memory usage lower. This in turn could make overall app performance better on a large application, and is very much encouraged, but it's difficult to define "performance" in a narrow way. It's also difficult to say when you should or should not use IB - there will be some times you're much better off doing it in code.
One often overlooked element to the IB or not debate is development speed, especially if you have multiple developers. On a larger team/project you'll probably have some developer(s) who specialise more in the infrastructure, business logic etc. of the app and some developer(s) who specialise more in the UI. In this case, use of IB will make it easier for them to work independently, which should make overall development more efficient.
I view IB as a core part of the development platform for iOS development. It's not the right solution in every situation but not knowing how to use IB will be a real limiting factor.
I'm trying to get started with an iPhone application, I had a look around at other questions but i'm still sorta stuck so hopefully someone can help...
First thing is I'm totally confused with the whole view concept, I'm more used to visual studio so I'm going to use the term 'form' to describe what I have in my head.
I want to achieve a home screen in an application with say 9 icons (much like the iphone home screen) which each lead to a different 'form'. Each form may have a different function so say one might be a simple calculator, one might play a video etc.
How do I do this, its destroying my soul trying to do something so simple... If you guys even have any links to get me on the right track it would be greatly appreciated
I suggest you take a look at the Stanford iPhone Programming Course. If you don't have the time to look through it all, I reccommend at least Lectures 5 and 6 about Views and ViewControllers. The slides are quite instructive and they come with video presentations that should help you get on your way in about an hour.
Apple's samples are a great place to start. There are some simple ones that can show you how views and view controllers work.
Also, in Xcode, when you create a new iPhone app template, that template usually has enough code to display a view, and sometimes a flip-side view or more. Sometimes, you should stop reading, and do.
I had the same weird learning curve as you, as things don't initially seem to make sense but they do - and once you've got your head round them they make perfect sense trust me!
Your 'forms' are viewControllers in this M-V-C land, they control all the 'view' (which are controls or any object which can be seen) within them. Normally they are loaded from a Nib (design from the interface builder), but don't have to be.
The way I would go about your problem is to use a navigationController as the base to handle all of your view controllers.
A navigation controller needs a rootviewcontroller to start so this will be your desktop Viewcontroller. I'm not sure how you are planning to populate this but all the icons will need to be stored in some kind of array. I suggest you use a simple UIButton. When then button is pressed you then alloc and init and push the required view controller.
I have been programming with the iPhone SDK for some time now.
I have not been using Interface Builder. This scares me a little. I know that in effect I may be 'fighting the framework' but I do not see it that way.
I find it very easy to just instantiate my UITabBarController in my app delegate, instantiate a UINavigationController, then push and pop view controllers as I go.
Naturally I do not have an extensive knowledge of how to architect an app with XIB files because I have never done so, however I do know the general gist of it, having built some Mac apps in Cocoa using NIBs. So I am not completely ignorant.
My question is whether there is an increase in development time when choosing to lay out UITableViewControllers and UIViewControllers using XIBs rather than programmatically instantiating them and then setting up the ivars.
As I see it, both methods still require you to subclass the view controller for customization which will probably occur for the majority of your views. As well, there are still manual classes required for delegates, and the process of connecting outlets from within the XIB seems comparable to me from setting an ivar.
Or am I missing some other major point?
Thanks!
Code takes much longer to write to configure UIs than IB does.
Plus, you can hand off design to designers and let them tweak the UI.
In the end they both accomplish the same thing. You should use either one depending on the circumstances. Most of the time writing the code to create and position views, and especially maintaining it down the road, will take much longer than using IB. In a simple app for the iPhone though, this might not be true and you'd be just as well off creating everything in code. Basically, you should know how to do both, and pick the path that involves the clearest code and quickest development.
IB shines when you're using it to actually lay out views; even two or three views can be a real hassle to lay out and configure in code. I do tend to use it for tab bar and navigation controllers, and sometimes for subcontrollers (usually only if I think the user is very likely to use it), but that's more just because I'm already there so I find it convenient.
With this new version 3 OS they're announcing next week, I'm hoping Interface Builder gains some of the flexibility it has in Cocoa, where you can add palettes for your own classes and even build up complex non-view data structures (by using custom palettes). We'll have to see, though.
Don't worry too much, IMO Interface Builder is a little over-rated too.
It's definitely useful for getting things up and running quickly, or if you have an app with a lot of screens that are tedious to setup, but you're not missing much.
For the uses you outline just doing things in code is fine, and possibly even a little easier to understand.
Laying out views, or custom cells though... then you get into a ton of font/color/position setting that quickly explodes into a lot of code, hard to maintain and tweak. Much easier to adjust what you want in IB in those cases.