요청 큐(Requesting Queue)사용하기
앞선 강좌에서 어떻게 Volley.newReuestQueue라는 메소드로 Volley의 기본 동작의 이점을 살려 쉽게 요청 큐를 만드는지 살펴보았습니다. 이번 강좌는 자신만의 커스텀된 동작을 추가하여 요청 큐를 만드는 과정을 다루게 됩니다.
이번 강좌는 요청 큐를 싱글톤 으로 만들어 애플리케이션과 생명주기를 같이하게 하는 추천할만한 방법 또한 설명합니다.
네트워크와 캐싱 설정하기
요청 큐는 동작을 하기 위해 요청 전달을 위한 네트워크와 캐싱을 위한 캐시 두 가지가 필요합니다. Volley의 toolbox에서 이 두 가지에 대한 표준 구현형을 사용할 수 있습니다.DiskBasedCache는 one-file-per-response 캐시를 메모리 인덱스와 함께 제공합니다. 그리고 BasicNetwork는 당신이 선호하는 HTTP 클라이언트에 근간한 네트워크 전송을 제공합니다.
BasicNetwork는 Volley의 기본 네트워크 구현형입니다. BasicNetwork는 반드시 애플리케이션이 네트워크와 연결되기 위해 사용하는 HTTP 클라이언트로 초기화되어야 합니다. 아랴의 경우 HttpURLConnection입니다.
아래의 예제는 요청 큐를 설정하는 과정에서 수반되는 과정들을 보여줍니다.
RequestQueue mRequestQueue;
// 캐시 초기화하기
Cache cache = new DiskBasedCache(getCacheDir(), 1024 * 1024); // 1MB 용량
// HttpURLConnection을 HTTP 클라이언트로 사용하기 위한 초기화입니다.
Network network = new BasicNetwork(new HurlStack());
// 초기화된 캐시와 네트워크로 요청 큐 초기화하기
mRequestQueue = new RequestQueue(cache, network);
// 큐 실행하기
mRequestQueue.start();
String url ="http://www.example.com";
// 요청을 구성하고 응답 처리하기
StringRequest stringRequest = new StringRequest(Request.Method.GET, url,
new Response.Listener<String>() {
@Override
public void onResponse(String response) {
// 응답과 관련된 어떠한 작업을 수행합니다.
}
},
new Response.ErrorListener() {
@Override
public void onErrorResponse(VolleyError error) {
// 수행 과정에서 오류가 발생할 때 처리합니다.
}
});
// 요청을 요청 큐에 추가합니다.
mRequestQueue.add(stringRequest);
// ...
만약에 한 번 진행될 요청을 만든다.면, 해당 쓰레드 풀에서 떠나고 싶지 않을 겁니다.'간단한 요청 보내기'에서 다룬Volley.newRequestQueue()로 필요한 어디서든 요청 큐를 만들고 응답을 받거나 오류가 전달 될 때 어디서나 stop()을 호출 할 수 있습니다. 하지만 더 일반적인 경우에 생명주기 전체에 걸쳐 작동하는 싱글톤 형태의 요청 큐를 만들게 됩니다. 해당 방법은 뒤에 이어집니다.
싱글톤 패턴 사용하기
애플리케이션이 네트워크를 계속해 사용한다면, 요청 큐의 단일 인스턴스(single instance)를 만들어 애플리케이션 생명주기 전체에 지속되도록 하는것이 아마 가장 효율적일 겁니다. 이는 다양한 방식으로 구현될 수 있습니다. 추천하는 접근법은 요청 큐와 다른 Volley의 기능을 캡슐화한 싱글톤 클래스를 적용하는 것입니다. 또 다른 접근법으로는 Application의 상속클래스를 만들어 Application.onCreate())에서 요청 큐를 설정하는 방법이 있습니다. 하지만 Application을 사용하는 방법은 지양되는 방법입니다. 왜냐하면 스태틱 싱글톤(static singleton)은 더욱 모듈적인 방법에서 동일한 기능성을 제공하기 때문입니다.
//일반적인 경우에 더이상 Application의 상속개체를 만들 필요가 없습니다. 대부분의 경우들에 있어서, 스태틱 싱글톤(static singleton)은 객체가 더욱 모듈적인 방법들에서 동일한 기능성을 제공하기 때문입니다. 만약에 싱글톤이 전역 컨택스트(global context, 예를 들면 브로드캐스트 리시버에 등록되는)를 필요로 한다면, Context.getApplicationContext())를 컨택스트(Context) 인자로 싱글톤이 getInstance() 메소드를 호출할 때 전달하면 됩니다.
핵심 컨샙은 요청 큐가 Activity의 컨택스트가 아닌, Application의 컨택스트를 이용해 초기화되어야 한다는 겁니다. 이 방식은 매번 액티비티가 재생성될(예를 들면, 사용자가 기기를 회전할 때) 때 마다 큐를 재생성하는 대신에, 애플리케이션의 생명주기 전체에 지속될 수 있도록 해줍니다.
아래의 예제는 요청 큐(Request Queue)와 이미지 로더(ImageLoader) 기능을 제공하는 싱글톤 클래스입니다.
public class MySingleton {
//스태틱의 싱글톤 인스턴스입니다.
private static MySingleton mInstance;
private RequestQueue mRequestQueue;
private ImageLoader mImageLoader;
private static Context mCtx;
private MySingleton(Context context) {
mCtx = context;
mRequestQueue = getRequestQueue();
mImageLoader = new ImageLoader(mRequestQueue,
new ImageLoader.ImageCache() {
private final LruCache<String, Bitmap>
cache = new LruCache<String, Bitmap>(20);
@Override
public Bitmap getBitmap(String url) {
return cache.get(url);
}
@Override
public void putBitmap(String url, Bitmap bitmap) {
cache.put(url, bitmap);
}
});
}
public static synchronized MySingleton getInstance(Context context) {
if (mInstance == null) {
mInstance = new MySingleton(context);
}
return mInstance;
}
public RequestQueue getRequestQueue() {
if (mRequestQueue == null) {
//만약 mRequestQueue가 없을 경우 새로 생성해 전달합니다.
//Application의 컨택스트를 사용하는 것이 중요합니다.
mRequestQueue = Volley.newRequestQueue(mCtx.getApplicationContext());
}
return mRequestQueue;
}
public <T> void addToRequestQueue(Request<T> req) {
getRequestQueue().add(req);
}
public ImageLoader getImageLoader() {
return mImageLoader;
}
}
아래의 예제는 싱글톤 클래스를 사용해 요청큐 작업을 하는 코드입니다.
// 요청 큐를 가져옵니다.
RequestQueue queue = MySingleton.getInstance(this.getApplicationContext()).
getRequestQueue();
// ...
// 요청 큐에 요청을 추가합니다.
MySingleton.getInstance(this).addToRequestQueue(stringRequest);