After reading some tutorials online, I've seen 2 different ways to declare properties.
I'm wondering if one is more correct than the other:
Option 1:
#import <UIKit/UIKit.h>
#interface AppDelegate : NSObject
#property (strong, nonatomic) UIWindow *window;
#property (strong, nonatomic) UITabBarController *mytabs;
#end
Option 2:
#import <UIKit/UIKit.h>
#interface AppDelegate : NSObject {
UIWindow *window;
UITabBarController *mytabs;
}
#property (nonatomic, retain) UIWindow *window;
#property (nonatomic, retain) UITabBarController *mytabs;
#end
The first option uses Automated Reference Counting (ARC); the second one does not. Neither one is "more correct" than the other - the first one is simply more modern. You should use ARC unless you have strong reasons not to (e.g. because of the need to support legacy code on legacy platforms).
Here is a link to learn more about ARC.
Option 1 has ARC enabled. Since iOS5 SDK it's the default option in Xcode.
strong means that the view controller will manage this variable
Here is a good ARC tutorial for iOS5.
Option 2 has Automatic Reference Counting disabled.
the view controller will retain (increase the retain count) when the variable is set
It used to be necessary to explicitly declare an instance variable to back each property. With the "modern" runtime, that's no longer required -- your #synthesize directive for the property will take care of creating the iVar if one doesn't already exist. Some people still keep the ivar declaration, either out of preference or just habit, and of course you'll see the ivars declared in older code. One benefit of doing it is that you can more easily see the values of your properties in the debugger.
The difference between using strong and retain is a matter of using ARC or not, respectively.
Related
When I control-drag outlet from the storyboard, I got the strong property by default. I'm using Xcode 9.4.1. The following code is what it looks like. Is it because of XCode Swift compatibility as in Swift it makes sense to create strong.
#property (strong, nonatomic) IBOutlet UILabel *lbl
The default value should be weak, but if you once change it manually to strong as shown in the photo, the default value changes to strong, so you need to manually put it back to weak.
I am using XCode 5.1.1, targeting iOS 7.0.
When creating outlets from my storyboard using the Assistant editor. I notice I have a few choices to create properties or ivars. The one I have been using is dragging directly to my *.m #implementation and it creates code like:
#implementation AudioViewController
{
__weak IBOutlet UILabel *posLabel;
__weak IBOutlet UILabel *durationLabel;
__weak IBOutlet UIButton *playButton;
}
I have no need to access these outside of this class, so this seems convenient, but I am wondering if there are any "gotchas" to this method vs creating properties, especially in regards to memory management. I read on other stack answers that you must create (weak) properties or I will have to [release] manually. I am wondering if this __weak takes care of that in this context?
Thanks!
Creating properties and instance variables with the same modifier is mostly analogous. When you are using ARC, you do not have to release strong properties or instance variables - they will be released when the object is deallocated. Interface element outlets are usually created as weak, because they are retained by the view hierarchy. You should be careful; if you intend to remove the elements from the view hierarchy at some point, you should change the modifier to strong to ensure they are retained by the view controller. Top-level outlets should also be created as strong to make sure they are retained after nib load.
I have two view controller files which is InputViewController and CurrencyViewController. I want to access the variable declared in InputView inside CurrencyView. It is designed in Empty Application Project.
You can declare the variable globally in AppDelegate & then can access in both viewController.
The changes made in the variable will reflect in both controllers.
Make the variable as a property of AppDelegate.h class
eg. #property (strong, nonatomic) NSString *Var;
& synthesize it in AppDelegate.m
#synthesize Var;
declare "AppDelegate * appDelegate" in both Controllers.h & then in controller.m in viewDidLoad write appDelegate=[[UIApplication sharedApplication]delegate];
now the variable can accessible using appDelegate.var anywhere in your code of both ViewController & changes are also reflected in both.
Hope this will work more efficiently for your need.
When I simulate a memory warning, viewDidUnload should run on unused objects, right?
How do I go about figuring out WHY my UIView won't go away?
FYI I'm using ARC and every ivar is an IBOutlet and looks like:
#property (nonatomic, weak) IBOutlet UIView *someView;
What class are we looking at here? Only UIViewControllers release their view in case of a mem warning.
If this is a custom class or a custom added view, you should unload it yourself.
I started to create a project from the master detail template and realize that my main controller should be a simple mvc. Is there any simple method to do the conversion beside recreate a project from scratch with a mvc template? What should be edited then?
The templates just set up your appDelegate with the proper elements. You could edit your appDelegate quickly, but unless you have a really compelling reason to edit the existing project it would likely be faster to just recreate the project.
With the master-detail template the appDelegate will have these properties (and code in the .m implementing them):
#property (strong, nonatomic) UIWindow *window;
#property (strong, nonatomic) UINavigationController *navigationController;
#property (strong, nonatomic) UISplitViewController *splitViewController;
The standard template will have these (plus the implementation code):
#property (strong, nonatomic) UIWindow *window;
#property (strong, nonatomic) ViewController *viewController;
The implementation file of the appDelegate will also be slightly different due to the NavigationController and SplitViewController in the master-detail. You can just change these files around and update your xib files, but again, it's probably just as fast to start a new project.