uiview Transition problem - iphone

i have a UIview holding two other UIviews. that two subviews having 15 buttons and images. i have to translate the parent view. but the translation is not smooth in 3g phone. im using UIviewanimation and CGAffineTransformTranslate for translating the view. please help me for making it more smoother.

This is a though question to answer in a general way. I have had views that scrolled smoothly suddenly animating jerkily after just a small change. In short, you need to make sure to have as few subviews as possible and have as few non-opaque views as possible (pngs with alpha values translates to non-opaque UIImageViews).
If all else fails, you can render the whole view into an image, switch out the view for the image just before scrolling, and then re-insert the view again after the animation. That way, you are only moving one big and (hopefully) opaque view.

If you have many images make sure they are small-sized, otherwise theyd take up too much memory and there would be nothing to do. To my experience 4-5 large images(740-480) were too much for the phone to handle.

Related

UIScrollView lags on iPhone

I'm trying to create a crossword app. The game runs in a UIScrollView, because the player should be able to zoom, scroll etc. The largest crossword are 21x21 which means there need to be 441 touchable tiles. What i've tried so far were to create an UIView and added it as a subView to the UIScrollView. Then I call a method that creates 441 custom UIButtons and set the backgroundImage.
Some of the UIButtons need to have a custom label overlay, so i added a UILabel and set it on top of the UIButton.
When I run the app in simulator all works as it should, but when i test it on an iPhone 4 the UIScrollView lags a lot.
I don't know if this the way to do it? Can you maybe try to guide me in the right direction of how to do this so the UIScrollView won't lag on a device.
Thanks in advance.
Big UIScrollViews are difficult to make smooth without some sort of caching mechanism, such as the one provided by UITableView.
One thing you can do, however, to make life easier for your rendering, is to make sure to use opaque backgrounds whenever possible. In stead of making a view transparent you should make it the same color as its underlying view. This is something that does help.
Also, I have experienced better performance using imageWithContentsOfFile: in stead of imageNamed: for initializing images to be used in a UIScrollView.
In order to not keep all those buttons in memory, you should work with reusable table view cells, this will really improve the scroll performance. Here's one component that could make your life easier: DTGridView, there are also others (you can check Cocoa Controls)

Adding views on top of UIScrollView

When you add a subView to UIScrollView, should this change the smoothness, or anything else for the UIScrollView? For example, if you have a UIScrollView with mainly text, then add a couple of views on top of it in order to add an effect to the text, should this change any of the gestures, or smoothness of the original UIScrollView without the subViews? Thanks.
It won't change the gestures.
As for the smoothness, it depends on how heavy your subviews are. I guess that if you add a lot of them, and they require to render a lot of dynamic content and such, it could make the scrolling a little rough, but if you are adding only a few subviews you should be fine.
As a comparison, think that a UITableView is a UIScrollView with a LOT of subviews on it (each cell is a subview, and cells have several subviews too), and it usually renders fast.
If the sub views you implement have the worst drawRect: implementation in the world, you don't need very many views to get slow, un-smooth scrolling.
You should profile your code in Instruments with the Time Profiler, and see what causes the slow scrolling.

Movement of UIButton which is in the UIScrollview becomes slow after pinching/zooming out

I have UIButtons in UIScrollview and also UIScrollview contains Imageview too. If i move UIButtons, particular area of the image within that UIButtons arranged will be colored..
Its happening well but my problem is movement of individual buttons are happening well If image is in normal size. and movement is getting delayed once after pinching or zooming..
Can anyone tell the reason why this is happening?
Thanks and Regards,
V.Karuna.
This kind of issue is usually down to the level of processing effort on the phone. Having to clip obscured views, and deal with transparency slows things down a lot. Make sure that you set everything you can to be opaque. This can make a massive difference. (opaque is a property of UIView therefore inherited by all controls, buttons etc)

Zooming out for the first time in UIScrollView is not smooth

I created UIScrollView and added UIView with lots of tiled UIButtons in the UIView. My problem is, when every time I zoom out the content using zoomToRect method of UIScrollView to the minimum scale I set, the zooming out is not smooth. But zoom-in and zoom-out for the second time is smooth. How can I make the zooming out for the first time to smooth zooming?
Thanks.
The slow initial zoom is obviously due to the phone allocating all the UIButtons the first time it has to draw them. They should be allocated incrementally or before the user starts to interact with them.
What are you doing that requires so much loading and drawing? It doesn't sound like the user would be able to interact with the million or so buttons they might be viewing.
I would suggest adding a pile of code to a UIScrollView Sub Class that makes it aware of it's content size, and it can then init the required UIButtons before the user starts to interact with your UIScrollview, or incrementally as I said.
There is demo code called 'Tiling' that sheds some light on using UIScrollViews to manage large content. It's quite complex, but a very complete demo that I'm sure most projects implement if they handle UIScrollViews with tiled content.
Before zoom out set your UIScrollView* scrollView like:
scrollView.contentInset = UIEdgeInsetsMake(0,0,0,0);

Maintaining proportions when autorotating custom UIView

This is probably either real easy, real dumb, or my google fu has taken a serious turn for the worse. Anyway, I'm implementing custom view for my app, which is using pure CGContext drawing, no subviews (for now at least). The thing is, I want it to autorotate, so I have shouldAutorotateToInterfaceOrientation return YES, and voila, the view rotates. But in doing so it's not actually redrawing the content (which I assume is rendered into a texture somewhere in the framework and splashed onto a rect, but that's not really relevant here), the rect is simply stretched, squishing the content. How can I get it to simply issue a draw of a bigger area while rotating? That is, my content is bigger than the screen, and I'd simply like the viewport to change during the rotation.
I've tried setting the view's contentMode to UIViewContentModeRedraw, but that didn't do anything, I've tried playing around with the autoresizeMask stuff, but didn't seem to help either. I've also tried inserting a setNeedsDisplay in willRotateToInterfaceOrientation, however that only caused it to redraw using the new bounds (i.e. squishing it first, and then stretching it out to the right size during the rotation), which is also not what I'd like to see.
Does anyone have any idea how I might go about getting this to work?
As it turns out, it's a mix of dumb and easy. I'm posting it here if anyone should care to read it someday. They way I managed to solve it was actually sandwiching a view between window and my view (I suppose you might be able to go to work on the window directly, but it felt more intuitive this way). That is, I added my view as a child view to that view, which I'll call the frame.
The frame is a resizing as normal, however, I turn OFF resizing of child views, and make my own view LARGER than the viewing area (square actually, 480x480, so it can cover the entire screen either way). Problem solved, basically.
Now I'm playing around with animating the offset of the view in the frame during willRotateToInterfaceOrientation, to have it appear to be rotating around the center, rather than the upper left corner, but that's a different question.