Cocoa Touch Best Practices

Cocoa Touch is the foundation of every iOS app that builds UI and implement attracting user experience. This session focuses on how to make use of the cocoa touch framework and aid developers in their iOS apps.

Goal

• Perforamce
• User Experience
• Future proof
  • Leverage Framework
    • reduce maintainance costs
    • get improvement for free
    • focus time on make app special
    • System Versioning? target two major recent iOS version
      • Include version fallbacks
      • if systemVersion == 9.0 (wrong)
      • if systemVersion >= 9.0 (correct)
      • if available(9.0, *)
      • else clause if unavailable.

• App Lifecycle

  • launch quickly!
  • applicationDidFinishLaunching return quickly!
    • Defer long running tasks
    • App will be killed if launching too long
  • Beyond App Launch (Being responsive to every input)
    • Not just async
    • Putting long running tasks into background queue
  • Don't take too much memory when goes into background because
    • the first background app spending most memory will be killed if foreground app requires more memory
    • In Split View , there are two forground app at the same time
      • the app die more easily.

• View and View controllers

  • Avoid hard-coded layout values (dimension scales in difference devices)
  • Thinking of layout in terms of sizes
    • Size thresholds trigger major changes
    • Packaged in TraintsCollections
  • Use Properties, Not tags
    • collisions with other code (using int and don't know others)
    • No Compiler warning
    • No runtime error
    • Add property in class and use it acorss the class
  • Make Timing Deterministic
    • Do not hard code any timer to match animation time of system UI
    • Leverage UIViewControllerTransitionCoordinator
      • Animation alongside a transition
      • Get accurate completion timing
      • Support interactive and cancelable animations (WOW)

• AutoLayout Best Practices

  • Modify Constraints Efficiently
    • Identify constraints that added, removed or changed
    • Unchanged constraints are optimized (!)
    • Avoid removing all constraints (since system also provide constraints to views)
    • Use explicit reference to the constraints
  • Constraints Specificity
    • De-duplicating constraints
      • the constraints does same of others.
    • Create flexible constraints
      • Avoid hard code values
      • V:30-[Label(==260)] is suggested as the label is not resize when the horiontal size get larger
      • Instead, descrive constraints using bounds
      • 
    • Fully specific constraints
      • avoid ambiguity due to underspecific
      • handy function for debug and testing
        • [UIView hasAmbigousLayout]
        • Call on window to reveal entire view tree
        • [UIView _autolayoutTrace] to find
        • Putting them into unit testing
          • ( if [UIView hasAmbigousLayout] true and show [UIView _autolayoutTrace] as test report)

• Table and Collection

  • Use self-sizing cells (intriniticContentSizes)
    • Fully specific constraints
    • thinking in the way as Width = input; height = output
    • Tips if the self-sizing not working
      • Adding height of contentView
      • if same as intriniticContentSizes height => ok
      • if not same => constraints are not set up correctly
  • Animating Heights Changes
    • change your model and reloadData , not good UX as not animated
    • use [tableView beginUpdates] for self-sizing or not
    • update model
    • update cell content by getting cell reference from [tableView cellForRowAtIndexPath]
    • [tableView endUpdates]
  • Custom CollectionView Layout
    • Sticky header in collectionView (supplyment cell)
    • [UICollectionView invalidationContext]
    • Invalidate on bounds changes
    • Build targeted invalidation context
    • repeat as necessary (as the operation are check)