iOS Accepting arguments of multiple types?

[moonman239]

Hi, helpful guys. I've got a question.

I'm building a method in which I need to work with properties specific to an object passed as an argument. The object can either be a UIView or a UIViewController.

More specifically, if the object is a view, I need to get a list of its subviews. If it's a view controller, I need to get a list of its child view controllers.

I'm thinking what I can do is make the argument type an NSObject. Then I can use code like this:

if (theObject.class == aView.class) 
{
UIView *theObject;
// do whatever I want to with the view
}
elseif (theObject.class == aViewController)
{
UIViewController *theObject;
// do whatever I want to with this controller
}

 

[dejo]

I would just make the parameter an id type.

Also, I would use the isMemberOfClass: instance method rather than your ==.

 

[chown33]

if (theObject.class == aView.class) 
{
UIView *theObject;
// do whatever I want to with the view
}
[COLOR="Red"]elseif (theObject.class == aViewController)
[/COLOR]{
UIViewController *theObject;
// do whatever I want to with this controller
}

The red-hilited one is very unlikely to work, even after changing "elseif" to "else if" (syntax fix).

I would be shocked and awed if I ever found an instance of a view controller that was actually a class object. I would be dazed and confused if I came across a class object stored in a variable named "aViewController". If you don't know the difference between a class object and an instance of a class, you should probably study that more.


Receiving an object of type id is a very common pattern for Cocoa methods. I suggest looking at some sample code, and using isKindOfClass: instead of dejo's isMemberOfClass: suggestion. You can google both method names to find examples of use (and misuse), e.g. on stackoverflow.

I also suggest reading the reference docs for each method.

Finally, be prepared to make a test case. You should be able to predict the results accurately, and then run the program and get those results. If that doesn't happen (either you can't predict, or the actual result doesn't match your prediction), you can post a specific question here.

 

[ArtOfWarfare]

I would advise against doing this and instead make two methods - one that accepts a view and another that accepts a view controller.

But if you feel it's best to have a single method, I'd add to what dejo and chown have said and say that if the passed in object is of neither class, that @throwing an exception may not be a bad idea. I rarely suggest using exceptions though as they generally are a sign of lousy code, in my opinion.

 

[PhoneyDeveloper]

+1 on two methods.

 

[MattInOz]

Why not just accept UIViewControllers?

I can think of a Apple View container that takes generic views only special sub-class UIViews like UITableViewCell.

 

[TheWatchfulOne]

I would just write one method and not two. One method would make your application more simple.

The OP may not know until run time which method needs to be called.

I would just have one method that accepts an object of type id as deja said. Use isKindOfClass: as chown33 said to determine the object type.

I would also do what ArtOfWarefare said and handle the case where the object is neither a UIView or a UIViewController.

But if you have to use introspection, I would use it inside the one method instead of using to figure out which of two methods to call.

 

[dejo]

I think it would help us to suggest better answers if moonman239 were to give us some background/context on why they are needing to do this. What is the purpose of this method and what kind of things are you planning on doing inside your if/else blocks?

 

[moonman239]

The red-hilited one is very unlikely to work, even after changing "elseif" to "else if" (syntax fix).

I would be shocked and awed if I ever found an instance of a view controller that was actually a class object. I would be dazed and confused if I came across a class object stored in a variable named "aViewController". If you don't know the difference between a class object and an instance of a class, you should probably study that more.


Receiving an object of type id is a very common pattern for Cocoa methods. I suggest looking at some sample code, and using isKindOfClass: instead of dejo's isMemberOfClass: suggestion. You can google both method names to find examples of use (and misuse), e.g. on stackoverflow.

I also suggest reading the reference docs for each method.

Finally, be prepared to make a test case. You should be able to predict the results accurately, and then run the program and get those results. If that doesn't happen (either you can't predict, or the actual result doesn't match your prediction), you can post a specific question here.

Thanks. I meant "aViewController.class."