I am working on an App built with Xcode 4.1 and linked against iOS 4.0. Today I have started testing on iOS5 to get it ready by the time the new OS launches.
We have an interesting issue where almost every UIView subclass animates when they are redrawn. The views returned as section headers of a table view are animated every time the user scrolls for instance. But practically almost any UIView update is animated. The effect on the screen is very disorienting.
I can't find anything on this issue. But I must be missing out on some big changes or doing something very wrong.
Anybody experiencing similar issues?
Based on what I've seen of iOS 5 this isn't normal behavior.
It sounds like you are wrapping some call to that TableView inside of a UIView animation block, so any call the UITableView makes (Such as LayoutSubviews) is also in that animation block. Another possibility is that you forgot to properly commit an animation, so all UIView changes past that are also included.
There have been some changes to UIView animations and the way they are run. Just anecdotally, I've had some trouble with Animations that used to run sequentially running on top of each other. So, maybe this is a bug in your code that was just never noticeable before.
Related
I am optimizing a transition that seems to be slow on my device. I am pushing one UIViewController from another when a UITableView's row is selected. There is a noticeable pause after row selection and before the new view is pushed.
Some logging indicates that all of my code is reasonably quick, from row selection until the pushed controller's viewWillAppear. But then the time between viewWillAppear and viewDidAppear is logged at around 0.7 seconds.
The transition itself (I believe) should only take 0.3 seconds. What could be accounting for the remainder?
I am testing on an iPhone 4, so I'm not expecting the snappiest performance. But I should be able to match the same performance of other similar apps on the same device, no?
I had a similar question a few weeks ago, and I wrote a blog post about what I found:
http://bradbambara.wordpress.com/2014/07/31/object-life-cycle-uiviewcontroller/
The TL;DR version is that iOS will:
perform the layout of your new scene
perform the transition to your new scene (if it's an animated transition)
...so my guess is the delay could be caused by an especially long transition, or if you're doing any performance-intensive work in your layout code.
The transition itself (I believe) should only take 0.3 seconds. What could be accounting for the remainder?
Resources are usually consumed in the following methods: drawRect:, layoutSubviews, viewDidLoad, viewWillAppear:. Also, loading from NIB may require quite much time.
After viewWillAppear:, iOS will make a snapshot of the new (and probably current) view to perform smooth animation between two screens. So make sure that drawing and layout code for both controller views is fast enough.
I am implementing a UIScrollView which behaves mostly like a UITableView, a bit more advanced with that.. but most of the API used are the same signature.. cellForRowAtIndexPath.. etc. First before people start storming why not just use a UITableView, let me just say that I can't. The reasons are fairly complex, but that is a decision been made.
The issue is now I am implementing infinite scrolling, basically when I scroll down and I am at 65% of the full contentHeight I am doing an async request to the backend to fetch more data and adding it to the data source and then calling reloadData. The issue is that if I am calling reloadData while the user is scrolling, it doesn't provide a very smooth scrolling experience. So what is the best way to tackle this? Also I noticed that reloadData basically refreshes the entire table view (in this case my scroll view). In my table view cell I am animating a UIImage to fade in. So when reloadData is called, the image that is already presented is being faded in again, which is kind of annoying.
How do I avoid such things?
Any tips and tricks?
In case you're still working on this, check out PSTCollectionView. It works exactly like UICollection view but supports backwards of iOS 4.3.
Its difficult to answer without knowing why you need to create a custom view similar to the tableview. If you have a developer account you might want to check the new iOS 6 view based on tableview. Not sure if I can talk more about it as it is under NDA.
For the UIImage fading, how about flagging each UIImage as displayed and then do a check when reloading the data or recalling the fade statement. Only fade the images that are not flagged as already presented?
In new iOS 6.0 there is new controllers call UIContainer view,its similar to UITableview but we can also set more then one column with that.
delegate methods for that controllers are almost same as in UITableview.you can use that controller if you have similar requirements.
I'm using a UIScrollView to display a custom UIView. When the user drags a finger across the UIScrollView, there is a noticeable delay before the display begins updating. If the user keeps touching the screen, the UIScrollView becomes very responsive after a short time. Subsequent attempts to scroll result in the same initial delay, followed by high responsiveness. This delay seriously affects the usability of the view and I would like to get rid of it.
In a test project I have written to try to get to the bottom of this issue, I have only been able to partially replicate the behaviour. The first time that the user scrolls is exactly the same - however any subsequent attempts to scroll are responsive straight away.
I have tried both setting delaysContentTouches = NO and subclassing UIScrollView so that touchesShouldBegin returns NO as suggested in multiple places online, but neither has worked.
I'm using MonoTouch on iOS 4.3, but Objective-C answers are fine. I would post code to help illustrate the issue, but since I have been unable to narrow down the problem this would be well over 1000 lines. Hopefully this is enough info to get a solution.
Does anyone know what might be causing this delay, and how I can get rid of it?
Some general suggestions for improving scrolling performance.
Have your scrolling views rasterize offscreen:
myView.layer.shouldRasterize = YES;
Set that property for each sub-view on the scrollview - do not set it for the children of those sub-views or you just eat up memory that way.
If your scrolling views do not need compositing, make sure you turn that blending off:
myView.opaque = YES;
Test using the simulator by leveraging these two features that appear on the Debug menu of the iOS Simulator:
Color Off-screen Rendered
Color Blended Layers
If that doesn't address your problem, and you have implemented UIScrollViewDelegate, double-check to make sure you are not doing anything time consuming in those methods - for example, based on your description, you might be doing something in scrollViewDidScroll, scrollViewWillBeginDragging, or scrollViewWillBeginZooming and if you are, optimize that so it happens before scrolling even begins. Also, make sure you're not doing anything in touchesBegan.
I suspect what is happening is there is some kind of interaction enabled in the content of your scroll view.
The system does not know if the initial touch down is going to be a tap on one of the subviews or a drag on the scroll view, therefore is causing a delay while it waits to see if you are going to lift your finger.
What are the subviews of the UIScroll view?
As an experiment set all the subviews of the UIScrollView to have userInteractionEnabled = NO, this will not be what you want, but its just a test. Is should scroll fine after this, otherwise I am wrong.
My iphone application has a user form under UIViewController.
When I out of application (go to background mode) and start application again some of my UIView changes its positions and sizes. (These UIViews depend on keyboard position)
Definately somewhere is my fault.
I try to figure what is going on when application starts again from background and where the UIView changes can be done.
May be you can suggest any links to read.
Thank you.
The UIViewController's viewDidLoad and viewWillAppear methods get called every time the view is dumped from memory, something that commonly happens when the app goes into the background. Depending on your code, it's possible that you're storing some position data that's not getting cleared. If that's the case, you can either:
Change your code to better fit the Model-View-Controller pattern so that the positioning code and variables are all in the controller, and you appropriately clean things up in its 'viewWillDisappearandviewDidUnload` methods (the better way), or
Clear out whatever remnants are hanging around in your application delegate's applicationWillEnterBackground method.
strange things happen in my iPhone app. Since a not defined point in time when I start my navigation based app (it doesn't matter if in simulator or on the device) the last UIView (the one that the user reaches last) is shown on startup. After the app is loaded it switches automatically to the RootViewController's view. It's like the last view does the job of a splash screen.
I'm a little bit confused. Did somebody experience the same thing and maybe got the definite hint for a solution?
Thanks.
Ok, SOLVED: It's a pretty good idea to delete a "Default.png" with a screenshot of the last UIView from the Resource folder. No UIView was actually loaded, just the image.... damn it. what a stupid thing and as often, the problem was sitting in front of the screen.