On 2 Apr 2009, at 22:33, WT wrote:
25 was just a test. The actual app has 2 interlocking 7x7 grids, so
the number of image views is actually 98. I should explain that this
animated laying out of image views happens only once and, from that
point on, the image views all remain in the same
Presuming that this is full-size, It is uncommon to have views that
are so small (the balls must be, what, 4X4 pixels or something?),
I'd say.
No, no, the smallest ball is 13x13 pixels and the whole picture is
nearly 320 pixels on each side. I had to shrink the picture to such a
small
I do have a custom UIView for the grid, but it doesn't do much for
now, since I'm currently using the UIImageView instances to do the
heavy lifting.
You are aware that you can pass an array of UIImages to a UIView and
it will animate them at whatever speed you tell it, right? It's not
I do have a custom UIView for the grid, but it doesn't do much for
now, since I'm currently using the UIImageView instances to do the
heavy lifting.
You are aware that you can pass an array of UIImages to a UIView and
it will animate them at whatever speed you tell it, right? It's not
On Apr 3, 2009, at 10:15 AM, WT wrote:
I do have a custom UIView for the grid, but it doesn't do much for
now, since I'm currently using the UIImageView instances to do the
heavy lifting.
You are aware that you can pass an array of UIImages to a UIView
and it will animate them at
On Apr 2, 2009, at 8:11 PM, WT wrote:
25 was just a test. The actual app has 2 interlocking 7x7 grids, so
the number of image views is actually 98. I should explain that this
animated laying out of image views happens only once and, from that
point on, the image views all remain in the
Thank you, Glenn and David.
In a perfect world, the application would be designed in a way that
completely abstracts how the animations are going to be implemented
but, alas, I'm not that experienced yet, so I am still trying to
ascertain what the best approach to go with is, so I won't
25 was just a test. The actual app has 2 interlocking 7x7 grids, so
the number of image views is actually 98. I should explain that this
animated laying out of image views happens only once and, from that
point on, the image views all remain in the same place, though each
image itself is
This is not doing exactly what you think it is.
You are certainly right that UIKit calls should /always/ be made from
the main thread, but the performSelector:withObject:AfterDelay
method actually performs the selector on the same thread that you call
it from, not a separate thread. This
Indeed. I actually already knew that -
performSelector:withObject:afterDelay: executes in the caller's thread
but, in n my haste to throw together a quick test, succumbed to my
thread-safety obsession (thanks to years of Java programming). No
harm, though.
I ended up doing something
Indeed. I actually already knew that -
performSelector:withObject:afterDelay: executes in the caller's thread
but, in n my haste to throw together a quick test, succumbed to my
thread-safety obsession (thanks to years of Java programming). No
harm, though.
I ended up doing something
Hello,
in the drawRect: method of one of my app's UIViews, I'm drawing a grid
of images, one per grid point. The code below works great except, of
course, that it ignores the animating argument. I would like to
animate the drawing by drawing what appears to the user as one image
at a
Hello again,
in anticipation that the answer to my question might be to add
UIImageViews as subviews rather than to draw UIImages from within the
superview's drawRect:, I tried the following little test, which works
like a charm. The question remains, though, whether this is the right/
13 matches
Mail list logo
