0

I have a blank!

I have a ViewController where I need to insert 3 subViews. No issue so far. In each of those subView, I need to add a UIView with some code (to draw a chart, for example).

My problem is here!

How do I initialise the UIView that have the chart methods? That view does not handle viewDidLoad because it's not a ViewController.

Thanks,

Rui

Fattie
  • 30,632
  • 54
  • 336
  • 607
Rui Lopes
  • 2,552
  • 6
  • 32
  • 48

1 Answers1

0

You should probably subclass UIView and build your custom view there. Then you can give this view the functionality you want, in this case the chart methods you mentioned. If you call it e.g. ChartView you can instantiate and add it to your view controller's view just like you would with a regular UIView instance, something like (assuming you're in your view controller, e.g. in viewDidLoad):

ChartView *chartView = [[ChartView alloc] initWithFrame:frame];
[self.view addSubview:chartView];
nburk
  • 20,293
  • 14
  • 73
  • 116
  • I would incredibly recommend to not do this! Just drag a container view in. Then as nburk says make a UIViewController called say "ChartView". in there and on the scene, make your chart display. – Fattie Oct 13 '14 at 11:13
  • just curios, why would you chose container views over subclassing `UIView`? – nburk Oct 13 '14 at 11:15
  • to me it sounds like these subviews should be fed some data and then be drawn according to the data that they received... that's a perfect case for subclassing `UIView` isn't it? containers are for view controllers, right? that's a case when you want to provide interaction,... or what am I missing? – nburk Oct 13 '14 at 11:19
  • Hi nburk! using view controllers is tremendously easier than using raw UIViews. The whole app could just be a UIView (no view controllers), but we don't do that right. You really "can't fight apple". it's incredibly easier to use storyboard than not use it; it's incredibly easier to use swift than avoid it, and so on! the OP will have to be completely familiar with container views so it's a good opportunity. – Fattie Oct 13 '14 at 11:20
  • Note that on these very old questions for instance people are hassling with the issues of loading custom UIView xibs and so on... http://stackoverflow.com/a/25910881/294884 (indeed note I added a new answer just saying "use container views!") – Fattie Oct 13 '14 at 11:21
  • Hmm, I fully agree that you should go with Apple's tools and frameworks, they usually know what's good for developers, and working against the frameworks is the biggest mistake you can make! However, I still think that this particular case suits better for subclassing `UIView` since the view most likely will have to be drawn in a custom way, that's something that you can't cover in IB anyway. Best way here might indeed be to combine our two approaches, subclass `UIView` and then display the custom view in a container... – nburk Oct 13 '14 at 11:23
  • "However, I still think that this particular case suits better for subclassing UIView since the view most likely will have to be drawn in a custom way" yes 100%, you may have to make one (likely many( UIView subclasses, to, use in the "new view" (i.e. the container view). **that's what I meant in my first comment here!!!!** – Fattie Oct 13 '14 at 11:26
  • It's worth nothing though. Very often with trivial things like imagine it's a bar chart. Today you'd just do that with "squares of colour" (I mean, just UIViews with some colour), and you'd just trivially generate the sizes and layout of those, in the "container'd view controller" in question. In this way, the result would be an amazing new View Controller (EasyChart), that you could use **absolutely anywhere** at any size etc - including within a contained view as in the use case described. – Fattie Oct 13 '14 at 11:28
  • it's funny here's an ancient QA about using tricky custom UIViews...http://stackoverflow.com/a/4051895/294884 (i just marked it "historic!" :) ) – Fattie Oct 13 '14 at 11:29