Xcode 8 seems to be printing, for whatever reason, lots and lots of extra debug information.
We can shut it down by means of an environment variable:
OS_ACTIVITY_MODE = disable
Category Archives: iOS
UITextView + Intrinsic Content Size
Note to future self: the trick to get intrinsicContentSize to properly work, in UITextView instances, is to simply disable scrolling in the UITextView instance.
That way… the intrinsic size will be properly calculated.
Using Xcode 7.x with an iOS 10 Device
Trick of the month….
- Upgrade your device to iOS 10
- Install Xcode 8 (Beta)
- Hook up your device and launch Xcode. It’ll download debugging symbols.
- Run this command in bash:
sudo ln -s /Applications/Xcode-beta.app/Contents/Developer/Platforms/iPhoneOS.platform/DeviceSupport/10.0\ (14A5261u) /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/DeviceSupport/10.0\ (14A5261u)
And now you can use your iOS 10 device with Xcode 7. Phew
ARC: weakSelf Caveats
Here’s an interesting ARC scenario. Consider the following snippet:
__weak __typeof(self) weakSelf = self;
int64_t delay = (int64_t)(0.1 * NSEC_PER_SEC);
dispatch_after(dispatch_time(DISPATCH_TIME_NOW, delay), dispatch_get_main_queue(), ^{
[weakSelf doSomething];
});
int64_t delay = (int64_t)(0.1 * NSEC_PER_SEC);
dispatch_after(dispatch_time(DISPATCH_TIME_NOW, delay), dispatch_get_main_queue(), ^{
[weakSelf doSomething];
});
Whenever the block gets executed… weakSelf might have a valid reference, or not. Right?.
Now, what happens with the following snippet?
__weak __typeof(self) weakSelf = self;
int64_t delay = (int64_t)(0.1 * NSEC_PER_SEC);
dispatch_after(dispatch_time(DISPATCH_TIME_NOW, delay), dispatch_get_main_queue(), ^{
[weakSelf doSomething];
[weakSelf doSomethingElse];
});
int64_t delay = (int64_t)(0.1 * NSEC_PER_SEC);
dispatch_after(dispatch_time(DISPATCH_TIME_NOW, delay), dispatch_get_main_queue(), ^{
[weakSelf doSomething];
[weakSelf doSomethingElse];
});
This is where it gets interesting!. There’s a possibility that doSomething might get executed, while doSomethingElse might not.
If you need to prevent such scenario, a possible workaround is:
__weak __typeof(self) weakSelf = self;
int64_t delay = (int64_t)(0.1 * NSEC_PER_SEC);
dispatch_after(dispatch_time(DISPATCH_TIME_NOW, delay), dispatch_get_main_queue(), ^{
__typeof(self) strongSelf = weakSelf;
[strongSelf doSomething];
[strongSelf doSomethingElse];
});
int64_t delay = (int64_t)(0.1 * NSEC_PER_SEC);
dispatch_after(dispatch_time(DISPATCH_TIME_NOW, delay), dispatch_get_main_queue(), ^{
__typeof(self) strongSelf = weakSelf;
[strongSelf doSomething];
[strongSelf doSomethingElse];
});
This snippet warrantees that: if (at the moment of the block’s execution) weakSelf is not nil, it won’t be for the rest of the snippet.
Another interesting note (for future reference) is: self is considered strong, and it may not get invalidated at the middle of a method execution. Okay?
P.s.: Thanks to this Blog Post
Swift: Unit Testing
I’ve recently stumbled upon severe issues, while trying to write a Unit Test, in Swift, that would access Swift Code that belongs to the main app.
Contrary to what almost everyone mentions, you should not import the Main App’s files into the Testing target.
Instead, this is what you should do:
- Enable Defines Module in the main target.
- Add an import at the top of the Unit Test, to make the main project visible.
- Make sure that the classes to be tested are set to public.