posted by By훈트 2011.01.24 20:35


내 클래스 내 마음대로!

 

 

[Intro]

 

어플리케이션, 특히 UI 프로그래밍을 하다 보면 메세지 처리 라는 녀석을 피할 수 없습니다.

예를 들어, 로딩 중에 '로딩 중' 이라고 알려 주는 다이얼로그를 표시하고 싶다고 할 때,

단순히 스레드로만 처리를 하면 서로 엉켜서 다이얼로그가 제대로 표시 되지 않을 때가 많지요.

그래서 아래와 같이 살짝 딜레이를 주게 되면 엉키는 것을 조금이나마 완화 시킬 수 있습니다.

Handler handler = new Handler();
handler.postDelayed(rShowDialog, 1000);

Handler는 이 뿐 아니라 UI Thread 실행 기능도 가지고 있죠.

스레드 여러개 사용해 보신 분들은 금방 아실겁니다.

 

위에서 Handler에 대해 잠깐 언급 하긴 했지만,

제가 여기서 다루고자 하는 것은 Handler가 뭐하는 것인지, 어떻게 사용하는 것인지가 아닙니다.

일단 Handler를 사용해 보신 분들을 대상으로 설명을 해 나갈 것이니,

그 점 양해 부탁 드립니다.

 

 

[흘러가는 메세지는 잡을 수 없다!] 

 

일단 Handler는 내부적으로 MessageQueue를 가지고 있습니다.

그래서 Handler로 무조건 적으로 메세지를 보내게 되면,

 

뭐... 쌓이겠죠.

 

하지만 이것은 어디까지나 물리적인 측면에서 볼 때 쌓이는 것입니다.

논리적인 측면에서 볼 때는 충분히 메세지를 놓칠 수 있습니다.

 

예를 들어 봅시다.

onDown 이벤트가 발생 한 뒤에 onSingleTapUp 이벤트가 발생 하는 상황을 살펴 보겠습니다.

보통 onDown - onSingleTapUp 이벤트가 발생 했다는 것은 한번 터치 했을 경우입니다.

그렇다는 것은 터치가 되는 대상이 존재 한다는 말이겠죠.

그럼, 이제 여기서 좀 더 세부적으로 살펴 보겠습니다.

 

터치가 되는 대상이 어떤 하얀색 사각형 '들' 이라고 했을때,

onDown 이벤트 시에는 어떤 사각형이 선택이 되었는지 검색을 하며,

onSingleTapUp 이벤트 시에는 선택된 사각형을 빨간색으로 만드는 일을 할 것입니다.

연결 동작으로 보면 터치 했을 때 선택된 사각형이 빨간색으로 변하게 되겠죠?

 

그런데 만약에 onDown 이벤트 시에 어떤 사각형이 선택이 되었는지 미처 찾기도 전에

onSingleTapUp 이벤트가 발생한다면 어떻게 될까요?

네... 물론 아무것도 변하지 않겠죠.

그렇게 되면 결과적으로 onSingleTapUp 이벤트는 아무것도 안하고 그냥 흘러가는 메세지가 됩니다.

 

물리적으로는 onDown 이벤트와 onSingleTapUp 이벤트 둘 다 발생 했지만,

논리적으로 봤을땐... 하나는 실패한 이벤트입니다.

마치 하드웨어에서 인터럽트가 많아지면 나중에 들어온 인터럽트는 무시당하는 경우와 비슷하죠.

 

그렇다면 위와 같은 경우에는 흘러가는 메세지를 그냥 보내야만 할까요?

잡아둘 방법은 없을까요?

 

 

[메세지를 흘러가지 못하도록 막자!]

 

이제부터 본격적으로 제가 하고싶은 이야기를 할 것입니다.

그림이 없어서 복잡할지도 모르겠지만, 최대한 잘 설명해 보겠습니다.

위에서 언급했던 onDown - onSingleTapUp 이벤트를 다시 한번 봅시다.

 

선택된 사각형을 찾았을 때 onRectangleFounded 메소드가 호출 되며,

onSingleTapUp 이벤트 안에서 선택된 사각형의 색을 바꾼다고 합시다.

 

그렇다면, 동작이 원하는데로 이루어지기 위해서는 아래와 같은 순서로 진행 되어야 합니다.

onDown - onRectangleFounded - onSingleTapUp - (선택된 사각형의 색이 변함)

하지만 만약 사각형을 찾는 시간이 onSingleTapUp 이벤트 보다 느리다면,

onDown - onSingleTapUp (색을 바꿀 사각형이 없음) - onRectangleFounded - (변화 없음)

 

onSingleTapUp 보다는

onRectangleFounded의 이벤트를 먼저 처리 해야 한다는 것을 다시 한번더 정리해 봤습니다.

항상 첫 번째의 가장 좋은 경우가 일어나면 괜찮은데,

두 번째의 경우가 일어나지 말라는 법은 없습니다. 보장 할 수 없죠.

그래서 한번 생각해 봤습니다. Lock을 걸면 되지 않을까...?

 

Lock을 걸어본다면 흐름은 아마 아래와 같을 것입니다.

onDown with Lock - onSingleTapUp (Lock에 의해 메세지가 실행 대기 상태가 됨) 
- onRectangleFounded with Unlock (대기 하고 있던 onSingleTapUp 메세지가 실행 됨)

onSingleTapUp 메세지는 Lock에 의해 Queue에 저장이 되고,

Unlock시에 Queue에 쌓인 메세지들을 실행 하면 되겠거니 하고 생각해봤습니다.

 

 

[Extends Handler]

 

우선 Handler를 extends 하기 위해서는 반드시 아래의 메소드를 구현 해야 합니다.

public void handleMessage(Message msg)
Subclasses must implement this to receive messages.

하지만 Handler에게 메세지를 보낸다고 해서

모두 handleMessage() 메소드에 들어가는것은 아닙니다.

 

 

다음으로, Handler에게 메세지를 보내는 방법은 여러가지 방법이 있습니다.

 

sendEmptyMessage Family of Handler class

public final boolean sendEmptyMessage(int what)
public final boolean sendEmptyMessageAtTime(int what, long uptimeMillis)
public final boolean sendEmptyMessageDelayed(int what, long delayMillis)

sendMessage Family of Handler class

public final boolean sendMessage(Message msg)
public final boolean sendMessageAtFrontOfQueue(Message msg)
public boolean sendMessageAtTime(Message msg, long uptimeMillis)
public final boolean sendMessageDelayed(Message msg, long delayMillis)

sendEmptyMessage는 내용 없는 메세지만, sendMessage는 실제 Message를 보냅니다.

어떤 메세지인가? 혹은 메세지에 데이터가 필요한가?에 따라서

유용하게 사용 할 수 있을 것입니다.

 

Message.sendToTarget()

메세지를 보내는 또 한가지 방법은

Message 객체의 sendToTarget() 메소드를 호출 하는 방법입니다.

Message 객체 안에 설정된 Target Handler에게 Message 객체 자신이 직접 보내지는 것이죠.

 

(Handler를 많이 써오시던 분들은 post Family를 많이 사용하셨을 겁니다.

post Family는 실행 가능한 Runnable을 직접 Message Queue에 넣는일을 하기 때문에

일단 여기서는 제외 시켰습니다.)

 

 

sendMessage를 하던 sendToTarget으로 자신을 직접 보내던,

중요한것은 Message 객체를 생성하는 일입니다.

Constructor를 사용하여 직접 Message 객체를 생성해도 되지만,

Message.obtain() 메소드나 Handler.obtainMessage() 메소드의 사용을 권장하고 있습니다.

 

Constructor로 만드는것과 obtain 메소드를 사용하는 것의 큰 차이는

obtain 메소드를 사용하면 재활용 될 객체를 pool에서 뽑아온다는 것이

큰 차이점이라고 볼 수 있습니다. 새로 만드는 것 보단 낫겠죠?

 

Message.obtain()과 Handler.obtainMessage() 메소드의 차이점은,

Handler.obtainMessage()의 경우 자동으로 Target Handler가

호출 하는 Handler로 정해진다는 것이 차이점입니다.

즉, Message.obtain() 메소드를 사용하면 Target Handler를 지정해 줘야 한다는 말과도 같겠죠.

 

Handler.sendMessage() 메소드와 Message.sendToTarget() 메소드,

Handler.obtainMassage() 메소드와 Message.obtain() 메소드,

이 중에서 마음에 드는 것으로 사용 하시면 되겠습니다.

 

 

[Implements LockableMessageHandler]

 

이제 실제로 구현에 대해서 살펴 보겠습니다.

앞서 이야기 했던 extends 방법을 조합하면 대충 머릿속에 그려지지 않나요?

 

더 앞서 이야기 했듯이,

제가 하고 싶은 것은 Lock일 때 메세지를 쌓고, Unlock일 때 쌓인 메세지를 실행 하는 것입니다.

그럼 Lock 상태와 Unlock 상태가 필요 하고, 메세지를 쌓아 둘 Queue도 필요 합니다.

 

이 점을 유념해서 한번 만들어 보겠습니다.

맨 처음으로 Handler를 상속받은 클래스를 만들고, handleMessage() 메소드를 Override 해줍시다.

public final class LockableMessageHandler extends Handler {
    @Override
    public void handleMessage(Message msg) { ... }
}

이제 Lock과 Unlock에 대한 메세지를 만들겁니다.

@Override
public void handleMessage(Message msg) {
    if(msg.what == 1) {
        isLocked true;
    }
    else if(msg.what == 2) { 
        isLocked false;
        
        // RUN!!!
        while(mRunnableQueue.size() > 0) {
            Runnable runnable = mRunnableQueue.poll();
            this.post(runnable);
        }
    }
    ...

Message.what은 사용자 정의 메세지 코드이며, integer 값입니다.

그래서 지금은 편의상 1과 2로 나눠 놨습니다.

 

메세지 코드 1번은 Lock 동작으로, isLocked 필드에 true 값을 세팅하기만 하고,

메세지 코드 2번은 Unlock 동작으로, isLocked 필드에 false 값을 세팅하고,

mRunnableQueue에 쌓여있던 Runnable 들을 모두 빼내어

Handler.post() 메소드를 통해 모두 실행하게 합니다.

 

여기까지는 제가 원하는 Lock과 Unlock 동작이 간단하게 구현 되어있습니다.

그럼 이제 Queue에 쌓는 메소드만 만들면 되겠군요!

@Override
public void handleMessage(Message msg) {
    ...
    else if(msg.what == 3) {
        Runnable callback = (Runnable) msg.obj;
        if(callback != null) {
            try mRunnableQueue.put(callback); }
            catch (InterruptedException e) { e.printStackTrace(); }
        }
    }
    ...
}

메세지 코드 3번은 매우 간단합니다.

Message.obj는 Message.obtain()을 통해 넘겨받은 Object 객체입니다. 

어떤 객체든 다 들어가지요~ 그래서 Message.obtain()을 통해

실행 하고자 하는 코드가 들어있는 Runnable 객체를 받은 뒤에,

무조건 mRunnableQueue에 쌓습니다.

 

이 코드는 지금 현재 Lock 여부에 상관 없이 무조건 쌓고,

Unlock 할 때 모조리 실행 되는 코드입니다.

근데 이런 동작은 뭔가... 좀 부족하죠~

 

그래서 좀 더 좋게 만들어 봤습니다!

@Override
public void handleMessage(Message msg) {
    ...
    else if(msg.what == 4) {
        Runnable callback = (Runnable) msg.obj;
        if(callback != null) {
            if(isLocked == false) { this.post(callback); }
            else {
                try mRunnableQueue.put(callback); }
                catch (InterruptedException e) { e.printStackTrace(); }
            }
        }
    }
}

메세지 코드 4번도 매우 간단합니다.

Message.obtain()을 통해 실행 하고자 하는 코드가 들어있는 Runnable 객체를 받은 뒤에,

만약 Lock 상태라면 mRunnableQueue에 쌓고, 아니면 그냥 Handler.post()로 실행 시켜줍니다.

 

이것도 참 별것 없는 코드네요...

하지만 3번 보다는 좀 더 나은 것 같습니다.

 

 

[Use LockableMessageHandler]

 

만들었으니 써봅시다!

앞서 이야기 했던 Message.obtain() 메소드를 사용하여 사용 할 수 있습니다.

일단 만들고...

LockableMessageHandler mHandler = new LockableMessageHandler();

아까 Lock이 1번이었죠? 그렇다면 이렇게 사용 할 수 있습니다.

Message.obtain(mHandler, 1).sendToTarget();
    -> Message.obtain(Handler h, int what)

귀찮으니 한줄에... 그리고 쌓는 동작은 3번이었죠?

Message.obtain(mHandler, 3, new Runnable() { ... }).sendToTarget();
    -> Message.obtain(Handler h, int what, Object obj)

이렇게 사용 할 수 있습니다.

 

 

[Complete Source]

 

클래스 밖에서 Message.obtain()을 호출해서 사용 할 수 도 있지만,

사실 클래스 안에서도 Message.obtain()을 호출해서 사용 할 수 있습니다.

그렇게 되면 코드가 한결 더 간결해 지겠죠~

 

그리하여 정리해 본 전체 소스 입니다.

 

public final class LockableMessageHandler extends Handler {
    // Fields
    private boolean isLocked;
    private ArrayBlockingQueue<Runnable> mRunnableQueue;
    
    private final int CODE_LOCK          = 1;
    private final int CODE_UNLOCK        = 2;
    private final int CODE_PUT           = 3;
    private final int CODE_PUT_IF_LOCKED = 4;
    
    // Constructors
    public LockableMessageHandler() {
        isLocked false;
        mRunnableQueue new ArrayBlockingQueue<Runnable>(100);
    }

    // Override Methods
    @Override
    public void handleMessage(Message msg) {
        if(msg.what == CODE_LOCK) {
            isLocked true;
        }
        else if(msg.what == CODE_UNLOCK) {
            isLocked false;
        
            // RUN!!!
            while(mRunnableQueue.size() > 0) {
                Runnable runnable = mRunnableQueue.poll();
                this.post(runnable);
            }
        }
        else if(msg.what == CODE_PUT) {
            Runnable callback = (Runnable) msg.obj;
            if(callback != null) {
                try mRunnableQueue.put(callback); }
                catch (InterruptedException e) { e.printStackTrace(); }
            }
        }
        else if(msg.what == CODE_PUT_IF_LOCKED) {
            Runnable callback = (Runnable) msg.obj;
            if(callback != null) {
                if(isLocked == false) { this.post(callback); }
                else {
                    try mRunnableQueue.put(callback); }
                    catch (InterruptedException e) { e.printStackTrace(); }
                }
            }
        }
    }

    // Handle Methods
    public void lock() {
        Message.obtain(thisCODE_LOCK).sendToTarget();
    }
    public void unlock() {
        Message.obtain(thisCODE_UNLOCK).sendToTarget();
    }  
    public void put(Runnable r) {
        Message.obtain(thisCODE_PUT, r).sendToTarget();
    }
    public void putIfLocked(Runnable r) {
        Message.obtain(thisCODE_PUT_IF_LOCKED, r).sendToTarget();
    }
}

깔끔하게 정리가 되었네요!

Handler를 extends 했기 때문에

평소에 쓰던 post(), postDelayed() 같은 메소드도 사용 가능합니다~

 

 

[Outro]

 

점점 내용도 난해해 지고 양도 많아지고 있습니다.

아무래도 기초지식 보다는 좀 Advance한 내용을 다루고자 하는 컨셉 때문인지도...

여튼 이 포스트에서 중점적으로 이야기 하고 싶은 것은

Handler를 원하는 대로 extends 하여 사용하는 방법입니다.

 

만약 Handler를 변경 하고자 하시는 분들에게 조금이나마 도움이 되었으면 합니다.

 

참고로 전 예전에 만들어 둔 AdvancedGestureDetectorWrapper와 함께

아주 잘~ 사용하고 있답니다. 으흐흐...

 

 

[Post Script]

 

이 내용에 대해 1월 부터 기획하고 있었는데 이제서야 마무리를 하게 됬습니다.

Nexus One이 튀어 나오는 바람에 리뷰를 한다고 설쳐대던 영향도 없지 않아 있었군요...

여튼 오래전 부터 쓰고 싶었던 포스팅을 마무리 하게 되어서 기분은 좋네요!

 

앞으로 더 난해한 내용들에 대해서 심도 있게 다루어 보고 싶은데...

시간이 별로 없군요...


[출처] 비즈페이님의 블로그

저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

티스토리 툴바