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 hav
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 same
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 whate
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
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 siz
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 p
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 an
25 image views seems a /little/ on the high side (probably not enough
to cause major worry), but other than that it seems like a perfectly
good approach.
If you haven't already, and it's something that possible, you might
want to consider what to do (i.e. should you try to stop the timer) i
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 sligth
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 sligth
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
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/
bes
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 time
14 matches
Mail list logo
