I have some view controller, that uses my own view class and XIB interface, so the view initializes from coder. In that view controller, when I move the slider, it redraws rectangle, in initial state rectangle is on full screen and when I move the slider to the left, the size of rect become smaller proportionally (from full screen to 10x14 continuously with 4 pixel intervals).
The "slider did change a value" calls some method, that sets new rectangle size end sends "setNeedsDisplay" method. And if I change to "setNeedsDisplayInRect:" method, it not updates all what I need on screen, there is some artifacts. But with debugging it updates all like I want. Tried to send deferent rectangles to update, like:
redrawRect=CGRectUnion(oldRect, newRect);
[cView setNeedsDisplayInRect:redrawRect];
and some others, same story. My question is, which rectangle I need to send in "setNeedsDisplayInRect:" ?
And the second question, how can I accelerate/optimize all that story for smoother animation and less cost?
Already solved the problem 1. The "setNeedsDisplayInRect:" method uses points, and not pixels like I thought.
Related
I have a UITableView and I would like that when they enter a certain area of the device, the cells' content view would appear to be reduced.
Only the part of the cell in this area would be scaled down. How can I achieve that?
I guess it has to use a UIView as an overlay view and apply a transform somehow to the underlying view that crosses it but I have no idea how to do it.
You can take a snapshot of the cell in question (before you leave the table view) by calling snapshotViewAfterScreenUpdates: with argument false on the cell. Now, as you say, you do whatever you want with the resulting snapshot view, including transforming it to be smaller.
Moreover, you can place the snapshot view into the interface and animate the change in its transform as part of the transition to the next view controller. That's what Apple is doing, for instance, in the Calendar app, when a year zooms into a month.
I have a requirement to draw a line on a UIView in IOS with OpenGL ES. But the line that is drawn could be able to move anywhere on the view when it is touched and dragged. Simply the user can re-position the line on the screen. I have no idea how this can be implemented. The line will be drawn with OpenGL ES.
I request all your helps and suggestions regarding this.
The solution is to use a second transparent view positioned over the OpenGL view, which acts as a proxy to your line.
Create a clear view (or a view with 0.0001 opacity) and add gesture recognizers to it. Initially place that view (say sized to 44 x 320), and centered over your line (I'm assuming its horizontal). When the user drags the clear view around, post the new position you want your line to appear in within the OpenGL view then tell it to refresh.
I seem to recall (but am unsure) if you can use gesture recognizers with completely clear views - you may need to make the view slightly opaque (but no visibly so) to get touches, but again just not sure.
I'm in the market for a nice thorough example/tutorial link or demo on programmatically creating and redrawing/resizing on rotation a view with nested tiled views. This means that the root view will need to rotate on rotation, and trigger all nested views to also rotate and resize.
For example, lets say you have a view with forty rectangle views tiled within, Id like to rotate an iphone/ipad and have the forty nested views also rotate (not hard) but more importantly resize and move. A four by ten grid might change to be five by eight.
I'm able to effect this programmatically but I'm finding that the x/y bounds etc are all off kilter.
Please no comments about "But just use storyboards"...
Thanks!
I've found that it can often be a bit of effort to get it working as you'd like/expect. Things to take into consideration are the callback you are using to pick up rotation, there are 3 and they serve a slightly different purpose
- (void)willAnimateRotationToInterfaceOrientation:(UIInterfaceOrientation)orientation duration:(NSTimeInterval)duration
This is probably the one you want to use, at this point when you query self.view.frame (or whatever you use to get the super frame) it will return the value that the frame will be once the rotation has complete. It also takes into account auto-resizing, and it gives you this before the rotation has taken place (ie no visible effect yet). Use this to calculate all the new positions and sizes of the views and set them.
- (void)willRotateToInterfaceOrientation:(UIInterfaceOrientation)orientation duration:(NSTimeInterval)duration
This tells you the rotation is about to happen, but still returns the frame for the current orientation, useful for hiding/showing views, but not for calculating new positions!
- (void)didRotateFromInterfaceOrientation:(UIInterfaceOrientation)fromInterfaceOrientation
This is called once rotation is complete, it returns the new sizes and frames, but if you attempt to reposition views here they will look as though they are jumping around after the rotation is complete.
I'd also recommend playing about with auto-resizing, as this can be a real bitch. I sometimes set the auto-resizing in code as well as in a xib juts to be sure there is no funny business!
If the rectangles are nested in a view controller they should rotate automatically (you probably knew that just thought I add it in case)
I have a UIScrollView over an image at the bottom of my app that acts as a dock with icons that can be scrolled through horizontally. Instead of the harsh edges of the UIScrollView, I would like the icons to fade out for a more aesthetically pleasing look. Being new to iOS development, I don't know if either of these would be valid options:
Create a faded image to use as an overlay on the scrollview so the
icons only appear through the visible portion.
Actually change the
alpha of the images based on their distance from the center (or from
each edge).
I suspect the first idea would be the most simple, but I'd like to throw this out there for any other ideas.
Note: I did see this tutorial, however that technique assumes that the background is a solid color. If I were to do it programatically, I would probably need to fade the individual images.
You can definitely implement something along the lines of #2. It'd be something similar to what the tutorial describes. The alpha transition however won't be as smooth as using the gradient layer mentioned in the tutorial or using an image since the entire icon would have the same alpha. How much discernible the difference is depends on the size of your icons. Smaller icons, very few will be able to tell the difference. Larger icons the difference would be quite clear.
You'd have to implement the
(void)scrollViewDidScroll:(UIScrollView *)scrollView
method in your scroll view's delegate class. This method will get called every time the scroll view changes the location of its content. In this method you can call its subviews and adjust their alphas as required. To optimize it a bit instead of calling the alpha adjustments on all the elements you can just update the subviews which are still partially/completely visible.
EDIT: to figure out which views to adjust you'll use the contentOffset property of the scrollView that gets passed as a parameter in the above method.
Assume that two very small areas of my view need to be redrawn. One is in the upper left corner, the other in the bottom right. I could use their coordinates to pass a single large CGRect that contains both areas to setNeedsDisplayInRect, but this will end up including a lot of other areas that do not need to be redrawn.
So the other option would be to simply pass their individual containing CGRects to setNeedsDisplayInRect, one after the next, i.e.
[self.view setNeedsDisplayInRect:rectForArea1]
[self.view setNeedsDisplayInRect:rectForArea2]
Which would generally be faster? Minimizing the number of times that drawRect: ultimately gets called, or minimizing the amount of screen area that it has to redraw, even if it must redraw twice?
It does not matter. As described here, iOS will always update the whole view, independent of what rect you pass into setNeedsDisplayInRect:
Note that, because of the way that iPhone/iPod touch/iPad updates its
screen, the entire view will be redrawn if you call
-setNeedsDisplayInRect: or -setNeedsDisplay:.
it is depending upon that two rect.
if both bounds addition are 75% of view bounds then i will call simply call
[self.view setNeedsDisplay];
because we draw almost whole view.
if both bounds addition are below 50% of view bounds then i will call simply call
[self.view setNeedsDisplayInRect:rectForArea1];
[self.view setNeedsDisplayInRect:rectForArea2];
because we need to draw small spaces