I am currently using the AppDelegate in my first iPhone app to handle application level events.
In my app I have an enabled and disabled state, so when the user selects disabled some of the buttons on the application should be set to disabled.
My AppDelegate gets notified of the state. But what is the best approach to let my UIViews know that they should disable some of their buttons?
What is the standard approach to communicate events from the AppDelegate to the UI screens?
EDIT:
My description is slightly wrong, the user can disable the buttons in my app but conditions such as lack of Wi-Fi can as well, so I need to be dynamically able to change the UI state also.
Use NSNotification class to notify to your views.
Communicate using NSNotification
Communicate using NSNotificationCenter
I would say AppDelegate is always not the best approach. In my apps, rather I prefer Singleton class, they are quite easy to use.
eg Singleton approach:
AppConfig* config = [AppConfig sharedInstance]; // AppConfig is my singleton instance
[[self usernameTextField] setText:[config studentName]];
[toggle setOn:[config alwaysShow]]; // toggle is UISwitch
hope this helps.
Related
I am a relative beginner to iOS development, but I managed to get my app to do everything I want it to. However, I have some questions about tying the app up together.
The only code I have currently inside my appDelegate handles remote notifications; when I receive a remote notification I send out the alerts, messages, and so on to the user. I also generate notifications for the notification center which cause different methods to run inside different view controllers.
What about all the different functions in the appDelegate? DidEnterBackground, WillEnterForeground, etc.? My app starts on one view (view1), which creates an object (stream1), which has a method stopStream. I have buttons to start and stop the streams ([self.stream1 stopStream]). My question in, how do I call these methods to stop that particular instance of the object in one of the appDelegate methods? Do I need to create a notification for the notification center inside the appDelegate, and handle it triggering in the view? Or is there a simpler method? Or am I doing things completely wrong and not according to best practices?
Any help would be appreciated! Also a link to a guide about the architecture of apps, or a link to your favorite book about building apps in iOS would be great!
Your app delegate only needs to implement the various app delegate methods if the app delegate actually needs to do something with those events.
If a given view controller or other class is interested in the various app delegate notifications (such as enter background, or return to foreground, etc.), then the view controller or other class should register for the corresponding notification. See the docs for UIApplication for the different notifications.
Do not have the app delegate method post a custom notification.
All the methods you're looking for can be found listed here in the docs.
As for what to do about them thats definitely up to your app. It is best practice to handle at least going in and out of the background properly so at least use the methods for those and take the appropriate action in your app.
Its very common for apps to simply blast out NSNotifications like you mention. Its perfectly acceptable in most circumstances.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Force iphone app to restart programmatically
How can I restart/reopen my iphone/iPad application programmatically
Note:
Although this has been down-voted I think it is a perfectly valid question for a new iOS developer to ask. There is a way to 'restart' your app from the user's perspective which is not technically restarting or exiting the iOS App. As pointed out by other answers an iOS App should never explicitly exit because this is not allowed on iOS.
My Answer:
If you want your app to go back to the state it was in at launch this is not 100% possible but I will explain a way to get most of the way there that should be sufficient for all valid purposes.
The first thing to do is to re-create your root view controller. I recommend doing this from a method in the app delegate like this:
- (void)resetAppToFirstController
{
self.window.rootViewController = [[MyMainViewController alloc] initWithNibName:nil bundle:nil];
}
In many cases this will be enough, but any app-state that you have should also be reset in this method. For example log out a user, reset any non-persistent state, and nullify (release) all objects that you can. This method can also be used to initially create your first view controller from application:didFinishLaunchingWithOptions.
Framework classes and Singletons:
You will not be able to completely reset the state of any framework singletons or per-app instances, such as these:
[UIApplication sharedApplication];
[NSNotificationCenter defaultCenter];
[NSUserDefaults standardUserDefaults];
[UIScreen screens];
// etc...
That is probably fine as you shouldn't be storing any non-persistent state in these anyway (except NSNotificationCenter, but all registered observers should have been removed when the objects were released). If you do want to initialise or reset any framework state you can do it in the same resetAppToFirstController method. Anyway, there should be no need to re-create these, or the window object.
If you have any of your own singletons, you can re-create these by storing them in a singleton-holder class (which is itself a real singleton). Conceptually, this is a simple singleton class with properties for each of your other singletons and a reset method to nullify and release them all. Your other singletons should use this class (instead of a static or global variable) to store singleton instances. Be careful if you use any third party libraries as they may also employ singletons and you will need to ensure these also use your singleton-holder so that you can reset them as needed. I think this technique is good practice anyway, because in some cases (for example unit testing) you do want objects which are usually singletons to go away and reinitialise to a pristine state. However, you don't want to couple the singleton implementations with your singleton-holder, so a good way to implement this is by using an NSMutableDictionary as an associated object on [UIApplication sharedApplication] with the singleton class names as keys. However, I'm going off topic a bit as this is a more advanced technique beyond the scope of this question.
The above should be sufficient to 'reset' your application as far as the user is concerned. You can even show the splash screen again if you want as your first view controller.
No, there is no way to restart an iOS application programmatically. The application's lifecycle is controlled by the OS.
Could anyone tell me when we use the AppDelegate.m and AppDelegate.h during iPhone programming? I have used only the ViewController.m and ViewController.h for basic learning. I just want to know when and why AppDelegate is used.
Both define classes, but the classes are used for different things. ViewController.h/m define a view controller class that manages a hierarchy of views -- basically, one screen of an application. You might have multiple screens that each have their own view controller.
AppDelegate.h/m define a class that manages the application overall. The app will create one instance of that class and send that object messages that let the delegate influence the app's behavior at well-defined times. For example, -application:didFinishLaunchingWithOptions: is sent when the app has finished launching and is ready to do something interesting. Take a look at the UIApplicationDelegate reference page for a list of messages that the app delegate can implement to modify the behavior of the application.
I would like to add the following to #Caleb's answer.
If care is not taken, the AppDelegate could easily become one of the most accessed objects in the application. I usually refrain from calling methods in the AppDelegate from any of my ViewControllers. Unless, something needs to be reported to the AppDelegate that would influence the behaviour of the whole application.
I keep my AppDelegate for the following:
initialization: whatever needs to be done on the very first launch (after an install or an update)
data migration from version to version (e.g. if you use CoreData and migrations)
configuration of objects linked via IBOutlets from MainWindow.xib
determining the initial orientation to launch in
saving uncommitted data / state prior to the application being terminated or entering background mode
registering for the Apple Push Notification Service and sending the device token to our server
opening one of the supported application URLs (e.g. maps://)
For other use case scenarios and a more thourough description of the AppDelegate, see the iOS Application Programming Guide.
The view-controller. h/m is responsible of controlling the connection between your model and your view (more on MVC here).
AppDelegate. h/m is responsible for the life-cycle of your application. What to do when the user press the home button and exit your app, what to do when the app enter background. Things like this.
k, I'm new to this so apologies all around, generally.
I'm trying to access the UISwitch value (on or off) from a different view and class and can't make it work.
It's a simple 2 view app. Main view and the second is a preference menu.
trying to write an if/else method to play sound when the switch (on the other view) is on and not when its off.
I cant seem to make it work. Any thoughts or some syntax examples would really help me out.
Thanks.
As Matt Wilding said "it's not good form to access UI components of one view controller from another...".
Instead of accessing the view object, when the switch state is changed by the user you save the status into NSUserDefaults as preference value. Whenever you want, you can access the switch status value through the preferences.
I'm going to take what I think you're trying to accomplish here and suggest an alternative approach. You want to have a preference in your app (assumed from "preferences menu") that allows the user to set something like whether or not you app plays background music. (May not be exact, this is just for clarification).
Typically, in a well designed app, the flow is driven by the data, with the UI reflecting the state of the data model and the controllers coordinating the two layers. What you are suggesting is to have your application play music based on the state of the UI, which is not backed by any data model. This cuts out the model level, and as you noticed, can lead to awkward attempts at communicating between the UI of different controllers for information.
Things like application preferences are typically stored in a nifty .plist file that is managed through the NSUserDefaults class. This would be a great place for the data level tracking of your preference. In this situation, the UISwitch would represent the state of the flag in the settings file, and changing the value of the switch would change the value in the file. Anywhere else in your application that you need to know if the play-sound-flag is set, you reference the data model info instead of the UI. This decouples the view controllers from each other, which is a good thing.
For this purpose add selector for swith and make NSInteger property in app delegate.Like the followed
[
yourSwitch addTarget:self action:#selector(switched:) forControlEvents:UIControlEventValueChanged];
-(IBAction) switched: (id)sender
{
int state=0;
if(yourSwitch.on)
state=1;
else
state=0;
objAppDelegate.switchState=state;
}
then you need to access this appDelegate property in second view where you are playing sound
then according to this value you can do what you want and for making object of appDelegate class you need this line
YourAppDelegateClass *objAppDelegate=(YourAppDelegateClass *)[[UIApplication sharedApplication] delegate];
ok if you have any other doubt then you can ask.
I am developing an iPhone application with multiviews (Nav controller), but i like to receive an event if user touches in any view of the view. I understand it can be done by subclassing application delegate? If that's true how can i do it? My requirement is, i like to receive an event as soon as user touches any where in any view within my application.
Thanks for your help and time.
Your reference to subclassing UIApplication will work. Read down through the comments and it covers a somewhat quirky IMO way to implement it (by having the AppDelegate be a subclass of UIApplication). Myself, I would create a separate class to be the UIApplication subclass, rather than having the app delegate do both jobs, but I see the merit of either way.
That said, this is a very large and unusual stick and may suggest a design failure. What problem are you solving with this?
A way to do it is to use a Singleton class (which acts as an observer/mediator), which the application is an example of, in which you have viewControllers subscribe to when they are intersted in the touch events of a certain view. When the touch occurs the Singleton class is informed of the event as a result it informs all subscribers to the event of the event.
Here is an example
#interface MyEventClass
{
-(void)TouchEventDidOccur;
-(void)subscribeToTouchEvent:(id)delegate selector(selector):sel
}
Above is the singleton class
now this is an example of what the view touchesBegan method might look like
-(void)touchesBegan...
{
[[MyEventClass sharedInstance] TouchEventDidOccur];
}
and how one would subscribe to the event
[[MyEventClass sharedInstance] subscribeToTouchEvent:self selector:#selector(receiveTouchEvent:)]
hope this helps
What's wrong with using notifications? If you have disconnected classes across your application, it's trivial to have them listen for a particular notification, then have your views or view controllers post that notification when a touch event happens. All of the observers will take action on the notification.