저는 둘다 같은 리스너 이기 때문에
핸들러의 경우 기본 리시버를 이용하지만
커스텀 콜백은 함수하나하나 사용자의 맞게 만들어 주는 차이
밖에 없다고 생각합니다.
검색을 좀 해보니 커스텀으로 할경우 함수 실행중 뒤로가기 나 오리엔테이션 변경에 따른 예외처리시 커스텀 콜백은
불안하다고 하는데
솔직히 이해가 가지 않습니다.
누가 속시원하게 대답해주실 분 있으신가요
거기서 예를 든건 이런거더군요
void do(Handler handler){
new Thread(){
void run(){
Message message=handler.obtainMessage();
message.obj=new Result();
handler.sendMessage(message);
}
}.start();
}
Usecase of my custom CallBack class
public interface CallBack{
void onResult(Result result);
}
void do(CallBack callback){
new
Thread(){
void run(){
callBack.onResult(new Result());
}
}.start();
}
사실 이렇게 콜백 쓰는 경우가 없는지라 만약에
void do(Handler handler){
new Thread(){
void run(){
Message message=handler.obtainMessage();
message.obj=new Result();
handler.sendMessage(message);
}
}.start();
}
Usecase of my custom CallBack class
public interface CallBack{
void onResult(Result result);
}
void do(CallBack callback){
new
Thread(){
void run(){
String value = ""
value = new Result();(리턴이 문자열이라고 가정)
(이곳에서 예외처리)
callBack.onResult(
value);
}
}.start();
}
이렇게 하면 똑같은거 아닌가요?? 왜 핸들러가 더 안정적이라고 하는지 모르겠어요;; 알려주세요
NoBrain님 말씀하신 UI 핸들링을 할수 있느냐 없느냐에 따라
핸들러가 더 안정적이다 라는 말이 나온게 아닌가 싶습니다.
callBack.onResult( value);
onResult로 콜백된 함수내에서 UI핸들링을 하게 되면 Exception이 발생하게 됩니다.
핸들러를 통해서 가게 되면 콜백 받는 쪽에서는 이미 UI쓰레드 위에서 핸들링 하게 되죠.
위에 답변 주신 두분의 말씀 너무 감사드립니다.
말씀하신대로 UI쓰레드에 대한 핸들링은 당연히 문제 되는것은 인지하고있습니다.
해당 예제는 UI쓰레드를 대상으로 해당 장단점을 말하고 있는건지 .. 흠 보통 콜백함수를 쓰면 해당 콜백 받는 쪽에서 다시 핸들러로
보내주는게 당연하기에 그에 대한 콜백 단점을 말하기엔 문제 가 있어보여서
음. 일단 이 의견에 대한 궁금증이 나온것은 현재 통신 쓰레드를 받아올때 콜백 함수로 결과 값을 도출 해왔는데요
해당 예시를 근거로 콜백 함수 보다 기본 핸들러를 쓰는게 더 안전하다는 의견이 있어서 고민하던 중이였습니다.
UI쓰레드 말고는 없을 까요.. .흠 근거를 제시하면서 토론을 해야하는데 별다른 차이가 안보여서 원.. ㅎㅎ
UI 쓰레드에 대한 핸들링때문인것 같습니다.
굳이 차이를 들자면 메시지 큐잉 처리를 해주냐 안해주냐 차이같구요
콜백 함수로 결과를 받아왔을때는 큐잉 처리가 되어 있지 않기 때문에
동기화(락을 잡는 동기화 말고 A->B->C 같은 순서의 동기화) 같은것에 문제가 생길 가능성등이 있을수도 있고요.
핸들러라면 메시지를 send했을때 내부적으로 큐잉 처리를 해주니 콜백보다는 동기화를 쉽게 할수 있을것 같네요.
제로이드님 답변 감사합니다.~
다들 관심 갖아 주셔서 많은 도움 됐습니다.
사실 보편적으로 통신 모듈 사용할때 콜백으로 사용하기 때문에 이에 대한 핸들러와의 비교 문제 였는데요
사실상 큐잉 문제라면 콜백 사용할때 ID값으로 값을 구분하기 때문에 해결이 될 것 같아 문제는 없을 것 같구요 UI쓰레드에 대한
추가 작업 때문같은 경우도 보편적으로 콜백 받으면 핸들러로 다시 보내주고 있기 때문에 해당 콜백사용이 문제는 되지 않다는 생각입니다.
역시나 말씀해주신 대로 핸들러의 경우 기본적으로 지원하고 있다는 점과 콜백은 사용자가 예외처리를 해줘야한다는 장단점을
확인 한 것 같습니다.
궁금증을 풀어주셔서 대단히 감사합니다. ~ ^^
이미 한참이나 지나버려서 의미있는말이 될지는 모르겠습니다만
작성하신 콜백에서는 do 에서 구동한 쓰레드를 onResult()에서
return 하지 않는것으로 진행하지 못하게 할 수 있습니다.
하지만 Handler 를 이용하신경우 메시지큐에 전달할 메시지가 푸시된후 바로리턴하기때문에
do 에서 구동한 쓰레드를 잡을수 없습니다.
이부분이 안전성으로 연결 될수 있다고 봅니다.
물론 do 를 다시 쓰레드로 감쌀수 있지만
그건 콜백을 쓴다는 내용과는 다른 의미이므로 논외가 될것같습니다.
또 한가지는 헨들러를 이용하면 처리가 시리얼하게정리되므로
동기화에 대한 정리도 단순해지구요.
절대적으로 어떤게 좋다 나쁘다는 아니지만
클레스간 통신을 할때 헨들러를 이용하는것도 나쁘지 않아 보입니다.
제 경우는 모든 public 메쏘드가 내부적으로 Handler 를 호출 하게 하는 경우도 있습니다.




핸들러는 프레임워크단에서 UI 핸들링이 되도록 지원을 해줍니다.
그래서 좀 더 안정적이지요
이거는 핸들러가 어떻게 UI 쓰레드에 접근하는지를 이해하셔야 해요.
일반적인 Thread 에서도 신뢰성은 낮지만 핸들러가 UI 쓰레드에 접근하는 방식을 이용해서
우회적으로 UI 쓰레드에 접근 가능한 핸들러를 생성할 수 있기도 하지요
어쨋든...프레임워크에서 지원하냐 안하냐 차이라고 보시면 될 것 같네요..
그 이상은 저도 아는게 없는터라 - _-;