awakeFromNib, layoutSubviews, dequeueReusableCellWithIdentifier and what happens in what order

If you have customized code in your UITableViewCell subclass like myself, you usually have some startup code for the cell, usually setting some constraints, or colors of text, default placeholder, etc. It generally doesn't matter whether this code goes in awakeFromNib or layoutSubviews, as long as what you do after dequeueReusableCellWithIdentifier doesn't depend on logic in either of these startup methods.

In the case where it does, you need to know which one happens in which order, in my case I'm using a custom UITextView that has placeholder text, via a nice blog post on how to do that:

https://grokswift.com/uitextview-placeholder/

The issue was that when opening a form to fill out for a new document the text is empty, so you need placeholder text. On top of this I have a label that needs to show (alpha = 1) when text from the user is inputted. When no text exists in the TextView the label needs to animate away and the Placeholder text needs to appear.

So you can see the possible logic branches I have, the issue was that at first launch of the cell before any text is set (if text already exists), my custom placeholder UITextView needs to get setup with constraints, placeholder text, placeholder text color, etc. But when the text already exists it needs to be set after the deque method is called, which then should disable the label and put the real text in the TextView (thus disabling the placeholder).

I got in a bind because I couldn't figure out which of these 3 methods run in which order, in this case, print out to console obviously shows you.

Here's the 3 important parts of code:

(called from the UITableViewController)

let cell = tableView.dequeueReusableCellWithIdentifier(notesTextViewCellId)

(inside the UITableViewCell subclass)

override func layoutSubviews() {
    super.layoutSubviews()
    print("layoutSubviews called")

    // do startup code here?
}

override func awakeFromNib() {
    super.awakeFromNib()
    print("awakeFromNib called")

    // or here?
}

or both?

In my case it was both.

Constraints needed to be in the awakeFromNib() and setting the placeholder logic needed to be in the layoutSubviews() as that happens AFTER the cell is dequed, where the awakeFromNib() happens before.

Here's the order when printed out to the console:

awakeFromNib called
notesCell dequeued
layoutSubviews called

Draw a red border around your UIView for debugging purposes

A lot of the times, you're dealing with UITextViews and UITextFields that have the same white background and border as the superviews they sit on top of. It's helpful every now and then to make sure they're obeying the constraints you want them to have. In my case, I made a self-contained UITextView that has a placeholder functionality but the textView wasn't constraining to the size of its container view.

DOH!

Ahh... needed better constraints:

func applyConstraintsToTextView() {

    if let validTextView = self.placeholderTextView {
        let viewsDictionary = ["textView":validTextView]
        self.addConstraints(NSLayoutConstraint.constraintsWithVisualFormat("H:|[textView]|", options: [], metrics: nil, views: viewsDictionary))
        self.addConstraints(NSLayoutConstraint.constraintsWithVisualFormat("V:|[textView]|", options: [], metrics: nil, views: viewsDictionary))
        setNeedsLayout()
    }
}

Now add this extension to UIView

extension UIView {

func drawRedBorder() {
    self.layer.borderColor = UIColor.redColor().CGColor
    self.layer.borderWidth = 1.0;
    }
}

simply call it on the view (any UIView subclass) and see where the borders are landing.

validTextView.drawRedBorder()

Much better...

Quickly add a simple UIActivityIndicator to your screen

Sometimes you need to quickly throw a progress indicator over your view while something processes (hopefully in the background).

I've found this code to be useful for that situation. Apply to your needs.

UIActivityIndicatorView *activityIndicatorView = [[UIActivityIndicatorView alloc] initWithFrame:self.view.frame];
activityIndicatorView.activityIndicatorViewStyle = UIActivityIndicatorViewStyleWhiteLarge;
activityIndicatorView.backgroundColor = [UIColor colorWithRed:0.0 green:0.0 blue:0.0 alpha:0.5];
[self.view addSubview:activityIndicatorView];
[activityIndicatorView startAnimating];

[self.presentingViewController dismissViewControllerAnimated:YES completion:^{
    dispatch_queue_t queue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0ul);
    dispatch_async(queue, ^{
        // do your processing in the background here
        dispatch_sync(dispatch_get_main_queue(), ^{
            // Update UI
            [activityIndicatorView stopAnimating];
            [activityIndicatorView removeFromSuperview];
        });
    });
}];

Finder shortcut to open a directory path

I find myself using this a lot after a co-worker showed me. Basically, if you come across a directory path you need to get to, like to drop files into a folder or delete file, whatever, instead of manually clicking each directory to get to the destination, you can copy and paste the path into finder via

   ⌘ + Shift + G

Modularize your UIImagePickerController usage in Swift

When you run across quick tutorials or answers on using UIImagePickerController the majority have you simply instantiating, containing, delegating and using it inside your UIViewController. As with most coding examples this is for demonstration purposes only, you should always, always abstract out functionality into reusable pieces in any application. The most obvious reason is that if one view controller needs the image picking functionalities, it's a safe bet that another will at some point. If not, well you'll probably run across another need for it in another application, much easier to strip out the code if it's self-containined in one class.
The history of this code has been in Objective-C and it's served me well in more than one app, here I'm converting and using it in Swift for the first time in an app I'm currently building.
To start, create a class, I like using Controller at the end of most classes or structs of this nature.

class PhotoPickerController : NSObject, UIImagePickerControllerDelegate, UINavigationControllerDelegate { }

You do need to inherit from NSObject, if you don't the compiler will tell you that you either need to mark the delegate methods for UIImagePickerControllerDelegate with the prefix @objc or inherit from NSObject.
Now setup your instance variables/properties (now the same thing in Swift remember)

var alertController: UIAlertController?
weak var buttonToPresentPopoverForiPad: UIButton?
weak var viewController: UIViewController?
lazy var pickerController = UIImagePickerController()

1) You'll need a UIAlertController (ActionSheet) to ask the user if they want to take a picture or load from the device/cameraroll.
2) You need to have a weak reference to the button that will start the photo picker workflow so that if an iPad is used, the popOver functionality will work properly, remember on iPhone it's a modal popup, on iPad it's a pop-over.
3) You need a weak reference to the UIViewController that will be presenting the workflow.
4) Finally you need the core of all of this, an instance of UIImagePickerController, and because of swift lazy instantiation awesomeness, you can do it in one simple line. Create it when you first call it.
Now comes the init for your custom container class. This will be the largest method and I suggest breaking it into smaller pieces, but for the sake of clarity,

init(buttonToPresentPopoverForiPad button: UIButton, viewControllerToPresent viewController: UIViewController) {

    super.init()

    self.alertController = UIAlertController(title: "Select a Photo", message: nil, preferredStyle: .ActionSheet)
    self.buttonToPresentPopoverForiPad = button
    self.viewController = viewController

    let cancelAction = UIAlertAction(title: "Cancel", style: .Cancel) { (action) in
        self.alertController?.dismissViewControllerAnimated(false, completion: nil)
    }

    alertController?.addAction(cancelAction)

    let photoAlbumAction = UIAlertAction(title: "Photo Album", style: .Default) { (action) in
        self.selectPicture(.PhotoLibrary)
    }

    alertController?.addAction(photoAlbumAction)

    let cameraAction = UIAlertAction(title: "Take a photo", style: .Default) { (action) -> Void in
        self.selectPicture(.Camera)
    }

    alertController?.addAction(cameraAction)
    alertController?.modalPresentationStyle = .Popover
    if UIDevice.currentDevice().userInterfaceIdiom == .Pad {
        let popOverPresenter = alertController?.popoverPresentationController
        popOverPresenter?.sourceView = self.buttonToPresentPopoverForiPad
        popOverPresenter?.sourceRect = self.viewController?.view.bounds as CGRect!
        popOverPresenter?.permittedArrowDirections = .Any
    }
} 

First, init the super which is NSObject like always, next setup your AlertController to be an ActionSheet with the proper actions, cancel, photo album and take a photo. Again the benefit of the newer UIAlertController API is that you can set the action results for each action inline with blocks, no more delegating to other methods.
For Cancel, just dismiss the alert all together, nothing to see here, just move on.
For Photo Album and Take a picture, you create a method that will open the appropriate modal workflow for each selection.
Finally finish up your AlertController for dealing with the iPad.
Now, here is the selectPicture helper method:

private func selectPicture(pickerType: UIImagePickerControllerSourceType) {
    if UIImagePickerController.isSourceTypeAvailable(pickerType){
        pickerController.delegate = self
        pickerController.sourceType = pickerType;
        pickerController.mediaTypes = [kUTTypeImage as String]
        pickerController.allowsEditing = false
        pickerController.navigationBar.tintColor = UIColor.whiteColor()
        self.viewController?.presentViewController(pickerController, animated: true, completion: nil)
    }
}

I generally now make my methods private that I obviously don't want available in the classes API. That's just my personal preference.
Follow the standard practices now for setting up the UIImagePickerController outlined in Apple's documentation. Choose what will suit you for colors of the navbar, the mediatTypes, etc.
Notice we set the delegate of the UIImagePickerControllerDelegate to self, this container class will handle the callbacks for the UIImagePickerController, instead of the more common example of a UIViewController bloated and dirty with all sorts of tasks assigned to it.
Here's then how you handle those callbacks:
Make sure you use the proper MARK: so indicating the delegate methods

// MARK: - UIImagePickerControllerDelegate methods

func imagePickerControllerDidCancel(picker: UIImagePickerController) {
    self.pickerController.dismissViewControllerAnimated(true, completion: nil)
}

func imagePickerController(picker: UIImagePickerController, didFinishPickingMediaWithInfo info: [String : AnyObject]) {
    let mediaType = info[UIImagePickerControllerMediaType] as! NSString;
    var originalImage, editedImage, imageToUse: UIImage?

    if (CFStringCompare(mediaType as CFStringRef, kUTTypeImage, .CompareCaseInsensitive) == CFComparisonResult.CompareEqualTo) {
        editedImage = info[UIImagePickerControllerEditedImage] as? UIImage
        originalImage = info[UIImagePickerControllerOriginalImage] as? UIImage

        if editedImage != nil {
            imageToUse = editedImage
        } else {
            imageToUse = originalImage
        }

        if let validDelegate = delegate, let validImage = imageToUse {
              validDelegate.photoPicker(self, didSelectImage: validImage)
        }
        picker.dismissViewControllerAnimated(true, completion: nil)

    }
 }

imagePickerControllerDidCancel is pretty straightforward, the only other method that you need would be imagePickerControllerDidFinishPickingMediaInfo, here you handle the image handed back to the delegate. Following standard documentation, you determine the mediatype that was selected, remember it could be a movie file, not just a photo. In our case we just want images. Then decide do you care about the edited image, did you allow image editing in the setup of the controller? Here's where you deal with that. Finally cast the image you want to an optional UIImage. Notice I then call another delegate (of this container class), indicating the image is ready to go and is valid. Now, here's really the last piece of functionality needed.
The user of your container class needs a way to get the image when it's all said and done and ready to give to a viewController and View. So lets go back to the top of your class file and create a protocol that declares a delegate method for use with your new class.

protocol PhotoPickerDelegate: class {

    func photoPicker(picker: PhotoPickerController, didSelectImage image: UIImage)
}

Now all you need to do is simply make your UIViewController or whatever else is using your class abide by this protocol. You could also use NSNotifications as well for even looser coupling, but I think the delegate pattern works fine for this.
Lastly, you need to implement this one method for the UINavigationControllerDelegate

/** UINavigationControllerDelegate is required to ensure the UIImagePickerController has a light status bar instead of black */
func navigationController(navigationController: UINavigationController, willShowViewController viewController: UIViewController, animated: Bool) {
    UIApplication.sharedApplication().statusBarStyle = UIStatusBarStyle.LightContent
}

Prefer Swift's for-in loop over traditional C for loop

I'm sure most of us started our first programming adventures in C.

How many times have you written

for (int i = 0; i < blah; i++)

or something similar in countless methods, functions, etc.?

In C, C++, Javascript, Java, it's ubiquitous.

Then I came upon the most glorious programming language ever created, Ruby

for index in 0..5
    puts "Value of local variable is #{i}"
end

This is obviously equivalent to:

for (int index = 0; i <= 5; i++)

The ease of reading should be obvious in Ruby's typical verbosity. Not that any programmer worth his/her salt can't immediately decipher a traditional for loop.

The idea though is to flow code in a way we read natural language.

So it was no suprise that Swift adopted this for-in loop pattern, and in all cases you should prefer to use this format over the C for loop.

Here's Swift's for-in

for index in 0...5 {
    print("current index is \(index)")
}

Now notice something slightly different

.. vs. ...

In Ruby .. means inclusive (in the example above 0 to 5 including 5). If you added one more dot, ... you'd get exclusive, meaning 0 to 5 excluding 5 (0,1,2,3,4).

In Swift, not the case, ... means inclusive. There currently isn't an exclusive dot offering, although when Swift was first released I remember there being 2 options. This makes sense, in reality if you need exclusive use, you juse use 1 less in value for your range maximum.

You even have the option to just exclude the variable name if it's not needed.

for _ in 0...5 {
    print("Hello")
}

Just remember, that will print 6 not 5 times. A better visualization when you want to do something a set number of times would be to start with 1, 1...5 (visualize needing to do something 5 times).

A good example that I'm currently using that to me reads better is parsring rows and columns in an app:

for rowIndex in 0...self.rows {
    for columnIndex in 0...self.columns {
        // now you have each row and column index.            
    }
}

Having said that there are without a doubt instances where you need to use a C for loop.

Swift's is slightly different:

for var index = 0; index < 10; index += 2 {
    print("index is \(index)")
}

Imagine you need to increment by 2, or multiply by 2 each time, or decrease in value, etc.

Using Xamarin Android Player with Android Studio

Android Studio and its accompanying emulator have actually improved considerably. I'd even say the emulator that ships now is perfectly sufficient to use, although there's obviously the better alternative(s) like GenyMotion.

Having said that, the Xamarin Android Player is probably the best out there for a free fast booting emulator.

First install the XAP, no need to install Xamarin Studio.

Launch Android Studio, have your project ready to launch on an emulator.

Here's thing, the running XAP (after you create a device and press play) will not show up in Android Studios list of devices in the AVD. Don't fret, as it won't matter.

When you finally push the run button you will get a screen like this with an option to now launch on the XAP:

Now you can use the XAP for your project :)