Skip to content
Wooseong Kim edited this page Dec 29, 2015 · 8 revisions

주소

Swish API Doc(gist): https://gist.github.com/devyunsy88/f90322bd9d55e44727fa
개발 서버 클라이언트 리스트: http://yooiia.iptime.org:3000/[email protected]
개발 서버 사진 리스트: http://yooiia.iptime.org:3000/[email protected]
릴리즈 서버 매니저 페이지: http://yooiia.iptime.org:8081/
서버 - 클라이언트 통실 프로토콜: https://gist.github.com/devyunsy88/f90322bd9d55e44727fa
MySql 서버: http://www.yooiisoft.com/phpmyadmin/index.php

SwishServer

간단히 말해 Alarmofire의 래퍼. 제일 코어 로직을 담당. 이것을 이용해서 UserServer, PhotoServer, StickerServer가 구성이 됨.

HttpRequest 객체를 사용해서 동작.

instance 메서드 requestWith<T>부분을 보면 addToRequests()라는 메서드가 있는데, 이 메서드의 의미를 잘 알아둘 필요가 있다. request 객체를 Requests 딕셔너리에 넣는다는 의미로 사용되었음. 오해의 소지가 있을 수 있기에 기록.

responseJSON()이라는 메서드에서 Response객체를 반환받는데, 이 객체는 Alarmofire의 객체로서 필요한 데이터가 들어 있다.

  • 참고: statusCode: 200(Success) / 201(Created, 새 객체가 서버에서 생성) / 400(Normal Error) / 500(Server Error)

handleResponse()

이 부분이 어려워서 기록을 따로 해 둔다. response.result.value는 데이터이고, JSON(value)를 통해 httpResult를 생성. httpRequest.parser(httpResult)를 통해서 result를 생성해서 httpRequest.onSuccess(result: result)를 호출. 이 마지막 result는 이다. 각 서버 클래스 맞게 등으로 넣어준다. 각 서버에서 이 제네릭은 받고 싶은 타입을 의미.

  • Parser: 결과값을 파싱해서 원하는 값으로 만드는 로직을 구현해야 하는 구현체로서 코드 중복을 막기 위해 SwishServer 단에서 제너릭으로 선언되어 있는 것. 그래서 각 서버 클래스의 메서드에서 들어온 값을 원하는 방향으로 파싱할 수 있게 클로져에서 파싱 로직을 구현.

사용 패턴

크게 5가지가 있다.

  1. Parameter 정보 등록
    예를 들어 registerMe()를 부른다고 할 때, 필요한 정보들을 가지고 Dictionary 생성이 필요. (ex: 유저 아이디, 어바웃 등)

  2. Parser 생성
    각 서버클래스의 메서드에서 들어오는 데이터 값을 원하는 방향으로 파싱할 수 있는 클로져 로직을 구현. UserServerupdateMe()의 경우 Response만 필요하고 반환 데이터 및 파싱이 필요가 없기에 SwishServer.DefaultParser를 전달하면 됨. 특별히 하는 일은 없다. HttpRequest<JSON>()으로 제네릭에 JSON을 대입하면 된다.

  3. HttpRequest 객체 생성
    파라미터, 파서 및 필요 정보를 가지고 이 객체를 생성

  4. Optional한 처리 해주기
    UserServerregisterMe() 메서드를 보면 useAuthHeader = false가 있는데, 최초 등록 시에는 토큰이 없기 때문에 예외적인 처리가 필요했음. 이와 같이 특별 처리가 있는 경우 HttpRequest객체에 추가 처리를 해줌

  5. Request 요청

UserServer

주의

현재 APNS 관련 처리가 아직 안되어 있으므로, UserServer 클래스에 추가 작업을 진행할 것

PhotoServer

조금 특이한 점은 으로 <Array>를 사용하고 있다는 것. 파서에서 데이터를 받아서 Array를 만들 수 있게 for문을 돌고 있다는 점을 알아두자.

photoResponseWith(), photoTrendsResult()

우선 용어는 조금씩 달라지고 있는 부분을 숙지하자. 비슷한 의미로 사용되고 있다.

사진의 raw data를 파싱하는 로직의 거의 동일하지만, 하나는 Array<PhotoResponse>, 하나는 Array<PhotoTrendsResult>를 생성해 줘야 하기 때문에 위 두 메서드로 구분되어 구현이 되어 있고, 마찬가지로 파싱하는 메서드도 두 개로 구분되어 있다. 그 곳에서 파싱 코어 로직은아래에 있는 photoInfoFromResultJson()을 사용하고 있다. 각 파싱 두 메서드에서 아래의 메서드를 통해 클로져 안에서 (photo, sender, imageUrl)을 반환해 주는데, 이 값을 가지고 PhotoResponse, PhotoTrendsResult을 각각 만들어 주게 된다.

photoInfoFromResultJson()

파서의 코어 로직 메서드로서, 다른 서버의 로직과 다른 점은 데이터를 파싱해서 만들 최종 데이터가 Array라는 점을 알아두자.

Tag Prefix

Request 취소가 필요할 경우 Tag를 붙인다. registerMe()같은 경우는 취소가 필요 없는데 반해 여기의 메서드들은 여러 이유들 때문에 취소해야 할 필요성이 있는데, 이를 위해 도입했고 만드는 로직은 SwishServer에 있다. 하나만 존재 해야하는 Request의 경우는 단일 태그를 사용하고, PhotoState 등 사진 하나 마다 필요할 수 있는 Request는 photoId를 포함해 태그를 생성.

보낸 사진 관련

추후 해야할 기능 중에 보낸 사진들 화면에서 보낸 사진들의 상태를 서버에 리퀘스트해서 받아오는 로직을 구현할 필요가 있음. viewDidLoad()viewWillDisappear()에서 execute()cancel()을 호출해 주어야 한다. JIRA에 등록했고 구현이 되면 이 내용은 삭제 필요.

안드로이드 로직에서는 SentPhotoCollectionAdapter의 생성자에서 ServerUtils.checkSentPhotoState()의 콜백에서 최신 데이터를 받아 refreshPhotoStats(result)를 호출해 주고 있다. 이와 유사한 방식으로 iOS에서도 구현할 것

참고

saveParamWith()는 서버에 사진을 보내는 관련 로직인데, UIImage를 base64String을 변환하는데 시간이 많이 걸리고 있어서 이를 비동기로 처리하는 로직이 있는데 이런식으로 처리할 수도 있다는 점을 알아두자.