I'm new to iOS and I'm trying to understand how the platform works, so excuse me if I make any dumb questions.
My question is based on the problem present in this post:
Inheritance on view controller Objective c
So far, I understand I can inherit controllers, but can I inherit a view? I think the answer is NO. If that is the case, what is the best way to solve the following problem?
I have a card matching game. Now, I have to expand the game to have a similar card game but with a different deck and rules.
Therefore, I want to reuse the code and have a main controller and 2 inherited controllers that redefine the creation of the deck. Now I need to have 2 different views because the two games have a different number of cards. So, what is the best way to do this? Would I have to copy all the controls from one view to another and modify what's needed?
You can inherit a view just fine. Just create a subclass of UIView when you add a new file and then import that subclass.
Regarding your question, I feel like the best way to approach it would be to have a subclass of UIViewController called something like CardsController which has a deck property and can manage the display and change of cards based on a set of rules defined by you. Then, subclass that view controller further for each of your two games, since they both make use of cards.
You can subclass any kind of object, controllers, views, whatever
ex:
#interface MyCustomView : UIView
#end
If your two different views share a lot of code, then you shouldn't create them separately. They should have a common parent with the common methods and both of them inherit from this generic uiview
Related
I made a subclass of UITableViewController named CalendarTableViewController.h and .m. It shows a list of events within specified range (e.g. all events in 2014). I'd like to have two more view controllers (for month and day) and stack them on top of the first view controller.
Because all three view controllers have similar properties and behaviors, I'd like to subclass my custom view controller. Is this possible?
I'm about a year into developing with Xcode, so I may be missing something stupidly simple. But, all I know is how to subclass UITableViewController. How do you subclass your own custom view controller?
I would appreciate if you could share your wisdom.
Yoshi
In the world of object-oriented programming, objects are categorized into hierarchical groups. Rather than using distinct terms for the different hierarchical levels such as genus or species, objects are simply organized into classes. In the same way that humans inherit certain characteristics as members of family, a class can be set to inherit functionality from a parent class.
When one class inherits from another, the child inherits all the behavior and properties defined by the parent. It also has the opportunity either to define its own additional behavior and properties, or override the behavior of the parent.
Long story short, yes, you can and you should create subclass(es) in such cases. This is how you do in Objective-c in .h file (in your new class)
#interface MySecondController : CalendarTableViewController {
}
In Swift
class MySecondController: CalendarTableViewController {
// subclass definition goes here
}
I hope it helps
In my project, I have two UIViewControllers in a tab bar application, each one contains a UITableView which displays information from RSS feeds. The two view controllers are supposed to be perfectly identical, except for a single NSString parameter (the feed URL).
I know that I can simply copy and paste the code from one UIViewController to another, but I was wondering if there is a better way to do this. I'm not sure if I'm phrasing this correctly, but I think I want to create a separate file which contains a UIViewController "instance" and apply that instance to each view controller in my app.
I'm wondering if something like I'm asking for is possible, and how it would be done.
I'm assuming these 2 view controllers are both installed as tabs of your tab bar controller.
If that's the case, then you want the two view controllers to be different instances of the same view controller class. Identical twins, if you will. Let's call it MyRSSTableViewController. You'd just give the MyRSSTableViewController class a feedURL property, and set that property as part of creating each instance of your MyRSSTableViewController class.
This is a fundamental concept of object-oriented programming, and if you don't get it then you need to stop and do some reading. You might want to check out the "Objective-C programming: The Big Nerd Ranch Guide". That book will teach you programming in C and Objective C from the beginning.
If you already have programming experience in other procedural languages then that book might not be the best choice for you. Tell us about your current skills and we can make better recommendations.
Personally I would just have the title switch and have the data source of the array change based on a bool value. and then call reload when you want to switch.
But the best method is definitely Duncan C's
what you can do is overload the constructor of your UIViewController (just like you would do with any class) and add the url as parameter.
Using this approach, you would create 2 instances of the UIViewController with the only difference in the parameter used when creating them.
Maybe this is a silly question, but I've bumped into it a number of times during iOS Development.
Sometimes I'll develop a view component that I want to use on multiple screens, so I'll decide to subclass UIView and make it something I can use in multiple places.
Then, I start adding functionality to it. Maybe it needs to respond to an NSNotification, or it is supposed to respond to user touches.
At a certain point, I start wondering if I should really be making a UIViewController subclass, and add it to my UI as a child ViewController.
Is there any consensus on where to draw the line between adding some behaviors to a UIView, and when to create a full UIViewController?
I can't tell you about the consensus, but here's my opinion:
Subclass UIView only when...
You want to do custom drawing
You need to customize some behaviour of an already existing UIView subclass
You have special needs for layouting subviews. Most layouting can be done by UIViewController, though.
Maybe for special touch handling that you can't be done with gesture recognizers
Subclass UIViewController in all other cases. You almost always need a controller anyway, for writing glue code that ties together views and models, or for handling user interaction. Consequently, Apple has made it easy in UIKit to let controllers do all the work and to keep views as "stupid" as possible. For instance, it is very simple to nest controllers to create complex view hierarchies, without the need to have a single view subclass.
An indicator that subclassing UIView is not the first thing one should do is the section titled "Alternatives to Subclassing" in the UIView class reference. An indicator that subclassing UIViewController is the preferred thing to do is that there is no such section in the UIViewController class reference :-)
You should use a controller anytime that you need to handle or control data. Views are supposed to be as stupid as possible, not knowing what they are displaying but rather where. You can easily subclass and reuse ViewControllers. A good example, say you need to retrieve a string (or text) from the user throughout your app via a popover controller and a modal. Create a generic subclass of UIViewController that has a view with a textfield and a button. You can then use this view and it's controller in any capacity you need. Reusing it in the popover, modal or anywhere else (and generally passing the data back through delegation). Since you are dealing with data you should not being using a sole subclass of UIView.
From my experience I subclass UIViewControllers more often then UIViews. It is a little difficult for me to understand if you are solely talking about Containers or reuse of views in general application workflow. Either way though it should be the same.
I've used the embedded view controllers to load reusable table views from time to time. I've found that it's useful sometimes but not always. Communication between the two can be cumbersome, like if you want the embedded controller to communicate back up to the container. Delegation makes it easier but still cumbersome. It also limits you to iOS 6, if I remember right iOS 5 and lower don't support embedded controllers.
If it's just adding methods you can use a category to store some extra methods. I do that a lot on NSManagedObjects that I don't want to subclass and if I regenerate the NSManagedObject from the datamodel I don't lose the code in my categories. Gives me added functionality like calculated fields or conversion methods without having to subclass. If you don't need those methods for a particular instance just exclude the reference to the category.
Subclassing never is bad though IMO.
I have a UIViewController that over time has had a lot of delegate events added to it which has made the controller class quite large. The UIViewController class contains quite a few view-management methods that are called from the event-delegate methods to manage the UIView that the controller is managing.
I am now adding further UIActionSheet delegate events to the class. My controller class is getting large and I'm thinking that I should break out the UIActionSheet delegate events and place them in a separate delegate class. This separate delegate class will then have to call back into the view controller class to get the view controller to adjust the view accordingly, using the view-management methods within the view controller. (The view controller accesses a separate model object that the view is representing).
I can see pros and cons to adopting this break-out approach. It feels wrong to be adding more and more delegate events to the controller, but creating separate classes for different categories of events that then need to call back into the controller also seems to introduce an unnecessary layer of complexity and obfuscation. The large controller class is 'simple and straightforward' but feels wrong, whilst using numerous different delegate classes will be somewhat more complex and involved but will result in smaller classes.
Can anyone provide some words of wisdom on this topic, and perhaps point me towards some iOS-specific reading on the matter?
Many thanks.
My approach to this matter is:
Make it work
Make it cleaver
Back to 1.
(Or 1 and 2 both in same turn if you are experienced in a field)
So if code works app looks good but you find that ups some class has 100 methods in it so try different design patters (if you haven`t already) and use those cleaver ideas to make code separation into different classes, delegates, encapsulate them if necessary et.
http://developer.apple.com/library/ios/#documentation/Cocoa/Conceptual/CocoaFundamentals/CocoaDesignPatterns/CocoaDesignPatterns.html
Just in case link to Cocoa Design pattern suggestions and i am from time to time looking into Pro objective c design patterns for ios. Might be not the best book out there but it is based on "Gang of four" design patterns book in ios context.
Hope this helps at least somehow,
Cheers
In the end I created quite a few additional classes for dealing with specific UIActionSheet instances. I created a base class and then subclassed this for each UIActionSheet requirement within the main controller.
The end result looks tidy, and doesn't add too much complexity.
Often, when I'm making my apps, I'm in this situation : I have a UINavigationController, handling the view stack, some UIViewControllers, controlling their respective views...
But when I want to add several custom UIViews in my mainView, I don't know how to manage my code.
Each UIViewController needs to handle one and only one view (wich normally occupy all the screen size), and a view should not control their content (update it a the extrême limit).
You can't neither do this :
[myViewController1.view addSubview:childViewController.view];
So if I want to achieve something like this, what should I do ?
The orange parts have to be 3 instances of the same UIView(Controller?), but with a content depending of a NSObject (User, obviously).
I think this very important to segment your content, this should be an easy problem, but I found a lot of contradictory answers so, what's the best practice to handle this common issue?
Theses orange views should be instances of UIViewControllers in order for it to handle their UITableViewDatasource? Is addChildViewController relevant in this case?
I already found a lot of things which work, but I don't know what should I do...
Also, I'm using xibs.
Thanks in advance if you can help me (and other people I think).
You can do it either way (view or view controller) depending on how you want to handle things. Certainly, you can have one object be the data source for multiple tables, so in that case, you would just add multiple views. If, however, you want to keep your code more compartmentalized, then add view controllers, and have each control its own view -- to do this, you do need to use addChildViewController, and use the methods that Apple describes for creating custom container controllers. Alternatively, you can use container views in a storyboard which makes the process of creating custom container controllers simpler.
You're on the right path... Create separate instances of your subviews, and add them to your view. If you will have more than 3 (for instance, imagine coverview for your music, and you could scroll indefinitely left and right), I'd take a look at UICollectionViewController ... That will help manage cell re-use.
But, if it's just 3, just create three instances with different frames and add them to your view.
Here's how I'd do it:
each orange box will be a custom view (inherits from UIView)
the view will have the label, image and the tableview.
since you are not sure of the number of instances of these views you'd be using, its better to use some kind of tagging, so that you can have one place for the datasource and delegate methods of the tables in these orange views.
in the datasource and the delegate methods, you can make use of the tableView.tag (same as the orangeView.tag property).
I personally dislike having more than one viewController in a view (except the splitVC), probably because I haven't had a such requirement.
I dont see how a uiviewcontroller for orange box would help, over a uiview.
as #James Boutcher mentioned in his answer, UICollectionViews will simplify this issue further.
Why not creating a UIView class and overriding the drawRect method and then adding subView for this class in your myViewController1.view