Tech

Having to create the same set of buttons over and over can become cumbersome. We'll try to make use of protocols and implement some default ones. Let's start with that:

@objc protocol CanGoBack { // Sounds better than Backable :)
 
  func back()
  
}

We all hate explicitly typed strings, especially for creating UIImages, but we can surely improve on that. Let's start with an enum, that has a var, to transform its raw value into an UIImage:

enum Asset: String {
  case back = "leftArrow"
  case logo
  case email
  case briefcase
	
  // Theoretically, a bang wouldn't be that bad here, 
  // as we should be 100% sure of what goes in this enum
  var image: UIImage? {
    return UIImage(named: rawValue)
  }
}

And why not improve UIImageView too, while we're at it?

extension UIImageView {
  convenience init(asset: Asset) {
    self.init(image: asset.image)
  }
}

I was reading Shannon's post about shape layers, and one of the resources he links to is this page about fill rules. It was interesting to see the inner workings of them. Go and bookmark calayer.com, as well!

The following snapping logic is for a collection with cells of the same size and one section, but the logic for more sections shouldn't be much different, or much more complex.

scrollViewWillEndDragging has an inout targetContentOffset parameter, meaning we can read and modify the end position of the scroll. Luckily, we don't need to take into consideration insets, line or item spacing (I've lost a lot of time by including them, then not being able to understand why the correct math produces wrong results):

let cellWidth = collectionView( // 1
  collectionView,
  layout: collectionView.collectionViewLayout,
  sizeForItemAt: IndexPath(item: 0, section: 0)
).width

I think that what I do here can't really be called writing; it's more like scribbling, my posts are rather small and rare. But I try to be consistent, even if what I'm going to write about seems to not be of a big deal, because I believe that any info, no matter how big or small, might turn out to be useful to someone.

On the other hand, despite all these facts, I have weeks when I have absolutely no idea what to write about; there's zero inspiration. I can't even imagine how hard it is to consistently write posts of 500, 1000 or more words. Hats off.

I personally find this a bit of a mouthful, especially if you have to type it a lot:

if someDate.compare(otherDate) == .OrderedAscending {
  // Do stuff
}

Update, Oct 10, 2017: These are now built-in for Date. Leaving these here like they are (Swift 2), since the whole post is just about them.

But we can have a few operators to make our lives a bit easier:

func <(lhs: NSDate, rhs: NSDate) -> Bool {
	return lhs.compare(rhs) == .OrderedAscending
}
 
func <=(lhs: NSDate, rhs: NSDate) -> Bool {
	return lhs < rhs || lhs == rhs
}
 
func >(lhs: NSDate, rhs: NSDate) -> Bool {
	return lhs.compare(rhs) == .OrderedDescending
}

Postarea originală poate fi găsită [aici][130]. Unele cuvinte/exprimări traduse ori sună ciudat, ori își pierd din înțeles, așa că pentru acestea, am adăugat între paranteze termenul în varianta netradusă "(așa)". Am încercat pe cât posibil să păstrez tonul autorului.

Aceasta este prezentarea pe care am ținut-o la [App Builders din Elveția][1] pe 25 Aprilie 2016.

Slide-urile sunt disponibile pe [SpeakerDeck][127]. Înregistrarea video a sesiunii este disponibilă pe [YouTube][128]. Articolul a apărut în format fizic în ediția din [iunie 2016 a Hacker Bits][129].

I think adding everywhere a deinit method, with a print statement inside, is a decent first barrier against retain cycles:

deinit {
  print("Object X has been deinitialized.")
}

This way, if you expect object x to deinit at some point but it doesn't, you at least know you need to start searching, and where.

Now, for the improved printing, to make this a bit cleaner and easier:

Usually an app has fonts with well defined purposes. So why not let enums make our lives easier, a little bit? First, a couple of them, to define our font families and weights:

struct Font {
  private enum Family: String {
    case avenirNext
    case proximaNova 
  }
  
  private enum Weight: String {
    case regular
    case medium
    case demiBold
    case bold
  }
}

Then a method to easily create fonts:

Let's say we have a custom UILabel, which in turn has several types; maybe a StatusLabel that can be of type sold out and expired. The label would have several common properties, but each type would have something specific. How can we go about this?

class StatusLabel: UILabel {
  enum StatusType {
    case soldOut 
    case expired
  }
  
  init(type: StatusType) {
    super.init(frame: .zero)
    
    font = UIFont.common
    layer.cornerRadius = 4
    textAlignment = .center
    translatesAutoresizingMaskIntoConstraints = false
  }
}

We now covered the common parts, and we could go ahead and set the backgroundColor and textColor like this: