android 疑難雜症 android api (82) —— InputConnection [輸入法] android在學習——activity關閉和dialog.dismiss衝突的解決(Ac

解決AndroidSQLite-close()was never explicitly called on database異常

這個異常的拋出並無讓程序崩潰。

　　　　這些異常信息來源於SQLiteDatabase類的finalize方法。從異常的信息＂close() was never explicitly called on database ，Application did not close the cursor or database object that was opened here
＂能夠知道這是因爲程序中使用到的遊標或SQLiteDatabase對象沒有close所致使。也就是說在程序中建立的Cursor對象或者SQLiteDatabase對象，在使用完後沒有關閉，而當它們都變成「垃圾"被ＧＣ時，就會打出以上的信息。

android.database.sqlite.DatabaseObjectNotClosedException: 

因此要想不發生這樣的錯誤，在編碼時必定要記住，當你不在使用Cursor或SQLiteDatabase對象時，將它們close()。

 

 

 慎用AsyncTask

Current thread has not called Looper.prepare(). Forcing synchronous mode

不氣不餒，根據現象3，又腦洞大開，想是不是AsyncHttpClient同步網絡請求時，因爲非Looper線程，致使回調執行是在UI線程中，形成了UI線程的阻塞？想到就作，我直接將AsyncTask改爲IntentService實現，試了下，不卡頓了，oh yeah！但同時引入新的問題，通信錄的操做沒執行，想了下，it's nothing, Service組件是要聲明在AndroidManifest.xml中的，試了下，兩個問題都完美解決！

 若是止步於此，那就太low了，看了下AsyncHttpResponseHandler的代碼，發現若是在非Looper線程中執行，那回調的代碼就在執行網絡請求（HttpClient.execute()）的線程中執行。並且，我用的是同步請求，網絡請求直接在發起網絡請求（AsyncHttpClient.post()）的線程中執行。也就是網絡請求、網絡請求的回調處理都是在AsyncTask的doInBackground()的線程中執行的。也就不存在回調在UI線程執行，形成UI線程阻塞的問題。

，google下"慎用AsyncTask"，隨便打開幾篇文章，第一個坑：AsyncTask在Android各個版本中能夠算是頻繁修改了，比較各版本代碼發現，修改過屢次，並且這種修改會致使很大的差異。最坑的修改是在Android 4.0開始的，AsyncTask的中execute方法的實如今4.0之前是採用Thread pool executor，各個版本對線程池中的可並行線程數限制不一樣，但畢竟多個Task是多線程並行。而在4.0開始，改成用serial executor，就是說同一時間只能有一個線程運行，其餘線程必須等待該線程完成以後才能開始執行，所以就變成了串行的worker thread。」 「三、串行和並行多版本不一致 AsyncTask在1.6以前爲串行，在1.6-2.3爲並行，在3.0以後又改成串行，在3.0以後雖然能夠經過代碼來改變默認的串行爲並行，可是又是一個繁瑣的操做」。

Can't create handler inside thread that has not called Looper.prepare()解決辦法

Message msg = new Message();       

msg.what = ID_USER;  

mHandler.sendMessage(msg); // 向Handler發送消息,更新UI  

 

Message msg = new Message();       

msg.what = ID_USER;  

 mHandler.sendMessage(msg); // 向Handler發送消息,更新UI   

android api (82) —— InputConnection [輸入法]

public abstract boolean finishComposingText ()

　　強制結束文本編輯器，不管聯想輸入(composing text)是否激活。文本保持不變，移除任何與此文本的編輯樣式或其餘狀態。光標保持不變。

android在學習——activity關閉和dialog.dismiss衝突的解決(Activity has leaked window com.android.internal.policy.impl.PhoneWindow)

其意思大概就是：窗體已經關閉了可是dialog仍然在顯示，Activity has leaked window（activity滲透出窗體），大概就是這個意思。那麼就要在activity finish()以前將dialog dismiss()掉。

protected void onDestroy() {
        // TODO Auto-generated method stub
        try{
            myDialog.dismiss();
        }catch (Exception e) {
            System.out.println("myDialog取消，失敗！");
            // TODO: handle exception
        }
        super.onDestroy();

關於android.view.WindowLeaked(窗體泄露)的解決方案

android.view.WindowLeaked通常會發生在Activity 與Dialog的顯示。
       Activity 中create 一個Dialog，若你先關閉Dialog再關閉Activity就是正常的，若你先關閉Activity再關閉Dialog就會報錯這個android.view.WindowLeaked錯誤了。
       分析這個緣由是：Dialog是基於Activity而建立的：new ProgressDialog(this)；this 就是Activity。 Activtity先finish,那Dialog就沒得依附了，因此就會報android.view.WindowLeaked。

Android 開發 對話框Dialog dismiss和hide方法的區別

dismiss和hide方法均可以隱藏對話框，在須要的時候也能夠用show方法調用顯示。可是，這二者是有區別的。

dismiss方法會釋放對話框所佔的資源，而hide方法不會。activity退出前必須調用dismiss方法關閉對話框。若是對話框上有progressbar,你會發現，調用dismiss方法後，再調用show方法，出來的對話框，上面的progressbar再也不會轉動，而調用hide方法的則沒有問題。因此，最正確的調用方法是，在activity的onDestory方法裏調用dismiss方法，其餘地方都用hide方法隱藏對話框。