I have ATMhud. I' m showing hud with progress bar. I want to download actualization then.
But user can back to previous view and stop actualization.
I' m tried push "push black view", but i only cover current view without navigation/tabar.
How i can block clicking everything, before actualization finish?
If I understood your question correctly, you want to prevent user to interact with your view till your loading process is finished. You can set Views userInteractionEnabled property for that.
When you go for loading show at that moment set
self.view.userInteractionEnabled = NO
and after when your process is finished
self.view.userInteractionEnabled = YES
so this way you can prevent user to interact anywhere on your view while process is undergoing.
Hope it helps.
Related
What I am asking may be impossible and sound weird, but here it goes.
Here is similar to what I want to achieve:
A user opens the app for the first time, there are two tab bars, in the first one (he has not tapped the second one yet) he presses a button that should initiate a progress view and text view changes and other view changes EVEN THOUGH the user has not loaded the other view controller by clicking the second tab bar.
So, is there a way to generally load a view controller before the user manually loads it himself, I know calling viewDidLoad manually will not help, any suggestions? Pretty confusing, it is like modifying a view but the controller has not loaded yet...
Thanks!
Make the changes in the other view controller and then let the controller configure its own view when it does its natural loading.
I have the need for an activity indicator view in my app when different views are loading and when data is being retrieved. The problem is the mainVC (where I would place the indicator) is not always aware of when processing is happening so it can start the indicator but it cannot stop it.
e.g. the mainVC loads and then programatically adds a new VC - this VC in turn asks a model to retrieve - it displays data etc. So this newly added VC actually knows when processing is finished and it does not have access to the indicator view (although the indicator is visible at the top).
I was thinking of using notifications - is this the best way of handling this situation?
I'd recommend looking at the brilliant MBProgressHUD library:
https://github.com/matej/MBProgressHUD
It's a very simple set of classes you can use to display loading and progress views that can be accessed by all view controllers in your app. Basically, you can set it up in your app delegate and add it to your app window.
Every view controller can then access the progress view from the delegate and show/hide it when required. It comes with an example project and code - it's very easy to use and customise.
Notifications are one half of the solution. You have to combine them with a persistent object so that you can also get the current state at all times. E.g., when a view controller is about to appear, it needs to read the initial "downloading" state from somewhere, because the VC might have been created after the "start" or "end" notification was sent.
Then, while the VC is alive, it can simply respond to notifications to update the indicator.
This design is particulary important for views, which run the risk of getting unloaded/reloaded all the time.
IPhone SDK - Leaking Memory with performSelectorInBackground
seems to suggest you can actually pushViewController in background thread.
But I get a warning from stackoverflow people that I shouldn't do this.
eg. (iphone) start timer from background thread?
is pushViewController considered "UI updating"?
(because I know that UI updating should be done in main thread only)
If it is so,
when a viewController takes a while to load, and want to show an indicator while loading.
What is my option?
Couple of strategies here.
1) BEFORE you do the push, but at the point you know you are going to do it, bring up a suitable activity view on the current view. I do this in some apps where you click on a row in a table but the pushed view has to do some web comms that takes time, so I leave the table cell highlighted in blue and add a white spinner to the left of the disclosure indicator. Works well.
2) Use lazy loading to get the new view controller on screen quickly, but defer the heavy code until after it has loaded so that the new controller can look after it's own activity view. By lazy loading I mean you should do as little as possible in the init method and make careful use of viewdidload / viewwillappear / viewdidappear etc to spread the work out and get an activity view on screen as soon as you can.
How can I go about adding a view that appears until the background task finishes (the task in question populates a view and takes ~5 seconds).
Thanks,
Wire a hidden image view in the xib to an IBOutlet, and simply show it before the task starts and hide it when it is over. There is a "hidden" option in the xib inspector's view section. Just before you call the task, use myImageView.hidden = NO;. Depending on what the background task is, you should be able to give the owner of that task a closure block, delegate, or selector that can call myImageView.hidden = YES;
Okay, after much trial and error I found a solution. In my case I wanted to show a view whilst my tabbarviewcontroller initialised, and due to the content within it this took 5 - 10 seconds. So to improve user experience I wanted an image to appear. Peter, the method you posted unfortunately didn't quite solve the problem as despite calling the view to be in view until after the tabview was called to appear, it was removed automatically.
So, what I did was set up an NSTimer for 10 seconds, and after the 10 seconds hide the view. Making sure I had [self.window bringSubviewToFront:imageview]; set to insure the tabbar didn't appear over the loading view.
I have a UIViewController that is pushed onto a UINavigationController and is currently displayed. When I go to start some asynchronous task inside the view controller, I can set hidesBackButton on self.navigationItem to YES, and the back button is hidden correctly.
As soon as the task is finished, and I set hidesBackButton back to NO (on the UI thread, I might add, I've made sure of this), nothing happens. The back button remains hidden.
Has anyone seen this before? What drives me especially crazy is that in my application (the same application), in a different UINavigationController hierarchy, the exact same code works correctly!
Are you calling hidesBackButton = NO from a thread? All UI operations should be done on the main thread, otherwise they won't have any effect.
i have not been able to replicate your problem on my machine. however, i faced a similar issue with tableviews even when i was updating my ui on the main thread. but calling setNeedsDisplay fixed that issue.
Can you try this and see if this works:
[self.navigationController.navigationBar setNeedsDisplay];
I guess this should work, you need to do the same, BUT ON THE NAVIGATIONBAR instead. please let me know if this worked - as i cannot test my solution because i never get this problem :-)
Have you tried forcing the view to refresh by calling setNeedsDisplay?
Maybe the OS is not picking up the changes instantly and you need to force it.
Have you tried using the setHidesBackButton:animated: method instead? Perhaps that has a slightly different behavior.
In my case I simply had to give a title to the view, as in:
self.navigationItem.title = #"Menu";
Marinus
I have had a similar issue recently. I tried literally everything I found in SO and other forums- nothing worked.
In my case there was a modally shown UINavigationController with a simple root controller which would push one of two view controllers (A and B) on top of the controller stack when the button A or B was pressed, respectively. Controller B was the one which was not supposed to show the back button. But still, sometimes it did, sometimes it didn't.
After hours of debugging, I managed to track it down. Controller A was a UITableViewController. Each time I selected a cell in this controller, the delegate would pop Controller A off the stack. BUT. I made use of a UISearchDisplayController as well. Turned out that popping the view while the search controller was still active messed up something in the navigation controller that made it impossible to hide the back button in Controller B afterwards (well, it eventually stayed hidden between viewDidLoad and viewDidAppear: but then it always turned visible).
So the solution (rather workaround) was adding this line to where Controller A was dismissed:
controllerA.searchDisplayController.active = NO;
// ...
// [self.navigationController popViewControllerAnimated:YES];
Hope this spares someone a couple of hours.