I'm going through the Beginning Iphone Development Apress book and I'm constantly getting problems when building my NIB files. My practice apps crash because of the NIBS. I now this because I'll just trade out mine for the sample ones and the app will work. I'll look at the sample nib and all of my connections will be the same. I'm having problems debugging my NIBS and figuring out exactly what's wrong. So...
1) Can you just design your interface in IB and do all the wiring in Code?
2) What's the best way to figure out what's wrong with your NIB's?
3) Anybody else have the same problems with doing the examples in the Apress book?
1) Can you just design your interface
in IB and do all the wiring in Code?
You can but it's WAAAY more work. If you don't want to use IB, then doing everything in code is a better options.
2) What's the best way to figure out
what's wrong with your NIB's?
Check each control and check all reference outlets (Command-2) and class dentities (Command-4).
Check Interface, Implementations for IBActions and IBOutlets, and Implementations for proper load sequences. (i.e. if using IB then initialize your view in viewDidLoad)
3) Anybody else have the same problems
with doing the examples in the Apress
book?
No
Interface Builder will indicate errors and warnings in NIB files by showing an alert icon in the bottom-right corner of the NIB document window. Click on that to see what the warnings are.
You can safely ignore "illegal geometry" warnings but missing outlets etc can be fatal.
If your apps "crash because of the NIBS", then what kind of error message are you getting when the crash occurs? Usually there's a pretty big clue about what's wrong if you look in the Xcode console, and usually that's the best way to start finding out what's causing the crash.
You can build your UI totally in code if you want. I personally prefer this and only resort to NIB files for views that have a lot of items that need to be positioned.
I recommend Erica Sadun's The iPhone Developer's Cookbook for a good tutorial that shows you how to do this. I wrote a review of it here.
NIBs clearly have their place, and many developers prefer to wire things up using a visual tool like Interface Builder. But some of us (like me) would rather do things in code where practicable.
I am pretty much a newbie as you as well, but found this post which advises on striking a balance between the two and illustrates it with an example:
http://wiresareobsolete.com/wordpress/2010/03/striking-the-balance-interface-builder-vs-code/
Related
I have just spend a lot of hours re writing my app to have it all in code instead of using storyboard.
Mainly because I wanted to understand what the storyboard did for me.
Obviously with this, I have noticed that my files have become severely big in terms of lines of code.
Apple seems to be more in favor of storyboard then writing lines of code, as per their WWDC videos.
As fellow developers do you still feel that writing everything out in code is the better way to go? I hope to get a good few opinions on this as I want to see if my feelings on the matter are supported by your ideas, having done this for a longer period of time no doubt.
Thanks in advance.
There are few advantages and disadvantages of both.
Advantages of adding controls by Code
You can prefer writing everything to code if most of controls are dynamic. So that you can load controls whenever required.
Its easy to reuse code and make application more dynamic e.g you want to make UI themes for application
Advantages of Storyoard/ XIB
Using Storyboard/ XIB load all controls(Better if application is static) at once for that view you have to just bind properly.
Design UI with storyboard/ XIB is easy as compare to code.
These are few advantages of both as per my understanding.
making application through the code, helps developer lot, it gives flexibility.but going through the storyboard decreases lines of code. for mobile application development decreased number of lines codes or less code is always welcome.
I have a question about universal app. My app will not have storyboards or xib file. There is possibility to write universal iPhone/iPad application without it? I found some tutorial how to create universal app with storyboard, but i don't want (i can't) use this feature in my project.
If it is possible What should i do? If i have to made changes only in ViewControllers? I'm start to do this, i'm not changing old project so i can do anythng - what should i learn/what should i remember?
I'm targeting to iOS 5.
EDIT:
I have a screen information in resource file and my rootViewController or any other ViewController will be created in compile time, so i can't have xib file for that, i can't put button on xib with Interface Builder becouse i don't even know how many buttons i will have there. I don't know how many screens i've got till i hit run in my project.
Not only can you write any type of iOS app without Interface Builder, it is actually much more testable and pliable. Some auto layout tricks are difficult (not possible?) in IB style projects, as well.
There is an incredibly impressive library called Masonry that wraps the NSLayoutContraint syntax. This makes it quite pleasurable to subclass views while not having to use ugly VFL or incredibly verbose NSLayoutContraint syntax (not even going to address frame setting...blech!). IB style apps also promote bad software development practices and anti-patterns (just dumping everything in a view controller presentation-wise. No Separation of Concerns!). Also, it is more difficult to work on larger teams (IMHO even small teams) while utilizing Nibs, Xibs, and Storyboards due to merge issues.
On top of all of that, you gain a much deeper understanding of the classes you are working with (UIView, UIResponder, etc.) when writing code in this manner (once again IMHO). There is an interesting article outlining some of these issues in more detail: http://doing-it-wrong.mikeweller.com/2013/06/ios-app-architecture-and-tdd-1.html This is by no means the only article that discusses this problem. Also, this will help for your app delegate: creating a universal window-based iphone app without generated xib file
This is certainly possible, I have only used storyborads once in the many apps I have published. As for not using XIBs, I am not sure why you would want to do that. You can lay out your views at runtime in the init method, but I feel like that is just making things unduly hard on yourself. You can set a XIB up for the iPad and one for the iPhone so you can tailor the UI specifically to each device.
Perhaps if you go into a bit more detail about why you are imposing this requirement on yourself we can discuss if it si worth the effort to go down that road.
Good Luck.
Is there a right/wrong approach for creating a Custom view using code or IB? I mean what should be the preferred way of designing a custom view.
As for all broad questions, the answer is "It depends what you're trying to do". Both IB and writing code have their merits. Some projects will end up with a bit of both.
There's some discussion here:
http://wiresareobsolete.com/wordpress/2010/03/striking-the-balance-interface-builder-vs-code/
Personally, I started out working with IB. But as I went deeper into iOS development, I started building my views in code....
Gave me a higher sense of control over my view objects.
But, like everyone else says, both ways are correct; It just depends on what you're comfortable with.
Like me, try both and see which one works best for you. You have nothing to lose either way.
I used to do it in code but now I mostly use IB to lay out my views and then do fine tuning in code, like setting the font for a UITextView. Always seems odd that you can't do that one in IB...
For my job, I've been writing an iPad application that the user can enter data into, view some pictures, etc. It's been annoying me that I'm reaaaallly slow at writing in Obj-C and I find myself bogged down in the UI (an example would be I always have to put in a UITableView which is time consuming...) I think that I have a pretty good handle on the language and Apple SDK.
Does anyone have any tips regarding how to speed up the development process from a UI perspective? Are there alternative tools to xCode and IB? Are there libraries with classes that are faster to program w/? Anything is appreciated,
mj
Interface Builder can already speed up your development considerably if you learn to use it. For example, see this custom table cell with IB tutorial.
For example, at my current employer I've seen a Cocoa Mac OS X app where the settings dialog was done completely in IB... there was no code for modifying or sync'ing the values in the NSUserDefaults with the interface elements, everything was done in IB.
Also, see this interesting article: Striking the Balance: Interface Builder vs. Code.
Avoid UITableViewController if you aren't already.
For speeding up TableView dev, I always keep a pretty generic implementation of TableView handy that I can copy and paste snippets from.
If you are constantly doing TableViews for different object types, try using Protocols to make the implementations more uniform.
Don't be afraid of UIViews as subviews as opposed to constantly using UIViewControllers. Sometimes a VC is just an extra layer of complexity that you don't need.
My experience is that the biggest thing you can do as an iPhone developer to become more efficient is to know when and when not to use Controllers as opposed to Views when doing complex interfaces.
Wish I could be more specific but your question is a little vague... there's nothing wrong with Interface Builder, it's just a steep learning curve.
Are there any good reasons why I should not use XIB / NIB files with an highly customized UI and extensive animations and super low memory footprint needs?
As a beginner I started with XIB. Then I figured out I couldn't do just about everything in them. It started to get really hard to customize things the way I wanted them to be. So at the end, I threw all my XIBs away and did it all programmatically.
So when someone asks me if XIB is good, I generally say: Yeah, if you want to make crappy boring interfaces and don't care too much about performance, go ahead. But what else could be a reason not to use XIB?
Am I the only iPhone developer who prefers doing everything programmatically for this reasons?
I think that Interface Builder is one of the biggest assets of Mac (and by extension, iPhone) software development. GUIs are visual; why not create them using a visual interface? IB is flexible enough that you can lay out an interface using its "generic" components, and then subclass them where necessary. Sure, if you have a unique interface you're going to have to subclass a view class and perform custom drawing, but you can also lay out your interface in IB and then easily use the inspector to switch the class to your custom subclass.
Honestly I think it's a spectrum of convenience. If you are comfortable writing everything in code then go for it. If you design your project well then it should be about the same amount of work creating new windows, etc. But I know that a lot of people aren't as comfortable with the GUI world so nib/xibs work well there.
I honestly find myself using XIBs as a base quite often and editing them with code to get the specific look I want. Personal preference.
For a specific con on that point, views can be difficult to configure after loading them from a xib. When you have conflicting settings between IB and code that can be nasty to troubleshoot.
Here's a question for the list. What is the performance hit to using a xib? I thought they were a plus because they don't get loaded into memory until you need them. That said, that load time is longer which will slow your program down. Thoughts?
One thing I found better about code is for the event connections on controls, when you search for uses of a method (message) you find them if they are coded and you don't find them if they were set in IB.
On the other hand laying out objects on a view is much easier in IB where you can see their size and positions. When you do that in code you have to guess at the size and origin settings and then run it and make adjustments, then run it again to see what it looks like.
When your application has some kind of "standard" views, go with the XIB. If you need real customization, depending on external content (XML...) do it programatically.
I started using XIBs and now it's all code, I find myself more comfortable this way. I had real problems with XIBs, and now writing the interfaces all in code really saves me time.
I save tons of time when dealing with UIControllers (UITabBarControllers, UINavigationControllers etc.) in the start up phase where all the navigation stuff is hooked up.
I just build X viewControllers with a accompanying XIB, throw in the stuff needed in IB, labels, images etc. This means that for almost any sort of app you can have a proof of concept up in a few hours. This is enough to justify spending some time learning the ins and outs of IB. Especially on the iPhone where you can have a ton of good UI ideas, but they all fail when they move from the Simulator to an actual device.
The best thing, in my mind, is to balance it out, if you find yourself using a lot of time doing the "change the frame 3 px -> compile -> ahh.. needs two pixels more -> change 2 px - compile -> ahh.. 1 more px" for something that could be done in IB, you will seriously start to waste time.
I start as above, but afterwards I often throw the XIBs away for custom stuff. The trick is to not spend hours on implementing versions of custom stuff in code over and over again, but figure out how it should be and do the custom stuff once:)
The XML content of a nib file is very complicated. This makes it extremely difficult to review changes or fix merge conflicts with a version control system like Git.
Interface Builder is a nice idea, but Bret Victor, in his talk "Inventing on Principle" and his essay "Learnable Programming," implicitly challenges Apple to build an even better IDE.
One idea, based on Bret Victor's principle: What if I could select a "Move Tool" in the iOS Simulator app that let me move a button in my app and then the frame code changed in the implementation (.m) file? This would be much better.