Currently I am retrieving a bunch of images from the internet and scaling them and then displaying them on my view.
The problem is I am doing it in the viewDidLoad method - so when the user taps they have to actually wait for this processing to happen and then the view is shown which causes a slight delay.
Is there anyway I could show the view and then somehow spark off the loading of the images AFTER the user has the view in front of them - similar to how a web page loads?
- (void)configureImages
{
if ([currentHotel.hotelImages count] > 0)
{
imageView1.image = [self getScaledImageFromURL: [currentHotel.hotelImages objectAtIndex:0]];
imageView2.image = [self getScaledImageFromURL: [currentHotel.hotelImages objectAtIndex:1]];
imageView3.image = [self getScaledImageFromURL: [currentHotel.hotelImages objectAtIndex:2]];
}
}
Consider NSOperation/NSOperationQueue, discussed in the Concurrency Programming Guide. There are several links to examples here.
Apps should use the asynchronous networking APIs for all networking to avoid blocking the user experience. It's best to avoid adding threads (such as happens when you use NSOperationQueue) for tasks like networking where the OS already provides async alternatives.
Apple supplies the async NSURLConnection, which works well but is a bit tedious to use. You can add a simple wrapper like gtm-http-fetcher which reduces async fetches to a single line with a callback when the load has finished. That will let you start all the loads in your viewDidLoad: method without stalling the user interface.
Related
I discovered performSelectorInBackground: a couple days ago, and I immediately knew a spot in my app where this would be perfect.
- (void)activate {
waitForStartCode.text = #"Loading...";
userNotifications.text = #"";
timeRemaining.text = #"";
[loadingNTP startAnimating];
[self performSelectorInBackground:#selector(initializeEverything) withObject:nil];
}
This is called when my view is visible. Before, while the NTP time servers were being connected to using CocoaAsyncSocket, my app froze until this process was completed. I really want a loading view with an animated UIActivityIndicatorView.
Everything in the initializeEverything -(void) works fine, exept the NTP initialization using CocoaAsyncSocket.
[NetworkClock sharedNetworkClock];
I get a :
Even with my unskilled eye, I could tell that CocoaAsyncSocket was not meant to be run in the background.
Is there any way around this?
CocoaAsyncSocket supports asynchronous networking. So in principle you do not need a background thread yourself to prevent your UI from freezing: CocoaAsyncSocket will handle communication in background for you.
I cannot say if you are using the framework in a "blocking" way or you are doing anything else that is making your UI block. But, as I said, in principle you do not need to manage a background thread yourself.
I've been reading everything I can find on here about this topic but am still not sure the best way to proceed. I have a heavy UIImageView that uses an array of fat UIImages acting as an animated loop. This UIImageView is serving as the background for every screen in the app. (Client's request, not mine, so don't hate.) We've optimized the png files as small as they can go but it's still a pretty heavy load.
I've read several posts about how UIImage searches the cache for an existing image of that name (Ex. Shared UIImageView for background image throughout app - Singleton Property) but this doesn't seem to be happening. I've also been reading here about singletons and instantiating in the appdelegate but I'm not sure if either of these are the right way to proceed.
What's the best way to load the UIImageView once over the life of the app and use it in the background of every viewcontroller? Btw, because it takes several seconds to load, I'm going to be adding a "loading" page at app start that uses a single static image and an activity indicator.
Also, I'm not as familiar with testing and performance tools. Which one should I be using to test performance and make sure this is what is causing the hesitations throughout the app?
Apologies in advance for the noob questions - I generally avoid asking questions at all but sometimes, as in this case, I don't even know where to begin the research.
I'm rather pleased with myself. I went with the AppDelegate technique and it's working beautifully. I declared a UIImageView property in the AppDelegate, then add the image code to its getter:
- (UIImageView *)backgroundImageView {
if (!_backgroundImageView) {
NSMutableArray *tempArray = [NSMutableArray arrayWithCapacity:150];
for (int imageNum = 0; imageNum < 150; imageNum++) {
[tempArray addObject:[UIImage imageNamed:[NSString stringWithFormat:#"image_00%03i.png",imageNum]]];
}
_backgroundImageView = [[UIImageView alloc] initWithImage:[UIImage animatedImageWithImages:tempArray duration:4.0]];
}
return _backgroundImageView;
}
This also allowed me to kill the object in applicationDidReceiveMemoryWarning.
Then I created a helper class that I can pop into all of my UIViewController classes:
+ (void)placeBackgroundImageUnderView:(UIView *)masterView {
myAppDelegate *appDelegate = (myAppDelegate *)[[UIApplication sharedApplication] delegate];
//Correct for shrinkage
appDelegate.backgroundImageView.frame = masterView.frame;
[masterView addSubview:appDelegate.backgroundImageView];
[masterView sendSubviewToBack:appDelegate.backgroundImageView];
}
This allowed me to add a single line in each viewDidLoad method:
[HelperClass placeBackgroundImageUnderView:self.view];
The thing is, just using UIImage alone should cache the whole thing and speed up load time. But it seems that every now and then the images would have to reload - memory issues? So this allows me more control over it by instantiating the object once and using that same object, while also being to set that object to nil to free up memory if needed.
Since adding it, the whole app has been loading much faster. I added an additional load screen with an activity indicator for that initial load (also works beautifully) and everything after that is instant happy.
I am creating a application which displays 8 thumbnails per page and it can have n pages. Each of these thumbnails are UIViews and are added to UIScrollView. However i have implemented Paging using the Apple sample code.
The prob:
Each thumbnail(UIView) takes 150
millisecs to be created and added to
scroll view
Hence for 3 pages it takes awful
huge time to be created and added to
the UI Scrollview.
At this point the scroll view is not very respsonsive and it is very jerky and gives a bad user experience
How can i create the thumbnails and add them to UIScrollview without affecting the touch responsiveness? I want them to run independent of the main thread which is resposible for handling touch events (i suppose).
Also i would like to mention that when a thumbnail is created i trigger a Async download of the image and the delegate method is called when download is complete.
Let me know the the options i have to make this more responsive and update UI without affecting the touch operations. The page control works fine with lazy loading of the grid of thumbnails.
TIA,
Praveen S
Grand Central Dispatch is easy to use for background loading. But GCD is only for after iOS4. If you have to support iOS3, performSelectorInBackground/performSelectorOnMainThread or NSOperationQueue are helpful.
And, be careful almost UIKit classes are not thread-safe except drawing to a graphics context. For example, UIScrollView is not thread-safe, UIImage imageNamed: is not thread-safe, but UIImage imageWithContentsOfFile: is thread-safe.
dispatch_queue_t mainQueue = dispatch_get_main_queue();
dispatch_queue_t concurrentQueue =
dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
dispatch_async(concurrentQueue, ^{
dispatch_apply([thumbnails count], concurrentQueue, ^(size_t index) {
Thumbnail *thumbnail = [thumbnails objectAtIndex:index];
thumbnail.image = [UIImage imageWithContentsOfFile:thumbnail.url];
dispatch_sync(mainQueue, ^{
/* update UIScrollView using thumbnail. It is safe because this block is on main thread. */
});
}
/* dispatch_apply waits until all blocks are done */
dispatch_async(mainQueue, ^{
/* do for all done. */
});
}
I was having a similar problem.
What i did was at an instance i kept only 3 pages in the memory and cleared remaining all.
If suppose there are 3 screens s1, s2, s3. And the user is viewing s2. Whenever he scrolls to s3 i will remove s1 and load a new page s4.
So that the users will have a better experience. And less memory will be occupied.
Whether you are using a subview or a separate ViewController for each "page" or element of the Scrollview, the jerkiness or poor performance can be helped by changing the location of your code.
Specifically the apple sample code for a scrollview with pagecontrol has something like this:
[self loadScrollViewWithPage:page - 1];
[self loadScrollViewWithPage:page];
[self loadScrollViewWithPage:page + 1];
However, that code appears in their sample in the method "scrollViewDidScroll". It's trying to do multiple heavy lifting by both scrolling and loading at the same time. Even if your images are local this is nasty.
If you move this and related code including a reference to the current page to "scrollViewDidEndDecelerating" the jerkiness of the interface is resolved because the loading happens while the scrollview is no longer moving.
I am creating a application which displays 8 thumbnails per page and it can have n pages. Each of these thumbnails are UIViews and are added to UIScrollView. However i have implemented Paging using the Apple sample code.
The prob:
Each thumbnail(UIView) takes 150
millisecs to be created and added to
scroll view
Hence for 3 pages it takes awful
huge time to be created and added to
the UI Scrollview.
At this point the scroll view is not very respsonsive and it is very jerky and gives a bad user experience
How can i create the thumbnails and add them to UIScrollview without affecting the touch responsiveness? I want them to run independent of the main thread which is resposible for handling touch events (i suppose).
Also i would like to mention that when a thumbnail is created i trigger a Async download of the image and the delegate method is called when download is complete.
Let me know the the options i have to make this more responsive and update UI without affecting the touch operations. The page control works fine with lazy loading of the grid of thumbnails.
TIA,
Praveen S
Grand Central Dispatch is easy to use for background loading. But GCD is only for after iOS4. If you have to support iOS3, performSelectorInBackground/performSelectorOnMainThread or NSOperationQueue are helpful.
And, be careful almost UIKit classes are not thread-safe except drawing to a graphics context. For example, UIScrollView is not thread-safe, UIImage imageNamed: is not thread-safe, but UIImage imageWithContentsOfFile: is thread-safe.
dispatch_queue_t mainQueue = dispatch_get_main_queue();
dispatch_queue_t concurrentQueue =
dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
dispatch_async(concurrentQueue, ^{
dispatch_apply([thumbnails count], concurrentQueue, ^(size_t index) {
Thumbnail *thumbnail = [thumbnails objectAtIndex:index];
thumbnail.image = [UIImage imageWithContentsOfFile:thumbnail.url];
dispatch_sync(mainQueue, ^{
/* update UIScrollView using thumbnail. It is safe because this block is on main thread. */
});
}
/* dispatch_apply waits until all blocks are done */
dispatch_async(mainQueue, ^{
/* do for all done. */
});
}
I was having a similar problem.
What i did was at an instance i kept only 3 pages in the memory and cleared remaining all.
If suppose there are 3 screens s1, s2, s3. And the user is viewing s2. Whenever he scrolls to s3 i will remove s1 and load a new page s4.
So that the users will have a better experience. And less memory will be occupied.
Whether you are using a subview or a separate ViewController for each "page" or element of the Scrollview, the jerkiness or poor performance can be helped by changing the location of your code.
Specifically the apple sample code for a scrollview with pagecontrol has something like this:
[self loadScrollViewWithPage:page - 1];
[self loadScrollViewWithPage:page];
[self loadScrollViewWithPage:page + 1];
However, that code appears in their sample in the method "scrollViewDidScroll". It's trying to do multiple heavy lifting by both scrolling and loading at the same time. Even if your images are local this is nasty.
If you move this and related code including a reference to the current page to "scrollViewDidEndDecelerating" the jerkiness of the interface is resolved because the loading happens while the scrollview is no longer moving.
I'm currently kicking off a background thread to do some REST queries in my app delegate's didFinishLaunchingWithOptions. This thread creates some objects and populates the model as the rest of the app continues to load (because I don't block, and didFinishLaunchingWithOptions returns YES). I also put up a loading UIViewController 'on top' of the main view that I tear down after the background initialization is complete.
My problem is that I need to notify the first view (call it the Home view) that the model is ready, and that it should populate itself. The trick is that the background download could have finished before Home.viewDidAppear is called, or any of the other Home.initX methods.
I'm having difficulty synchronizing all of this and I've thought about it long enough that it feels like I'm barking up the wrong tree.
Are there any patterns here for this sort of thing? I'm sure other apps start by performing lengthy operations with loading screens :)
Thanks!
I usually have a Factory class that’s responsible for wiring all the objects together. The Factory is created by the application delegate in the applicationDidFinishLaunching:
- (void) applicationDidFinishLaunching: (UIApplication*) app {
// Creates all the objects that are needed to wire
// the application controllers. Can take long. We are
// currently displaying the splash screen, so that we
// can afford to block for a moment.
factory = [[Factory alloc] init];
// Now that we have the building blocks, we can wire
// the home screen and start the application.
home = [[factory wireHomeScreen] retain];
[window addSubview:home.view];
[window makeKeyAndVisible];
}
Now if the Factory creation takes long, I simply wait under the splash screen or put up another view that displays spinner until everything is ready. I guess you could use this very scheme if you can perform the initialization synchronously:
#implementation Factory
- (id) init {
[super init];
// Takes long, performs the network I/O.
someDataSource = [[DataSource alloc] init…];
return self;
}
- (id) wireHomeScreen {
// Data source already loaded or failed to load.
HomeScreen *home = [[HomeScreen alloc] init…];
[home setDataSource:someDataSource];
return [home autorelease];
}
#end
With a bit of luck there’s just a single long operation in your startup routine, so that you won’t lose anything by serializing the init.
If you want to perform the data source init in background, you can display some introductory screen that will cue the home screen once the data has been loaded:
- (void) applicationDidFinishLaunching: (UIApplication*) app
{
// Create the basic building blocks to wire controllers.
// Will not load the data from network, not yet.
factory = [[Factory alloc] init];
// Display something while the data are being loaded.
IntroScreen *intro = [[IntroScreen alloc] init];
// Main screen, will get displayed once the data are loaded.
home = [[factory wireHomeScreen] retain];
// The intro screen has to know what do display next.
[intro setNextScreen:home];
// Start loading data and then notify the intro screen
// that we are done loading and the show can begin.
[factory.someDataSource startLoadingAndNotify:intro];
[window addSubview:intro.view];
[window makeKeyAndVisible];
}
Now when the data source has finished loading the data, it will tell the intro screen to cue the real content (home screen, in this case). This is just a rough sketch (for example the memory management might be different in the real case), but in principle it should work fine.
I ran into a similar issue a while back writing a REST application. It wasn't at the home screen but the general idea was the same. Issues with synchronizing call backs with NSURLRequests and so on. I found an example code from Apple that doesn't really solve this problem but illustrates how Apple solved it. Here's the link...
http://developer.apple.com/iphone/library/samplecode/XMLPerformance/Introduction/Intro.html
They do block the thread, so maybe it's not the solution you are looking for. In short, they use...
-(void) get {
finished = NO;
... do threading stuff ...
do {
[[NSRunLoop currentRunLoop] runMode:NSDefaultRunLoopMode beforeDate:[NSDate distantFuture]];
} while (!finished);
}
Just make sure your thread calls set finished to YES at some point.
It's not a pattern by any means, but I found it very helpful if you are using multiple threads in your application.