👆🏻 여기 햄버거를 눌러 목차를 확인하세요
- 네트워크 통신을 하기 위해 URLSession의
dataTask(with:completionHandler:)메서드를 사용했다. 하지만 서버가 아직 만들어지지 않았거나 당장 인터넷 통신이 불가한 경우 등을 대비해 실제 메서드 대신 mock 객체의 메서드를 활용해 데이터를 받아오는 방법을 구현했다.- URLSession을 mocking한 MockURLSesssion 타입을 구현했다.
- 두 타입을 추상화한 URLSessionProtocol을 구현하고 requirement로 URLSession의 메서드인
dataTask(with:completionHandler:)선언했다.
- 네트워크 통신을 하는 타입은 URLSession과 MockURLSession을 추상화한 타입을 가지고 있어야 하며 이는 둘 중 어느 것이든 될 수 있기 때문에 인스턴스를 외부에서 주입하는 방식으로 구현했다.
struct NetworkManager {
let session: URLSessionProtocol
init(session: URLSessionProtocol) {
self.session = session
}
}- 그리고 실사용은 주입받은 객체가 무엇인지 관계없이 그대로
dataTask(with:completionHandler:)메서드를 사용한다
let task: URLSessionDataTaskProtocol = session
.dataTask(with: request) { data, urlResponse, error in
//...
}
task.resume()- 이를 위해 Mock 객체는 실제 객체와 유사하게 작동해야 하며 실제 데이터와 흡사한 가짜 데이터를 전달해줘야 했다. 로컬에 Items와 Item, 두 가지 데이터가 있었고 파일 이름을 각 데이터의 url로 지정했다. 그리고 각 데이터의 url을 넘겨주면 해당하는 데이터를 반환, 다른 url을 넘겨주면 통신에 실패하도록 구현했다.
- 해당 메서드는 URLSessionDataTask 를 반환하는데 Mock 객체에서는 URLSessionDataTask를 상속받는 MockURLSessionDataTask를 반환하도록 했다.
- URLSessionDataTask 의
resume()를 override하기 위함이다. - 하지만 URLSessionDataTask를 초기화하는 init()은 deprecated되었다는 경고 메시지가 떠서 그대로 상속을 받기에 부적절하게 생각되었다.
- 따라서 이 둘을 추상화하는 URLSessionDataTaskProtocol을 구현했다.
- 다만 이 경우
dataTask(with:completionHandler:)메서드는 더이상 URLSessionDataTask가 아닌 이를 추상화한 URLSessionDataTaskProtocol 타입을 반환해야 한다. - 다음 로직을 추가해 리턴 타입을 수정했다.
protocol URLSessionProtocol { func dataTaskWithRequest(with request: URLRequest, completionHandler: @escaping (Data?, URLResponse?, Error?) -> Void) -> URLSessionDataTaskProtocol } extension URLSession: URLSessionProtocol { func dataTaskWithRequest(with request: URLRequest, completionHandler: @escaping (Data?, URLResponse?, Error?) -> Void) -> URLSessionDataTaskProtocol { dataTask(with: request, completionHandler: completionHandler) as URLSessionDataTaskProtocol } }
- URLSessionDataTask 의
- Unit Test를 할 함수는 리턴타입을 Result타입으로 구현했다.
- 리턴할 때는 switch문을 사용해 성공과 실패 시 값을 따로 반환했다.
case .success(let decodedData): completion(.success(decodedData)) case .failure(let error): completion(.failure(error)) }
- 대신 리턴값을 사용하거나 테스트할 때에도 성공과 실패를 구분해서 값을 벗겨야 했다.
case .success(let data): outcome = data.title case .failture(let error): print(error) case .none: print("none") }
- XCTTestExpection을 생성한다.
- 비동기 작업이 완료된 시점에 해당 expectation의
fulfill()메서드로 비동기 작업이 완료됨을 알린다. - 비동기 작업을 호출한 함수에서는
wait(for: [expectation], timeout: 5.0)로 expectation이 충족되기를 기다린다.- expectation이 fulfill되거나 5초가 지날 때까지 기다린다.
- 혹시 비동기 작업이 너무 오래 걸리면 기다리지 않는다. 시간을 정해두면 비동기 작업에 실패하는 경우 5초를 초과하여 기다리지 않아도 되는 이점이 있다.
// given let urlString = MockURL.mockItem.description let url = try XCTUnwrap(URL(string: urlString)) var outcome: String? let expectation = XCTestExpectation(description: expectationDescription) let expectedValue = "MacBook Pro" // when sutNetworkManager?.fetchData(url: url) { (result: Result<Item, Error>) in switch result { case .success(let data): outcome = data.title default: XCTFail() } expectation.fulfill() } wait(for: [expectation], timeout: 5.0) // then XCTAssertEqual(outcome, expectedValue)
POST와 PATCH 요청을 보내기 위해 메서드의 httpBody를 multipart/form-data 로 지정하면 된다. multipart/form-data 형식이 무엇인지 간단하게 알아보기 위해 title=choco, price=9000 이라는 정보를 보낼 수 있는 형식들을 예를 들어보면 다음과 같다.
-
aplication/x-www-form-urlencoded방식title=choco&price=9000 -
multipart/form-data방식multipart/form-data 방식은 key/value 쌍을 쉽게 표현하는 형식
--XXX Content-Disposition: form-data; name="title" choco --XXX Content-Disposition: form-data; name="price" 9000 --XXX--
httpBody와 그 내부의 각 정보들은 boundary로 감싸져 있다.
- boundary는 내용들은 모두 같은 요청에 관한 내용임을 알리기 위한 고유 문자열이다.
- 따라서 같은 요청에서는 같은 boundary를 사용해야 한다.
- 고유 문자열은 UUIDString으로 랜덤하게 생성할 수 있다.
"Boundary-\(UUID().uuidString)"
--Boundary-XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
Content-Disposition: form-data; name=\"title\"
choco
--Boundary-XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
Content-Disposition: form-data; name=\"price\"
9000
--Boundary-XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX--multipart/form-dat 형식의 httpBody를 만들어 출력해보면 다음과 같다.
- httpBody를 먼저 디코딩해준다
String(decoding: request.httpBody!, as: UTF8.self)- 실제 출력한 결과물
- httpBody에는 다음 세 가지 정보를 담았다 -
title: choco,price: 9000,image: jpeg 파일 - 이미지 데이터는 사람이 알아볼 수 없는 형식으로 출력된다.
- httpBody에는 다음 세 가지 정보를 담았다 -
--Boundary-265B324D-9628-4D91-AC7A-31C6E93020B7
Content-Disposition: form-data; name="title"
choco
--Boundary-265B324D-9628-4D91-AC7A-31C6E93020B7
Content-Disposition: form-data; name="price"
9000
--Boundary-265B324D-9628-4D91-AC7A-31C6E93020B7
Content-Disposition: form-data; name="images[]"; filename="photo1602058207.jpeg"
Content-Type: image/jpeg
// 이미지 데이터 내용인데 알아볼 수 없는 형식
// ���J�;ى� ;�Ȧ8@#?N��.w?\����Q�Lcp��������� 등의 문자들로 이루어진 데이터
--Boundary-265B324D-9628-4D91-AC7A-31C6E93020B7--DELETE 요청은 httpBody를 application/json content-type으로 보내면 된다.
- parameters를 바로 Data형식으로 변환해서 httpBody에 담을 수 있다.
func deleteData(url: URL, parameters: [String:String]) {
var request = URLRequest(url: url)
request.httpMethod = "DELETE"
request.setValue("application/json", forHTTPHeaderField: "Content-Type")
let dataBody = try? JSONSerialization.data(withJSONObject: parameters, options: [])
request.httpBody = dataBody!
sessionDataTaskAndPrintResults(with: request)
}디코딩하는 메서드에 디코딩할 데이터를 인자로 넣어주는 방법 대신 Decodable 타입에 디코딩 메서드를 추가했다. 즉, Decodable한 data에 parse(type:) 메서드를 적용하면 data 자체가 디코딩된다. 메서드에서 따로 data를 받을 필요가 없다는 뜻.
// data: Decodable
let parsedResult = data.parse(type: T.self)- 추가해준 parse 메서드
extension Decodable {
func parse<T: Decodable>(type: T.Type) -> Result<T, Error> {
let decoder = JSONDecoder()
if let data = self as? Data,
let decodedData = try? decoder.decode(type, from: data) {
return .success(decodedData)
}
return .failure(NetworkError.failToDecode)
}
}상품의 목록을 UICollectionView를 통해 2단 그리드 형식으로 구현했다. viewDidLoad()가 실행되면 Model인 items에 데이터가 들어가도록 초기화하는 메서드 initializedItems()를 구현했다.
네트워킹을 하는 NetworkManager 의 메서드를 이용해 데이터를 fetch하고, 데이터가 성공적으로 받아와지면 메인스레드에서 컬렉션 뷰를 업데이트하도록 했다.
GridItemCollectionViewCell 클래스를 이용해 컬렉션 뷰에 들어가는 셀의 커스터마이징을 관리하도록 만들었다.
셀들의 이미지를 한 번에 받아오면 부하가 크기 때문에 당장 필요한 셀들의 이미지만 다운받도록 지연 로딩을 적용했다. collectionView(_:cellForItemAt:) 에서 셀을 dequeue한 뒤 바로 ImageLoader라는 타입을 통해 셀의 이미지를 업데이트 했다.
ImageLoader 코드
ImageLoader는 셀에 업데이트해야하는 이미지가 캐시에 있으면 캐시의 이미지로 업데이트하고 캐시에 없으면 비동기로 다운을 받아 업데이트 한다. 이때, 셀의 이미지뷰 업데이트는 main 스레드에서 실행해준다.
class ImageLoader {
static let shared = ImageLoader()
let cache = URLCache.shared
private init() {}
func loadImage(from urlString: String,
completion: @escaping (UIImage) -> Void) {
guard let url = URL(string: urlString) else { return }
let request = URLRequest(url: url, cachePolicy: .returnCacheDataElseLoad)
if let response = self.cache.cachedResponse(for: request),
let imageData = UIImage(data: response.data) {
DispatchQueue.main.async {
completion(imageData)
}
} else {
URLSession.shared.dataTask(with: url) { data, response, error in
guard error == nil else { return }
guard let response = response,
let statusCode = (response as? HTTPURLResponse)?.statusCode,
(200...299).contains(statusCode) else { return }
guard let data = data else { return }
guard let imageData = UIImage(data: data) else { return }
self.cache.storeCachedResponse(CachedURLResponse(response: response, data: data), for: request)
DispatchQueue.main.async {
completion(imageData)
}
}.resume()
}
}
}이미지를 다운받는 작업은 비동기로 이루어지며 작업 시간이 길어질 수 있다. 만약 이미지가 다 다운되지 않았는데 사용자가 스크롤을 한다면 처음 이미지를 요청했던 셀의 위치가 변경된다. 즉, 같은 위치에 있는 셀이 다른 이미지를 요청하게 될 수도 있다.
첫 구현은 셀의 indexPath를 비교했다. 셀을 dequeue했을 당시의 indexPath와 이미지가 모두 다운로드되었을 때의 indexPath를 비교해서 둘이 같은 경우에만 이미지를 업데이트해준다.
// self = cell
ImageLoader.shared.loadImage(from: currentURLString) { imageData in
if indexPath == collectionView.indexPath(for: self) {
self.thumbnailImageView?.image = imageData
}
}위 로직을 추가해 이미지를 업데이트하면 더이상 이미지가 깜빡이며 바뀌거나 이상한 셀에 들어가는 문제는 발생하지 않았다.
- UICollectionViewFlowLayout의
collectionView(_:layout:sizeForItemAt:이나 itemSize 프로퍼티를 활용해 직접 계산한 셀 크기를 사용하는 경우 컬렉션뷰의 Estimate Size를 None으로 지정해야 계산한 크기대로 셀이 표시된다. - 하지만 이렇게 하는 경우 이미지의 다운이 완료된 셀의 indexPath가 nil이 나올 때가 다수 발생했다.
collectionView.indexPath(for: self)를 출력해보니 여러차례 nil이 출력됐다. - 이유는 알 수 없었지만 일단 해결을 하기 위해 두 번째 방법을 사용했다.
위와 거의 동일한 방법인데 이번에는 indexPath대신 셀의 프로퍼티를 비교하는 로직을 구현했다. 셀이미지의 url주소를 프로퍼티로 저장해둔 후 해당 값이 같은 경우에만 이미지를 업데이트를 하도록 했다.
// self = cell
ImageLoader.shared.loadImage(from: currentURLString) { imageData in
if self.urlString == currentURLString {
self.thumbnailImageView?.image = imageData
}
}🥊 컬렉션뷰의 셀 크기를 직접 계산한 값으로 표시하고 싶다면 Estimate Size를 None으로 해야하는데 이 경우 지연 로딩 구현시 셀의 indexPath 비교 대신 프로퍼티 비교를 활용해야 한다.
- itemSize: delegate가
collectionView(_:layout:sizeForItemAt:)메서드를 구현하지 않는 경우 이 프로퍼티의 값을 사용해 각 셀의 크기를 설정한다. flow layout 객체가 컨텐츠의 모양을 구성하기 위해 제공하는 프로퍼티이며 모든 셀에 동일한 크기를 적용한다. 기본 크기 값은 (50.0, 50.0)이다. collectionView(_:layout:sizeForItemAt:): 고정된 크기 집합을 반환하거나 셀의 내용에 따라 크기를 동적으로 조정할 수 있다. 각각의 셀마다 다른 크기를 지정하기 위해 이 메서드를 사용한다.
--
extension ItemsGridViewController: UICollectionViewDelegateFlowLayout {
func collectionView(_ collectionView: UICollectionView, layout collectionViewLayout: UICollectionViewLayout, sizeForItemAt indexPath: IndexPath) -> CGSize {
// itemSize를 지정하는 로직 구현
return CGSize(width: cellWidth, height: cellHeight)
}
}처음에는 collectionView(_:layout:sizeForItemAt:)메서드를 사용해서 구현을 했었는데, 모든 셀의 크기가 고정인 점을 고려하여 itemSize로 구현하도록 수정했다.
UICollectionViewFlowLayout을 생성해 itemSize의 width를 컬렉션 뷰의 sectionInset을 뺀 값의 2로 나누어서 반환하는 메서드를 구현했다.
이 과정에서 Main.storyboard의 디바이스와 시뮬레이터 디바이스가 다를 경우, collectionView.bounds.width가 다르게 나오는 이슈가 있었다.
(lldb) po (collectionView.collectionViewLayout as! UICollectionViewFlowLayout).itemSize
▿ (194.0, 329.8)
- width : 194.0
- height : 329.8
(lldb) po collectionView.bounds.width
414.0
위는 스토리보드에서 iPhone11로 설정하고, 시뮬레이터를 iPhone SE로 실행했을 때 collectionView의 bounds.width가 414.0으로 나온 것을 기록한 것이다.
이를 해결하기 위해서 layoutIfNeeded() 메서드를 이용했다.
⇒ layoutSubViews() : View의 값을 호출한 즉시 변경시켜주는 메서드, 시스템에 의해 View의 값이 재계산되어야 하는 적절한 시점에 자동으로 호출된다. 이를 유도할 수 있는 여러 방법이 있고, update cycle에서 layoutSubVies()의 호출을 예약하는 행위이다.
layoutSubViews() 메서드를 수동으로 예약할 수 있는 메서드가 setNeedsLayout()과 layoutIfNeeded() 이다.
둘의 차이점은 비동기냐 동기냐의 차이이다. layoutIfNeeded()는 동기적으로 동작하는 메서드이기 때문에 즉시 값이 변경되어야하는 애니메이션에서 많이 사용한다고 한다. 출처
func configureItemSize() -> UICollectionViewFlowLayout {
collectionView.layoutIfNeeded() // 뷰의 값을 업데이트하기 위해 메서드 호출
// itemSize를 지정하는 로직 구현
layout.itemSize = CGSize(width: cellWidth, height: cellHeight)
return layout
}- flow layout은 컬렉션 뷰 레이아웃의 타입이다. 컬렉션 뷰의 아이템은 스크롤 방향에 따라 한 행이나 열에서 다름 행으로 흘러 배치된다. 각 행에는 들어갈 수 있는 수만큼의 셀이 표시된다.
- delegate object를 사용하여 레이아웃 정보를 동적으로 조정할 수 있다.
- 각 섹션에는 고유한 사용자 지정 머리글과 바닥글이 있을 수 있다.
NSCache는 흔히 생성 비용이 크지만 단기적으로만 필요한 객체를 임시 저장하기 위해 사용한다. 해당 프로젝트에서는 한번 다운받은 이미지는 다시 다운받지 않도록 NSCache를 활용했다. 이미지의 url과 UIImage를 key, value로 갖는 딕셔너리 형태로 매핑을 해서 이미지를 가져오도록 했다. 하지만 일반 딕셔너리 대신 NSCache 타입을 활용해 이미지를 캐싱했다.
- NSCache는 다른 어플리케이션에서 메모리를 필요로 할 때 내부 아이템을 일부 삭제하는 기능이 있어 시스템의 메모리를 너무 많이 차지하지 않음을 보장한다.
- NSCache는 thread-safe하기 때문에 여러 스레드에서 해당 캐시에 항목을 추가하거나 제거할 수 있다.
- NSMutableDictionary와 다르게 항목을 추가할 때 객체를 복사하지 않는다고 한다.
네트워크 통신의 request와 response를 매핑하는 URLCache를 접하게 되어 사용해봤다. 네트워크 데이터는 다음 이유로 URLCache를 사용하는 것이 더 좋다고 한다:
- NSCache는 메모리를 일부 비워주긴하지만 다 비워주지는 않기 때문에
didReceiveMemoryWarning()을 오버라이드해 메모리를 직접 flush해줘야 한다. - NSCache가 메모리를 일부 비워주는 방법이 체계적이지 않다고 한다.
- URLCache는 in-memory이자 on-disk 캐시라고 한다. 큰 메모리 덩어리를 할당하는 것이 아니라 더 유연한 구조라고 한다. in-memory와 on-disk는 메인메모리와 하드디스크로 속도, 용량, 휘발성에서 차이가 있는 저장구조.
- 속도 - in-memory 데이터베이스는 모든 자료가 메인 메모리에 저장되기 때문에 데이터를 읽거나 수정할 때 디스트 입출력 작업이 필요하지 않아 더 빠르다.
- 용량 - in-memory 데이터베이스의 용량은 메인 메모리 용량으로 한정된다.
- 휘발성 - in-memory는 데이터베이스 제품에 따라 휘발성일 수도 있고 아닐 수도 있는 반면 on-disk는 휘발성이지 않다.
참고 자료 To
NSCacheor not toNSCache, what is theURLCacheSwift: Loading Images Asynchronously and storing with NSCache and NSURLCache
URLCache도 잘 작동되는지 확인하기 위해 셀마다 용량이 평균 2MB의 매우 큰 이미지를 로딩하도록 구현해봤다. 결론은, NSCache는 잘 작동되는 반면 URLCache는 캐싱이 잘 되는데도 화면이 매우 버벅거렸다.
| NSCache | URLCache |
|---|---|
 |
 |
구현 방법
URLCache는 기본 용량이 크지 않기 때문에 용량이 큰 이미지들을 캐싱하고 싶으면 용량을 키워줘야 한다. 용량은 다음 방식으로 확인해볼 수 있다. (단위는 byte)
URLCache.shared.memoryCapacity
URLCache.shared.diskCapacity
// URLSession.shared.configuration.urlCache?.memoryCapacity
// URLSession.shared.configuration.urlCache?.diskCapacitymemoryCapacity와 diskCapacity를 넉넉하게 각각 500MB로 설정해줬다. 둘 다 크기를 키워주면 두 곳에 저장되고 한 곳만 키워주면 한 곳에만 저장된다. (memory는 메인메모리, disk는 하드디스크)
- 두 곳에 모두 저장할때나 한 곳에만 저장할 때나 속도 차이는 느끼지 못 했다.
URLCache.shared = {
let cacheDirectory = (NSSearchPathForDirectoriesInDomains(.cachesDirectory, .userDomainMask, true)[0] as String).appendingFormat("/\(Bundle.main.bundleIdentifier ?? "cache")/" )
return URLCache(memoryCapacity: 500*1024*1024,
diskCapacity: 500*1024*1024,
diskPath: cacheDirectory)
}()AppDelegate.swift의 application(_:didFinishLaunchingWithOptions:)에서 해줬는데 다른데서 해줘도 별 상관은 없는 것 같다.
다음 두 메서드로 request에 해당하는 response를 캐싱하고 꺼내왔다.
if let data = cache.cachedResponse(for: request)?.data {}
self.cache.storeCachedResponse(CachedURLResponse(response: response, data: data), for: request)
- 실제 적용한 코드
class ImageLoader {
static let shared = ImageLoader()
var cache = URLCache.shared
private init() {}
func loadImage(from urlString: String,
completion: @escaping (UIImage) -> Void) {
guard let url = URL(string: urlString) else { return }
let request = URLRequest(url: url, cachePolicy: .returnCacheDataElseLoad)
if let data = cache.cachedResponse(for: request)?.data,
let imageData = UIImage(data: data) {
DispatchQueue.main.async {
completion(imageData)
}
} else {
URLSession.shared.dataTask(with: url) { data, response, error in
guard error == nil else { return }
guard let response = response,
let statusCode = (response as? HTTPURLResponse)?.statusCode,
(200...299).contains(statusCode) else { return }
guard let data = data else { return }
guard let imageData = UIImage(data: data) else { return }
self.cache.storeCachedResponse(CachedURLResponse(response: response, data: data), for: request)
DispatchQueue.main.async {
completion(imageData)
}
}.resume()
}
}
}하지만 URLCache는 이미지 용량이 커지자 스크롤이 매우 버벅이고 일부 이미지는 다시 다운받는 것처럼 깜빡인다. 디버깅을 해보니 캐싱은 잘 되는 것을 두 가지로 확인할 수 있었다:
-
이미지들을 한 차례 다 로딩한 후에는 이미지들을 가져올 때 계속 캐시에서 빼내오는 코드가 실행됐다.
-
이미지가 캐싱될 때마다 사용되고 있는 캐시의 용량이 늘어남을 확인했다.그리고 최종적으로 캐시된 용량을 확인해보니 실제 이미지들의 용량의 합인 31MB과 같았다.
캐싱이 잘 되는데도 버벅이는 문제가 발생하는 것으로 봐서 두 가지 문제가 의심됐다:
- 캐시에서 response를 꺼내올 때 오래 걸리지 않을까 의심됐다.
- NSCache는 value를 UIImage로 저장하는 반면 URLCache는 URLResponse 타입으로 저장하기 때문에 매번 response의 데이터를 UIImage로 변환하는 작업이 필요하다. UIImage로 변환하는 작업이 오래 걸리지 않을까 의심됐다.
URLCache는 request, response를 키값 형태로 저장하기 때문에 이미지 캐싱보다는 다른 용도로 사용하는 것이 아닐까 하는 생각도 들었다. 일단은 네트워크 통신용 캐시라고 생각해서 NSCache가 아닌 URLCache를 사용했지만 이미지가 너무 큰 경우 버벅이는 문제가 발생하기 때문에 URLCache를 정말 네트워크에서 받은 이미지 캐싱에 사용해도 되는지 더 알아볼 필요가 있을 것 같다. (작은 크기의 이미지들은 잘 캐싱된다.)
컬렉션 뷰는 컨텐츠에 cell을 추가하기 전에 collectionView(_:willDisplay:forItemAt:) 메서드를 호출한다.
isNotLoading Bool타입 프로퍼티를 이용해 현재 추가적인 데이터를 더 로딩중인지 아닌지를 체크하고, indexPath.row가 전체 데이터보다 4개정도 적을 때 data를 추가로 fetch하도록 loadMoreData() 메서드를 구현했다.
URLSession's dataTask(with:completionHandler:) is used to retrieve data through network communication. However, in case of lack of server or internet connection the view should be filled with dummy data stored locally. And this data is retrieved by a Mock calss of URLSession through its dataTask(with:completionHandler:) method.
- MockURLSession mimics the behavior of URLSession. The application can simply substitute URLSessionwith MockURLSession to mimic data fetching process.
- To group these classes, an Interface called URLSessionProtocol is declared. This protocol declares a
dataTask(with:completionHandler:)function.
-
URLSessionProtocol type is initialized through dependency injection since it can either be URLSession or MockURLSession.
struct NetworkManager { let session: URLSessionProtocol init(session: URLSessionProtocol) { self.session = session } }
- A networking type uses
dataTask(with:completionHandler:)method to fetch data regardless of which subclass of URLSessionProtocol is injected.
let task: URLSessionDataTaskProtocol = session
.dataTask(with: request) { data, urlResponse, error in
//...
}
task.resume()- To achieve this behavior, Mock class should return data depending on the parameters of
dataTask(with:completionHandler:). - There are two sorts of data in this application; Items and Item. The local address of data is passed as the url of the data and the Mock class returns dummy data accordingly. It behaves as if the network has failed if the data address is invalid.
-
dataTask(with:completionHandler:)method returns URLSessionDataTask type. However, MockURLSession's method returns MockURLSessionDataTask.- It was necessary to override URLSessionDataTask's
resume()method - However, URLSessionDataTask's init() has been deprecated and thus seemed inappropriate to inherit from.
- So we declared a protocol called URLSessionDataTaskProtocol that groups URLSessionDataTask and MockURLSessionDataTask
- Since
dataTask(with:completionHandler:)of URLSession and MockURLSession are different, URLSessionProtocol now declaresdataTaskWithRequest(with:completionHandler)function that returns URLSessionDataTaskProtocol type so that both the mocking class and the actual class returns the same type.
protocol URLSessionProtocol { func dataTaskWithRequest(with request: URLRequest, completionHandler: @escaping (Data?, URLResponse?, Error?) -> Void) -> URLSessionDataTaskProtocol } extension URLSession: URLSessionProtocol { func dataTaskWithRequest(with request: URLRequest, completionHandler: @escaping (Data?, URLResponse?, Error?) -> Void) -> URLSessionDataTaskProtocol { dataTask(with: request, completionHandler: completionHandler) as URLSessionDataTaskProtocol } }
- It was necessary to override URLSessionDataTask's
-
Used Result Type as the return type of functions to be tested
case .success(let decodedData): completion(.success(decodedData)) case .failure(let error): completion(.failure(error)) }
-
Since the return type holds different values for differente Result cases, it was necessary to unwrap return values as follows.
case .success(let data): outcome = data.title case .failture(let error): print(error) case .none: print("none") }
-
To test an asynchronous function it is necessary to notify when the function returns.
-
XCTTestExpection was created before calling the function to be tested.
-
Its
fulfill()method was used to notify the end of the asynchronous process. -
The
wait(for: [expectation], timeout: 5.0)waits for the expectation tofulfill()- Wait until the expectation is fulfilled or 5 seconds passes
- By setting timeout we only wait for 5 seconds when the asynchronous job fails.
// given let urlString = MockURL.mockItem.description let url = try XCTUnwrap(URL(string: urlString)) var outcome: String? let expectation = XCTestExpectation(description: expectationDescription) let expectedValue = "MacBook Pro" // when sutNetworkManager?.fetchData(url: url) { (result: Result<Item, Error>) in switch result { case .success(let data): outcome = data.title default: XCTFail() } expectation.fulfill() } wait(for: [expectation], timeout: 5.0) // then XCTAssertEqual(outcome, expectedValue)
To send POST or PATCH requests the httpBody's content had to be of multipart/form-data type.
-
aplication/x-www-form-urlencodedtitle=choco&price=9000 -
multipart/form-datamultipart/form-data also represents data in a key-value format
--XXX Content-Disposition: form-data; name="title" choco --XXX Content-Disposition: form-data; name="price" 9000 --XXX--
httpBody and the data it contains are all wrapped by boundaries
- Boundary is a unique string that identifies an httpBdy
- The same request's httpBody has to use the same Boundary to mark the beginning and the end
- A unique string can be generated through UUIDString
"Boundary-\(UUID().uuidString)"
--Boundary-XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
Content-Disposition: form-data; name=\"title\"
choco
--Boundary-XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
Content-Disposition: form-data; name=\"price\"
9000
--Boundary-XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX--- Decoding httpBody
String(decoding: request.httpBody!, as: UTF8.self)- Output
- httpBody contatins three data -
title: choco,price: 9000,image: jpeg file - Image data is unreadable to human
- httpBody contatins three data -
--Boundary-265B324D-9628-4D91-AC7A-31C6E93020B7
Content-Disposition: form-data; name="title"
choco
--Boundary-265B324D-9628-4D91-AC7A-31C6E93020B7
Content-Disposition: form-data; name="price"
9000
--Boundary-265B324D-9628-4D91-AC7A-31C6E93020B7
Content-Disposition: form-data; name="images[]"; filename="photo1602058207.jpeg"
Content-Type: image/jpeg
// Image Data
// ���J�;ى� ;�Ȧ8@#?N��.w?\����Q�Lcp��������� and so on
--Boundary-265B324D-9628-4D91-AC7A-31C6E93020B7--DELETE request's httpBody was of application/json content-type
- httpBody is of Data type so parameters of dictionary type is encoded to Data type
func deleteData(url: URL, parameters: [String:String]) {
var request = URLRequest(url: url)
request.httpMethod = "DELETE"
request.setValue("application/json", forHTTPHeaderField: "Content-Type")
let dataBody = try? JSONSerialization.data(withJSONObject: parameters, options: [])
request.httpBody = dataBody!
sessionDataTaskAndPrintResults(with: request)
}Instead of creating a Decoding type or creating a decoding function in the main logic, we added a decoding method in Decodable's extension.
- Decodable types now have a decoding method. There is no need to create a JSONDecoder() instance or a decoding type's instance.
- Data doesn't need to be passed as parameters because the decoding method decodes the data itself.
// data: Decodable
let parsedResult = data.parse(type: T.self)- Decoding method
parse<T>(type:)
extension Decodable {
func parse<T: Decodable>(type: T.Type) -> Result<T, Error> {
let decoder = JSONDecoder()
if let data = self as? Data,
let decodedData = try? decoder.decode(type, from: data) {
return .success(decodedData)
}
return .failure(NetworkError.failToDecode)
}
}The goal was to display two custom cells per row in UICollectionView. items model data is fetched through NetworkManager and updated in the main thread.
Lazy Loading was applied when downloading cell images to improve performance by delaying load. collectionView(_:cellForItemAt:) dequeues a cell and updates image through ImageLoader.
ImageLoader Code
class ImageLoader {
static let shared = ImageLoader()
let cache = URLCache.shared
private init() {}
func loadImage(from urlString: String,
completion: @escaping (UIImage) -> Void) {
guard let url = URL(string: urlString) else { return }
let request = URLRequest(url: url, cachePolicy: .returnCacheDataElseLoad)
if let response = self.cache.cachedResponse(for: request),
let imageData = UIImage(data: response.data) {
DispatchQueue.main.async {
completion(imageData)
}
} else {
URLSession.shared.dataTask(with: url) { data, response, error in
guard error == nil else { return }
guard let response = response,
let statusCode = (response as? HTTPURLResponse)?.statusCode,
(200...299).contains(statusCode) else { return }
guard let data = data else { return }
guard let imageData = UIImage(data: data) else { return }
self.cache.storeCachedResponse(CachedURLResponse(response: response, data: data), for: request)
DispatchQueue.main.async {
completion(imageData)
}
}.resume()
}
}
}Downloading an image is an asynchronous task that may take quite a while. If the user scrolls the screen before images are updated then cells have to display different images.
To solve these problems images had to be updated only when the requesting cell and the to be displayed cell's information matches.
The first solution was to compare the cell's indexPath when it has been dequed and its indexPath when the download has been completed.
// self = cell
ImageLoader.shared.loadImage(from: currentURLString) { imageData in
if indexPath == collectionView.indexPath(for: self) {
self.thumbnailImageView?.image = imageData
}
}- The collectionView's cell size is calculated either in UICollectionViewFlowLayout's
collectionView(_:layout:sizeForItemAt:or using theitemSizeproperty. And the collectionView's Estimated Size has to be set to None for the cell size to be applied in both cases. - However cells who completed image downloads had nil indexPaths when checked like so
collectionView.indexPath(for: self). - This seemed to be due to cell prefetching.
Instead of comparing cells' indexPaths, the second logic compares cells' properties. To check whether the image should be updated or not an image's url path was added as the cell's property. Only if the cell's image url path matches is the image updated.
// self = cell
ImageLoader.shared.loadImage(from: currentURLString) { imageData in
if self.urlString == currentURLString {
self.thumbnailImageView?.image = imageData
}
}UICollectionViewDelegateFlowLayout'scollectionView(_:layout:sizeForItemAt:)method - It is used to set various cell sizesUICollectionViewFlowLayout'sitemSizeproperty - It is used to set a single cell size which is set to a default value of (50.0, 50.0)
extension ItemsGridViewController: UICollectionViewDelegateFlowLayout {
func collectionView(_ collectionView: UICollectionView, layout collectionViewLayout: UICollectionViewLayout, sizeForItemAt indexPath: IndexPath) -> CGSize {
// setting itemSize
return CGSize(width: cellWidth, height: cellHeight)
}
}
Our goal was to display two items in a row. Since all our cells had the same size we set its size using UICollectionViewFlowLayout's itemSize property. In doing so, we calculated the cell size by dividing the width of UICollectionView.
let itemSize = (collectionViewWidth - sectionInset) / 2However when the storyboard's device was different from the simulator's device, the collectionView's width was firstly set to the width of the storyboard's device. When the storyboard had iPhone11 and the simulator had iPhone SE as their devices thre results were as follows.
(lldb) po (collectionView.collectionViewLayout as! UICollectionViewFlowLayout).itemSize
▿ (194.0, 329.8)
- width : 194.0
- height : 329.8
(lldb) po collectionView.bounds.width
414.0
layoutSubViews() - method that updates the View. It is called by the system and there are several ways to call it.
layoutIfNeeded() - method that calls layoutSubViews() and updates the view immediately. It's often used in animation.
func configureItemSize() -> UICollectionViewFlowLayout {
collectionView.layoutIfNeeded() // updates the view
// setting itemSize
layout.itemSize = CGSize(width: cellWidth, height: cellHeight)
return layout
}Some data are very expensive to download. If they are only needed temporarily it get even more expensive. To reduce cost, we saved image files to NSCache in url-UIImage as the key-value pair.
- According to some references, NSCache partially empties itself when it is short of memory. This ensures that NSCache doesn't take up too much memory.
- NSCache is thread-safe so it is safe to add or erase items in a multi-thread environment.
- Unlike NSMutableDictionary it does not copy items when caching it.
Reference To
NSCacheor not toNSCache, what is theURLCacheSwift: Loading Images Asynchronously and storing with NSCache and NSURLCache
URLCache caches URL requests so we thought it was a better fit for caching images that are downloaded online. The reference states that URLCache is better for some reasons:
-
NSCache does empty some memory but it is still required to flush memory through
didReceiveMemoryWarning() -
NSCache's memory clearing algorithm is not structured.
-
URLCache is more flexible because it is both in-memory and on-disk cache.
- In-memory and on-disk differ in three categories: speed, capacity, volatility
- speed -
in-memorydatabase save all its data to the main memory so its reading and updating processes are much faster because there is no need of I/O tasks. - capacity -
in-memorydatabase's capacity is limited to the main memory capacity - volatility -
in-memorycan either be volatile or non volatile buton-diskis always non volatile.
- speed -
- In-memory and on-disk differ in three categories: speed, capacity, volatility
Reference To
NSCacheor not toNSCache, what is theURLCacheSwift: Loading Images Asynchronously and storing with NSCache and NSURLCache
To check if URLCache works as well as NSCache we tested it by caching big images of average size 2MB. To sum up, NSCache worked fine while URLCache had low performance issues even though it did cache images.
| NSCache | URLCache |
|---|---|
|
|
Imeplementing URLCache
The default URLCache capacity is not so big.
URLCache.shared.memoryCapacity
URLCache.shared.diskCapacity
// URLSession.shared.configuration.urlCache?.memoryCapacity
// URLSession.shared.configuration.urlCache?.diskCapacityTo cache all the images it is necessary to increase URLCache capacity. We set both memoryCapacity and diskCapacity to 500MB. Images are cached to both memories if both have space.
- We didn't spot any particular difference when caching to both memory and disk.
URLCache.shared = {
let cacheDirectory = (NSSearchPathForDirectoriesInDomains(.cachesDirectory, .userDomainMask, true)[0] as String).appendingFormat("/\(Bundle.main.bundleIdentifier ?? "cache")/" )
return URLCache(memoryCapacity: 500*1024*1024,
diskCapacity: 500*1024*1024,
diskPath: cacheDirectory)
}()This can either be done in AppDelegate.swift's application(_:didFinishLaunchingWithOptions:) or in a relevant type like a networking type.
URLCache provides methods to read and save data.
// reading response
if let data = cache.cachedResponse(for: request)?.data {}
// storing response
self.cache.storeCachedResponse(CachedURLResponse(response: response, data: data), for: request)
-
Code sample
if let data = cache.cachedResponse(for: request)?.data, let imageData = UIImage(data: data) { DispatchQueue.main.async { completion(imageData) } } else { URLSession.shared.dataTask(with: url) { data, response, error in // ... guard let data = data else { return } guard let imageData = UIImage(data: data) else { return } self.cache.storeCachedResponse(CachedURLResponse(response: response, data: data), for: request) // ... }.resume() }
-
However if we use a custom URLSession by setting up configuration data is automatically cached and read without the former processes.
private let customURLSession: URLSession = { URLCache.shared.memoryCapacity = 512 * 1024 * 1024 let config = URLSessionConfiguration.default config.requestCachePolicy = .returnCacheDataElseLoad return URLSession(configuration: config) }() customURLSession.dataTask(with: url) { data, response, error in // ... }
Images did not show quickly and the scroll wasn't working right when using URLCache. Caching was done because URLCache's disk usage did go up as images piled up and images were gotten from the cache once stored. Since there was no problem with caching we thought it was a lot of burden to convert data to UIImage type.
-
UICollectionView calls
collectionView(_:willDisplay:forItemAt:)before adding cells. -
If
indexPath.rowis 4 less than the whole data count and if data is not being loaded,loadMoreData()is called to fetch more data.