I have several view controllers each of them has a label or a button. I want to change visible view controller button's or label's text from the AppDelegate. I know that it is a bad practice but I in the AppDelegate runs a background thread which looks fow new images for user on the server and if there are ones it must update new images counter in the label on the navigation bar of the current dispalyed view.My idea was to use in the AppDelegate.m next code: (ControllerWhichLabelIWantToChange*) self.navigationControllerClass.visibleviewcontroller. ... But here I can't see a label or a button for which I define a property in ControllerWhichLabelIWantToChange. So the question how can I access elements of different view controllers from the AppDelegate and change them?
One suggestion, which might be better for you, is to use NSNotificationCenter to send notifications on various changes. Any view wishing to refresh themselves may respond to such notifications. This is a common practice. Say, for example, you are processing theme data in the background, and you've got 20 live views that require theming, you could post a notification when your background process has completed, and all views that are observing the notification will be notified, and they can update themselves.
Related
My app contains TabBar controller with 5 viewcontrollers. It is possible to click on a button in each of viewcontrollers which will popup another view in which user can choose a setting. The button (which was clicked) is supposed to change its background according to chosen setting in each viewcontroller. So if the user clicks on button in VC1 and chooses the setting, this information should spread into all of the other VCs so that the button has the same background.
I am using storyboards, and I know that this is easily possible between 2VCs using segues, protocols, closures... I cannot find a proper way to spread information to more than 2VCs.
The only solution I can think of is usage of UserDefaults. I would save an information about a button setting and then call ViewWillAppear in each VC, where the background of the button would be set according to the value in UserDefaults. Is there a better solution, please?
EDIT:
As #cora mentioned in the comments, I was able to solve this using Notification Center.
You have several options, including:
Pass an array of the tab controllers to your "popup settings" controller and call a "settingSelected" func in each one directly.
Using Protocol / Delegate pattern, you could create an array of delegates in your "popup settings" controller.
You can use Notification Center.
You could subclass the button and use UIAppearance proxy.
Which approach to use will depend on a number of factors, based on exactly what all you need to do (are there other "settings"? or only that button background?)
You may want to search for swift using themes to see various different approaches.
“Is there a better solution, please?”
Not necessarily. Is this in fact a user default, to be preserved between launches? Then this is exactly what user defaults are for.
If not, then at least you need some central location where information about the current button color can be stored. An obvious candidate here is the tab bar controller itself. It gets notified every time there is a tab bar item switch, so it’s a perfect candidate.
Since you have mentioned you are using a UITabbarController, you can use an instance of UITabbarController and then access .viewControllers property of it and call their added public methods to get them triggered on events that you add. Additionally, using Notification Center makes more sense to me since your code will be more readable. Sometimes Notifications can just get a little confusing for new developers who are working on your code.
I have been asked this question many times in the interview searched every where didn't get any proper answer.So finally posting this question here.
You may go through this.
Yes, you can have multiple windows. A key window is the one who receives the user input.
Starting with Rob's answer I played around a bit and would like to write down some notes for others trying to get information on this topic:
It is not a problem at all to add another UIWindow. Just create one
and makeKeyAndVisible. Done.
Remove it by making another window
visible, then release the one you don't need anymore.
The window that is "key" receives all the keyboard input.
UIWindow covers everything, even modals, popovers, etc. Brilliant!
UIWindow is always in portrait implicitly. It does not rotate.
You'll have to add a controller to the new window's root controller and let that handle rotation.
(Just like the main window) The window's level determines
how "high" it gets displayed. Set it to UIWindowLevelStatusBar to have it cover everything.
Set its hidden property to NO. A 2nd
UIWindow can be used to bring views on the screen that float on top of everything. Without creating a dummy controller just to embed that in a UIPopoverController.
It can be especially useful for iPhone where there is no popover controller but where you might want to mimic something like it.
And yes, it solved, of course, my problem: if
the app resigns activation, add a cover window over whatever is
currently shown to prevent iOS from taking a screenshot of your
app's current content.
Generally one application require only 1 UIWindow, but still there may be some scenarios where you need to use multiple UIWindow in one application.
For example, you wish to show a view on the top of system AlertViews, or can the default Keyboard.
UIWindows are the special UIViews, for which their display order is controlled by .windowLevel property.
You don't need to add a new UIWindow as a subview of any of view. You can simply create a new UIWindow and call either window setHidden:NO or window makeKeyAndVisible depend on the level, you have given to it.
There are three default window enum levels defined:
UIWindowLevelNormal
UIWindowLevelStatusBar
UIWindowLevelAlert
Of course it can have multiple windows. Just, only one to be displayed at a time, that's the keyWindow. You can have multiple windows stored in array or whatsoever, and make them keyWindow when you want to display them.
And, yeah, read the documentation #Mannopson suggested, it's very useful.
I want a button that will become available at, say, 8 AM. I know how to check if the button is available when the view is loaded, but, if the user is looking at the button as the clock turns to 8 AM, how do I get the button to become active without loading the view?
The button should always be present. Use its hidden to hide and show it as necessary. Or you can use its enabled to enable or disable it as necessary, but this can require more work, because a disabled button might not automatically look disabled so the user won't understand that it isn't truly "available".
Thus we have three cases to deal with:
The user moves to this view controller, the view controller loads its view, and your code decides about the button state / visibility now. You've already handled this one.
The view controller is already present and the view is visible, and the availability-change moment comes. In this case you will need previously to have set up a notification to prompt the view controller to take action now. Do not loop perpetually watching the time. Use an NSTimer or similar (a local notification is also worth considering).
The view controller is covered by another view controller and then uncovered. Perhaps the state needs to have changed in the meantime. So you will also want to do this check generally in viewWillAppear:, not just in viewDidLoad.
Let us say I used some code to change the appearance property of the UINavigationBar including the UIBarButtonItems in my app. Is there any simple way to reset the appearance for some specific views to the default iOS style?
A couple of options I can think of.
Save the initial state in variables (background, font etc) to use
later during the reset.
Destroy and recreate the view. If this is done during a transition
(page switch etc) it may not be noticeable to the user.
Keep the original view hidden behind the new view and destroy the
new view when you want to reset it. (This may be memory expensive.)
I think your best bet may be to create a custom object (extend the original NavBar etc), save its original appearance variables (color, font etc) and add a reset option to be called by the controller.
I have always been a bit unclear on the type of tasks that should be assigned to viewDidLoad vs. viewWillAppear: in a UIViewController subclass.
e.g. I am doing an app where I have a UIViewController subclass hitting a server, getting data, feeding it to a view and then displaying that view. What are the pros and cons of doing this in viewDidLoad vs. viewWillAppear?
viewDidLoad is things you have to do once. viewWillAppear gets called every time the view appears. You should do things that you only have to do once in viewDidLoad - like setting your UILabel texts. However, you may want to modify a specific part of the view every time the user gets to view it, e.g. the iPod application scrolls the lyrics back to the top every time you go to the "Now Playing" view.
However, when you are loading things from a server, you also have to think about latency. If you pack all of your network communication into viewDidLoad or viewWillAppear, they will be executed before the user gets to see the view - possibly resulting a short freeze of your app. It may be good idea to first show the user an unpopulated view with an activity indicator of some sort. When you are done with your networking, which may take a second or two (or may even fail - who knows?), you can populate the view with your data. Good examples on how this could be done can be seen in various twitter clients. For example, when you view the author detail page in Twitterrific, the view only says "Loading..." until the network queries have completed.
It's important to note that using viewDidLoad for positioning is a bit risky and should be avoided since the bounds are not set. this may cause unexpected results (I had a variety of issues...)
This post describes quite well the different methods and what happens in each of them.
currently for one-time init and positioning I'm thinking of using viewDidAppear with a flag, if anyone has any other recommendation please let me know.
Initially used only ViewDidLoad with tableView. On testing with loss of Wifi, by setting device to airplane mode, realized that the table did not refresh with return of Wifi. In fact, there appears to be no way to refresh tableView on the device even by hitting the home button with background mode set to YES in -Info.plist.
My solution:
-(void) viewWillAppear: (BOOL) animated { [self.tableView reloadData];}
Depends, Do you need the data to be loaded each time you open the view? or only once?
Red : They don't require to change every time. Once they are loaded they stay as how they were.
Purple: They need to change over time or after you load each time. You don't want to see the same 3 suggested users to follow, it needs to be reloaded every time you come back to the screen. Their photos may get updated... you don't want to see a photo from 5 years ago...
viewDidLoad: Whatever processing you have that needs to be done once.
viewWilLAppear: Whatever processing that needs to change every time the page is loaded.
Labels, icons, button titles or most dataInputedByDeveloper usually don't change.
Names, photos, links, button status, lists (input Arrays for your tableViews or collectionView) or most dataInputedByUser usually do change.