Swift3은 명확하고 정교한 Swift 코드를 위해 고유의 특징을 만들어 담은 새 API 설계 가이드라인을 소개한다. 이 이야기는 Swift API 가이드라인 너머에 있는 철학을 탐구하고 Swift 표준 라이브러리, Cocoa, Cocoa Touch API를 통한 그 응용프로그림을 탐험할 것이다. 어떻게 이 API 변형이 여러분 Swift 코드에 영향을 줄 수 있는지 확인해보고, 어떻게 Swift3으로 부드럽게 변형할 수 있는지 배워보자. Swift3이 어떻게 Objective-C API를 불러오는지, 어떻게 기존의 Objective-C 라이브러리를 Swift 인터페이스로 만드는지 배워보자.

"ed/ing" 규칙

가변(Mutating)

x.sort()
x.append(y)

불변(Nonmutating)

z = x.sorted() 
z = x.appending(y)

필요없는 단어는 생략하기

- (void)addObject:(ObjectType)anObject; 
- (void)removeObject:(ObjectType)anObject;

Swift 코드가 너무 생략되버릴 수 있는데, 작은 단어 갯수로 코드를 최소화시키는 것이 그 목표는 아니다. 너무 짧은 Swift 코드가 있는 곳에는 강타입 시스템의 부작용이다...

func add(_ anObject: AnyObject) 
func remove(_ anObject: AnyObject)

x.insert(y, at: z) // “x, insert y at z” 
x.subViews(havingColor: y) // “x's subviews having color y” 
x.capitalizingNouns() // “x, capitalizing nouns”

x.insert(y, position: z) 
x.subViews(color: y)
x.nounCapitalize()

JSON Models

중요 note : 우리 예제는 Xcode8.0 베타2에서 만들어졌고, 아마 항상 모든 버전에서 잘 동작하지는 않을지도 모른다. 만약 여전히 엘케피탄에서 작업하고 있다면 Xcode8.0 beta Release Notes에 들어가서 IDE와 Source Editor Extension에 관한 Xcode8.0 beta 이슈를 보아라. 또한 당신의 extension을 실행시킬때 약간의 딜레이가 있다. 만약 프로젝트가 너무 빨리 열린다면 extension이 불러와지기 전에 켜진것이며, 테스트 Xcode의 인스턴스 메뉴에서 사용할 수 없을 것이다.

요약

선언 스타일(Declarative style)

빠른 반복

• 실시간 리로딩(Live reloading)은 당신이 그 파일에 수정하고 저장할 때마다 앱을 리로드할 것이다. 기본적으로 시뮬레이터로 전환하는 것을 막고 ⌘ + R을 누르지 않아도 된다.
• 핫 리로딩(Hot reloading)은 앱 전체를 리로드하지 않고 당신이 수정한 부분만 리로드한다. 당신이 네비게이션 스택 깊숙히 테이블 뷰 셀의 UI를 작업하고 있었다면, 그 바뀐점을 보기위해 시작화면에서 셀까지 찾아가지 않아도 된다. 그리고 컴포넌트는 이미 그 안에 있던 상태로 그대로 있을 것이다. 이것은 WYSIWYG 프로그래밍 경험(WYSIWYG programming experience)이다. 앱을 위해 Xcode가 결코 제공하지 않았던 호화로운 기능이다.

크로스 플랫폼

"훌륭한 앱이군요! 안드로이드에서도 동작하나요? [...]오, 안드로이드 버전은 언제 배포할 계획이시죠?[...], 오."

불확실한 로드맵

여기서 다음년도로!

우리는 곧 계획을 발표할 것이다-Konstantin

명백히 위압하는(Patently daunting)

The license granted hereunder will terminate, automatically and without notice, if you (or any of your subsidiaries, corporate affiliates or agents) initiate directly or indirectly, or take a direct financial interest in, any Patent Assertion: (i) against Facebook or any of its subsidiaries or corporate affiliates, (ii) against any party if such Patent Assertion arises in whole or in part from any software, technology, product or service of Facebook or any of its subsidiaries or corporate affiliates, or (iii) against any party relating to the Software.

명백히 침묵하는(Patently silent)

자바스크립트

• 기술적으로 불완전함
• 언세이프
• 늦은 발전

자바스크립트의 결점

안전은 사고가 없는 것이다(Safety is no accident)

• 자바스크립트에서의 "class", "type", "instance" 개념은 주요 프로그래밍 세계에서의 개념과 완전히 다르다.
• 자바스크립트에서는 타입을 너무 신뢰할 수 없게 정의해서, 이것들이 유용한 용도를 제공하지 못한다.

당신의 예상하지 못한 예외 처리를 다루기 위해서는 마지막 라인의 방어로 예외를 남겨놓는게 최고이다. 그리고 예상되는 에러를 컨트롤 플로우 문으로 관리하기에도 최고이다.

• 열거형이 없다. 연관타입을 가진 열거형은 말할것도 없다. 신뢰성 높은 상태 표현에 행운을 빌 수 있을까.
• guard문이 없다.
• 제네릭이 없다.
• 컨트롤 플로우문의 표현력을 늘리기위한 where이 없다.

• suggest는 주어진 파일에대해 타입 주석 제안을 보여준다(suggest Shows type annotation suggestions for given files)
• type-at-pos는 주어진 파일과 위치에 타입을 보여준다(type-at-pos Shows the type at a given file and position)
• get-def는 변수나 프로퍼티의 선언 위치를 받는다(get-def Gets the definition location of a variable or property)

내가 여기 처음 왔을때, 여기는 전부 늪이였어. 여기 늪에 성을 세울거라는 말에 모두가 나를 얼간이라 했지만, 똑같이 만들어서 그냥 보여주었지. 그것이 늪으로 가라앉았고, 나는 두번째 것을 지었어. 그것도 늪으로 가라앉았고 세번째것을 또 지었어. 그것은 불에타고 쓰러져서 늪에 가라앉았어. 그러나 네번째는 버티고 있어. 그리고 이게 너가 얻어야 할 것이고, 영국에서 가장 강한 성을 얻어냈지.

자바스크립트 생태계: 속박과 굴레

• 수많은 구식 버전의 브라우저 사용자들
• 각색의 브라우저 벤더 집합
• 수십억의 사이트와 그 사이트의 각 개발자들

Emacs의 주요 수업에선 확장을 위한 언어는 단지 "확장 언어"가 될 수 없다고 한다. 실제 프로그래밍언어가 되야하고, 상당한 양의 프로그램을 짤 수 있어야하며, 그것을 유지보수할 수 있게 설계되야한다. 왜냐하면 사람들이 그것을 바라니까! [...] Tcl은 진지한 프로그래밍 언어로 설계되지 않았다. 이것은 "스크립트 언어"가 되기위해 설계되었으며, "스크립트 언어"라 가정하는 것은 실제 프로그래밍 언어가 되려고 할 필요가 없었음을 의미한다. 따라서 Tcl은 하나의 능력을 빼먹었는데, 배열이 부족하다; 링크드리스트를 만들 수 있는 구조체를 빼먹었다. 그것은 가짜로 넘버를 가지고 있는데, 매우 느리지만 동작은 한다. Tcl은 작은 프로그램을 만드는데 적합하나, 그 넘어를 하기엔 적합하지 않을 것이다.

언어 설계자로서 이 언어가 왜 선천적으로 더 낫고 더 나쁜지 우열을 가리는 토론을 사랑한다. 그러나 이런 건방진 주장에는 많은 문제가 있다. 궁극적으로 모든 언어의 이슈는 그 사용자가 원하는 것을 투표할 때 합의가 생긴다. 만약 Tcl이 그들이 사용하는 것보다 더 생산적이게 만들었다면(혹은 이미 그렇게 되었다), 다른 언어 사용자들이 이것이 더 낫다고 하면서 온다면, 그때 사람들은 언어를 바꾼다. 이것이 법칙이고 이게 맞다.

• 피할 수 있는 에러를 만드는 당신을 막는 안전장치의 부족
• 많은 목적에 맞지 않는 작은 표준 라이브러리
• 당신의 의도를 명확하게 표현하지 않는 문법과 의미론(syntax and sementics)
• 더딘 발전
• 위의 모든 것들(자바스크립트)

더 나은 제안들

• 더 종합적인 API
• 더 성숙한 IDE
• 더 나은 문서
• 명확하고 친숙한 라이센싱
• 동등한 퍼포먼스(더 낮진 않더라도)

결론

• 이식성 - 한가지 이상의 플랫폼을 타겟으로 한다.
• 생산성 - 성숙한 IDE와 다른 개발 툴, 문서, 그리고 표현력 있는 그 개발 언어
• 안전 - 당신이 만들 수 있는 실수를 그 플랫폼이 얼마나 막을 수 있는지의 정도
• 지속성(longevity) - 당신의 앱이 살아있는 동안 플랫폼이 얼마나 오래 가는지

감사

바뀐 이력

커멘트

참조

기억할것: Swift는 여전히 ABI-안정성이 지원되지 않음!

2.3으로 가야할까 3.0으로 가야할까?

그렇다. 두가지 다이다.

1. 의존성은 중요하다. 여러분의 의존성이 Swift2.3이나 Swift3.0을 지원하는지 확인해야한다. 대부분 주요 라이브러리/프레임워크들은 둘 다 지원하고 있다(Alamofire, Charts). 그러나 기억해야할 것은 Swift3.0을 업그레이드 하는 방법은 하나밖에 없다. Swift3.0으로 새 개발을 시작하고 나면 2.3버전의 모든 의존성이 업데이트 없이는 작동하지 않을 것이다.
2. 8.x 버전의 Xcode는 Swift2.3 지원을 멈출 것이다. Swift2.3은 Swift3.0으로 업그레이드 하기 힘든 프로젝트를 위한 매개 단계의 경향이 있다.
3. 만약 여러 프로젝트에 걸쳐진 개인의 CocoaPods이 있다면 먼저 이것부터 업그레이드 해야한다.

Swift2.2에서 2.3으로 마이그레이션 이슈

Swift2.x에서 Swift3.0으로의 마이그레이션 이슈

Swift2.3

Swift3.0

(인지할만한)주요 변화들

1. 외부모듈이 클래스나 맴버를 사용할 수 있다.
2. 외부모듈이 클래스나 맴버를 오버라이드 할 수 있다.

// Before
let red = UIColor.redColor().CGColor
// After
let red = UIColor.red.cgColor

이제부터 id는 'AnyObject'가 아닌 'Any'로 불러오기 때문에, 이전에 여러분이 'AnyObject'로 동적인 검색을 수행하는 곳에서 애러가 뜰 수도 있다.

(인식하지 못할지도 모르는)작은 변화들

1. toNearestOrAwayFromZero
2. toNearestOrEven
3. towardZero
4. awayFromZero

굳이 걱정하지 않을 정도로 작은 것

이 모든 변화가 Swift3에서 일나날까?

1. Sequence-기반 생성자를 추가하고 Dictionary에 메소드를 합친다.
2. 약 참조(weak reference)에서 강 참조(strong reference)로 self를 업그레이드하여 옵셔널 바인딩을 사용할 수 있게 해준다.
3. 표준 라이브러리에 AnyHashable을 추가한다.

1. 순환 알고리즘
2. .self 제거
3. 커스텀 Objective-C 표현을 제공하는 것을 Swift 타입에서 허용
4. 동적 케스터로부터 연결 변환 동작을 제거
5. Sequence end-operation 이름을 합리화

보너스

1. Swift 언어에서 where문 제거
2. 인스턴스 맴버를 접근하기 위해 self가 필요함
3. extension에서 접근 변경자 제거

"리액티브 프로그래밍이 뭔가?"

--a---b-c---d---X---|->

a, b, c, d are emitted values
X is an error
| is the 'completed' signal
---> is the timeline

  clickStream: ---c----c--c----c------c-->
               vvvvv map(c becomes 1) vvvv
               ---1----1--1----1------1-->
               vvvvvvvvv scan(+) vvvvvvvvv
counterStream: ---1----2--3----4------5-->

"왜 RP 적용시키기를 고려해야할까?"

예제와함께 RP처럼 생각하기

"Who to follow" 제안 박스 구현하기

• 시작하면 API로부터 계정 데이터를 불러오고 3가지 제안을 띄운다.
• "Refresh"를 클릭하면 3개의 또다른 계정을 띄운다.
• 계정중에 'x' 버튼을 누르면 그 계정은 사라지고 다른 계정을 띄운다.
• 각 줄은 계정의 아바타를 띄우고, 누르면 그들 페이지로 이동한다.

요청과 응답

--a------|->

Where a is the string 'https://api.github.com/users'

var requestStream = Rx.Observable.just('https://api.github.com/users');

requestStream.subscribe(function(requestUrl) {
  // execute the request
  jQuery.getJSON(requestUrl, function(responseData) {
    // ...
  });
}

requestStream.subscribe(function(requestUrl) {
  // execute the request
  var responseStream = Rx.Observable.create(function (observer) {
    jQuery.getJSON(requestUrl)
    .done(function(response) { observer.onNext(response); })
    .fail(function(jqXHR, status, error) { observer.onError(error); })
    .always(function() { observer.onCompleted(); });
  });

  responseStream.subscribe(function(response) {
    // do something with the response
  });
}

var responseMetastream = requestStream
  .map(function(requestUrl) {
    return Rx.Observable.fromPromise(jQuery.getJSON(requestUrl));
  });

var responseStream = requestStream
  .flatMap(function(requestUrl) {
    return Rx.Observable.fromPromise(jQuery.getJSON(requestUrl));
  });

requestStream:  --a-----b--c------------|->
responseStream: -----A--------B-----C---|->

(lowercase is a request, uppercase is its response)

responseStream.subscribe(function(response) {
  // render `response` to the DOM however you wish
});

var requestStream = Rx.Observable.just('https://api.github.com/users');

var responseStream = requestStream
  .flatMap(function(requestUrl) {
    return Rx.Observable.fromPromise(jQuery.getJSON(requestUrl));
  });

responseStream.subscribe(function(response) {
  // render `response` to the DOM however you wish
});

새로고침 버튼

var refreshButton = document.querySelector('.refresh');
var refreshClickStream = Rx.Observable.fromEvent(refreshButton, 'click');

var requestStream = refreshClickStream
  .map(function() {
    var randomOffset = Math.floor(Math.random()*500);
    return 'https://api.github.com/users?since=' + randomOffset;
  });

var requestOnRefreshStream = refreshClickStream
  .map(function() {
    var randomOffset = Math.floor(Math.random()*500);
    return 'https://api.github.com/users?since=' + randomOffset;
  });

var startupRequestStream = Rx.Observable.just('https://api.github.com/users');

stream A: ---a--------e-----o----->
stream B: -----B---C-----D-------->
          vvvvvvvvv merge vvvvvvvvv
          ---a-B---C--e--D--o----->

var requestOnRefreshStream = refreshClickStream
  .map(function() {
    var randomOffset = Math.floor(Math.random()*500);
    return 'https://api.github.com/users?since=' + randomOffset;
  });

var startupRequestStream = Rx.Observable.just('https://api.github.com/users');

var requestStream = Rx.Observable.merge(
  requestOnRefreshStream, startupRequestStream
);

var requestStream = refreshClickStream
  .map(function() {
    var randomOffset = Math.floor(Math.random()*500);
    return 'https://api.github.com/users?since=' + randomOffset;
  })
  .merge(Rx.Observable.just('https://api.github.com/users'));

var requestStream = refreshClickStream
  .map(function() {
    var randomOffset = Math.floor(Math.random()*500);
    return 'https://api.github.com/users?since=' + randomOffset;
  })
  .startWith('https://api.github.com/users');

var requestStream = refreshClickStream.startWith('startup click')
  .map(function() {
    var randomOffset = Math.floor(Math.random()*500);
    return 'https://api.github.com/users?since=' + randomOffset;
  });

스트림으로 3가지 제안을 모델링하기

refreshClickStream.subscribe(function() {
  // clear the 3 suggestion DOM elements 
});

var suggestion1Stream = responseStream
  .map(function(listUsers) {
    // get one random user from the list
    return listUsers[Math.floor(Math.random()*listUsers.length)];
  });

suggestion1Stream.subscribe(function(suggestion) {
  // render the 1st suggestion to the DOM
});

var suggestion1Stream = responseStream
  .map(function(listUsers) {
    // get one random user from the list
    return listUsers[Math.floor(Math.random()*listUsers.length)];
  })
  .merge(
    refreshClickStream.map(function(){ return null; })
  );

suggestion1Stream.subscribe(function(suggestion) {
  if (suggestion === null) {
    // hide the first suggestion DOM element
  }
  else {
    // show the first suggestion DOM element
    // and render the data
  }
});

refreshClickStream: ----------o--------o---->
     requestStream: -r--------r--------r---->
    responseStream: ----R---------R------R-->   
 suggestion1Stream: ----s-----N---s----N-s-->
 suggestion2Stream: ----q-----N---q----N-q-->
 suggestion3Stream: ----t-----N---t----N-t-->

var suggestion1Stream = responseStream
  .map(function(listUsers) {
    // get one random user from the list
    return listUsers[Math.floor(Math.random()*listUsers.length)];
  })
  .merge(
    refreshClickStream.map(function(){ return null; })
  )
  .startWith(null);

refreshClickStream: ----------o---------o---->
     requestStream: -r--------r---------r---->
    responseStream: ----R----------R------R-->   
 suggestion1Stream: -N--s-----N----s----N-s-->
 suggestion2Stream: -N--q-----N----q----N-q-->
 suggestion3Stream: -N--t-----N----t----N-t-->

제안을 닫고 캐싱된 응답을 사용하기

var close1Button = document.querySelector('.close1');
var close1ClickStream = Rx.Observable.fromEvent(close1Button, 'click');
// and the same for close2Button and close3Button

var requestStream = refreshClickStream.startWith('startup click')
  .merge(close1ClickStream) // we added this
  .map(function() {
    var randomOffset = Math.floor(Math.random()*500);
    return 'https://api.github.com/users?since=' + randomOffset;
  });

    requestStream: --r--------------->
   responseStream: ------R----------->
close1ClickStream: ------------c----->
suggestion1Stream: ------s-----s----->

stream A: --a-----------e--------i-------->
stream B: -----b----c--------d-------q---->
          vvvvvvvv combineLatest(f) vvvvvvv
          ----AB---AC--EC---ED--ID--IQ---->

where f is the uppercase function

var suggestion1Stream = close1ClickStream
  .combineLatest(responseStream,             
    function(click, listUsers) {
      return listUsers[Math.floor(Math.random()*listUsers.length)];
    }
  )
  .merge(
    refreshClickStream.map(function(){ return null; })
  )
  .startWith(null);

var suggestion1Stream = close1ClickStream.startWith('startup click') // we added this
  .combineLatest(responseStream,             
    function(click, listUsers) {l
      return listUsers[Math.floor(Math.random()*listUsers.length)];
    }
  )
  .merge(
    refreshClickStream.map(function(){ return null; })
  )
  .startWith(null);

합쳐보기

var refreshButton = document.querySelector('.refresh');
var refreshClickStream = Rx.Observable.fromEvent(refreshButton, 'click');

var closeButton1 = document.querySelector('.close1');
var close1ClickStream = Rx.Observable.fromEvent(closeButton1, 'click');
// and the same logic for close2 and close3

var requestStream = refreshClickStream.startWith('startup click')
  .map(function() {
    var randomOffset = Math.floor(Math.random()*500);
    return 'https://api.github.com/users?since=' + randomOffset;
  });

var responseStream = requestStream
  .flatMap(function (requestUrl) {
    return Rx.Observable.fromPromise($.ajax({url: requestUrl}));
  });

var suggestion1Stream = close1ClickStream.startWith('startup click')
  .combineLatest(responseStream,             
    function(click, listUsers) {
      return listUsers[Math.floor(Math.random()*listUsers.length)];
    }
  )
  .merge(
    refreshClickStream.map(function(){ return null; })
  )
  .startWith(null);
// and the same logic for suggestion2Stream and suggestion3Stream

suggestion1Stream.subscribe(function(suggestion) {
  if (suggestion === null) {
    // hide the first suggestion DOM element
  }
  else {
    // show the first suggestion DOM element
    // and render the data
  }
});

다음으로 해야할 것은 무엇인가

이렇게 하려면 무엇이 필요한가?

그냥 해보자!

브라우저

가상머신(Virtual Machine-VM)

V8 VM

V8 템플릿

V8 컴파일 && 자바스크립트 실행

C++ -> V8템플릿 -> 자바스크립트를 실행 -> ?

C++ 모듈로더

자바스크립트 모듈로더

NodeJS 런타임 라이브러리?

이벤트 루프

Thanks!

터치 핸들링

Hit Testing

Responder Chain

제스처

요약

관련 링크

• (번역) Hit-Testing in iOS 

새로운 버전의 Buffer 앱의 새로운 변화

목표 : 부드러운 스크롤링을 위해 초당 60프레임을 지원

전략: 페이스북의 AsyncDisplayKit을 사용하기

다음으로 할것 + 여러분의 생각

이론

• 바이너리를 난독화 시킨다
• 바이너리 크기가 작아진다

• 따로 분리된 dSYM 파일은 각 빌드마다 생성되기 때문에 긴 빌드시간이 걸린다.

문제점

0   YourApp                         0x00000001001e1594 0x100058000 + 1611156
1   YourApp                         0x00000001000ed74c 0x100058000 + 612172
2   UIKit                           0x000000018f2b67b0 -[UIApplication sendAction:to:from:forEvent:] + 96
3   UIKit                           0x000000018f42a5ec -[UIBarButtonItem(UIInternal) _sendAction:withEvent:] + 168

symbolicatecrash YourApp\ \ 17-10-16\ 23-15.crash YourApp.app/YourApp > symbolicated.crash

• Cocoa SDK 메소드들이 결국 바뀌었다.
• Bitcode를 활성화하면 그 서버에서 애플이 앱을 다시 컴파일한다.

비결

• 시뮬레이터 빌드 속도가 더 빨라진다(우리는 거의 항상 연결되있는 디버거를 쓰므로 이제 크레쉬 리포트는 필요하지 않다)
• 기기 빌드에대해 모든 크레쉬 리포트(디버거 외부에서 동작할 확율이 높은)

요약

크레쉬 조사하기

공유된 앱 컨테이너

어떻게 크레쉬를 낼까

• 몇백개의 데이터베이스 쿼리에 applicationDidEnterBackground 메소드를 설정한다.
• 내 맥에서 콘솔앱을 열고 Castro를 언급한 메시지로 걸러낸다.
• Xcode를 통해 앱을 설치하되 앱 아이콘을 눌러 앱을 실행한다.
• 앱을 백그라운드로 보내기위해 홈버튼을 누르고 바로 포켓몬고를 열어 메모리 압박으로 인한 Castro의 정지를 기대한다.

백그라운드 패치를 해냄

• 앱이 정지해있을때 앱을 죽이면 데이터 쓰기가 이루어질 수 없고 데이터를 오염시킨다.
• 파일이 두 앱 간에 공유되고 두번째 앱/extension이 실행되면, 두번째 앱은 강제로 락을 풀고 일관된 상태에 파일을 복구하려 할 것이다. 첫번째 앱은 일관되지 않은 상태를 빠져나오거나, 공유된 파일을 완전히 무시한다.

결론

• 애플은 다른 서비스들이 발견하지 못한 크레쉬를 보고해준다. 아이튠즈 커넥트나 Xcode, 외부 서비스들까지도 크레쉬 리포트를 확인해보자.
• 파일 락의 정책은 당신의 데이터베이스가 공유된 공간에 있을 때 더욱 엄격해진다.
• 백그라운드 패치 완료 블락에 의존하는 것으로는 충분하지 않다. 활성 백그라운드 작업없이는 백그라운드에서 어떤 작업도 하지마라.
• 앱 라이프 사이클의 특정 부분에서만 나타나는 이슈는 디버깅하기 힘들다. 아직 재현해보지 못했다면 새 시에라의 Console.app을 배워서 사용해보아라.
• 기술 지원 사건들(Technical Support Incidents)을 기억하며, 이것도 우리가 매년 지불하는 개발자 맴버쉽에 포함된다(원문: Don’t forget about Technical Support Incidents, you get 2 included in your developer account payment every year).

• 사용자가 다운로드를 시작하고 앱을 멈춘다.
• 몇 초뒤(내 경험으로는 10-30초이다) 앱은 꺼진다.
• 다운로드는 다른 프로세스에서 계속 진행된다.
• 다운로드가 끝나면, 앱은 다시 켜지고 당신의 앱 델리게이트가 다운받기 시작할때 사용한 id와 함께 application(handleEventsForBackgroundSessionWithIdentifier:)에서 받는다.

다른 에러로 나타날 수도 있다. 실제로 내 로컬 서버가 동작하지 않을때 커넥션 에러가 나는데, 다운로드는 계속 진행되는것 같지만 계속해서 0%를 가리켰다. 로컬 서버를 켜니 마치 아무 문제 없던것처럼 다운로드를 시작했다.

실패 처리하기

일시정지와 재개

셀룰러 다루기

백그라운드 다운로드

그들이 말하는 그냥 오프라인 다운로드 추가하기

프로세스를 생각해보자

• 백엔드 url에관한 정보는 코드 어디에 놔둘까?
• url 끝부분은 어느 코드에서 알아야할까?
• 요청을 어떻게 만드는지는 코드 어디에서 알아야 할까?
• 요청을 보내기 위해 준비해야하는 파라미터는 코드 어디에 둘까?
• 인증(authentication) 토큰은 어디에 저장해 둘까?
• 어떻게 요청(request)을 실행할까?
• 언제 그리고 어디서 요청을 실행할까?
• 요청 취소에 대해서도 고려해야할까?
• 잘못된 백엔드 응답이나 백엔드 버그도 고려해야할까?
• 써드파티 라이브러리를 사용해야하나? 어떤것을 사용할까?
• 코어데이터도 처리해야할 것이 있나?
• 이 솔루션을 어떻게 테스트해볼까?

백엔드 url을 저장하기

끝부분(Endpoints)

요청을 실행하기

• NetworkService — 내부적으로 NSURLSession과 구성되어 HTTP 요청을 실행할 수 있게 한다. 모든 네트워크 서비스는 한번에 하나만 요청할 수 있고, 요청을 취소할 수도 있으며(큰 장점이다), 성공하거나 실패한 응답을 위한 콜백을 가지고 있는다.
• BackendService — (좋은 이름은 아니지만 꽤 잘 들어 맞는다)백엔드와 관련있는 요청(위에서 설명한 *Request 객체)을 받는 클래스이다. NetworkService를 사용한다. 내가 현재 사용하는 버전에서는 응답 데이터를 NSJSONSerializer를 이용하여 json으로 만든다.

요청을 큐하기

• 모든 네트워크 오퍼레이션을 간편하게 취소할 수 있다.
• 이미지를 다운받거나 열악한 네트워크 환경에서 많은 데이터를 소모해야하지만 앱 동작에는 크게 상관없는 다른 오퍼레이션들을 취소할 수 있다.
• 큐를 필요한 순서대로 실행할 수 있고 빨리 답변 올 수 있는 것부터 실행할 수 있다.

코어데이터와 함께 작업하기

• 오퍼레이션에서 어떤 코어데이터인지 알고 잇어야했다. 왜냐하면 프레임워크를 분리하기 위해 떼어놓은 모델을 가지고 있고 네티워크 레이어 역시 프레임워크로부터 분리되 있었다. 네트워크 프레임워크는 모델 프레임워크에대해 알고 있어야 했다.
• 각 오퍼레이션은 어떤 컨텍스트에서 동작하는지 알아야 했으므로 NSManagedObjectContext 파라미터를 받아야 했다.
• 응답을 받고 성공(success) 블럭을 호출할 때마다 먼저 컨텍스트에 객체를 찾으려 하거나 디스크에 객체를 패치하기위해 디스크 검색을 해야만 했다. 내 생각엔 이 점이 매우 큰 단점이었고, 아마 당신도 항상 코어데이터 객체를 생성하고 싶지는 않았을 것이다.

• 이렇게 파싱하고 오브젝트를 생성하면 디스크에 접근하지 않으므로 빠르다.
• 오퍼레이션에 NSManagedObjectContext를 전달할 필요가 없다.
• 성공 블럭에서 파싱된 아이템으로 코어데이터 객체를 갱신할 수도 있고, 오퍼레이션을 생성하는 곳 어디에든 있을 수 있는 코어데이터 객체를 참조할 수 있다. — 오퍼레이션이 큐에 추가될 때의 내 경우이다.

응답을 맵핑하기

• Invalid — 파싱된 json이 nil이고, nil을 반환하면 안될때나, json이 하나의 객체가 아니라 객체의 배열일때 던지는 에러타입이다.
• MissingAttribute — 이름이 의미하는 바와 같다. json에서 키를 잃어버리거나 파싱 후에 값이 nil이면 안되는데 nil일때 던지는 에러타입이다.

예제 프로젝트

요약

• 가장 큰 이점은 비슷한 설계의 다른 새 오퍼레이션을 쉽게 추가할 수 있고, 이 레이어가 코어데이터에대해 전혀 모른다는 점이다.
• 큰 노력없이 코드 커버리지를 거의 100%에 근접하도록 만들 수 있다. 완전 어려운 케이스를 어떻게 커버할지 생각할 필요도 없다. 어디에도 케이스가 없기 때문이다(원문: because there is no such cases at all).
• 이 네트워크 레이어의 핵심은 비슷한 복잡성을 가진 다른 앱에서도 다시 사용할 수 있다는 점이다.

왜 불변 모델인가?

모델 갱신하기

• (보통 JSON 응답으로부터) 딕셔너리를 사용하여 모델을 초기화한다.
  
• "builder" 오브젝트를 사용하는데, 이것은 그냥 모든 프로퍼티를 받아다가 필요한것만 변경하는 방식이다. 기존에 만들어놓은 모델로부터 빌더를 만든 뒤, 우리가 필요한 프로퍼티만 변경하고, initwithBuilder를 호출하여 새로운 모델을 받는다. (이것에 대해서는 나중에 새 포스팅에서 설명하겠다)
  

 API 데이터를 불러오고 캐싱하기

데이터 일관성

변화를 관찰하기

변화들을 보내기

Model View Controller(MVC)

Model View Presenter(MVP)

• 사용자는 View에서 상호작용한다.
• View와 Presenter는 one-to-one 관계를 가진다. 이 의미는 하나의 View는 하나의 Presenter에 맵핑된다.
• View는 Presenter에 참조하고 있지만, Model에는 참조하지 않는다.
• View와 Presenter 사이에 두 방향으로 소통할 수 있다.

Model View ViewModel(MVVM)

• 사용자는 View에서 상호작용한다.
• View와 ViewModel은 many-to-one 관계를 가진다. 그 의미는 여러 View는 하나의 ViewModel에 맴핑될 수 있다.
• View는 ViewModel에 참조되지만 ViewModel은 View에대해 모른다.
• View와 ViewModel의 사이에 두방향 데이터 바인딩을 제공한다.

안드로이드 구현

• Activity / 앱 플로우의 독립적인 기능을 재사용할 수 있다.
• Activity 수를 줄인다.(앱 용량을 덜 잡아 먹는다)
• Controller와 의존적인 부분을 줄인다.

• Controller를 가볍게 만들어라, View와 Model을 연결해주는 역할만 하면 된다.(단일 책임 원칙)
• 이벤트를 다른 Controller에게 넘겨주어라(i.e. analytics)
• 안드로이드 클래스로부터 분리해라 ― 재사용을 위해

관련된 좋은 습관들

• Controller는 추상화에 의존한다(interface)
• 시스템 구성과 의존성을 컨트롤하기위해 코드 중심에 위치시킨다.
• 차후에 의존성 주입(dependency injection)을 옮길 수 있게 한다.

• 우리는 여러 기록장치를 사용하기 때문에 파사드를 이용해 이 API들을 한데 모아둘 필요가 있다.
• A/B 테스트나 다른 임시적인 기능들은 추상화돼있어야하고, 분리된 Controller나 파사드를 통해 접근가능해야한다.

이것들은 어떻게 생겼을까?

• Square mortar: Activity 라이프 사이클의 행동으로부터 분리시켜, View를 가볍게 만들고 View를 Controller와 한 쌍으로 만들어주는 간편한 라이브러리
• inloop AndroidViewModel: 엄청난 양의 코드 없이 Fragment나 Activity로부터 데이터와 상태를 분리시켜준다. 벙어리(dumb) View가 되는걸 줄인다.
• sockeqwe mosby: 현대 안드로이드 앱을 위한 Model-View-Presenter 라이브러리.