I am working on iPhone application in which i have more than 20 class and i am declaring that classes NSMutableArray into my application's app Delegate file, and accessing them from my different views.
All NSMutableArray are filled by XMLParsar requesting from server.
My application is getting slow in process, is it because i have declare in app delegate file?
or is that proper way to implement?(declaring all objects into app delegate file.)
Thanks.
Nope, you should try to keep your application delegate as simple as possible. There are other ways how to handle shared data - singleton for example. Here's an example: http://www.johnwordsworth.com/2010/04/iphone-code-snippet-the-singleton-pattern/ There also other methods too, depends on your task and application.
Related
I am trying to use Core Data without storyboarding in my app. I want to manage many relationships and I have a kind of singleton class to manage the access to the managedObjectContext, model, and persistentStoreCordinator I got it from this link Singleton datalayer without appdelegate
My problem is that I dont want to use StoryBoards but all the examples that I found use Storyboards. I have problems with UITableView because appDelegate doesnot found it.
I want to create a Single Application and then with a singleton to manage the context and everything, show the objects that I get in a JSON format with nsfetchedresultcontroller or with fetchrequests if I only need one item.
I am using this class. also I have another class called CoreDataTableViewController.h/m it is a subclass of UITableViewController and it has the methods of NSFetchedResultControllers. I got this of the Stanford IOS course. Then I have my MainViewController its a subclass of CoreDataTableViewController and there I get the data from the Json and put it in my ManagedObject and also I overwrite the method cellForRowAtIndexPath. But when I start the simulator I have an error. loaded the "ViewController" nib but didn't get a UITableView.
Core Data doesn't care whether you're using Storyboards or not. Just copy the Core Data related code that you need (you can create a singleton containing the relevant managedObjectModel/context, persistentStoreCoordinator objects and methods) and add it to your own project.
There are no relation between the two. If you need an example of core data that doesnot use storyboard, try Apple's. Good luck!
I am making a application for the iphone and i am using window based application and i am doing this:
#importing all UIViewController class in the appDelegate class.
creating the object for accessing the variables and function and I am controlling all
action,event and controls from the appDelegate class.
I want to ask that is this right approach. I dont want to use view based application, I want to use UIViewController class just only controllers display.
If this is not a good approach for making the application tell me the good process for doing this.
I suggest you take a look at this:
http://www.icodeblog.com/2011/10/11/back-to-basics-an-introduction-to-view-controllers/
You should also read up on the iPhone-programming-basics, you will find a lot of nice tutorials and articles with a quick Google-search for "iPhone programming".
You could just create a singleton that holds the data and methods you want to share and access it from any view controller you want. Conceptually, it's not much different then what you are doing with the appDelegate class but it is better so that you don't clutter up the app delegate.
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.
I am developing app with finding audio frequency by using FFT. In my app, I am not able to call application delegate method in app delegate class as given in below, but I could able to call other custom methods in app delegate class. What mistake I have done?
Please help me!
(void)applicationDidFinishLaunching:(UIApplication *)application
It looks like your project files have got a bit mixed up. To be honest, it's probably easier to start with a new application template as a base and then add your changes into it. If that is not possible, have a look at the following
In your {project_name}.plist file under the Resources folder you should see a setting
Main nib file base name
This will tell you which nib file is loaded at the start (normally MainWindow). Open this file and have a look for 'Files Owner' 'UIApplication'. Right click on this and there should be a link to the delegate. If it isn't there, then that's your problem
Check to make sure your application delegate inherits from NSObject and NOT NSApplication as NSApplication is a singleton. Otherwise your application object will be its own delegate.
You should now be using application:didFinishLaunchingWithOptions:
I am developing an iPhone app for some sweet undergrad research I've been working on. Sadly, my school doesn't offer software engineering / design classes so when it comes to questions of best practices in OO Design, I do a lot of reading.
My Dilemma:
My application loads a view (v1) where, upon user's button click, v1's controller class executes an action method. This action method should fill an array with objects. After that, the user will either execute the action again or click a different tab to load another view. Other views in the application will use the array that v1 populated.
So, where should this shared array be declared? Right now, it's in the AppDelegate class from when I was testing features without a GUI. Should I grab the AppDelegate singleton and add items to it in the v1ViewController? Should it be declared as static?
Thanks for the help!
^Buffalo
EDIT:
Follow-up Question: When interacting with a singleton, which is the better way to talk to it:
[[MyAwesomeSingleton sharedInstance] gimmeSomePizza];
or
MySingleton *s = [MySingleton sharedInstance];
[s gimmeSomePizza];
I guess what I'm wondering is, do you make the sharedInstance method call every time or do you define a pointer to the sharedInstance and then reference the pointer?
Using the app delegate to store data that's shared between views and view controllers is reasonable and appropriate.
In my apps, I view the app delegate as the controller part of MVC, with UIViews and view controllers all being part of the "view". I prefer to use a variant of MVC called Passive View that keeps the model and view parts of my app strictly segregated with only the controller connecting them.
I'm assuming that the array of objects you're storing is your app's model, so storing them on your app delegate makes sense. As Daniel D said, there's no need to make it static.
The app delegate is really the heart of your program. You create and initialize your model and views in your -applicationDidFinishLaunching: method and save your model data and view state in -applicationWillTerminate:. When your view controllers receive events that changes your model, you can call methods on your app delegate to make those changes.
You could store it in an ivar in the app delegate. You don't need to make it static since the app delegate is a singleton anyways (there's never more than 1 instance).
If the app delegate is getting a bit complicated, you can factor out the data storage into a separate model object or perhaps use Core Data.