J2ME對話框選擇功能實現(xiàn)原理
這里向大家描述一下J2ME如何實現(xiàn)對話框選擇功能，在手機這么小的屏幕上開發(fā)使用，難點之一就是頻繁的屏幕切換。盡管midp2.0的UI部分已經(jīng)很豐富了，但這些UI部件都是基于事件回調(diào)的。
J2ME實現(xiàn)對話框選擇功能
在手機這么小的屏幕上開發(fā)使用，難點之一就是頻繁的屏幕切換。盡管midp2.0的UI部分已經(jīng)很豐富了，但這些UI部件都是基于事件回調(diào)的。這在處理大量的、基本的問答式交互時顯得力不從心。
本文實現(xiàn)了一個阻塞當(dāng)前線程的對話框，簡要地說，你可以運用諸如win32API中dialog函數(shù)那樣的方式來實現(xiàn)對話框并阻塞等待返回值，然后根據(jù)返回值執(zhí)行不同的處理。
疑問何在？
首先回顧一下midpUI的事件處理機制。有兩個要素：
1）首先UI部分由系統(tǒng)的一個線程負責(zé)維護。也就是說不能阻塞系統(tǒng)的事件處理要領(lǐng)。
2）事件處理運用的是一種回調(diào)機制。首先UI部件運用諸如setCommandListener之類的要領(lǐng)為自己注冊一個回調(diào)接口（其中的回調(diào)要領(lǐng)由用戶實現(xiàn)）；等到觸發(fā)了相應(yīng)事件就調(diào)用這個注冊好的接口的回調(diào)要領(lǐng)。
以下是一個實現(xiàn)了CommandListener的類的代碼片斷：
- Formf=newForm("Helloworld");
- f.addCommand(exit);
- f.setCommandListener(this);
可以想象基于事件回調(diào)的處理方式，在處理大量的、基本的問答式交互時顯得力不從心。你不得不為每一個僅僅是詢問要不要繼續(xù)的對話框而實現(xiàn)一個又一個類，或者處理一個復(fù)雜的回調(diào)函數(shù)。如果選擇后者，那么在一個又一個的if-else中處理不同邏輯事件的代碼片斷一定會煩死你。
較好的做法
這時候我們不免懷念一下win32Api中對話框函數(shù)的處理方式：
- intchoose=Dialog(title，type……);
- if(choose==OK){……}
- elseif(choose==Cancel){……}
這樣處理將會阻塞當(dāng)前線程，等待返回值，然后根據(jù)返回值執(zhí)行處理。這樣做很cool的原由就是在一個邏輯性很完整的任務(wù)中，你可以一次性在一個回調(diào)要領(lǐng)中完成所有邏輯，而不必為了問詢基本的YES/NO疑問而在不同的類中間跳來跳去。
如何在MIDP下實現(xiàn)
我們遇到的***個疑問來自于我們的要領(lǐng)必須要阻塞當(dāng)前線程等待返回值。也就是說，這個對話框不能在UI的回調(diào)中直接運行，比如commandAction中。處理辦法是將所有的事件處理都放到一個線程類中處理。（這是一點額外的負擔(dān)，但不可防止）。還好這個工作量不大，要想實現(xiàn)兩個對象之間的通信也不難。
第二個疑問是如何阻塞當(dāng)前的線程，我們祭出Java線程的三板斧之wait()/notifyAll()。我們可以指定一個信號量（初值false），當(dāng)其為false時阻塞當(dāng)前線程，在得到用戶通知后將信號量改為true，并喚醒線程。
下面看一下主要思路
【編輯推薦】
- 深入探究J2ME Hashtable實現(xiàn)原理
- J2ME中Font和Color的設(shè)置
- J2ME數(shù)據(jù)結(jié)構(gòu)中Hashtable和Vector的使用
- MotorolaJ2ME開發(fā)時需要注意的幾個細節(jié)
- Java2平臺J2SE、J2EE、J2ME三大版本的區(qū)別
