I've run across a couple of similar questions here regarding getting an animated MKOverlayView working property with decent performance (e.g., an animated radar overlay). However, while the answers have helped lead me in the right direction, I still don't fully grasp what I'm missing yet.
I've been trying to get this UIImageView method working, which simply adds an UIImageView as a subview of the MKOverlayView, then adds the necessary images in the animation sequence to its animationImages property. This doesn't seem to work for me as the UIImageView and its associated images are never rendered. I've even tried calling setNeedsDisplay on the overlay view which also doesn't help. In my instance, the images used in the animation have to be loaded from a remote server first and are updated fairly frequently.
There's also this method that suggests using cocos2D to setup an animated sprite, which I'd like to avoid if the above method with UIImageView works successfully.
I've been struggling with this for two days straight now, so there's likely something I'm totally missing? Do I need to use Core Graphics to do the drawing similar to how it's performed in the main drawMapRect:zoomScale:inContext: method (which I've also tried but didn't work)?
Maybe you can try this. Subclass the MKCircleView and animate a UIImageView added on it with Core Animation. It works well with the map moving around and scale with the map zoom in and out.
http://yickhong-ios.blogspot.com/2012/04/animated-circle-on-mkmapview.html
Related
I've been looking at this thread as I'm trying to implement the same thing. However, I see that the Canvas class is implemented as a subclass of UIImageView. I'm trying to do the same thing except in a UIView. How will using a UIView rather than UIImageView affect the implementation of this solution? I see self.image used a couple times, but I don't know how I'd change that since I don't think that is available in a generic UIView.
Yes, you can implement this as a UIView subclass. Your model should hold the locations of the touch events (or the paths constructed from those locations) and then the drawRect of the view can render these paths. Or you create CAShapeLayer objects associated with those paths, too. Both approaches work fine.
Note, there is some merit to the approach of making snapshots (saved as UIImage) objects that you either show in a UIImageView or manually draw in drawRect of your UIView subclass. As your drawings get more and more complicated, you'll start to suffer performance issues if your drawRect has to redraw all of path segments (it can become thousands of locations surprisingly quickly because there are a lot of touches associated with a single screen gesture) upon every touch.
IMHO, I think that other answer you reference goes too far, making a new snapshot upon every touchesMoved. When you look at full resolution image for retina iPad or iPhone 6 plus, that's a large image snapshot to create upon every touch event. I personally adopt a hybrid approach: My drawRect or CAShapeLayer will render the current path associated with the current gesture (or the collection of touchesMoved events between touchesBegan and touchesEnded), but when the gesture finishes, it will create a new snapshot.
In the answer to that question, self.image is drawn into the drawing context first, then drawing is applied on top, then finally the image is updated to be the old image with new content drawn on top.
Since you just want to add a UIBezierPath, I'd just create a CAShapeLayer into which you place your bezier path, and place it on top of your views backing layer (self.view.layer). There's no need to do anything with DrawRect.
I would like to show a swipe-able 360 degree view of a product along a single axis by using multiple images stitched together to make it animated.
I'm new to iOS development, and am hoping to get pointed in the right direction to find libraries or built-in methods that could help me achieve this. I'm guessing this is a fairly common task, but I'm not even sure of the correct terminology. (I'm dabbling in RubyMotion as well, so that would be a bonus if it could work using that approach.)
how i might do it:
get an image showing up in the ui, running on the phone, base case :)
make a 'ThreeSixtyImageView' (subclass of UIView) that contains a big UIImageView.
keep an NSArray of UIImages in your ThreeSixtyImageView class; load up all your UIImages into that array.
keep a number that's an index into that array. when it changes, set the UIImageView image to the UIImage at that array index! hook up a button that increments the index (and show that image) to make sure that works.
add a UIPanGestureRecognizer to track touch state
when the pan gesture begins, remember which image you're on, and where they tapped (as an anchor point)
when the pan gesture updates, subtract the anchor and divide by something that feels nice to get 'how much user wants images to rotate'. this gives you a new image index value.
update your main UIImage with that new image index (into your array)
if there's a step here you don't understand, look in the examples included in the xcode/iOS documentation, and copy their code! the sample code is pretty good, and helped me a lot with editing XIB documents, and learning about GestureRecognizers.
good luck!
I'm developing a iOS project that involves drawing small graphics (lines and paths) on the screen.
I initially chose to use Quartz instead of OpenGL, because I need to display some basic shapes and I need to update them every 5 seconds, so I thought Quartz was better and easier.
I found out that I can't simply draw in a view, but I have to subclass a UIView and draw in the drawRect method.
In my project, the user should be able to pinch and zoom on graphics, so I planned to add a pinchgesture to the view, but I am doubtful about how to redraw everything after the pinch. Do I have to erase everything and re-add the subviews so the drawRect will trigger or is there a better way to do this?
Thanks a lot.
When using Quartz, you technically don't have to subclass the view and replace the drawRect, but it probably is best practice. When you want to redraw your window, just call [self setNeedsDisplay]; (if calling from the subclassed view, or [self.view setNeedsDisplay]; if doing it from the view controller). This will result in calling your drawRect method for you and it takes care of everything for you.
See the setNeedsDisplay documentation for more information.
I've seen a lot of helpful tutorials that show one how to:
make an image move according to a predefined path, or
move the image, a few pixels at a time, in response to a UIButton.
What I want to do is have the image "drift" arbitrarily according to an Vxy velocity I define, then have the button(s) change the velocity. (Yes, I'd have it slow down with time if no action made).
In other languages there might have been a way to do Change Pxy position by Vxy (to ad infinitum) unless button pushed. I believe GET was the command. I can think of a way to do that in iOS I suppose but that would involve setting up a series of 1 sec CGMutablePathRef anims. Alternatively, I have seen some talk of NSTimer: would it be a good practice to introduce some sort of delay: draw, delay, draw, delay.
Request: specific classes or terms I can search in the manuals for myself.
Iirc using uiview's animateWithDuration:completion is cheaper than using core animation. frame is an animatable property. So, yeah I think I would use an NSTimer to call your method for default calculation of the end frame of your view and then call animateWithDuration:completion there.
[deleted bad idea]
I ran across a wonderful tutorial for anyone considering such a project;
http://www.youtube.com/watch?v=nH_Rj152DRM
I believe the key "noob" problem I was having was in not realizing I should declare the instance variable for my sprite/ image in the
-(void) viewDidLoad{
then work on other properties of the animation in touches/ other user events. Once I figured that out, I am now capable of doing the heavy lifting for the rest of the project myself.
I'm working on an iPad-App with ARC which have to display thousands of UIImageViews in a UIScrollView...
When I load them all at once (or more accurately in a queue with GCD), I run out of memory after a while of loading..
Now, I thought i have to use lazy-loading and load only those UIImages which are necessary and a kind of release those which are no longer visible, but I don't know if this is possible with ARC..
Anybody have an idea to do this, or a better idea to handle this case..?
Thanks, tonistair
Make something that implements UIScrollViewDelegate, and in its viewDidScroll method, calculate the currently visible rect from contentOffset and bounds. Then remove things that are no longer visible, and add things that have just become visible (or some other appropriate algorithm). ARC has nothing to do with this.