I'm experiencing long delays (1-3 seconds) between the calls to viewWillAppear and viewDidAppear.
This happens after loading a large view, sometimes printing wait_fences as well.
No connection to UIAlertView or any of the other causes I see in related questions.
There isn't anything going on in viewWillAppear, calling super and not performing any animations.
What could be the reason for this long delay?
I've experienced exactly the same thing.
I had a tableview with an image in each cell.
I preload the images into an array but was still having this weird delay between these calls.
Making the images smaller (from full camera size to 36X36) when put into the array did the trick.
I think the delay is just the UI loading all the elements.
Make your elements more efficient.
Related
Most of the iOS apps I use are very responsive, when I tap on an element it goes to the next view right away. In my app, some of my view controllers take 0.5-1.0 second to load.
My code is all in the viewDidLoad method and I'm pretty sure that's the problem but I can't move anything out since I need every single element that I instantiate.
A solution I thought is to move all the work I do in viewDidLoad in a thread then call the main thread when I'm ready to call addSubview, would that work even if UIKit is not thread safe? Or is there something else I'm missing?
Try to move some code you might have in viewDidLoad to viewdidAppear. viewDidAppear is being called once the view is presented. If you have to make some hard work, do it there and maybe show aa spinner somewhere while you do that.
What are you exactly doing in viewDidLoad? Btw remember that a view is only loaded when you need it, if you want to switch between views faster I can suggest you to create an initializion phase where you call -view on all the view controller you want to show, maybe helped with a spinner or a progress bar. but pay attention this would work only with intensive loading task and not memory consuming tasks. It sounds very strange your request, so is better the you try to explain better why your viewDidLoad is so slow, maybe there is something wrong.
Define your UI elements in Xcode as part of designing the interface. That way, Xcode can compile your storeyboard or xib files into the rapidly loading binary form.
I have a MBProgressHUD that shows when data is being pulled on the background asynchronously. Sometimes when the network is slow this will take forever. So as of now I am just hiding it after 30 seconds if it hasn't been dismissed. What is a good way to dismiss this HUD for a slow network connection?
I would say that the best solution is probably to keep the HUD up the whole time the data is loading so that the user knows that something is happening, and perhaps give them an option to cancel it if that is appropriate for your app. Alternatively, if it is possible for you to load and display the data piecemeal (i.e. before you have the entire set of data), then you should just display the HUD until you have enough data that you can start displaying something in the UI that the user can interact with.
Basically, what you want to avoid is a situation where it could appear to the user that nothing is happening and the UI is essentially blank with nothing for them to do.
Implement MBProgressHUD delegate
it will be called every time whether if it is fast or slow network connection,In case of slow network connection there will be a time out and this delegate will be fired,remove the hud from the superview in this delegate
-(void)hudWasHidden
{
[HUD removeFromSuperview];
}
Is there any significant difference in performance when you call
[someObject performSelector:#selector(testMethod:) withObject:anotherObject];
vs
[someObject testMethod:anotherObject];
?
The first causes an extra call to objc_msgSend() that isn't necessary in the second case.
The performance difference is unlikely to remotely matter unless you are calling said method as quickly as you possibly can many 10s of thousands of times and you aren't doing any significant work in testMethod:.
I.e. don't worry about it unless you measure an actual performance problem.
Interesting fact, performing a selector with a delay of 0 causes that method to be called at the top of the next run loop of the app. You can use that to delay certain events that occur frequently (used a lot in optimizations of UI, like images that get reloaded in a UIScrollView)
No there isn't any performance hit that I am aware of, and if there is any it is not significant.
I’ve come across an important difference when passing data to another view controller in prepareForSegue.
using:
[viewController performSelector:#selector(aMethod:) withObject:anObject];
aMethod is called AFTER viewDidLoad and viewWillAppear of the destination viewController.
using:
[viewController aMethod: anObject] ;
aMethod is called BEFORE viewDidLoad and viewWillAppear of the destination viewController.
So if you’re sending data important for the setup of the destination viewController, use the second way.
There is a lot difference in above both methods. I was trying to get animation of Two buttons coming from right side and stops at center but the second button was coming with 0.3 second delay. Now the main point comes here. I was using one animation method for both of 2 buttons. Now i wanted that when I click Finish button, then both buttons should go to left and again New buttons come. This was fine till reading.
Now when i was writing method for Finish button click. I was performing going out of buttons Animation first and then coming in buttons, but when I used the Above second method i.e. [someObject testMethod:anotherObject]; then what happens is I was not able to see the Going out Animation and directly coming in animation of buttons was shown.
Here actually comes the use of first method i.e. [someObject performSelector:#selector(testMethod:) withObject:anotherObject withDelay:delay];
The reason I found was when I click the Finish button the animation runs in different thread and the other code runs in different thread so the going out action was performed in another thread and coming in was performed in another thread. So first thread was not shown.
After using first method with Delay time of total animation. I achieved my goal. So both methods have their own significance.
For my experience,there are two differences:
The first one can add afterDelay:(CGFloat)seconds, and this is the only case I use the first one.
[someObject performSelector:#selector(testMethod:) withObject:anotherObject afterDelay:1.0];
The second one, you need to define it in someObject.h. Otherwise, you will get a compile warning.
The answer is that they are exactly the same.
There are two really good articles one from Mike Ash, where he explains the objc_msgSend():
http://www.mikeash.com/pyblog/friday-qa-2012-11-16-lets-build-objc_msgsend.html
And an another one from Tom Dalling who is explaining that perform selector is calling objc_msgSend().
http://tomdalling.com/blog/cocoa/why-performselector-is-more-dangerous-than-i-thought/
I have a UITableView that displays a lot of images in the cells, and i am not quit happy about the scroll performance. My UITableView is something like the photo app on the iphone. Does anybody knows why the iphone foto app scrolls so damn fast as if their's nothing on the screen.
And does anybody has some tips/tricks to increase my performance/scrolling speed?
You should precache your images and not do it lazily. As you scroll your table the UITableViewDataSource:cellForRowAtIndexPath: method is called, and if you're loading your images in there then you'll see it requesting your cell contents as your scroll, creating latency in your application. Try putting making your cellForRowAtIndexPath: something like this:
NSDate *date = [NSDate date];
... your cell loading code ...
NSLog( #"Elapsed time to generate cell %.2d", [date timeIntervalSinceNow] );
You'll see how long you're spending for getting each cell.
To get around this, you can be as complex as you need to - if you have a lot of images, you're going to have to be more and more clever. You can do paged loading, where you keep track of the last cell requested's NSIndexPath, and determine if the scroll is going up or down and use +NSImage:imageNamed: to fetch at once some page worth of images forward (ie, 5 images forward of your current position), or whatever works out for you (taking advantage of the fact that people have to return their finger down to the bottom of the table to swipe again, and so the consumption of table elements has pauses - you can make your page size large enough to fill a swipe). This is probably still not great, though, because you'll just be suffering all your impact at once instead of a jittery load for every cell.
You can return control to the UI rapidly and allow the system to schedule your prefetched page of images using NSRunLoop:performSelector:target:argument:order:mode: off the main runloop using NSImage:imageNamed:, and then when the cell is requested if you're fetching far enough ahead it'll be available to display.
You need to be painfully aware of memory concerns though. If you're finding this to be an issue, use NSImage:initWithContentsOfFile:, which will clean up image caches in low memory situations. Depending on the strategy used by the cache invalidation algorithm these situations may cause a "stutter" as you purge caches and have to reload your invalidated prefetches.
Great scrolling performance results have been reported by subclassing UITableViewCell and drawing the contents of each cell directly. See the accepted answer for this question for more details and links to code samples.
The problem here is memory, you are loading too many high resolution pictures at once, the foto app does not use a tableview it uses a scroll view and it only loads a max of 3 pictures at a time , so memory is not a concern, if u are trying to do something similar to the foto app use a scroll view
I'm using the three20 project for my iPhone app. I've narrowed my problem down and I'm now just trying to re-create the 'Web Images in Table' example that comes with the project. I've copied the code exactly as in the project, with the exception that I do not use the TTNavigator (which the example does) but I am adding my TTTableViewController manually to a tabBar.
The problem is as follows; the images in the table should load automatically from the web, like in the example. But they only load after I scroll the table up and down.
In the console it clearly says it is downloading the images, and you see the activity indicator spinning like forever.. And unless I scroll up and down once, the images will never appear.
Anyone? Thanks in advance.
P.S:
If I'm using this code in any random UIView, It also doesn't work (only shows a black square):
TTImageView* imageView = [[[TTImageView alloc] initWithFrame:CGRectMake(30, 30, 100, 100)] autorelease];
imageView.autoresizesToImage = YES;
imageView.URL = #"http://webpimp.nl/logo.png";
[self.view addSubview:imageView];
If I put this code in my AppDelegate (right onto the window), it does work .. strange?
POSSIBLE SOLUTION:
Although I stopped using TTImageView for this purpose, I do think I found out what the problem was; threading (hence accepting the answer of Deniz Mert Edincik). If I started the asynchronous download (because basically that is all the TTImageView is, an asynchronous download) from anywhere BUT the main thread, it would not start. If I started the download on the main thread, it would start immediately..
Sounds like a threading problem to me, are you creating TTImageView in the main runloop?
I find one interesting thing. When I use combination TTTableViewController, TTTableViewDataSource and TTModel I have same problem with loading TTImageView. My problem was, that my implementation of Model methods 'isLoading' and 'isLoaded' don't return proper values after initialization of model. That forces me to call reload on model manualy in 'viewDidAppear' method and that causes image loading problem. So I repair my 'isLoading' and 'isLoaded' methods to both return 'NO' after Model init, and everything is fine.
When an image finishes loading try sending a reloadData message to the table view. This forces the table to recalculate the size of the rows and redraw the table. Just be careful that you don't start downloading the image again in response to this message.
I've written something similar to this where an image view will load its own image from the web.
Im my experience, when the image had loaded successfully but was not shown in its view, it was a case that the cell needed to be told to redraw.
When you scroll the table view, the cells are set to redraw when the come onscreen, which is why they appear when you scroll.
When the image loads, tell the cell that it is sitting in to redraw by sending it the message setNeedsDisplay.
That way, when the image finishes downloading, the cell its sitting in (and only that cell) will redraw itself to show the new image.
It's possible that you might not need to redraw the entire cell and might be able to get away with simply redrawing the image view using the same method call. In my experience, my table cells view hierarchy was flattened, so I had to redraw the whole cell.
I don't have an answer for what you want to do, but I will say that this is considered a feature, and the expected behavior. You use TTImageView in UITableView when you want to do lazy loading of images. TTImageView will only load the images whose frames are visible on the screen. That way, the device uses its network resources to download images that the user has in front of them, rather than a bunch of images that the user isn't even trying to look at.
Consider having a long list that may contain a couple hundred thumbnail images (like a list of friends). I know from experience that if you kick off 100+ image requests on older devices, the memory usage will go through the roof, and your app will likely crash. TTImageView solves this problem.
This is a thread problem. You can load the images by including the line:
[TTURLRequestQueue mainQueue].suspended = NO;
in - (void)didLoadModel:(BOOL)firstTime.