티스토리 뷰
Java App using REST API - Network Data in Android Course - 정리 ( Volley )
tbMaster 2021. 2. 18. 19:55android 플랫폼을 기반으로 REST API 강의가 있길래 정리해보았다.
Java App using REST API - Network Data in Adnroid Course : www.youtube.com/watch?v=xPi-z3nOcn8
* 이 동영상에서는 Volley를 이용한다. (retrofit 도 비슷하기 때문에 금방 적을 할 수 있다니깐... Volley로 Tutorial 진행해보자)
* 해당 영상은 하나 하나 알려주기 때문에 따라하기 좋다. google developer 문서의 Volley를 보고 진행하기 때문에 문서를 보면서 진행하면 좋다.
* 학습 내용
- 기능 1 : 지역코드를 이용하여 날씨 데이터를 받아온다.
- 기능 2 : 지역명을 입력하여 지역코드를 받아온다.
- 기능 3 : 지역명을 이용하여 7일 간의 날씨 데이터를 받아온다.
[ 학습 코드 ]
api 제공 사이트 : https://www.metaweather.com/api
※ 퍼미션
INTERNET, NETWORK 퍼미션 두개 필요 ( 영상에서는 INTERNET만 추가하였으나, 그러면 에러남 )
※ Gson 사용 (WeatherDataService 클래스 - getCityForecastByID 메소드 )
일일히 속성 세팅하면 너~~~무 많음. 따라하긴 했지만... Gson 사용하면 한줄로 끝남
※ Volley의 MessageQueue는 background에서 데이터를 받기 때문에 main thread에서 값을 받으려면 JAVA의 callback을 사용하게 되고, 여기서 callback 지옥을 경험하게 된다. 그래서 이 동영상에서는 다른 언어에서 지원하는 라이브러리를 사용하여 callback 지옥에서 벗어나라고 추천한다. 현재 rxAndroid를 공부하고 있는데 이때 사용하면 참 좋을 것 같다. 아래 코드가 callback에 callback을 호출하는 부분이다.
전체 코드 : gitlab.com/mskim0ct/volley_rest-api_tutorial.git
[ Volley ]
: 네트워킹을 더 쉽고, 빠르게 하는 HTTP 라이브러리
developer.android.com/training/volley?hl=ko
이점
- 네트워크 요청의 자동 예약.
- 여러 개의 동시 네트워크 연결
- 표준 HTTP 캐시 일관성을 갖춘 투명한 디스크 및 메모리 응답 캐싱
- 요청 우선순위 지정 지원
- 취소 요청 API. 단일 요청을 취소하거나 취소할 요청의 블록 또는 범위를 설정할 수 있습니다.
- 용이한 맞춤설정(예: 재시도, 백오프)
- 강력한 정렬 기능을 이용하여 네트워크에서 비동기식으로 가져온 데이터로 UI를 올바로 채우는 작업을 쉽게 실행할 수 있음.
- 디버깅 및 추적 도구
주의사항
- Volley는 파싱하는 동안 모든 응답을 메모리에 유지하므로 대규모 다운로드 또는 스트리밍 작업에는 부적합 (대규모 다운로드 작업은 DownloadManager와 같은 대안을 사용하는 것이 좋습니다.)
Volley - "RequestQueue" 중요!!!!
역할 : reqeust 를 담아내는 Queue. 네트워크 실행, 캐시read/write, 응답 파싱을 위한 작업자 스래드 관리
특징
- 기본 RequestQueue 제공
- Custom ReqeustQueue 제공 ( Singleton을 이용한 RequestQueue
[ request 처리 과정 - send a request ]
requestQueue 에 request를 add() 하면
Volley는 cache proccesing thread 및 network dispatch thread들을 포함하는 thread pool을 실행
requestQueue에 request가 추가되면
cache thread에서 request를 처리할 수 있다면, cache thread에서 파싱된 response을 mainThread에 전달한다.
cache thread에서 request를 처리할 수 없다면, request는 network thread에 queue에 전달되고, 먼저 처리가능한 network thread가 network queue에 있는 request를 받아 HTTP transaction 수행 및 worker thread에서 response를 받는다. response는 파싱하여 cache에 쓰고, 파싱한 response를 다시 main thread에 전달한다.
( Note : 비용이 많이 드는 blocking I/O, parsing/decoding 은 worker thread에서 수행한다. 어떤 thread에서든 request를 추가할 수 있지만, response는 항상 main thread에 전달된다. )
[ request 처리 과정 - cancel a request ]
※ request 취소 시, response handler 가 호출되지 않기 때문에, response handler에 의존적인 부분이 있다면, 해당 부분을 처리하는 과정이 따로 필요하다.
취소를 원하는 request에 cancel을 이용하여 단일 취소 가능
ex) request.cancel();
request에 TAG를 설정하여, requestQueue에서 동일한 TAG로 설정한 모든 reqest를 취소 가능
ex) request.cancelAll(TAG);
Activity 내에서 요청된 모든 request를 취소하고 싶을 경우, Activity로 취소 가능
ex) request.cancelAll(this);
[ Singleton 을 이용한 RequestQueue 설정 ]
한번의 요청과 thread pool을 남겨놓을 필요가 없을 경우, Volley에서 제공하는 Volley.newRequestQueue을 사용하면 됨. 그러나 일반적으로 애플리케이션의 전체 기간동안 계속 실행되길 원할 경우, singleton으로 RequestQueue를 설정한다.
애플리케이션이 지속적으로 네트워크를 사용하는 경우라면, RequestQueue의 단일 인스턴스를 설정하는 것이 가장 효율적일 것이다.
추천 방법 : RequestQueue 및 기타 Volley 기능을 캡슐화하는 singleton 클래스를 구현
!!!주의 Context 설정 시, ApplicationContext로 RequestQueue를 인스턴스화해야 Activity가 재시작(화면 회전 등)할 때마다 RuquestQueue가 재생성되지 않고 유지할 수 있다.
Volley - "Request" (standard request, custom request)
Volley에서 제공하는 standard request
- StringRequest : response가 string 형태
- JsonObjectRequest : response가 JsonObject 형태
- JsonArrayRequest : response가 JsonArray 형태
Custom request ( Request<T> : request를 통해 얻고 싶은 response의 type )
- parseNetworkResponse()와 deliverResponse() 구현해야 함
parseNetworkResponse(NetworkResponse response) : Response<T>
Response는 파싱한 response의 원하는 타입(ex : string, image, JSON)으로 delivery를 위해 캡술화한다.
- NetworkResponse response : byte[]의 payload, HTTP status code, response header을 포함한다.
- Response<T> : 리턴은 반환을 원하는 T 타입 및 cache metadata 또는 실패 시 처리 내용을 반환한다.
deliverResponse(T response) : Void
parseNetworkResponse 에서 반환된 response를 main thread에 전달하는데 deliverResponse를 통해서 전달된다.
[ REST API ]
en.wikipedia.org/wiki/Representational_state_transfer
: The letters API stand for Application Program Interface.
* REST 인터페이스의 원칙에 대한 가이드
- 자원의 식별 : 서버가 가지고 있는 자원에 주소를 지정
- 메시지를 통한 리소스의 조작 : 자원을 지칭하는 메시지, 특정 메타데이터 (클라이언트 측) -> 자원의 변경/삭제 가능 (서버 측) <- 자원지칭 메세지, 특정 메타데이터만으로 충분한 서버 자원의 핸들링 가능
- 자기서술적 메시지(self-descriptiveness) : 메시지는 자신을 어떻게 처리해야 하는지에 대한 충분한 정보를 포함해야 한다. 메시지 이해를 위해 내용까지 살펴보지 않고, 메시지가 가지는 정보만을 가지고 메시지를 이해할 수 있어야 한다.
- 애플리케이션의 상태에 대한 엔진으로써 하이퍼미디어
: 클라이언트가 서버가 가지는 리소스에 접근을 원하면, 서버가 제공하는 링크를 통해 자원에 접근 가능하다. 서버가 제공하는 하이퍼링크를 포함하는 택스를 통해 자원에 접근하며, 이는 클라이언트가 하드 코딩으로 정보를 얻어야할 필요가 없다.
[ SOAP ]
ko.wikipedia.org/wiki/SOAP#메시지_형식
: Simple Object Access Protocol
: HTTP, HTTPS, SMTP 등을 통해 XML 기반의 메시지를 컴퓨팅 네트워크 상에서 교환하는 프로토콜이다.
: SOAP에는 몇가지 형태의 메시지 패턴이 있지만, 보통의 경우 RPC패턴으로 네트워크 노드(클라이언트)에서 다른 쪽 노드(서버)로 메시지를 요청하고, 서버는 메시지를 즉시 응답하게 된다.
[ Microservices Model ]
: 애플리케이션을 느슨하게 결합된 서비스의 모임으로 구조화하는 서비스 지향 아키텍처(SOA) 스타일의 일종인 소프트웨어 개발 기법.
: 애플리케이션을 서비스로 분리하여 모듈형태로써, 독립성을 갖게 된다.
-> 서비스 : 규모가 작고, 메시지 전달 가능, 컨텍스트별로 묶임, 독립적 전개 및 분산적이며 빌드가 되며, 자동화된 프로세스들로 출시
: 서비스에 대한 이해, 개발, 테스트 및 교체가 용이, 각 서비스가 병렬적으로 개발이 가능하다.
: 각 서비스들을 포함하는 애플리케이션은 확장성이 용이해진다. (서비스 별로 지속적인 배포가 가능)
* 철학
- "한가지 일을 하되 잘해라"
* 비평
- 서비스들은 정보의 장벽을 형성
- 모놀리식 서비스와 비교했을 때, 네트워크 레이턴시, 메시지 처리 면에서 비용이 더 많이 든다.
- 테스트와 전개가 더 복잡하다.
- 서비스 규모 축소를 주된 목적으로 바라보면, 너무 많은 서비스ㄹㄹ 생성하는 결과를 낳을 수 있다.
[ JSON and XML ]
- JSON : JavaScript Object Notation, 키-값 쌍으로 메시지를 전달할 수 있는 포맷
- XML : Extensible Markup Language, 특수한 목적을 위한 다목적 마크업 언어 (태그를 통한 구조, 데이터를 설명하는 포맷)
[ CLIENT and SERVER ]
NON-BLOCKING CODE : callback fuction의 목적은 application이 서버로부터 요청한 데이터를 받을 때까지 다른 작업을 계속해서 진행할 수 있도록 한다.
요청 데이터를 받을 때까지 멈춰있지 않고 백그라운드로 돌려놓고 계속해서 다른 작업을 진행한다.
ANDROID UI THREAD : Lopper는 Message Queue에 있는 Task들을 Handler에 전달하고 Handler는 Task를 실행시킨다.
'android' 카테고리의 다른 글
| [android] 디바이스에 설치된 application 확인 방법 (0) | 2021.01.16 |
|---|---|
| [android] adb 명령어 사용 몇 가지 (0) | 2021.01.13 |
| [android] 부팅시 Receiver 디버깅 하는 방법 (0) | 2020.12.06 |
| [android] turn screen on / show when lock screen 에서의 double lifecycle (0) | 2020.11.05 |
| [android ] setTurnScreenOn 및 requestDismissKeyguard 관계 (0) | 2020.11.02 |