Evolution of Asynchronous Programming on iOS

0ebf471a3ae8df42a84f93a7efbbdbd0?s=47 Ash Furrow
October 02, 2015

Evolution of Asynchronous Programming on iOS

Presented at Mobiconf 2015: http://2015.mobiconf.org

0ebf471a3ae8df42a84f93a7efbbdbd0?s=128

Ash Furrow

October 02, 2015
Tweet

Transcript

  1. Ash Furrow, Artsy (on iOS) Evolution of Asynchronous Programming

  2. Evolution of Async Programming

  3. Agenda • All decisions are made in a context •

    iOS developers are human; we tend to conflate things • Older solutions have value, too • There are benefits to using older technology
  4. (•_•) <) )╯ / \ \(•_•) ( (> / \

    (•_•) <) )> / \ Decisions are made in a context
  5. What’s a context?

  6. Contextual Questions • What technology is available? • How much

    do I understand the options? What about my team? • How popular is the technology? • How stable are the tools I would need to use? • How easy is it to learn? • How quickly do I need to complete the task?
  7. Decisions aren’t made in a vacuum

  8. Unique, in space… and time

  9. Adopting a codebase

  10. Context includes experience

  11. But you don’t have to You can never understand the

    context a decision was made in
  12. It is enough to appreciate that a context existed

  13. Be empathetic

  14. iOS developers conflate things ⽌ •́ ﹏ •̀ ⽎

  15. conflate verb [ with obj. ] combine (two or more

    ideas, texts, etc.) into one.
  16. Humans look for patterns

  17. None
  18. None
  19. What does this have to do with iOS development?

  20. Some popular development practice When learning iOS, we’re bad at

    that practice Popular development practice is bad + =
  21. We get better at iOS development New thing comes out,

    and we’re good at it New thing is good + =
  22. This is why new things are always so appealing

  23. Why do iOS devs do this? There are several explanations

  24. iOS is young … really young

  25. Always older APIs for us to blame iOS is constantly

    changing
  26. I’ve done this a lot You probably have, too

  27. Only human

  28. Remember… Don’t be hard on yourself!

  29. And don’t be hard on others! We’re all just winging

    it!
  30. ⊂_ヽ   \\ Λ_Λ    \( ˇωˇ)    / ⌒   / へ\

      /  / \\ ƀɹϊɹɹ ヽ_つ   / /  ( (ヽ  | |、 \  | ⼃丿 \  | |  ) / ノ )  Lů Older solutions have merit
  31. –Lots of people, for hundreds of years “Those who don’t

    study history are doomed to repeat it.”
  32. Wrong

  33. –Me, just now “Those who don’t study the past can’t

    make informed decisions about the present.”
  34. History of Async Programming

  35. performSelector: Family • iOS 2+ • Easy(ish) • Supports delays

    • Cancellable(ish) • Threadsafe(ish)
  36. NSThread • iOS 2+ • Difficult, mostly • Sometimes, kind

    of cancellable • Complicated
  37. NSOperation • iOS 2+ • Supports concurrency • Supports dependency

    graphs • Cancellable • More boilerplate
  38. Blocks / GCD • iOS 4+ • Super-easy • Super-dangerous

    (reference cycles) • Better in Swift • Not cancellable
  39. NSOperation + Blocks • iOS 4+ • Everything from NSOperation,

    but also with blocks • Less boilerplate • Slightly more verbose than blocks (this is Objective-C, remember) • Not popular – why?
  40. NSProgress • iOS 7+ • Confusing • No one knows

    what it’s for • I don’t know • Do you know?
  41. NSURLSessionTask • iOS 7+ • Network-specific async abstraction • Very

    nice • Seriously, very nice • (Will discuss more later)
  42. Let’s build something Those are only tools

  43. Abstraction Blocks Function pointers NSOperation ???

  44. Example Abstractions • Adding block callbacks to UIGestureRecognizer, UIAlertView, etc

    • Futures, promises • Sequences, signals (FRP)
  45. Those are great abstractions, but… I feel we ignore NSOperation

  46. NSOperation • Cancellable • Chainable, dependency graphs • Concurrency support

    • Completion handlers • Prioritization • Interoperate with GCD
  47. Why so GCDerious?

  48. Why GCD? • iOS devs favour GCD over other suitable

    abstractions • Why? • NSOperation is unfamiliar, feels unnecessary • Not-invented-here-syndrome • Apple is good at marketing
  49. None
  50. Different solutions work for different problems

  51. Get familiar with your options

  52. Don’t be mean to developers who disagree with you

  53. There are benefits to older solutions (╯°□°)╯︵ ┻━┻

  54. Developers (like me ) tend to say Objective-C is “old

    and busted”
  55. Old, yes, but not busted

  56. Older Technology • “Old” is stable • “Old” is usually

    well-documented • “Old” is easy to hire for • “Old” has a lot of helpful resources, libraries, tutorials, etc
  57. AFNetworking uses NSOperation

  58. Let’s look at another example

  59. NSURLSession • Very protocol-oriented • NSURLSessionDelegate • NSURLSessionTaskDelegate • NSURLSessionDataDelegate

    • NSURLSessionDownloadDelegate
  60. NSURLSession • Separate delegates isolate different areas of concern •

    One object may conform to all protocols • Many, small protocols are better than one massive one • Swift protocols don’t even support optional functions!
  61. NSURLSession • Could have been completely blocks-based… • Instead, based

    on ideas behind NSOperation • NSURLSession probably wraps an NSOperation, anyway • This is good! No leaky abstractions
  62. Try to be more like NSURLSession

  63. Go read NSOperation.h

  64. Wrap Up • Decisions are made in an unknowable context

    • Developers are bad at evaluating things • New and shiny things aren’t always better • Old solutions carry extrinsic benefits
  65. So what’s the best way to do asynchronous programming on

    iOS?
  66. It depends. ¯\_(ツ)_/¯