Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I want to ask a simple question as i am new in Objective c.
Is there are any difference to write method on AppDelegate instead of UIViewController??
Or which type of method i should write on AppDelegate.
And what if i write method in UIViewController and call from AppDelegate.
Is there are safe to write method on UIViewConroller class and call it from AppDelegate.m file by that UIViewController's object.???
If i write it on ViewController and call it from AppDelegate.m then is it safe or not???
The AppDelegate is shared singleton class.
That means appdelegate object will be created only once in your entire app life cycle.
Creating method in AppDelegate is recommended when you have to process something multiple times in your application and that method may be called through viewcontroller, from appdelegate itself or other singleton class.
Like. Process zip archive, Check version of iOS device
And yes Most important thing
This can also be done in other ways.
However if you want to call viewcontroller method from AppDelegate you need to create an object of viewcontroller or get viewcontroller object from memory. And there should be some solid reason to do that.
It depends on your app Architecture and Requirement.
Hi #Dhaval you can write and call method from any where in your project but for that you have to define the function definition in .h file and that make this function global for the project.
Next thing is that when you define any function in app delegate it access by it share instance because app delegate instance live still your application is not terminate.
Related
I just started working with core data in iOS app dev using swift. The first two things that I encountered are: 1. AppDelegate 2. NSManagedObjectContext.
I understand that 'AppDelegate.swift' file is a source file just like the 'ViewController.swift'. But in all the tutorials it was referred as 'something which will be used later'. Perhaps, now is the time to get familiar with it. Could you kindly tell me what exactly it does?
What does an object of type 'NSManagedObjectContext' do? What is its function? Could you please put its function in simpler words?
Thanks in advance.
Have a look at the following figure for visual understanding of Key objects in an iOS app:
Role of AppDelegate:
The app delegate is the heart of your app code. It handles app initialization, state transitions, and many high-level app events. This object is also the only one guaranteed to be present in every app, so it is often used to set up the app’s initial data structures.
AppDelegate is used for the whole app, you can use it to manage the app life cycle, on the other hand, ViewController is used for a single view. you can use it to manage life cycle of a view. One app can have multiple views. but only one AppDelegate.
Role of NSManagedObjectContext:
The NSManagedObjectContext is a fundamental concept of Core Data.It is like transaction in a relational data. You can fetch objects, you can create objects , update and delete them, save them back to the persistent store, etc. Basically for all the core data operations, you will need to interact with NSManagedObjectContext.
UIApplicationDelegate is an interface between device (the iOS system) and your application. You will i.e. handle push notifications in this class
Context is more complicated. Generally all object that comes from CoreData has some context which is responsible for sync all object in this context. So if you fetch object A and in some other point of code you will fetch again this object (lets call it A2) and both are fetched in the same context then A == A2 is always true. But that's just the tip of the iceberg.
I'm just beginning to work on iPhone apps. How do I know when I should be putting stuff in AppDelegate versus a custom class? Is there a rule or any type of analogy with another programming language like Python or PHP that uses an AppDelegate like pattern?
I normally avoid the design approach implied by Andrew's use of the term "heart of your application". What I mean by this is that I think you should avoid lumping too many things in a central location -- good program design normally involves separating functionality by "area of concern".
A delegate object is an object that gets notified when the object to which it is connected reaches certain events or states. In this case, the Application Delegate is an object which receives notifications when the UIApplication object reaches certain states. In many respects, it is a specialized one-to-one Observer pattern.
This means that the "area of concern" for the AppDelegate is handling special UIApplication states. The most important of these are:
applicationDidFinishLaunching: - good for handling on-startup configuration and construction
applicationWillTerminate: - good for cleaning up at the end
You should avoid putting other functionality in the AppDelegate since they don't really belong there. Such other functionality includes:
Document data -- you should have a document manager singleton (for multiple document applications) or a document singleton (for single document applications)
Button/table/view controllers, view delegate methods or other view handling (except for construction of the top-level view in applicationDidFinishLaunching:) -- this work should be in respective view controller classes.
Many people lump these things into their AppDelegate because they are lazy or they think the AppDelegate controls the whole program. You should avoid centralizing in your AppDelegate since it muddies the areas of concern in the app and doesn't scale.
Your application delegate is the heart of your application. It's effectively your "Program Controller".
The Application Delegate is the class that receives application-level messages, including the applicationDidFinishLaunching message most commonly used to initiate the creation of other views.
While not exactly similar you could think of it as the "main()" routine of your Cocoa program.
#Shivam, thanks.
From what I understand of appDelegate, is close to what an Application is in Android. The viewDidLoad, viewDidDisappear is comparable to what Android's Lifecycle. Every application has a life cycle, from launching to interruptions from calls coming in, to notifications showing up. If you need your code to do something special when these system events occur then you need to write code the methods.
In Android we use onPause, onDestroy, onCreate kinda callback methods to handle such system events.
Hope this will help a little more ...
Programmers new to this language always have the same question - does the program start from a main method? Yes, you are right in this case; IOS apps also start from a main method. Your main class calls the below function:
UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class]));
UIApplicationMain kicks off the Cocoa Touch run loop and app infrastructure which creates a UIApplication object. Our application needs content so objective-c uses a delegate to handle this. That's why we call it AppDelegate (act as delegate of UIApplication). We implement some of the optional methods of that delegate and it behaves accordingly.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I'm wondering if I should be relying less on my projects' App Delegate to setup my app - or should this sort of code belong to a singleton class part of the model?
For example -let's say, before my user gets to the first view - I need the app to download some data from a server and I need to preform a few checks and create a BaseDataStore type of class to store the stuff the app downloads. All this before my app starts.
Putting all this code in the applicationDidFinishLaunchingWithOptions seems like the right thing to do - as this is what gets called once the app has launched. My question: Is this the right place to put it? Or do I create my own class for this sort of thing?
In short: YES, you need to create your own classes.
To put all code in the AppDelegate and ViewController classes is a popular habit in iOS.
iOS apps tend to have small (auto-generated) model classes, which are then managed from the ViewControllers or the AppDelegate. Which is the fastest way to create a fart-app and the like.
In case you're building anything bigger then a fart-app, I suggest to take a different approach: A manager class could be in change of your model (setting it up, saving, etc). The AppDelegate then calls into the model manager when needed. Also, the application code generally improves when the "application logic" is placed in the model classes. To accomodate model changes (and regenerating the model classes), the auto-generated ManagedObjects should then be extended via categories containing your "application logic".
For simple project loading data from network your process should be :
Create a custom LoadingViewController
Show it from the AppDelegate applicationDidFinishLaunchingWithOptions
Get the data with an entity manager
With a callback (delegate pattern should be nice) launch the first viewcontroller according to your data
The first 2 steps are for showing the app data is loading to the user (if you don't do that you'll have the Default.png showing a long time). If the first ViewController data can be refreshed you can directly load it, show cached data first and launch the refresh.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking for code must demonstrate a minimal understanding of the problem being solved. Include attempted solutions, why they didn't work, and the expected results. See also: Stack Overflow question checklist
Closed 9 years ago.
Improve this question
I wnt to call to my webservice once every 45sec. Actually what I want to do is, user start to play some music within my application if user playing a song, every 45sec app should send a call to web service saying "User playing a song" likewise. I dont have any idea about iOS threads. So can anybody tell me how can I do this? Do I need to do threads or are there any other way to do this?
Thankyou
Here's some code to help you.
Set a NSTimer somewhere, like in viewDidLoad, to run every 45secs, performing your web service call:
[NSTimer scheduledTimerWithTimeInterval:45.0
target:self
selector:#selector(callService)
userInfo:nil
repeats:YES];
And then implement the selector used in the timer, running some code in background, as you want:
-(void)callService
{
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
//Code in this part is run on a background thread, call your service here
});
}
You need to perform this action on background thread. So it wont affect the UI. User can perform any other action. For that you may want to use an NSTimer and performSelectorInBackground: withObject:. Using an NSTimer You can repeatedly call a method. From that call the web service method in background. GCD also a better option.
I'm just beginning to work on iPhone apps. How do I know when I should be putting stuff in AppDelegate versus a custom class? Is there a rule or any type of analogy with another programming language like Python or PHP that uses an AppDelegate like pattern?
I normally avoid the design approach implied by Andrew's use of the term "heart of your application". What I mean by this is that I think you should avoid lumping too many things in a central location -- good program design normally involves separating functionality by "area of concern".
A delegate object is an object that gets notified when the object to which it is connected reaches certain events or states. In this case, the Application Delegate is an object which receives notifications when the UIApplication object reaches certain states. In many respects, it is a specialized one-to-one Observer pattern.
This means that the "area of concern" for the AppDelegate is handling special UIApplication states. The most important of these are:
applicationDidFinishLaunching: - good for handling on-startup configuration and construction
applicationWillTerminate: - good for cleaning up at the end
You should avoid putting other functionality in the AppDelegate since they don't really belong there. Such other functionality includes:
Document data -- you should have a document manager singleton (for multiple document applications) or a document singleton (for single document applications)
Button/table/view controllers, view delegate methods or other view handling (except for construction of the top-level view in applicationDidFinishLaunching:) -- this work should be in respective view controller classes.
Many people lump these things into their AppDelegate because they are lazy or they think the AppDelegate controls the whole program. You should avoid centralizing in your AppDelegate since it muddies the areas of concern in the app and doesn't scale.
Your application delegate is the heart of your application. It's effectively your "Program Controller".
The Application Delegate is the class that receives application-level messages, including the applicationDidFinishLaunching message most commonly used to initiate the creation of other views.
While not exactly similar you could think of it as the "main()" routine of your Cocoa program.
#Shivam, thanks.
From what I understand of appDelegate, is close to what an Application is in Android. The viewDidLoad, viewDidDisappear is comparable to what Android's Lifecycle. Every application has a life cycle, from launching to interruptions from calls coming in, to notifications showing up. If you need your code to do something special when these system events occur then you need to write code the methods.
In Android we use onPause, onDestroy, onCreate kinda callback methods to handle such system events.
Hope this will help a little more ...
Programmers new to this language always have the same question - does the program start from a main method? Yes, you are right in this case; IOS apps also start from a main method. Your main class calls the below function:
UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class]));
UIApplicationMain kicks off the Cocoa Touch run loop and app infrastructure which creates a UIApplication object. Our application needs content so objective-c uses a delegate to handle this. That's why we call it AppDelegate (act as delegate of UIApplication). We implement some of the optional methods of that delegate and it behaves accordingly.