It is possible to call one method from inside another. I've implemented this function
- (void)pickAndDecodeFromSource:(UIImagePickerControllerSourceType) sourceType
I want to call following method inside the above one.
- (void) viewDidAppear:(BOOL)animated
I think I understand what you're asking... the question is.. well not there. Nonetheless:
What I think you're asking: "How do I call viewDidAppear from within another method...?"
- (void)pickAndDecodeFromSource:(UIImagePickerControllerSourceType)sourceType
{
...
[myController viewDidAppear:YES]; //Simply call it on whatever instance of a controller you have
...
}
If the question was actually "How do I override viewDidAppear?" then this is it:
- (void)viewDidAppear:(BOOL)animated
{
[super viewDidAppear:animated];
//YOUR STUFF
//GOES HERE
}
You can always call the delegate methods directly:
[self viewDidAppear:YES]
Called from inside your method should work.
I'm not sure exactly what you mean, but from the nature of your question I am guessing you are new to Obj-C so I strongly suggest reading Introduction to The Objective-C Programming Language if you have not already. If you have, great! What you are looking for is most likely under Objects Classes and Messaging - Object Messaging - Message Syntax
Related
1) For the interface .h file, should I import classes (#import "Person.h") or should I use #class (#class Person)? And I should always use import in the .m, right?
2) Can I get rid of the following methods if I don't use autorotate?
- (void)didReceiveMemoryWarning
{
[super didReceiveMemoryWarning];
}
- (BOOL)shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)interfaceOrientation
{
// Return YES for supported orientations
return (interfaceOrientation == UIInterfaceOrientationPortrait);
}
3) Do I need to separate IVariables from properties when declaring them in the interface? I see both ways being done.
Edit:
What about these methods?
- (void)viewWillAppear:(BOOL)animated
{
[super viewWillAppear:animated];
}
- (void)viewDidAppear:(BOOL)animated
{
[super viewDidAppear:animated];
}
- (void)viewWillDisappear:(BOOL)animated
{
[super viewWillDisappear:animated];
}
- (void)viewDidDisappear:(BOOL)animated
{
[super viewDidDisappear:animated];
}
#class is usually enough in your header file. See this question.
All of those methods are performing their default behaviors, so you can remove them regardless of whether you use autorotation. You would want to keep them if you need to add additional behavior. (Using super means to call the superclass implementation — i.e., the implementation that would be used if you hadn't defined this method. So if you are only calling super and not doing anything else, there's no point.)
It's fine to leave them out, but I think this only works after iOS 4. See this question.
You can use #class for types, but if your class subclasses something you need to import the latter. Likewise for protocols. You will probably need to import the class, e.g. #import "Person.h", at the top of the implementation file. A good rule I can offer: If the compiler chokes here, import!
Yes. As jtbandes points out, the call goes through to super which has a default implementation.
You don't need the iVar declarations if there's a property to go with them, I do without because I don't want to clutter my interface. I think this works since Objective-C 2.0, not since iOS4.0. (I've used this on iOS3.0 for example). Also, omitting iVars helps prevent zombies and maintain the correct retain count - it encourages you to use the right setter. But some times it's good to use iVars with no property and a "#private" declaration if your object needs to store some data but you don't want to expose it. An example I often come across is UITableViewController, which might hold an array to populate it's rows.
I'm new - i'm sorry - but I'm experimenting with multiview iphone apps, and wondered whether the below idea was a) possible and b) sensible.
I want to create a method that can remove and add views based on some parameters - the outgoing view, the incoming view and the incoming class.
- (void)switchViews:(Class)inView:(Class)outView:(Class)inClass{
inClass *tempView = [[inClass alloc]
initWithNibName:#"inView" bundle:nil];
tempView.burgerViewController = self;
self.inView = tempView;
[tempView release];
[outView.view removeFromSuperview];
[self.view insertSubview:tempView.view atIndex:0];
}
This would be called by:
[burgerViewController switchViews:viewMainMenu:viewOptions:ViewMainMenu];
Any help is much appreciated - I have a lot to learn.
Mike.
Your code is wrong, in that (it appears that) you've misunderstood how method names work in Objective-C.
For example, as your method currently stands, it is named:
switchViews:::
That's probably not what you're looking for.
A better name might be:
replaceView:forProperty:withViewOfClass:
Declared, that would look like:
- (void) replaceView:(UIView *)outView forProperty:(NSString *)propertyName withViewOfClass:(Class)inClass;
And you would use it like this:
Class viewOptions = ...;
NSString *viewMainMenu = #"...";
[burgerViewController replaceView:viewMainMenu forProperty:viewMainMenu withViewOfClass:viewOptions];
For more on Objective-C method names and interleaved arguments, check out the Objective-C Programming Language Reference.
Well, your first problem is that you release tempView and then attempt to insert it into the view. Don't release tempView at all, just keep it as-is for insertion into the main view.
What code is correct and why ?
- (void)viewDidLoad
{
/*my code
*/
[super viewDidLoad];
}
or
- (void)viewDidLoad
{
[super viewDidLoad];
/*my code
*/
}
It doesn't really matter that much. It's more about the way you'd like it. Would you want the super to respond first or the self? If it doesn't really matter that hard, do what you like.
It depends on whether you want your subclasses code to execute before or after the superclasses code for that method. I would say it's more common to do your own custom code after the call to super so that your subclasses code follows the superclasses code. Again, it depends on exactly what your trying to do.
I'd say the latter. You want your superclass's code to run first before you run your own.
Or, if you're completely replacing the function, you'd just comment out the call to the superclass's implementation.
I have a subclass of UIView that's instantiated in a XIB file. I need it to do some initialization (settings some variables and creating a subview).
However, I do not always instantiate this view via Interface Builder. I do it programmatically too. In both cases, the initialization needs to be the same.
My designated initializer is initWithValues:.
The question is; where do I perform the initialization?
Since I have to perform it in 2 different locations, I figured I need to refactor it in a separate initialize method (or something like that), and call it from initWithValues:.
But when loading from IB, both initWithCoder: and awakeFromNib are called. From which method do I have to call initialize? Or do I have to call initWithValues: from initWithCoder: and do nothing in awakeFromNib?
You should use initWithFrame: when initializing views (since it's the designated initializer). Hence, if you have initWithValues: make sure you call initWithFrame: from it.
Something like this should work for initializing: ;)
- (void)initialize{
//init your ivars here
}
- (id)initWithCoder:(NSCoder *)aCoder{
if(self = [super initWithCoder:aCoder]){
[self initialize];
}
return self;
}
- (id)initWithFrame:(CGRect)rect{
if(self = [super initWithFrame:rect]){
[self initialize];
}
return self;
}
I was going to add a further explanation, but mplappert's answer is clear enough. Use awakeFromNib if necessary.
That depends on what you need to initialize. As soon as awakeFromNib gets called, all outlets and action connections of your view are established which is not the case in initWithCoder:. So if you need to rely on those connections, use awakeFromNib. Otherwise you can safely do all your initializing in initWithCoder:.
Unfortunately, the above answers don't take into account these things:
- (void) awakeAfterUsingCoder - and the fact it's called after anything is created by the coder (once for every Xib view).
awakeFromNib suffers from the same fate, I've noticed. (The reason I found this)
Another initializing issue is that initWithCoder and initWithFrame can be avoided for custom views. And if they are called, lazy loading (though not as important on views themselves), means you "might" be able to modify values. I believe I've done so in initWithCoder, but if you then initialize values in awakeFromNib, it's undone at least once.
I've gone so far as to:
- (void) awakeFromNib (or didMoveToSuperView);
{
BOOL called = NO;
if(!called)
{
called = YES;
}
}
Another method I use is to simply call the initializer needed, then call my own class or superclass-specific initializer.
I, too, am looking for a dependable one-time place I can rely on. Until then, I hope my headaches save the next person an hour or so.
Steve
-(void)viewWillAppear:(BOOL)animated{
//something here
[super viewWillAppear];
}
Is [super viewWillAppear]; always required? If not when and why do you use it?
First of all, the correct boiler plate should be:
-(void)viewWillAppear:(BOOL)animated{
[super viewWillAppear:animated];
//something here
}
In other words, call super first, then do your own thing. And you have to pass the animated parameter to super.
You usually want to call the super class' implementation first in any method. In many languages it's required. In Objective-C it's not, but you can easily run into trouble if you don't put it at the top of your method. (That said, I sometimes break this pattern.)
Is calling super's implementation required? In the case of this particular method you could get unexpected behavior if you don't call it (especially if you have subclassed a UINavigationController for example). So the answer is no not in a technical sense, but you should probably always do it.
However, in many other methods there may be good reasons for not calling super.
Calling super method provide possibility to execute code in parent class.
Regarding your question according to Apple doc
So, yes, this method required.
In my experience, calling [super viewWillAppear] in the first line, when calling reloadData after that, makes it impossible to retrieve the previously selected row when coming back from a detail view. When [super viewWillAppear] is the last sentence, you can get the selected row and show the previously selected row hint. This happens only when using [tableView reloadData] inside viewWillAppear.
Lets say you have 2 class, a Parent and a Child. Child inherits from Parent. They have a method called greet which returns a string.
Here is what the parent method looks like:
Code:
-(NSString *)greet {
return #"Hello";
}
We want the child to learn from his parents. So we use super to say greet how Mommy would greet, but with our own little additions too.
Code:
// Inherits from Parent
-(NSString *)greet {
NSString *parentGreeting = [super greet];
return [parentGreeting stringByAppendingString:#", Mommy"]
}
So now Parent greets "Hello", and the Child greets "Hello, Mommy". Later on, if we change the parent's greet to return just "Hi", then both classes will be affected and you will have "Hi" and "Hi, Mommy".
super is used to call a method as defined by a superclass. It is used to access methods that have been overriden by subclasses so that the class can wrap its own code around a method that it's parent class implements. It's very handy if you are doing any sort of inheritance at all.