J2ME中怎么實現(xiàn)對話框選擇功能

這期內(nèi)容當(dāng)中小編將會給大家?guī)碛嘘P(guān)J2ME中怎么實現(xiàn)對話框選擇功能，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

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)的一個線程負(fù)責(zé)維護(hù)。也就是說不能阻塞系統(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中。處理辦法是將所有的事件處理都放到一個線程類中處理。（這是一點額外的負(fù)擔(dān)，但不可防止）。還好這個工作量不大，要想實現(xiàn)兩個對象之間的通信也不難。

第二個疑問是如何阻塞當(dāng)前的線程，我們祭出Java線程的三板斧之wait()/notifyAll()。我們可以指定一個信號量（初值false），當(dāng)其為false時阻塞當(dāng)前線程，在得到用戶通知后將信號量改為true，并喚醒線程。

下面看一下主要思路

上述就是小編為大家分享的J2ME中怎么實現(xiàn)對話框選擇功能了，如果剛好有類似的疑惑，不妨參照上述分析進(jìn)行理解。如果想知道更多相關(guān)知識，歡迎關(guān)注億速云行業(yè)資訊頻道。