I have a custom uiview subclass that gets the data it needs to display from a datasource which is a subclass of nsmanagedobject. Is there any way that the nsmanagedobject subclass can hold a pointer to the view? I would like to do this so that the view controller can get some information about the frame size of the uiview by asking the datasource how much space its view takes up.
The major flaw in the design you are describing is that you have a UIView communicating directly with a data object. This goes against the basics of MVC and it's very likely you can achieve whatever it is you need by introducing a controller between these two elements. Please elaborate a little more about the frame size you're trying to calculate for a more detailed answer.
Related
Is there some "best-practice" way to add subviews to a UIScrollView?
For Example:
I have a UIViewController which loads images with corresponding description from a server.
Those images+descriptions should be added in a horizontal scrollView.
When the data is loaded, should I create a method in my UIView to handle this stuff,
or is it more convenient to do this in my UIViewController?
Your view controller would be an most appropriate place to handle this, as controllers should connect your view (the scroll view) to the data (the images).
If the scroll view's layout is simple, it could be done entirely with the controller. But, if the layout is complex, you may want to consider subclassing UIScrollView and handling some of the layout there (similar to how UITableView works).
For more info on standard application architecture, read Concepts in Objective-C Programming on Apple's developer site.
By my way of looking at it, the separation of concerns would break down like this:
the UIViewController is responsible for getting the images and handing them to the UIView
UIView is responsible for displaying them.
So the -addSubview: is a view implementation detail, should go in the view, and be opaque to the controller.
There is plenty of opinion that both UIViewController and UIView are confused and intertwined in such a way to make them both part of the conceptual "view" (in a MVC sense), but I think it's still cleaner this way.
As you can see, opinions differ. :) Personally, I despair of MVC, and think Model-View-ViewModel to be a much clearer, cleaner, and more sensible way of approaching all this.
UICollectionView is same as that of UITableView except it is meant to display Images and its description.
Here is what you can do.
Create a UICollectionView, it is the subclass of UIScrollView. SO there is no need of UIScrollview.
Since you need image and description both for each item, I will recommend delete the UICollectionViewItem from UICollectionView.
Create a seperate custom UICollectinViewItem class, define UICollectionItem in .xib file (UIImageVIew and UILabel).
When you define the datasource method "– collectionView:cellForItemAtIndexPath:" define the UICollectionVIewItem class here. Exactly we defines custom UITableVIewCell.
I am gonna design a component in IOS, in which we will have Table view and Grid View; means user can see his data in table or grid. So what i am doing is i added a UIViewController and added two child view controller one for table and another one for collection view. I am handling everything using UIViewController only. Its means when user wants to use my component he has to add as a child view controller only. My question is that "Is it the best practice to use UIViewController like i am doing or Should I convert everything to UIView because UIView is light weight." I am gonna write only presentation logic in my component. We will get data from outside using delegate. And if i should use UIView then when should i use UIViewController?
Thanks
Your current approach is correct.
UIViews should do one and only one thing: paint a view when asked to.
UIViewControllers are more complex. They are are responsible for setting up views with any data they need to do their job, compositing multiple views (or view controllers) together if needed, responding to events from view components or from the device in general, and communicating with the rest of the code/system.
Because your code wants to show two different kinds of information, it fits the UIViewController much better than the plain UIView style.
As you've pointed out, Apple themselves have many examples of UIView subclasses that have delegates and do complex things. However, if you're writing a new component and it is complex (as yours is), I seriously recommend going for the UIViewController approach.
A note on history: Apple used to be of the advice that UIViewControllers should only show/composit UIViews and not other UIViewControllers (even though, confusingly, they didn't always follow their own advice!). This would align with their making of some quite complex UIView subclasses. However, they changed this stance a while back, and added support to UIViewControllers for compositing other UIViewControllers' views inside them. If Apple's stance had always been as it is now, you might find that some of their UIView subclasses were implemented as UIViewControllers!
As an experiment, it would probably be quite educational to try and implement your component both ways. I predict that you'd find UIView approach more unwieldy, with you having manually re-plumb some of the 'wiring' that you'd get 'for free' with the UIViewController approach.
Avoid putting logic in UIView subclass.
As I think you can make grid view by using table view just simply add multiple views on each cells
at time of switching grid to list or list to grid simply check your type and reload tableview
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.
This is an Object Oriented Programming question:
So I am trying to build a UIView class that displays scatter plot. In my current implementation, I've created a datasource protocol that allows the chartView to ask for all the info it needs to plot the its data.
As it stands right now, when someone initializes the chartView and gives it a datasource, the chartview creates/manages several subviews: a 'dotsView' that displays all the data points, a scrollview to which the dotview is added (so it is scrollable), and a 'skeletonView' that sits in the background and displays other chart data like grid lines.
This system at first worked great, however, I decided that i'd like to animate changes to the points, and so i began to contemplate using a collectionView in lieu of the 'dotsView' placed within the scrollview since it'll handle the animation for me. However, as a collectionview would require a delegate, datasource, layout object, etc, all the sudden my chartView seems to looks more and more like a controller and not a view.
Now here is my question: Is it the wrong approach to allow a UIView to coordinate/configure other UIViews, even if those UIViews are a fundamental requirement of the whole? On the one hand, I'd love to preserve the simplicity of my chartView's public interface (initialize the view, give it a datasource, and you're done). On the other hand, this chartView is really not a view anymore, its more like a controller. But I don't want a consumer of my chart to think/treat it like a controller, I want them to use it as a view.
Any thoughts? I'd love to hear the insights of others.
Thanks!
It is totally fine for your ChartView to create a UICollectionView, use it as a subview, and be the data source and delegate for that subview, because the use of UICollectionView is an implementation detail of the ChartView.
Apple does this in UIPickerView. Under the covers, a picker view creates one table view for each component, and the picker view makes itself the data source and delegate for each table view. You can see in UIPickerView.h that it conforms to UITableViewDataSource. You can check that it conforms to UITableViewDelegate at runtime with +[NSObject conformsToProtocol:], or by using class-dump on the UIKit framework. Or you can just write a test app and poke around the view hierarchy. The debugger command po [[UIApp keyWindow] recursiveDescription] will get you started.
UIPickerView is the only view subclass in the iOS SDK that I know of that acts as the data source and delegate for its subviews, but many other UIKit view classes create and manage their own subviews. Examples:
UIScrollView has private subviews for its scroll indicators.
UITableView has private header, footer, section index, and row separator subviews.
UIButton has a private UILabel to display its text and a private UIImageView to display its image.
UISegmentedControl has private UILabel and UIImageView subviews.
UIProgressView uses several private UIImageView subviews to display its parts.
UISlider uses several private UIImageView subviews to display its parts.
UITextField uses private UIImageView subviews.
You answered you own question my friend: Is it the wrong approach to allow a UIView to coordinate/configure other UIViews -- YES!. Views should be casted by a Controller from an organizational stand point IMHO. I would build a Charting Controller that can cast out single and composite views and kill two birds with one stone. The you could route urls to the controller from Ajax to change the data represented in the chart
Please help with this issue that is driving me insane...
I want to populate a table with coredata (in a UIViewcontroleer), not a UITableController, as I need the table to be small and not take the whole screen,
I have tried different approaches, to no avail, and no answer to fix the problems,
Im adapting some code from tutorials that use the whole screen,
example problem, Request for member tableView in something not a structure or union
all my searches for code show the use in iphone with tableview, It would be awesome if you know of a sample for ipad with a view controller (not in split view),
thanks in advance
Your error stems most likely from you using the tableView property which is not available in UIViewController. It's difficult to judge what you did wrong, did you implement the necessary UITableViewDataSource and UITableViewDelegate methods? If you implement these it's no problem to use a UIViewController with core data. But remember the UITableViewController does more than just fill the table, it also resizes the table view when the keyboard is shown. You'll have to do this yourself, too.
UITableView has a rowHeight property that you can set directly or via the delegate method tableView:heightForRowAtIndexPath:.
UITableViewCell has a font property that you can set, to make the font smaller.
UITableView class ref says rowHeight is in points. If that means the same as points in NSFont, it should be easy to coordinate the two.
And of course you can resize the table view’s frame in IB.
So you ought to be able to get what you want using a UITableViewController.
As for the error, do you know what line is generating it? Have you set breakpoints to find out?