I'm trying to figure out the SQLite functionality for the iPhone, and I'm having some problems reading my database file from an overridden UITableViewDataSource function. I am storing the database file location in an ivar (as an NSString) in my application delegate, however when I try to access that string from an overridden UITableViewDataSource function, it returns some other object. If I access the string from any of the classes own instance methods, it works fine.
Is there any way to access the application delegate from within overridden UITableViewDataSource functions?
The Application is a singleton which maintains a reference to the app delegate. You can always access your app delegate using:
[UIApplication sharedApplication].delegate
You may need to cast the return to your own app delegate class to get rid of warnings. Even better, write an accessor that returns your upcast app delegate:
#pragma mark access to app delegate etc.
+ (MyAppDelegateClass*) sharedAppDelegate; {
return (MyAppDelegateClass*)[[UIApplication sharedApplication] delegate];
}
Roger is correct, but I personally find it extremely confusing to mix dot syntax and bracket syntax in the same statement.
If this confuses you as well, the equivalent syntax, using only bracket notation, is:
[[UIApplication sharedApplication] delegate];
and yes, you may need to cast the result to be your application delegate class, rather than the generic UIApplicationDelegate class, or you will get a number of compiler warnings, most likely.
While I don't like sticking too much into my AppDelegate, I'll often need to access it to get to other singletons in my app, which makes the method call + cast a little cumbersome. So in most of my apps, I'll define a quick macro in my global header file.
Example follows:
#define MY_DELEGATE (AppDelegate*)[[UIApplication sharedApplication] delegate]
It's a lot easier to refer to MY_DELEGATE.
The problem turned out to be really simple. I had created the NSString to hold the path to my database file using stringByAppendingPathComponent: . I failed to realize that this was going to be autoreleased, and so I didn't bother to explicitly retain it. That reason it was returning a different type of object was because that memory had been reused once the string had been autoreleased.
Explicitly retaining the string holding the path to the database file solved the problem.
Related
I am trying to adopt a SDK written in objective-c in a swift project. The objective-c way to initialize the SDK is as follows:
#implementation ViewController
nokeSDK *nokelock;
- (void)viewDidLoad
{
[super viewDidLoad];
// Do any additional setup after loading the view, typically from a nib.
//INITIALIZE NOKE SDK
nokelock = [[nokeSDK alloc] init];
nokelock->cmd = [[nokecommand alloc] init];
I don't believe there is an equivalent to the arrow operator in swift, so is it possible to still initialize? I can't seem to find any info about his particular subject.
In Objective-C, a property is merely syntactic sugar for accessor methods; if, as is usually the case, these are a front for an instance variable, you can, with the right privacy access, bypass the accessor methods (or not have them in the first place) and get/set the instance variable directly. That's what your code is doing.
But Swift doesn't draw that distinction. A variable declared at the top level of a type declaration, in Swift, is a property; behind the scenes, a stored property has accessor methods, and you are passing through those automatically when you get/set the property. There is no separate instance variable to get/set.
To see what I mean, make a hybrid Swift / Objective-C app with class Thing whose interface looks like this:
#interface Thing : NSObject {
#public
NSString* s;
}
Now create the generated interface. You will see that, in Swift, s is nowhere to be seen.
Presumably, therefore, to rewrite your code, you'd need to turn cmd into a property, or at least provide a setter method. Otherwise, Swift will never be able to set the Objective-C cmd instance variable. Of course, if it is also up to you to rewrite nokeSDK in Swift, your problems are over, as you can now do whatever you like.
I need to call
[[MKLocationManager sharedLocationManager] _applyChinaLocationShift:newLocation]
in my iOS app.
I believe MKLocationManager is a private class, and there does not seem to have a MapKit/MKLocationManager.h file.
I'm not targeting App Store. It's there any way I can use that private API?
Update at 2011-6-23
I really need the answer, or could I de-complie the iOS SDK?
100 reputation is almost all I have. Please help me.
If the above answer isn't working for you, this may be because the entire class is private (including it's header). Here's an alternative approach using some runtime trickery; you must be sure that the signature is correct but we can use some defensive coding to avoid a crash.
First, unless you are calling this just once, I'd wrap up the code in a helper method:
// in some header file, you may want to give the method a prefix too
CLLocation *ApplyLocationManagerChinaLocationShift(CLLocation *newLocation);
You can now use NSClassFromString to obtain a reference to the class and performSelector to perform the method. We can try and make sure the method exists first to be on the safe side:
CLLocation *ApplyLocationManagerChinaLocationShift(CLLocation *newLocation)
{
id sharedLocationManager = [NSClassFromString(#"MKLocationManager") performSelector:#selector(sharedLocationManager)];
SEL theSelector = #selector(_applyChinaLocationShift:);
// this will ensure sharedLocationManager is non-nil and responds appropriately
if (![sharedLocationManager respondsToSelector:theSelector]) {
return nil; // fail silently - check this in the caller
}
return [sharedLocationManager performSelector:theSelector withObject:newLocation];
}
I haven't run the above code but it should do the trick. If for some reason the #selector() calls do not work (I think they should), then you can replace them with NSSelectorFromString() calls instead.
You can simply create the method description yourself, essentially creating your own category on MKLocationManager. By defining how the private method looks you make it callable. But you must be certain about it's signature, because if you are off then your app will just crash.
This category could be put in it's own .h file or if you only use it in one place right above the #implementation.
#interface MKLocationManager (china)
- (CLLocation *)_applyChinaLocationShift:(CLLocation *)newLocation;
#end
I'm able to make the method for the call [self weaponAttachments:mpk5] but I don't like having to call self. I think [mpk5 weaponAttachments] is more natural and is easier to read.
The problem I'm having is I need to pass in the weapon (mpk5) in order to use it, which I can do with the first method but not with the second one. Does this mean that I need to subclass NSDictionary in order to be able to use a statement like [mpk5 weaponAttachments]? If so, how do I get ahold of the caller "mpk5" so that I can use it inside the method?
EDIT
I apologize for not putting this in the first time but my objective is to have [mpk5 weaponAttachments] return an NSDictionary or NSArray. Right now I have NSDictionary *attachments = [self weaponAttachments:mpk5]; which works but it just doesn't seem like the best approach.
So firstly, your two calls are a little mixed up:
[self weaponAttachments:mpk5] calls the weaponAttachments method, passing in the variable mpk5.
But [mpk5 weaponAttachments] is either asking the mpk5 object to return the weaponAttachments property or is asking the mpk5 object to run a method called weaponAttachments (I'm simplifying here - it's always a method, but if you're using properties you probably won't realise this as Objective-C will create them for you).
These are fundamentally different things.
On to the brunt of your question:
I don't like having to call self
...unfortunately, if you're working in an object-oriented language you're going to have to get used to this. Say I have a class called mySimpleClass, and a method inside that class called doSomething. Writing this:
[mySimpleClass doSomething] would be what we call a static method. Whereas calling [self doSomething] from within an instance of mySimpleClass would be an instance method.
If you're unsure of the difference between static and instance methods you should probably step back and take a look at some of the basic guides out there.
I've read that it's bad to use self.ivar = (convenience method) in and object's 'init' method, as this messes with inheritance.
However, if you know you're not going to subclass your object, is it ok to use the self keyword assignment?
i.e. self.iVar = [Object objectConvenienceMethod];
The reason I ask is this. I create a new object with its own init method, and in that method, I perform various initial assignments. Since I don't use the self keyword, I assign them directly to the iVars, and therefore use the alloc methods rather than the convenience methods. I.e.
iVar = [[Object alloc] init];
Or if I use a convenience method, I retain it. I.e.
iVar = [[Object convenienceMethod]retain]
But... when I run my program with the memory leak tool on, all of these assignments are identified as memory leaks.
If I can use the self keyword plus a convenience method instead of alloc-init, then this would avoid the problem.
If I choose to use the alloc-init approach though, where am I supposed to release the iVars?? Just in dealloc?
Thanks for your help :)
Michael
No, because it isn't only subclass behavior you need to take into account — superclass implementations and even the behavior of code generated by the framework (e.g. synthesized accessors and the black magic used to implement KVO) can also cause trouble. It will probably be OK, but that's still a significant chance of being not-OK. All in all, it's best just to follow Apple's recommendation and assign directly.
Assigning to ivars in init shouldn't be reported as leaks in a properly functioning program. If you're seeing that, there's some other problem that you need to address. Try reducing the problem to a minimal case that we can try out and ask about that — then we can tell what's wrong.
If you alloc or retain them in your class's init method, you should release them in the corresponding dealloc method.
I am thinking your "enclosing" class is not being released, and hence its dealloc method is not being called resulting in your iVars not being released.
What is the easiest way to create a global object. I have tried declaring the object outside the method with no luck.
#implementation UV_TouchpadViewController;
NSMutableString *string = [NSMutableString stringWithFormat:#"text"];
Very close -- you can't initialize a non-local variable with a non-const expression, and a method call is inherently non-const, even if it looks like it should be. So basically, change it to
NSMutableString *string;
but if it's only going to be used inside the implementation file (eg. other classes would only get at it through UV_TouchpadViewController, not get/set it directly (this is also the recommended pattern)), then qualify it as static, like so
static NSMutableString *string;
If on the other hand you do want to be able to access it directly from outside UV_TouchpadViewController, leave off the static, but add
extern NSMutableString *string;
to your header file (outside the class #interface), and whomever includes the header will be able to access it. (Note that you could instead just put NSMutableString *string; in your header file, however this is quickly becomes unclear)
Also, if you are trying to do this for a singleton class, (I can't think of a good reason to have a global mutable string -- you know they're not thread safe right?) I recommend reading Apple's docs on singletons first, where they suggest you use ivars, not global variables, even for singletons. However, UV_TouchpadViewController should not even be a singleton (if it is in any way a view controller), it should just have a single instance, if that's all you want.
If on the other hand you just want all UV_TouchpadViewControllers to have access to this one variable, note that across almost all languages this is considered a bad design pattern (globals are bad), and that you should instead stick it in, say, your app delegate (which is guaranteed to have a single globally accessible instance), where it can be an ivar+accessors, and generally considered a setting and (with a little extra code) persisted.
EDIT:
If you want to have a singleton that maintains global state, which I still recommend against -- you should create a class, like for instance ApplicationState, which handles all of the application's global state as a model object in the traditional model-view-controller pattern. I wont go into detail here because that would be highly redundant of a google search.
In your Application Delegate, somewhere, add an ivar ApplicationState *state, and a corresponding #property (and #synthesize in the implementation file).
There are few easier ways to shoot yourself in the foot than by using global variables.
You should never expose a dumb object like a string which has no access control to every object in the app. Any random piece of code anywhere in the app can change the mutable string leading to chaos as the app grows larger.
Usually when people want a global variable what they actually need is either the user defaults or a data model.
The user defaults (NSUserDefaults) is the preference persistence system that saves application state and user's settings both between launches and as the app runs. You can park small bits of data, such as strings, in the defaults and access them easily from anywhere in the app.
A data model is dedicated object that holds the applications data and manages access to it such that only the data model has final control. This makes it easy to tell what has changed the data and how. The data model can be a simple custom class or something elaborate such as core date. You can park the data model in the app delegate or create it as a singleton as the other answered have explained.
I have been using the Apple API for years and I have never needed to use a real global variable. If you think you need one, you probably have misunderstood something about application design in the Apple API. You might want to post a question explaining what you're trying to do with a global variable and what the best strategy should be for doing it without the dangers of using a global variable.
Do you need it for each instance of the class? If so, you should make it an Instance variable. Put
NSMutableString *string;
In your header
And then you can set it in any method in your class.
If this isn't what you meant, update your question or comment.
You can achieve that by implementing getter and setters in the delegate class.
In delegate .h file
Include UIApplication delegate
#interface DevAppDelegate : NSObject <UIApplicationDelegate>
NSString * currentTitle;
- (void) setCurrentTitle:(NSString *) currentTitle;
- (NSString *) getCurrentTitle;
In Delegate implementation class .m
-(void) setCurrentLink:(NSString *) storydata{
currentLink = storydata;
}
-(NSString *) getCurrentLink{
if ( currentLink == nil ) {
currentLink = #"Display StoryLink";
}
return currentLink;
}
So the variable you to assess is set in the currentlink string by setters method and class where you want the string ,just use the getter method.
AppDelegate *del=(AppDelegate *)[[UIApplication sharedApplication]delegate];
TO set:
[del setCurrentLink];
TO Get:
NSString *value=[del getCurrentLink];
All the best
Add:
NSMutableString *globalString = nil;
to any .m file of any object. The nil initialization adds a little safety, since nil objects can be "safely" messaged without outright crashing the app.
Add:
extern NSMutableString *globalString;
to the headers of any other objects that needs to access this global.
Add:
if (globalString == nil) {
globalString = [ [ NSMutableString stringWithFormat:#"text"] retain ];
}
to the init of any class(es) that could be the very first to touch this global, or to some init that happens even earlier.
Globals are a less verbose form of singleton, but with no access restriction or tracking. Use with caution.
actually as per my r&d i got that by use of extern we have to create an instance but the final thing is to #define your variable and can access any where you want without any creating of instance and other thing just directly use variable by its name....