I can set the language for every single element through
#property(nonatomic, retain) NSString *accessibilityLanguage
and I remember that somewhere I came across a mention about a way to set the language for ALL elements at once. I think it was not a category on NSObject but an API that Apple provided. Can'T find it anymore.
Is there an API or was it really just the NSObject category?
You can set the accessibility language of your complete app by setting the accessibilityLanguage property of [UIApplication sharedApplication]. So for setting the language to US English, use [[UIApplication sharedApplication] setAccessibilityLanguage:#"en-US"];
Thanks to zavié: https://stackoverflow.com/a/21284038/2728579
Related
I've found a couple of sources that explain how to use the AppDelegate to share data between objects in an iOS application. I've implemented it quite painlessly and it looks like a good approach in my situation. Thinking about what could be done using the AppDelegate, I am wondering where the line should be drawn.
Obviously there are other ways to share data across view controllers, use Singleton objects, and NSUserDefaults. When is it appropriate to use the AppDelegate to share data? In my current situation, I use this approach to store the appleDeviceToken used for push notifications. I use that token when users login or logout of the app.
In MyAppDelegate.h I declare the property:
#property (nonatomic, retain) NSString *appleDeviceToken;
In MyAppDelegate.m I synthesize appleDeviceToken and then set it:
#synthesize appleDeviceToken;
------------------------------------------------------
- (void)application:(UIApplication*)application didRegisterForRemoteNotificationsWithDeviceToken:(NSData*)deviceToken
{
NSString *devToken = [[[[deviceToken description]
stringByReplacingOccurrencesOfString:#"<"withString:#""]
stringByReplacingOccurrencesOfString:#">" withString:#""]
stringByReplacingOccurrencesOfString: #" " withString: #""];
appleDeviceToken = devToken;
}
Then, in my LoginViewController.m I retrieve it and post it to my server:
NSString *urlForDeviceTokenPost = [NSString stringWithFormat: #"/api/users/%i/appleDeviceToken", userId];
MyAppDelegate *appDelegate = (MyAppDelegate*) [UIApplication sharedApplication].delegate;
NSString *appleDeviceTokenStr = appDelegate.appleDeviceToken;
AppleDeviceToken *appleDeviceToken = [[AppleDeviceToken alloc] init];
appleDeviceToken.deviceToken = appleDeviceTokenStr;
[[RKObjectManager sharedManager] postObject:appleDeviceToken delegate:self];
This works great so far, but is this the ideal approach? What else should I know?
When the data and objects are truly global and/or cannot be pushed further down the graph. Storage at this high level is usually not required. As well, your implementations should usually have little to no knowledge about the app delegate -- What's worse than a Singleton? The God-Singleton :) If the app delegate is complex, something's gone wrong. If the app delegate's interface is visible (via #import) to many of your implementations or they message it directly, then something is wrong.
There is no need for an (idiomatic ObjC) singleton -- there is one instance of the app delegate.
NSUserDefaults is for persistence of small values (as the name implies) -- the ability to share is a side effect.
Since the data is already sent into the app delegate by UIKit in this case, that may be a fine place to store the data, or an object representation of. You might also consider forwarding those messages to an appropriate handler. The important point -- In most cases, you would want initialization to flow down the object graph, and to flow from the lowest points possible (e.g. as opposed to many objects referring back to the app delegate). So you might see the app delegate set a top-level view controller's model, but the view controller can then set the models of the view controllers it pushes. This way you will reduce dependencies and control flow, cause and effect will be easier to trace, and you will be able to test it more easily -- free of the context of a massive global state.
The following line always indicates that you've done something wrong:
MyAppDelegate *appDelegate = (MyAppDelegate*) [UIApplication sharedApplication].delegate;
The application delegate is the delegate of the UIApplication. It is called that for a reason. It is not called the ApplicationDataStore or even the ApplicationCoordinator. The fact that you're asking the application for its delegate and then treating it as something other than id<UIApplicationDelegate> means that you've asked it to do something it isn't tasked with doing. It's tasked with managing the things UIApplication needs (which doesn't mean "everything the 'app' needs).
It appears that you've already built a place to store this information: RKObjectManager. I would have the app delegate pass the token there, and I'd have the login view controller just note that it is time to push it. I wouldn't even put the string #"/api/users/%i/appleDeviceToken" in the view controller. That's not related to displaying the view. That's something for you networking stack (which you seem to have housed in RKObjectManager). "ViewController" means "controller for helping display the view" not "processor of the operation that the view represents."
That seems like an appropriate use. The application delegate is tempting to misuse because it's an easily-accessible object that's already present in every app. It has a real purpose, though, which is, as its title indicates, to make decisions for the application object, just as a table view delegate does for its table view object.
In this case, you're storing information that was passed to the delegate from the application itself. I'd say that's where the line is drawn.
Storing this token seems to be in accordance with the app delegate's purpose, unless you had another controller object which was focussed on dealing with remote notifications. In that case, you would probably just pass the token right on to that controller.
I'm more pragmatic. Since the appDelegate in my app knows how the tabBarController was populated, and all the navigation controllers, I have several methods there that let some arbitrary class communicate with some other class - usually these are single instances of some class (but not singletons). That said, if what you want to put there does not have a compelling reason to be in the appDelegate, well, it probably doesn't belong there!
I want to make a class that can hold settings for my app. Its pretty basic. I will access it from a few different classes, but only want 1 version of this container class to exist so they all see the same data.
Is there something special i need to flag for this?
Here is what I've done so far:
Filters.h
#import <Foundation/Foundation.h>
#interface Filters : NSObject
{
NSString *fuelType;
}
#property (nonatomic, copy) NSString *fuelType;
#end
Filters.m
#import "Filters.h"
#implementation Filters
#synthesize fuelType;
#end
Is there some flag i need to use when i alloc an instance of this class or how should I work this if I need to access the fuelType value from 2 different classes?
Thanks
-Code
For global application settings a better way would be to use NSUserDefaults or if you want to store data for use you should look up using core data and sqlite.
Lastly, if you want to go for ease of use you could do a core data style app delegate class and grab it by using:
[[[UIApplication sharedApplication] delegate] myClass] that way you'll always have that version of the class.
You need a singleton:
you can create your singleton by your own or use AppDelegate object which is an object that is always alive and never released while your application in the frontground (just put the vars needed there and initialize them dynamically).
Here are some links on how to create a singleton.
Cocoa fundamental Guide: Creating a Singleton
and
CocoaDev Singleton Pattern
What you're looking for is a singleton. Most people advise against using singletons though as it is often considered "dirty". See "Singleton" in this apple doc to learn more about it.
we are a group working on an iPhone app. and its our first time. I just would like to know the easy way to implement a public class so that my partner can give me a variable that contains a value i need to use in my code. It doesn't have to be a class any other easy solution would work.
Just to make it more clear my friend has a value in his code that i need to use to display it on the screen "using my code". What i know is that everything has to communicate through a controller class which in this case the thing i need to implement my friend must be able to call it, give it the value then i take this value and display it. THANK YOU IN ADVANCE!
I. Just make an property in .h
#property (nonatomic, retain) NSString *userName;
and in .m file
#synthesize userName;
Docs here
II. He can make and delegate protocol in his class, the you need to set your object to be the delegate of his class instance and implement the delegate method. When he has the vale will call the delegate method and you will recive it in your method.
Docs here
I'm unable to refer to my integer pickedItem declared in my RootViewController.h in my DetailViewController.m file.
Not sure if I should declare this as a global variable, but tried unsuccessfully to do so.
I think this should be simple, but I haven't got any other suggestions (from other posted answers) to work.
Thanks in advance.
You can access the app delegate through [[UIApplication sharedApplication] delegate] this call. And then can access the root view controller's property (assuming you have access to the rootViewController object in appDelagate).
In RootViewController.h
#property(nonatomic, assign) NSInteger myInt
And from anywhere in the code
UIApplicationDelegate *delegate = [[UIApplication sharedApplication] delegate];
delegate.viewController.myInt = 31;
p.s. I have just typed the code, not compiled. So there might be some typo.
You just wouldn't want it coded this way. I recommend taking a look at NSNotificationCenter, or create a delegate class for yourself, to communicate to the DetailViewController of page changes. There shouldn't be a dependency from detail -> root the way you have it.
Based on your code above, I don't see where you're setting rootViewController on detailViewController? Is it nil? I'd think referencing rootViewController.pickedItem if rootViewController was nil would cause a crash, but worth checking.
Also, is pickedItem being set appropriately? In other words, is it set before the detail code is being called?
I am pretty new to iphone programming therefore I apologize if my question could result trivial or obscure.
In many examples and tutorials I have seen that in the declaration of the outlets within Xcode (interface section of the view controller) the keyword "IBOutlet" is used or it is not, in conjunction with the class the outlet belongs to, apparently without a relevant difference.
e.g.
IBOutlet UIButton * myButton;
or
UIButton *myButton;
I have seen by myself in my experiments that both ways seem to work the same (provided that in both cases I set the proper connections in IB, and declare the property and synthesize it)
Anyone could tell me if there is a relevant difference and different behavior between the two statements?
Thank you
IBOutlet is defined the following way:
#define IBOutlet
So it has no impact on the running code, and its only purpose is to allow Interface Builder automatically determine it while parsing class header. Without IBOutlet keyword in header you will need to declare it in IB Inspector's Identity tab to make it avaliable to be connected to interface elements.