Another noob question, but while looking at some code examples, I see stuff like
UIViewController *controller = [[UIViewController alloc] init...
Making an instance of the class UIViewController which I understand. But then you have these instance variables of your own class. Like let's say I was building a simple counter program called Counter and it counts when you touch the screen and I have a property for my view controller called "count." So when I run my program, is that when my instance of my class is created? Because it's not like I ever create a Counter *counter object. Thanks.
So when I run my program, is that when
my instance of my class is created?
Yes, when your program executes the objects are created.
If you have allocated and initiated counter but are using it, I'm surprised anything works.
You allocate and initialize objects before you use them and then release them when you are done.
I think you may be confused because of the way loading nib (XIB) files instantiates objects without any actual Objective-C code to instantiate the object.
Read about the NIB Object Lifecycle in this guide: https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/LoadingResources/CocoaNibs/CocoaNibs.html#//apple_ref/doc/uid/10000051i-CH4-SW18
Basically, the first NIB gets loaded based on whatever is specified in the YourAppName-Info.plist for "Main nib file base name" and that will instantiate any objects defined in there and then set IBOutlets to point to them as specified in the NIB file. As a result, certain objects will seem to just "be there" referenced in the outlets (like IBOutlet UIWindow *window in your app delegate) by the time your code executes.
I recommend the book Beginning iPhone 3 Development as a great tutorial for all of these things.
Related
In the project i am currently working upon, there are lots and lots of UIViewController objects (of some UIViewController subclass) are created and used. And believe me it was creating lots of issues. And I am working upon it (kind of refactoring).
As I see, most of the (those)objects required initialization only once and used multiple times. As I will be working on this project from now (and also the project is of long duration), How can I be sure that each of the UIViewController Subclass object is only one alive at a time.
I doubt if I should make all the UIViewControllers Singleton. And if so, How should I implement that. Meaning; Should I initialize all the objects in applicationDidFinishedLaunching:WithOptions or where?
Another Question is: (As I think might not be true) Should all the UIViewController in project be singleton?
If you want to ensure that all the UIViewController objects in the project are being created only once then only way is Singleton. And you need not to intialize them in applicationDidFinishLaunching. You can intialize them any where(usually where you need them).
Go to link for creating singleton properly: http://cocoasamurai.blogspot.in/2011/04/singletons-your-doing-them-wrong.html
Source : Make UIViewController a singleton?
Well making them singleton if you want them to be only one object of each subclass is not a bad idea,
if you made them singletons, don't initialize them in applicationDidFinishedLaunching:WithOptions but initialize them as soon as you need them (read more about lazy initialization)
However i would suggest to make each webView a property of your Appdelegate, such that whenever you need them you will get them from the appDelegate
I have recently started to learn about programming for the iPhone and after going through numerous online tutorials and books (most of which tell you to write this here without offering any explanation as to why or how stuff is working) I still have many questions unanswered and it would be great if someone could help me clarify them.
Here goes:
1) In Interface Builder, what is file's owner, first responder, and a delegate, and where is the actual code that draws the view?
2) When using Interface Builder and you add components to the screen, I understand that Interface Builder doesn't automatically write the code for you, but how should I handle the events fired by the different components? From a best design practice view, should each component have its events handled in a separate file? (would such file be the component's delegate ?) or is it better to just make the viewcontroller class implement all of the interfaces of its components?
3) When creating a UITableView for example, and I define the function:
- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section {
return [listOfItems count];
}
I am saying that the object tableView of type UITableView has this callback function. Right? So in case I have another UITableView named MyTableView I should write a function as such:
- (NSInteger)MyTableView:(UITableView *)MyTableView numberOfRowsInSection:(NSInteger)section {
return [listOfItems count];
}
There's some big questions here and very hard to answer in a stack overflow post.
1)
A. What is the File Owner?
The nib is a file right? So what would own the nib file? Well the owner is whatever object you call initFromNib: on.
AClassName *theOwner = [[AClassName alloc] initFromNib:#"nibfile"];
A nib file is just a freeze dried object, a description of an object, a serialization of an object. The object is often freeze dried with a bunch of helper objects to it can be unfrozen and ready to go. Remind me of how Egyptian Pharaohs were buried with many of their servants and many of their possessions, they would be ready to go in the after life. The owner is the main object that has been frozen. In a frozen state (the nib file) the owner is frozen and you can't work with it. When you unfreeze by loading the nib file the main object that's unfrozen is the owner.
B. What is the First Responder?
When you interact with your program by touching the screen, shaking the phone, typing on the keyboard the program must respond to that event, many other frameworks call this handling the events or actions. The First Responder is the first object that gets to respond to the user's interactions. This will typically be the NSView that the user touches, which responds by redrawing itself and sending updated information to the View's Controller (Remember, NSView inherits from NSResponder - now you know why).
It's in the nib file so you can override the typical behavior. The Cocoa Framework is used for the Mac too so programmers might want to have a single object handle keyboard input rather than letting each view handling the keyboard input itself. This is rarely used in iPhone programs directly, because you typically want what the user touches to respond to user interaction (redraw itself) and pass on updates. So you can usually just ignore it in the nib file.
C. What is a Delegate?
What does a person do when they delegate? They tell someone else to do this job for them and report back. People delegate all the time. I delegate fixing my car to a car mechanic. I delegate cooking dinner to the cook at a restaurant I'm dining at. "Johnson, I need you to write that TMI Report for me" said my boss delegating to me for I was company expert on TMI. Classes in the code are no different.
The delegate in the Interface Builder is the Application's delegate. The UIApplication class is going to hand off lots responsibilities to it by sending messages to methods defined in the UIApplicationDelegate Protocol. For instance if your delegate implements the applicationDidFinishLaunching: method it'll receive a message after the instance of UIApplication has initialized and finished its startup routine.
D. Where is the drawing code?
Apple has provided with the Framework in classes like NSView, NSWindow, NSTableView and it's not open-source so you can't view the source code. But the reason the window launches and appears when your first run an application built on one of Apple's templates before adding your own code is due to what occurs in the file main.m.
int main(int argc, char *argv[]) {
NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
int retVal = UIApplicationMain(argc, argv, nil, nil);
[pool release];
return retVal;
}
The call UIApplicationMain(argc, argc, nil, nil) starts everything rolling. It loads in the nib file to unfreeze the UIApplication object and other objects in the nib file. Then it asks the application to start it's main loop. Once unfrozen the UIApplication object (the nib's owner) then tells it's MainWindow to display on the iPhone Screen and keeps the UIApplicationDelegate in the loop about what's going on.
Well that's my answer to 1). Took a while to write I hope it helps. One thing that really helped my understanding was: creating a new Window-based Application project, deleting the MainWindow.nib and then attempting to recreate it from an empty nib file, so that it functions the same way.
Here goes:
In Interface Builder:
The "file's owner" is the Objective-C class to which your interface belongs. Usually for a view controller this means the custom view controller subclass you're creating.
The "first responder" is mostly there for behind-the-scenes handling of events; it's used to figure out when your class and interface handle events, and when to pass them up the responder chain.
A "delegate" is a general term for any object which receives messages about the actions of another object. In Interface Builder, it can sometimes be used to pass actions around between objects, or can refer to the "app delegate," which is a class that exists in almost all iOS projects and receives messages about the behavior of the application itself.
To handle events from your GUI components, the generally accepted thing to do is to define a method with return type IBAction in your view controller implementation, then hook it up to an event from a component. Then when that event is triggered, your method is called. It's not usually necessary to break them out into a lot of separate files unless you have a very complex structure.
Not quite. If you have another table view, you can call it myTableView, but you should still hook it up to the same table view delegate and data source, and the method name doesn't change. Let's break the first part of this method signature down:
The (NSInteger) means this method returns an integer
The phrase tableView: is part of the method name, and shouldn't be changed. A table view will always call the method tableView:numberOfRowsInSection: for the information it wants, so changing to `MyTableView* would break.
(UITableView *) means the first argument is of type UITableView
tableView means that the name of the variable inside this method for the calling table view is tableView
Think about reading through the View Controller Programming Guide - it covers a lot of these concepts and links to more documents that explain delegation, table views, etc.
1.) File owner is the (generally) UIViewController subclass associated with the View you are building in IB (what you call GUI builder is actually termed Interface Builder)
First Responder is generally used in the background by the program to indicate what has control at the moment (generally don't do much with this)
The delegate is the file that receives the actions done on the view (and thus must implement how to handle these), (see below)
2.) Generally you will have a ViewController code file for each Interface Builder View (the File Owner). Generally this will be where the actions are handled for specific components (say, clicking on a button). You will set up variables (and methods for button clicks and etc) to handle each component from IB (a textfield or button is an IBOutlet, while an action like clicking on a button is an IBAction) As far as best design, I believe you should have a delegate for each view that does all the above, but I generally just use the ViewController as the delegate and implement it there (for relatively simple views)
3.) No, the parameter name (which is what tableView and MyTableView are in your examples) are used inside the function to indicate the value that you passed it. When you call this function you would call it like [myTableView numberOfRowsInSection:2]; and inside the function anything you needed from "myTableView" is actually referenced by the parameter name tableView...That is for any function, but for UITableViewDelegate methods (like the one you are referencing, it will be called automatically by the UITableViewController if it's delegate is set to the file you define this function.
Wow looking back thats some blocks of text, my best advice would be to get Beginning iPhone Development by Mark and LaMarche, it addresses all this very well.
I'd also suggest looking at some of the very basic examples in the Apple documentation to get a gist for how Interface Builder and delegates are properly used.
Edit: as a commenter pointed out, the Stanford iOS course is fantastic and where i learned the basics (along with the book above)
See my answer to this question for an explanation of what "loading a xib file" means and the meaning of File's Owner and outlets. It's perhaps a bit advanced for a beginner, but if you really want to know the "what" of what's going on and figure out the "why do it this way" for yourself, it's probably a good read:
Put a UIView into a UITableView Header
I have a common application pattern: user enters data in the main view controller, then views it in a table in a modal view controller, where rows can be deleted or modified. I was following the general design strategy from the Stanford iPhone course, but somewhere things went off the rails and all I've been getting is SIGABRT's and exceptions like "Illegal attempt to establish a relationship 'xyz' between objects in different contexts."
As in the Stanford course, I use a singleton class called "Database" which should return the same context whenever requested. So the first commands in my viewDidLoad method on the main view controller are:
dbsingleton = [Database sharedInstance];
nmocontext = [dbsingleton managedObjectContext];
nmocontext is an ivar I use throughout the view controller. When the user wants to see the other view controller, with the table, I alloc-init it, then present it modally. (It has an NSFetchedResultsController that supplies the data from my store.) I've tried various strategies here:
I've made the NSFetchedResultsController a retained property set by the main view controller
I've made the NSManagedObjectContext a retained property set by the main view controller; and
I've used the singleton internally by repeating those two lines of code above at the beginning of the table view controller's viewDidLoad method.
Whichever I go with, the one problem I just can't solve is that after the user closes and deallocs the table view controller (and its NSFetchedResultsController), I start getting crashes in the main view controller when the store is accessed (like the "Illegal attempt" error mentioned above).
What are best practices for dealing with this common application pattern? I am still hoping to make this application iPhone SDK 3.x compatible, but I do seem to have fewer crashes when I'm using iOS 4 -- if there are underlying issues with 3.x that are causing me problems, please let me know and I may target iOS 4 only.
Thank you!
This is just a guess but I assume the following problem for your crashes after closing the tableview:
You declared a property
#property (retain, nonatomic) NSManagedObjectContext* nmocontext;
do you properly release the ivar nmocontext in dealloc?
If yes your problem is the assignment
nmocontext = [dbsingleton managedObjectContext];
This never retains nmocontext within your viewcontroller but you release it on dealloc.
Second:
"Illegal attempt to establish a relationship 'xyz' between objects in different contexts."
This is not a memory management issue, but you probably created another new context to add objects (like in the apple core data iphone samples) and tried to set a NSManagedObject as relationship from a different context.
It sounds like you don't have your singleton properly configured.
A singleton should override release to do nothing such that when it is sent a release message nothing happens. If you do not override release then any random piece of code anywhere in the app can kill the singleton and defeat the entire purpose of using a singleton. The next time you call singleton, you actually get another new object which in this case also returns a new managed object context.
See Cocoa Fundamentals Guide: Creating a Singleton Instance.
Singletons are powerful and flexible but very easy to do wrong. They are so easy to screw up that many experienced developers simply refuse to use them. If don't have experience with them, don't use them when you are just starting out.
While fixing third-party code I've discovered a really brilliant idea) Guy was using 2 appDelegate objects in project xibs. I assume he thought that this would be some kind of singletone or such. But after some rethinking of that piece of code, I found that there is no technical restrictions on it.
Here is my example: simple project with navController and 2 views. Each with it's viewController. When app launched, first view is on screen. When user taps button, second view is pushed to navController. For now there is appDelegate object in MainWindow.xib. Now, if you'll add just the same appDelegate object to second view's xib. Now right when second view is pushed, you can see that one more instance of appDelegate is created and destroyed (if you'll override init and dealloc methods and insert log there).
Here I'm very surprised. Does it mean that only one appDelegte instance can be created? If yes, then why? appDelegate is just a NSObject subclass implementing UIApplicationDelegate protocol.
The appDelegate object created by xCode on every iphone project is the entry and exit point of an application. It does not make sence to have more than one instance of this class, if you do (besides perhaps some application settings being lost) which class does the applicaiton delegate to? Why can you only make one? Most probably this is because the class is implementing a Singleton patterns under covers so ensure only one instance of the app delegate is made, i bet that even when you try to alloc another one of these, the original app delegate is the only one kept. You can probably dig around the docs and find more info on apples site at http://developer.apple.com/iphone
UIApplicationDelegate is a protocol and doesn't have state in itself, thus there's nothing that prevents you to have several of them. Contrast this with UIApplication that has state and
provides sharedApplication singleton accessor
It should be totally possible to replace UIApplication's delegate property on the fly. I don't see much of the benefit, though.
I think what's happening here is that there is an instance of the AppDelegate class in the second Nib, but no other objects are retaining it. Therefore it gets created and immediately released. If you added a retained property to the view controller that connected to the AppDelegate, then it wouldn't get released immediately.
You can have multiple objects that implement the UIApplicationDelegate protocol, but it's not usually done because 90% of the behavior would be identical in all cases.
I think you could do something along these lines:
Note the old UIApplication.delegate.
Create your instance of UIApplicationDelegate with the old delegate as parameter.
Make sure to call the old delegate in each method you implement.
Make it return the old delegate in the - (id)forwardingTargetForSelector:(SEL)aSelector method.
Replace the [UIApplication sharedApplication].delegate with yours.
It replaces the original app delegate with your, making sure that the old delegate will still be called, especially if you did not override each and every method the UIApplicationDelegate protocol defines.
I found out this:
applicationDidFinishLaunching (an delegate method of the UIApplicationDelegate Protocol) seems to be called BEFORE my views from the nib file are loaded completely. So I tried all the day to change an image of an UIImageView right after my app launched in the iPhone simulator, but nothing happened.
Then I wrote a little action method that I call with the press of a button. And then it happened: WORKS!
So the applicationDidFinishLaunching delegate method isn't really the right place for stuff that has to be done after the app is really "ready". I gues there's something better that waits for the nib to be loaded completely. but where? and what?
I gues there's something better that waits for the nib to be loaded completely. but where? and what?
For application specific things like global settings, preferences, etc., -appDidFinishLaunching is the right place.
For UIView specific things, you typically use the -viewDidLoad method in a UIVIewController subclass. It is pretty much the only place you are guaranteed that the nib file is loaded, the IBOutlets are initialized and the IBActions are attached.
This is difference from the Mac OS X world, where -awakeFromNib was the place to do it.
Hey until your views and their view controllers instantiated you can't modify their ui. However just for the sake of your problem you can always declare the uiimageview as a property of your app delegate class and initialize it in the appDidFinishLaunching event. But that's the worst practise. As on the iPhone which has limited memory always lazy load ie: only initialize objects when and just before they are actually required by your UI. So ideally you should be doing this in the viewDidLoad event of the view where you want to use this UIImageView.
applicationDidFinishLaunching is usually used for stuff like database file checks, opening database connection, populating global variables, any other application wide logic, checking for an available Internet connection etc