Volley, Volleyer, Multipart upload.

1445664805_web-code

Volley는 2013년 구글에서 발표한 너무나도 유용하며 간편한 네트워크 작업 http open api 이다. 쉽고 빠르며 용량이 적은 장점 이 많은 이브러리로서,  단순히 서버와의 비동기 통신에서  필요한 기능들 모두를 volley라이브러리를 통해서 거의 해결했었다. 거기에는 단순한 GET, POST 부터 string이나 file업로드인 multipart upload 까지 포함 되어 있다.

하지만 volley에도 무시할 수 없는 단점이 존재 한다. 예를 들어 request 객체의 구현등이 있다. restful환경에서 최근들어 json을 이용한 비동기 통신을 자주 하는데 json object나 array에 대한 parse request, response 등이다. 몰론 Gson을 이용하여 class대 json obejct(array)를 대응하여 알아서 파싱하여 data bean object로 만들어주는 좋은 라이브러리도 있다.

그래도 결국 개발자는 Request를 상속받아 response형을 구현한 구현체를 만들어야 한다. 기본적으로 주어지는 JsonArrayRequest나 JsonObjectRequest가 존재 하지만 것만으로는 부족하다고 느껴질 수 있다. volley에 익숙해져가는 개발자는 자신도 모르게 string에서 xml까지 다양한 구현체를 만들고 Generic type을 활용하여 여러가지 response와 request에 대응하는 방법을 사용 할 수도 있겠다.

더 단순하고 문제없을만한 해결방법을 찾다가 naver의 Volley Extension을 사용해본적도 있다. volley extension은 확실히 괜찮은 라이브러리이다. AUIL(Android Universal Image Loader)에서 사용되는 disk, memory cache들을 가져와 사용 할 수 있게 도와주는Volley-caches, 그리고 위에서 언급했었던 다양한 request 구현체의 제공(JacksonRequest, Jackson2Request, SimpleXmlRequest)한다.

그리고 volley에서 제공했던 NetworkImageView를 상속한 서브 이미지뷰 클래스인 ‘TwoLevelDoubleTapZoomNetworkImageView’와 ‘MultiLevelSingleTapZoomNetworkImageVIew’ 이다. 클래스 이름에서 볼 수 있듯이 더블탭, 싱글탭 등의 확대-축소 , 핀치 줌 등의 지원이 추가된 이미지 뷰 라고 할 수 있겠다. 이 또한 기존 기능에서 아쉬웠던 기능이 추가 된 것이다.

그리고 ‘Volleyer’가 있다. request구현체의 문제를 해결하게 되면서 추가된 스타일리쉬한 builder패턴을 적용한 라이브러리다.

예제 소스에서도 볼 수 있듯이 builder패턴과 chaning method를 이용하여 한눈에도 request객체의 생성에서 http 전송, response, error handling등이 한눈으로 확인 할 수 있음을 알 수 있다. 이러한 가독성의 증가는 결국 개발자의 비용을 단축 시킬수 있다.

volleyer는 좋은 라이브러리 이다. volley의 단점을 최대한 제거 했으며 개발자로 하여금 정리된 듯한 프로세스를 구성 할 수 있게 해준다. 하지만 chaining method방식이 나에게 있어선 단점으로 보였다.

Image의 path를 얻고 File 인스턴스를 생성해서 volleyer의 addFilePart()메소드를 이용하여 이미지파일을 전송 하려고 했다. 하지만 생성한 File인스턴스의 파일 존재 여부는 volleyer 외부에서 확인 할 수 있겠지만 (file.exists()메소드 등) 내부에서는 Http body에 addPart()할때 File의 null체크를 하지 않아 오류가 발생하여 앱이 죽는 일이 발생 했었다.

어쩌면 chaining method를 구현 하는 방식에 다른 방법이 있을까 해서 찾아봤지만 시간도, 능력도 부족하여 다음으로 미뤘고 어쩔 수 없이 addFilePart()를 포함한 volleyer 소스1 과 addFilePart()를 포함하지 않은 volleyer 소스2를 분기 하여 구성 했었다. 이는 결국 2개의 분기지만 내부는 사실상 동일한(이미지 파일의 업로드의 유무) 작업 하는 코드를 따로 관리해줘야 하는 문제가 생긴 것 이다.

이 외에도 특수한 처리를 해줘야 하는(서버측 에서의 요구 사항에 의한..) 상황이 발생하여 volleyer를 사용하지 못하는 경우가 생겨서 아래에 정리한 MultiPartRequest를 구현해서 사용 했다.

주석을 최대한 달아서 이해하기 쉽게 해보려 노력 했는데 어떨진 모르겠다. 이 모듈은 아직 완벽하게 검증 된 녀석이 아니다. 예를 들어 파일의 사이즈가 좀 커지면 2번 이상으로 업로드를 나누어서 하는것 같은데 이에 대한 처리가 없다.  또한, 업로드 파일이 크면 클수록 그에대한 대비가 필요할 텐데 그런거에 대해서 아직 고민한 것 이 없다. 만약 혹시 누군가 이 모듈 클래스를 사용하게 된다면 그에 대한 대비가 필요 할 것 이다.

 

이 Request모듈을 사용 하기 위해선 다음과 같은 작업들을 추가로 해야 한다.

 – app의 build.gradle 파일에 다음과 같은 apache의 http components  라이브러리 모듈 사용을 명시한다. 몰론 아래처럼 gradle에 명시하지 않고, jar파일을 받아서 import해도 상관 없다.

 – 당연한 것이지만 volley나 volley extension등의 모듈 추가는 필수 이다.

 

좋은 라이브러리는 개발의 비용을 크게 단축 시켜 준다. 몰론 이러한 라이브러리를 바닥부터 만들어서 배포 하기 위해 엄청난 시간을 들여도 상관 없다. 하지만 이미 많은 사람들이 달라붙어이슈를 피드백 하고 수정하고 업데이트 되어 stable한 상태의 안정성이 인정된 라이브러리를 쓰지 않고 새로 만드는것은 많은 부담이 될 것 이다.

처음엔 이러한 라이브러리들을 쓰는거에 대한 부담이 컷었다. 라이브러리에 대한 의존성 문제와 개인 실력의 증가 여부에 대한 고민이 생기기 때문이다. 하지만 요즘엔 그런게 없다. 오히려 이러한 라이브러리들이 github에서 배포되니 내부 소스들을 보면서 코딩 스타일이나 알고리즘 이나 여러가지 좋은 면을 배워가는게 나쁘진 않다고 생각 된다.

 

 

 

You may also like

댓글 남기기

이메일은 공개되지 않습니다. 필수 입력창은 * 로 표시되어 있습니다.