Re: Design Question: Bindings & Custom Views
Re: Design Question: Bindings & Custom Views
- Subject: Re: Design Question: Bindings & Custom Views
- From: Cathy Shive <email@hidden>
- Date: Thu, 28 Aug 2008 14:15:02 +0200
On Aug 28, 2008, at 12:26 PM, Oleg Krupnov wrote:
I think there are times when it's appropriate to have wrapper
objects - that
are view related - for your model objects. In an image browser,
it's likely
that there is a "thumbnail" object that draws "image" objects.
Yeah, maybe "view-related wrapper objects for model objects" is the
right term.
In your image browser example, this problem sounds as follows: where
to store the cached thumbnail images, to avoid re-creating them anew
in each drawRect call? Also, if a thumbnail is in process of dragging
inside the custom view, where to save the flag that the thumbnail
should be highlighted, the next time we draw it in drawRect?
You can go about this several ways. the "crude" way ;) is to have a
thumbnail for each image that needs to be drawn and have the thumbnail
cache a bitmap (maybe two or three different sized bitmaps for
different zoom levels) for each image. So the thumbnail just creates
them once and then keeps them around as long as the image is on the
screen for quick drawing.
A less crude way is to implement some type of caching system - so, if
the images are drawn in several views at the same time, all the views
can share a centralized cache of bitmaps.
As far as the view keeping states like which objects need to be
highlighted, the view can set a "isHighlighted" flag in a thumbnail
when it is selected, so the thumbnail can draw itself differently, or
the view can keep track of the selected image indexes and draw
selection highlights itself.
If you look at the design of NSTableView, it keeps track of which row
indexes are selected and draws each highlight right before it draws
the "cells". If you are customizing the NSCell drawing in a table
view, the cell object can check if it "isHighlighted" and adjust its
drawing based on that. The return value of "isHighlighted" is
something that the view determines for the cell.
I thought this kind of problem should be well-known and commonplace
among Cocoa developers...
I think this is more of a general interface widget design problem than
a Cocoa problem. Cocoa developers get this kind of GUI behavior out
of the box - NSTableView, IKImageBrowser, etc., so it won't come up
unless you're doing something very custom - as I'm guessing you are.
Looking at the API for these classes can certainly lead you in the
right direction for designing your own custom views, if you're looking
for the "Cocoa" way to do it.
Also, I have to ask, but is it possible for you to use a pre-made
object like an NSOutlineView for your UI?
So maybe your custom view creates "thumbnails" for the shapes it
needs to
draw and keeps the view-related properties and states in those
objects -
instead of adding them to the shape objects themselves? It's a
little crude
- but from what I can understand about your problem - it could be a
place
for you to start separating the model and view in your design.
I am not sure I understood this phrase. Why is it crude? Anyway, I am
looking to solve the problem in the standard way, not reinvent
anything.
The reason I say it's crude is because what I'm suggesting to you is
to have your view make a separate "thumbnail" object for each model
object you need to draw. You can use this object to cache things and
to keep track of states of each individual object for the view. It
will work well as a way to keep the view related properties out of
your model. This wrapper class will also make the needs of your view
very clear. Eventually, you can evolve the design of your view so
that it can handle all of the states, positioning, hit tests, caching,
etc. itself, maybe eliminating the need for a wrapper thumbnail class
altogether.
I usually start with the most simple, or crude (maybe that was the
wrong word ;)) solution and evolve the design from there.
Again, there is no standard Cocoa way to design a custom view like
this - but taking a look at how some of the comparable Cocoa GUI
widgets are implemented can give you some good hints. I've learned
tons from NSTableView - it's a very flexible design and can be used to
display any model object you can throw at it. Look at how NSTableView
and the IKImageBrowser use delegate and data source designs and how
they work with "cells" - their "thumbnails" - to draw.
If you can use one of these widgets instead of implementing your own
with very similar behaviors, that would be the best solution - but I
certainly understand that there are types of interactions that are
very custom and then you need to roll your own - but even in this case
you can use NSTableView or IKImageBrowser for inspiration.
http://developer.apple.com/documentation/GraphicsImaging/Reference/IKImageBrowserView/IKImageBrowserView_Reference.html#/
/apple_ref/occ/cl/IKImageBrowserView
http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Classes/NSTableView_Class/Reference/Reference.html
Cheers,
Cathy
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden