The last two are identical; "atomic" is the default behavior (note that it is not actually a keyword; it is specified only by the absence of nonatomic
-- atomic
was added as a keyword in recent versions of llvm/clang).
Assuming that you are @synthesizing the method implementations, atomic vs. non-atomic changes the generated code. If you are writing your own setter/getters, atomic/nonatomic/retain/assign/copy are merely advisory. (Note: @synthesize is now the default behavior in recent versions of LLVM. There is also no need to declare instance variables; they will be synthesized automatically, too, and will have an _
prepended to their name to prevent accidental direct access).
With "atomic", the synthesized setter/getter will ensure that a whole value is always returned from the getter or set by the setter, regardless of setter activity on any other thread. That is, if thread A is in the middle of the getter while thread B calls the setter, an actual viable value -- an autoreleased object, most likely -- will be returned to the caller in A.
In nonatomic
, no such guarantees are made. Thus, nonatomic
is considerably faster than "atomic".
What "atomic" does not do is make any guarantees about thread safety. If thread A is calling the getter simultaneously with thread B and C calling the setter with different values, thread A may get any one of the three values returned -- the one prior to any setters being called or either of the values passed into the setters in B and C. Likewise, the object may end up with the value from B or C, no way to tell.
Ensuring data integrity -- one of the primary challenges of multi-threaded programming -- is achieved by other means.
Adding to this:
atomicity
of a single property also cannot guarantee thread safety when multiple dependent properties are in play.
Consider:
@property(atomic, copy) NSString *firstName;
@property(atomic, copy) NSString *lastName;
@property(readonly, atomic, copy) NSString *fullName;
In this case, thread A could be renaming the object by calling setFirstName:
and then calling setLastName:
. In the meantime, thread B may call fullName
in between thread A's two calls and will receive the new first name coupled with the old last name.
To address this, you need a transactional model. I.e. some other kind of synchronization and/or exclusion that allows one to exclude access to fullName
while the dependent properties are being updated.
How can one get the dimensions of the screen in iOS?
The problem with the code that you posted is that you're counting on the view size to match that of the screen, and as you've seen that's not always the case. If you need the screen size, you should look at the object that represents the screen itself, like this:
CGRect screenRect = [[UIScreen mainScreen] bounds];
CGFloat screenWidth = screenRect.size.width;
CGFloat screenHeight = screenRect.size.height;
Update for split view: In comments, Dmitry asked:
How can I get the size of the screen in the split view?
The code given above reports the size of the screen, even in split screen mode. When you use split screen mode, your app's window changes. If the code above doesn't give you the information you expect, then like the OP, you're looking at the wrong object. In this case, though, you should look at the window instead of the screen, like this:
CGRect windowRect = self.view.window.frame;
CGFloat windowWidth = windowRect.size.width;
CGFloat windowHeight = windowRect.size.height;
Swift 4.2
let screenRect = UIScreen.main.bounds
let screenWidth = screenRect.size.width
let screenHeight = screenRect.size.height
// split screen
let windowRect = self.view.window?.frame
let windowWidth = windowRect?.size.width
let windowHeight = windowRect?.size.height
Best Answer
You can use something like
UIInterfaceOrientationIsPortrait([UIApplication sharedApplication].statusBarOrientation)
to determine the orientation and then use the dimensions accordingly.HOWEVER, during an orientation change like in UIViewController's
Use the orientation passed in
toInterfaceOrientation
since the UIApplication's statusBarOrientation will still point to the old orientation as it has not yet changed (since you're inside awill
event handler).Summary
There are several related posts to this, but each of them seem to indicate that you have to:
[[UIScreen mainScreen] bounds]
to get the dimensions,Links
Working Code
I usually don't go this far, but you piqued my interest. The following code should do the trick. I wrote a Category on UIApplication. I added class methods for getting the currentSize or the size in a given orientation, which is what you would call in UIViewController's
willRotateToInterfaceOrientation:duration:
.To use the code simple call
[UIApplication currentSize]
. Also, I ran the above code, so I know it works and reports back the correct responses in all orientations. Note that I factor in the status bar. Interestingly I had to subtract the MIN of the status bar's height and width.Hope this helps. :D
Other thoughts
You could go about getting the dimensions by looking at the UIWindow's
rootViewController
property. I've looked at this in the past and it similarly reports the same dimensions in both portrait and landscape except it reports having a rotate transform:Not sure how your app works, but if you aren't using a navigation controller of some kind, you could have a UIView under your main view with the max height / width of parent and grows / shrinks with parent. Then you could do:
[[[[[[[UIApplication sharedApplication] keyWindow] rootViewController] view] subviews] objectAtIndex:0] frame]
. That looks pretty intense on one line, but you get the idea.However... It would still be better to do the above 3 steps under the summary. Start messing with UIWindows and you'll find out weird stuff, like showing a UIAlertView will change UIApplication's keywindow to point at a new UIWindow that the UIAlertView created. Who knew? I did after finding a bug relying on keyWindow and discovering that it changed like that!