코모스튜디오

asyncTask를 연속으로 사용할 때 어떤 문제점이 발생 할까? 1. 만약, 1개의 비동기 태스크를 사용한다고 가정 하자.2. 비동기 태스크가 사용자에 의해 계속 호출 된다고 하자.3. 비동기 태스크는 할 일을 다하고 onPost에서 마지막 할일을 마쳐 준다.4. 무슨 문제가 있나? 5. 원래 비동기 태스크의 결과는 항상 onPost에서 얻어오기를 희망 한다. 6. 하지만... 연속으로 비동기태스크를 돌리게 되면 섞이는 경우가 발생한다.7. A가 처음 태스크, B를 두 번째 태스크라고 하자.8. A가 돌고 있는데 B를 실행 했다. 9. A의 onPost가 실행되고 A는 마무리 짓는다. 이것이 정상이다. 하지만10. B가 실행되면서 A의 onPost 이전에 실행 된다. 즉, 끼어든다.11. 하지만.. A..

안드로이드 리스트의 경우에는 간단히 list.setSelector를 해주면 아이템 클릭 효과를 줄 수 있다. 뿐만 아니라 Preference에서도 비슷하게 사용 할 수 있는데, getListView를 한 뒤 리스트처럼 사용하면 아이템 클릭시 효과를 얻을 수 있다. 하지만 언제나 어려운 문제는 발생하는 법. 만약 Preference를 오버라이드(Override)한 다면 어떻게 처리 해야 할까? 오버라이드를 했으니 메인 프리퍼런스 액티비티가 어찌 손을 쓸 수도 없고... 오버라이드한 프리퍼런스에서 getListView를 하기도 그렇고... 그럼 도데체 이 리스트 아이템을 어떻게 가져 올 거냐? 여기 저기 검색을 해봐도 오버라이드 되지 않은 프리퍼런스의 아이템에 대한 얘기 밖에 없다. 그럼... 어차피 새로 ..

안드로이드 AsyncTask를 전역으로 쓴다면? 즉, 재활용 하겠다는 의미인데 가능 할까? 불가능하다! 만약 한 번 쓴 비동기 태스크를 재 활용 하려고 하면 아래문구를 보게 될 것이다. java.lang.IllegalStateException: Cannot execute task: the task has already been executed (a task can be executed only once) 즉, 변수 이름은 재활용이 가능 하지만 다시 쓰려면 새로 할당을 받으라는 것이다. 당연한 것 아니겠나? 얼음 얼리는 통을 사서 물을 채우고 얼음을 얼려서 먹었는데, 다음 번에 얼음을 먹으려면 당연히 물을 다시 부어서 넣고 기다려야 먹을 수 있지 않겠는가? 그 당시 얼음 통과 얼음은 그 당시의 내 위장 속..

일반적으로 뷰 속에 버튼등을 넣을 수 있다. 그리고 이 뷰를 오버라이드 하면 새로운 커스텀 뷰를 만들수도 있다. 그러나 조심해야 할 점이 있으니... 뷰는 닫히면 사라진다. 만약 닫을 때 제거 하지 않으면 다음에 열 때 '니 자식의 애비가 살아 있으니 애비를 저리 치우고 다시 나와라'라는 말을 듣게 될 것이다. 즉, 무조건 제거를 해주어야 하는데 여기서 문제가 발생한다. 비동기 태스크가 문제다... 얘는 뷰가 닫혀도 언제든 갑자기 툭하고 나와서 실행 될 수 있다. 해당 클래스에 있다고 무심결에 이 뷰를 불러다 쓰면 죽느다. 이건 문제가 참 쉽다. 하지만 뷰 속에 있는 아이템을 불러다 쓰면 살아 있을 수도 있다. 뷰만 제거 하고 속 살은 제거 하지 않았기 때문에 아직 가비지 청소가 되지 않았다면 속살은 살..

BackgroundResource를 asyncTask에서 사용할 때는 반드시 onPostExecute 또는 onProgressExcute 에서 사용 하도록 하자. doInBackground에서 사용 할 경우에는 시스템이 스레드를 돌면서 BackgroundResource를 해결 하러 다니는데... 따로 스레드를 돌려서 사용하면 죽는다. 시스템이 하는 일은 스레드에서 하지 말자. 아빠가 하는일은 아빠가 하도록 하자.

안드로이드 브로드캐스트 리시버에서 하지 말아야 할 것들... 일단 생각 나는 것부터 적어 보자. 1. 프로그래스 다이얼로그를 쓰지 말자. 2. asyncTask를 쓰지 말자. android.view.WindowManager$BadTokenException: Unable to add window -- token null is not for an application 둘 다 위와 같은 에러가 난다. 왜냐? 브로드 캐스트는 시스템 스레드에서 도는데 1, 2번은 UI 스레드에서 돌기 때문이다. '결국, 너는 누구냐?' 가 된다

브로드캐스트를 날리면 티켓을 끊어 놓은 리시버가 무조건 받겠지 하고 생각 할 수도 있지만, 회사 내부 사정으로 티켓을 취소 해버리는 경우도 발생 할 수 있다는 점도 알고 있어야 한다. 리시버에 등록 해놓으면 OS가 기억 하고 있다가 보낼 시간이 되거나 보낼 타이밍이 되면 브로드캐스트를 날린다. 하지만 OS도 내부적으로 바쁘거나 여타 기타 사정으로 브로드캐스트 메시지에 유효기간을 정해 놓았을 경우가 발생 할 수도 있다. 즉, 분명 어떠한 순간에는 이 메시지를 놓칠 수도 있다는 거다. 그럼 어떻게 해야 할까? 어떻게?? public class InitReceiver extends BroadcastReceiver { @Override public void onReceive(final Context contex..

UI 가 있는 곳에서 스레드 작업을 조금 길게 하면 화면에 버벅거리면서 아예 멈추는 경우도 발생한다. 하지만 스레드 대신 AsyncTask를 사용하면 이런 현상을 말끔히 해결해준다. class MainForReadyInitAsyncTask extends AsyncTask { @Override protected void onPostExecute(Void result) { // 작업이 완료 된 후 할일 super.onPostExecute(result); } @Override protected void onPreExecute() { // 작업을 시작하기 전 할일 super.onPreExecute(); } @Override protected Void doInBackground(Void... params) { /..