Ive been having problems with reloadData on a TableView. I've finally been able to establish that the variable I use to tell reloadData what to reload is resetting to NULL.
I've added the variable in ClassAppDelegate.h as follows:
#property (nonatomic, retain) id globalid;
and then synthesized in ClassAppDelegate.m as follows:
#synthesize globalid;
I then acces the variable in which ever class and method i need to use it with (in the method):
NDSClassAppDelegate *detailControllerAD = [[NDSClassAppDelegate alloc] init];
And then use it in this way to obtain the variable in that method:
NSLog(#"GlobalID at FetchTweets %#", detailControllerAD.globalid);
Why would my variable be resetting on reloadData?
You shouldn't be instantiating an app delegate object - your application is given one at launch as part of the UIApplicationMain() function, and it should live the lifetime of your application. Use [[UIApplication sharedApplication] delegate] to get the delegate, i.e. NDSClassAppDelegate *appDelegate = [[UIApplication sharedApplication] delegate]. Then, anywhere you need to set or read the globalid property, set it on this instance of the application delegate.
Instance variables (which properties are usually backed by) vary independently between instances of objects so you can't store a value in one object and then have the same value appear in another.
When you use this
NDSClassAppDelegate *detailControllerAD = [[NDSClassAppDelegate alloc] init];
new instance created of app delegate.
use this
[[UIApplication sharedApplication] delegate]
to get existing instance of app delegate.
You can use above way to share the data throughout the application . I was also have same requirement in one of my previous application . At two three forum i have read about the sharing the data though out the application . But according to them this is not a good practice to store the data at application level because using app delegate as a model object is non delegate related stuff. So the cleaner approach is to use the singleton class . Create one singleton class to preserve all the variables state. That will be the cleaner approach .
Related
I am using Xcode 4.3 and need to know the parent view controller of the current view.
I am also using storyboard.
self.parentViewController always returns nil.
I saw different answers to save the parent view controller in AppDelegate class as a property. E.g., To create a variable: UIViewController parentViewController in AppDelegate and in the code write:
appDelegate.parentViewController = self;
I am afraid that it will consume memory - as this is a heavy object.
What is the best approach to know aretnViewController when using story board?
Whether or not an object is "heavy" does not matter as long as you store only a reference to it (in your case in the application delegate). Creating a second object would make a difference, but the line
appDelegate.parentViewController = self;
does not do that, it merely stores a reference to the object.
I know that this does not answer your direct question, but I think you should go ahead with the "store a reference in the app delegate" approach.
This question already has an answer here:
Closed 10 years ago.
Possible Duplicate:
How or where should I store object instances that I require globally within my iOS app?
I have some global object (uses in almost all Application Screens) and mostly they are created right after application starts. I want to have access to this objects from all my ViewControllers (nothing else, only ViewControllers). Where to store it?
I think about #property in AppDelegate but i think (but I can be wrong) this is a ugly solution.
Objects can be quite complex, this is not a simple types.
You can make global objects accessible by placing them in a class with class methods for accessing global objects, implementing +(void)load to prepare these objects, and storing them in static variables.
Header:
#interface GlobalObjects
+(void)load;
+(MyObject1*)myObject1;
#end
Implementation:
#import "GlobalObjects.h"
static MyObject1* _myObject1 = nil;
#implementation GlobalObjects
+(void)load {
_myObject1 = [[MyObject1 alloc] init];
}
+(MyObject1*)myObject1 {
return myObject1;
}
#end
Usage:
MyObject1 *shared = [GlobalObjects myObject1];
You could also make the variable static inside its method for lazy initialization.
Yeah I use properties of the App Delegate, then access them by casting the sharedApplication delegate property.
__weak AppDelegate *appDelegate = (AppDelegate *)[[UIApplication sharedApplication] delegate];
Hope this helps,
Jonathan
#property in AppDelegate is a good solution. You could also use a singleton.
You app delegate is fine if you just have a bunch of objects.
Otherwise you might build a sort of "model object" containing all of your global data.
Or, you might store them with Core Data, if they have any structure at all.
But, as I said, if you have just a couple of objects, the app delegate will just do fine.
if it's only used among view controllers, you might consider storing it in the highest level view controller which actually needs access to the shared object (when creating/pushing new controllers, set that reference counted property).
in this way, you might think of the master view controller populating the detail view controllers with their content/models.
that's really stepping away from qualification as (and burdens of) a global.
In another question ( Accessing an NSApplications delegate in another class? ) I asked about calling the Application's delegate because I needed it's managedObjectContext for a fetch request. However, when I try to let all values be displayed in an NSTableView on application startup, I'm running into problems. DataController, my NSTableViewDataSource, calls it's init-method before my application delegate calls it's applicationWillFinishStartup or any other method to initialize the managedObjectContext. What am I doing wrong? How else can I fill an NSTableView with already existing objects?
You should access managedObjectContext only via its getter, even from DataController, as in [appDelegate managedObjectContext] or appDelegate.managedObjectContext.
Your managedObjectContext method should automatically set up the managed object context; you shouldn't write an explicit moc setup routines in your applicationDidFinishLaunching, etc. And the standard core-data template is written that way.
Now, for this to work, the app delegate needs to be properly set up from the point of view of DataController. However, init is called before all the IBOutlet is set up, so that's the wrong place to perform setup operations of objects inside the nib. Instead, use awakeFromNib to do these things. awakeFromNib is sent to every object after the IBOutlet etc. are all set up.
That said, writing your own DataController is a total waste of time. Just instantiate the standard NSArrayController in the nib file, and use it in the Core Data mode via binding. There's absolutely no need for you to write the fetch request by yourself. Study Apple's own CoreData sample codes and then google "Binding CoreData Tutorial" for many tutorials available on-line.
A quick question regarding Managed Objects.
I created an Array with Managed Objects (in Object 1: TableViewConbtroller), and pass one of those objects to another class/object (object 2: TableCell).
The original array should still be retained in the original caller class.
Then Object 2 is released, does that mean that that particular item in the array is released as well, as the reference to it in Object 2 was released?
I am trying to better understand how to work with ManagedObjects as I get 'Object was released' errors.
[EDIT]
After some experimenting I came across the following scenario:
I have the main AppDelegate.
In a different class I create an AppDelegate to obtain the ManagedObjectContext.
appDelegate = (iDomsAppDelegate *)[[UIApplication sharedApplication] delegate];
[self setContext:[appDelegate managedObjectContext]];
When the class is finished, and I release it, the variable in the class 'appDelegate' is also released. But then the ManagedObjectContext is closed, and obvious any future attempt to use it will cause a crash. So should I leave the appDelegate unreleased?
This comes to the same question as the above about when and how to release in those situations where an objects is used from another class. I think a way of putting it is, how to know when you own an object and when not.
The UIApplication retains your app delegate, so releasing it in your view controller's dealloc method will not deallocate the app delegate.
i want to access a integer and a string from a class to all the other classes?
what is the best way to do it?
i want to increase the values any where in the program and then want to update them in the class declared....
any idea how to achieve this???
Here's a question (and good answers) about singletons.
You could also use the app delegate, as frankodwyer suggested, and access it from anywhere using:
id delegate = [[UIApplication sharedApplication] delegate];
For ease of use and type safety I use a category like this:
// put his in your delegate header file
#interface UIApplication(MyAppAdditions)
+ (MyAppDelegate*)sharedDelegate;
#end
// put his in your delegate implementation file
#implementation UIApplication(MyAppAdditions)
+ (MyAppDelegate*)sharedDelegate {
return (MyAppDelegate*)[[self sharedApplication] delegate];
}
#end
Now you can access your app delegate from everywhere: [UIApplication sharedDelegate]
You could make the integer and string properties of your app delegate and pass references to the delegate around to your views. I do something like this myself, though to be honest it is a pain and also a little error prone to make the app delegate available to all the views.
Or (and this is probably better), you could declare a singleton class (google the singleton pattern) as one of your data classes, and have your integer/string be properties of that. Then you could access the getters/setters of your singleton from anywhere in your program. You will need to take extra care if you have multiple threads however,