UIView as opposed to UIViewController...

  • I get indications from reading that you shouldn't really subclass UIView in general or to do routine things,  and that any time you implement drawRect in the subclass of a UIView,  you are taking a performance hit compared to doing some drawing in other ways?

    is this true,  in the case of doing this in the ViewController,  is this below more efficient?  or better?  or what?

    - (void)viewDidLoad {
        [super viewDidLoad];

    trailersViewPlane = [[UIImageView alloc] initWithImage:nil];
    trailersViewPlane.frame = self.view.frame;
    theBounds = CGRectMake(0, 0, trailersViewPlane.frame.size.width, trailersViewPlane.frame.size.height);
    [self.view addSubview:trailersViewPlane];

    then drawing within an NStimer loop in this added subView inside the viewController?  (the subview bounds are as big as the whole view)

    etc....

    I guess i am not sure which way to go..  (do everything in a UIView subclass,  or do everything in a UIViewController subclass.)

    it doesn't seem like anything you do in the controller,  is easy to get to draw in a UIView subclass,  and maybe equally hard to get stuff to translate over to the controller if you do a lot of work in the UIView...

    i'm just lost as to how an NSTimer and a looping set of code should be worked into these two classes..  should it be in the UIView? or the Controller?  seems like it should be in the controller,  but then really all the work has to be in the controller, since you can't even call the drawRect while in the controller,  so what would you do in the UIView?

    any of that make sense?

    thanks in advance,
    Jon.
  • Am 07.03.2010 um 03:57 schrieb Jon:

    > I get indications from reading that you shouldn't really subclass UIView in general or to do routine things,  and that any time you implement drawRect in the subclass of a UIView,  you are taking a performance hit compared to doing some drawing in other ways?

    No. Where does it say that?

    A view draws data (like an image) but should know nothing about any model (that is is an image of a person record).
    A view controller feeds the data (image of person) to its views.

    So, if you have a special drawing ou need to perform subclass a view and implement drawRect.

    > is this true,  in the case of doing this in the ViewController,  is this below more efficient?  or better?  or what?

    Your example just adds a subview, nothing else. It make no sense for your question as you don’t draw anything.

    > then drawing within an NStimer loop in this added subView inside the viewController?  (the subview bounds are as big as the whole view)

    NSTimer? What? Why? Please explain what you want to do.

    > etc....
    >
    > I guess i am not sure which way to go..  (do everything in a UIView subclass,  or do everything in a UIViewController subclass.)

    Usually neither. You share the work between them.
    Please read this:
    http://developer.apple.com/iPhone/library/documentation/General/Conceptual/
    DevPedia-CocoaCore/MVC.html


    > it doesn't seem like anything you do in the controller,  is easy to get to draw in a UIView subclass,  and maybe equally hard to get stuff to translate over to the controller if you do a lot of work in the UIView...

    If your view has to do "a lot of work" something is wrong.
    The view just draws information. It does not work on them.

    > i'm just lost as to how an NSTimer and a looping set of code should be worked into these two classes..  should it be in the UIView? or the Controller?  seems like it should be in the controller,  but then really all the work has to be in the controller, since you can't even call the drawRect while in the controller, so what would you do in the UIView?
    >
    > any of that make sense?

    No. Because you did not tell at all what you try to achieve with your timer and view.

    atze
  • On Sat, 06 Mar 2010 19:57:32 -0700, Jon <tramblin3...> said:
    > I get indications from reading that you shouldn't really subclass UIView in
    general or to do routine things,  and that any time you implement drawRect in
    the subclass of a UIView,  you are taking a performance hit compared to doing
    some drawing in other ways?

    You could be misreading whatever you're reading. Implementing drawRect in a
    subclass of UIView is *how* you do custom drawing.

    Besides, don't optimize prematurely. Just write your program and then see
    what the performance is actually like.

    m.

    --
    matt neuburg, phd = <matt...>, <http://www.tidbits.com/matt/>
    A fool + a tool + an autorelease pool = cool!
    AppleScript: the Definitive Guide - Second Edition!
    http://www.tidbits.com/matt/default.html#applescriptthings
  • You've misread. The performance note is that if your view does not
    need to draw, then you should not implement -drawRect:. A view with an
    empty -drawRect: method consumes more memory and requires more
    processing time to display than the same view that does not implement -
    drawRect: at all.

    But if you need to draw, you need to draw. All other methods of
    getting content into a UIView (or more specifically the view's
    CALayer) consume similar processing time in most cases.

    --
    David Duncan @ My iPhone

    On Mar 6, 2010, at 6:57 PM, Jon <tramblin3...> wrote:

    > I get indications from reading that you shouldn't really subclass
    > UIView in general or to do routine things,  and that any time you
    > implement drawRect in the subclass of a UIView,  you are taking a
    > performance hit compared to doing some drawing in other ways?
previous month march 2010 next month
MTWTFSS
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31        
Go to today