I have an app that generates a PDF and displays it at the same time. As expected, there is about a 2-second delay between pressing the "Generate PDF" button and the QLPreviewController presenting the document. Not only that, it appears as though the document fades in momentarily, freezes, and then completes the fade-in.
I understand that the reason for the delay is because it is generating the PDF first, but the design of the application doesn't allow for any other mechanism. I was hoping to put a brief "LOADING..." animation before the QLPreviewController view appears, but everything I've tried so far still presents a 2-second delay.
Can anyone provide guidance on what I might be able to do here?
There are lots of options. I'd suggest that whatever you do, it be asynchronous. This will allow for the UI to not 'freeze' and you can put a loading screen up even if it is for 2 seconds.
There are many ways to implement this. Some involve actual background threads and others don't.
You can use, delegates, NSNotifications, blocks, NSOperations, and/or Grand Central Dispatch.
Here's a tutorial on how to use Grand Central Dispatch
Here's a tutorial on blocks
Related
I want to implement animation like This link while application interact with server.
If someone has example to implement this kind of animation then please provide me link.
Start animation
Server request in background thread
End animation in completion block of server request in the main thread
If you want that specific one I think you are going to have to make it yourself, but if you don't here are some open source alternatives.
DGActivityIndicatorView
MONActivityIndicatorView
YRActivityIndicator
interaction designer at Creativedash here =]
For something like that you'd make a png sequence, and set the animationImages property of a UIImageView. iOS is great at animating png sequences.
When your load starts, do yourLoadingImage.startAnimating() and when it's over (in the completion for your request), call yourLoadingImage.stopAnimating().
There's a property called animationDuration, and you need to set that as well, just to indicate how long the animation loop is - this doesn't indicate how long the animation will play for. It loops until you tell it to stop.
yourLoadingImage.animationDuration = 1 //set the loop duration to 1s
We actually did a short blog post on this process, and it can be the same for really any custom loader. http://news.ui8.net/create-a-custom-animated-loading-indicator-with-swift/
It seems like the fade animation between the launch screen and my first view is really slow.
I don't think it used to be like that. Is there a way to control the speed of that transitional animation?
I looked at some apps on my phone and the launch screen doesn't fade as slowly as mine. What things could I have done to affect that?
(No I don't have slow animations turned on, only the fade animation is slow)
In WWDC 2012 video iOS App Performance: Responsiveness they enumerate a whole list of issues that have impact on the app startup time, ranging from attaching to unnecessary frameworks, optional linking to frameworks that you really could make required, the use of static initializers, overly complicated initial scenes, too much information stored in preferences, etc.
That video covers a range of topics, like the above, which impact startup time. In the demonstration, they show how one might benchmark the startup time. Unfortunately, in my experience, there's a good chance that you might not be able to do anything to fix this issue (e.g. you need certain features and therefore need certain frameworks), but it's still an illuminating video and it might give you some ideas of things you can try to alleviate the start-up performance issues.
If your app splash screen show more time, so please check following things in your app.
1. AppDelegate.m
in didFinishLaunchingWithOptions method have you called any heavy method which takes more time for finish task if yes then change that method location, basically in appDelegate class don't write any heavy methods.
2. first view of your app.
check viewDidLoad() method, if you call many method or any heavy method from here then your launch image will show still your control not come out from viewDidLoad method, so if you want call any methods at view launch time then call them from viewWillAppear or viewDidAppear method (in viewDidAppear method don't call any UI related methods)
I never figured out what was going on here, but the next day when I started up xCode and the simulator it was back to the normal loading time.
I have an app where on start it checks the user's position and then get the weather for that spot. Mainly wind direction and speed.
It does the normal check to see it it has Intenet connection, but I found that if there is connection, but very slow the app freezes on launch screen (doing the check on startup).
I have a class that does this, which is called at startup after which a home screen is loaded.looking around, GCD seems the right way to go, but can I get the answer to be displayed in a label in the home screen when it is finished with getting the data? Main tread would have left, or rather bypassed that class and have arrived at the main screen.
Would I need to maybe use something like Notification Centre to help the label updating and re-load?
Thanks for any thoughts or code snippets.
Jorgen
PS. I am trying to keep the app iOS 5.1 to keep old iPads happy.
GCD seems the right way to go, but can I get the answer to be displayed in a label in the home screen when it is finished with getting the data? Main tread would have left, or rather bypassed that class and have arrived at the main screen. Would I need to maybe use something like Notification Centre to help the label updating and re-load?
Yes, I think you're on a very good track here. Let's keep the two issues separate, though:
After doing your background work, still in GCD, you're going to come back onto the main thread because you now want to update the interface. That's easy and straightforward.
If you have a communication problem, a notification can be an excellent solution. You can broadcast the need to update that label, and if the correct view controller exists and is listening, it will get that information.
Having said that, though, you should think about your architecture, since there may be a better way than a notification. Once you are back on the main thread, why are you not in a place where you have a way to know whether the correct view controller exist and to talk to it directly. I'm not saying the notification is bad/wrong! I've used this solution myself, and a notification is quite a standard way to come back from, say, an NSOperation. I'm just saying, give it a little thought.
I'm developing a small app on top of core data. At startup, I need to launch a maintenance task - fast but important -. To run this task, the app delegate must open a UIManagedDocument, and perform various checks on it. The app views must not start until the checks are completed. Because opening a UIMD is asynchronous, the app delegate isn't done when the first UIview tries to access the doc. The application then crashes due to a race condition because the app delegate and the view are trying to open the doc at the same time, while the doc state isn't yet finalised.
I'm using a storyboard, so segues are pretty much in control of the OS... Next time, I'll do it all manually..
What would be your recommendations ?
Note:
1)I can not perform the task when the app. goes into background state, because if it is brought back up again, avoiding inconsistent states between the underlying database and what's displayed in the view will be very tedious.
2)For the same reasons, performing the maintenance task during normal execution is not easily done.
3) All views access the UIMD via a singleton, according to the code proposed here
Setting a mutex lock in the UIView isn't my preferred route, because the screen remains black - no data -, while displaying the tab bars, until it is released by the app delegate.
Is there a way to have the app delegate wait for a signal before it hands the control over to the UIViews ? In this case, are there any gotchas ? I suspect this is probably not the recommended way to do, and iOS might kill the app if the delegate stays too long waiting for the maintenance task to complete. What would be "too long" in this case?
You could do it more elegant way. The first view the user will see must be some kind of SplashView - just an image with progress indicator. It should stay on top while your task is going on. It's not too important how you're showing this view. You can set it as the first in your storyboard or just create it manually in applicationDidFinishLaunching message.
Then in your task send a NSNotification when it's about to finish and in the observer in your AppDelegate just hide your SplashView and present your first view with valuable content.
You can even add some visual effects for transition between those views and your app will look really great! :)
I've been searching for something like this in SO and nothing came up. So i've decided to ask for the first time here.
I'm working on an iOS project. I have a UIWebView working fine with a NSURLRequest. But, when i load a URL with multiple asynchronous requests (i.e. wsj.com) like ads and Facebook likes stuff; the scroll interaction of the web view becomes laggy and unresponsive.
I've been debbugging and that happens when the delegate method shouldStartRequest is executed (several times)
First shoot: using threads. Didn't work.
Second shoot: playing with web view properties of interaction.
Third shoot: tried to stop the unnecessary calls (my business rules doesn't need them) didn't work. Even if i kill them, the laggy effect remains.
The curious thing about all this is that Safari renders and works fine with the same URL.
I'm looking for thoughts, does anybody has some clue of what's happening here?
Thanks!!