這裡向大家描述一下J2ME如何實現對話框選擇功能,在手機這麼小的屏幕上開發使用,難點之一就是頻繁的屏幕切換。盡管midp2.0的UI部分已經很豐富了,但這些UI部件都是基於事件回調的。
J2ME實現對話框選擇功能
在手機這麼小的屏幕上開發使用,難點之一就是頻繁的屏幕切換。盡管midp2.0的UI部分已經很豐富了,但這些UI部件都是基於事件回調的。這在處理大量的、基本的問答式交互時顯得力不從心。
本文實現了一個阻塞當前線程的對話框,簡要地說,你可以運用諸如win32API中dialog函數那樣的方式來實現對話框並阻塞等待返回值,然後根據返回值執行不同的處理。
疑問何在?
首先回顧一下midpUI的事件處理機制。有兩個要素:
1)首先UI部分由系統的一個線程負責維護。也就是說不能阻塞系統的事件處理要領。
2)事件處理運用的是一種回調機制。首先UI部件運用諸如setCommandListener之類的要領為自己注冊一個回調接口(其中的回調要領由用戶實現);等到觸發了相應事件就調用這個注冊好的接口的回調要領。
以下是一個實現了CommandListener的類的代碼片斷:
- Formf=newForm("Helloworld");
- f.addCommand(exit);
- f.setCommandListener(this);
可以想象基於事件回調的處理方式,在處理大量的、基本的問答式交互時顯得力不從心。你不得不為每一個僅僅是詢問要不要繼續的對話框而實現一個又一個類,或者處理一個復雜的回調函數。如果選擇後者,那麼在一個又一個的if-else中處理不同邏輯事件的代碼片斷一定會煩死你。
較好的做法
這時候我們不免懷念一下win32Api中對話框函數的處理方式:
- intchoose=Dialog(title,type……);
- if(choose==OK){……}
- elseif(choose==Cancel){……}
這樣處理將會阻塞當前線程,等待返回值,然後根據返回值執行處理。這樣做很cool的原由就是在一個邏輯性很完整的任務中,你可以一次性在一個回調要領中完成所有邏輯,而不必為了問詢基本的YES/NO疑問而在不同的類中間跳來跳去。
如何在MIDP下實現
我們遇到的第一個疑問來自於我們的要領必須要阻塞當前線程等待返回值。也就是說,這個對話框不能在UI的回調中直接運行,比如commandAction中。處理辦法是將所有的事件處理都放到一個線程類中處理。(這是一點額外的負擔,但不可防止)。還好這個工作量不大,要想實現兩個對象之間的通信也不難。
第二個疑問是如何阻塞當前的線程,我們祭出Java線程的三板斧之wait()/notifyAll()。我們可以指定一個信號量(初值false),當其為false時阻塞當前線程,在得到用戶通知後將信號量改為true,並喚醒線程。
下面看一下主要思路