屏幕導(dǎo)航

除了游戲程序，在通常的MIDP應(yīng)用程序中，通常會(huì)有很多個(gè)Screen或Canvas，這些屏幕一般靠命令來實(shí)現(xiàn)切換，比如用戶點(diǎn)擊“Next”應(yīng)該跳到下一屏，點(diǎn)擊“Back”應(yīng)該返回到上一屏。當(dāng)屏幕數(shù)量相當(dāng)可觀時(shí)，如何在各個(gè)屏幕之間導(dǎo)航就值得好好考慮了。

經(jīng)典的MVC模式可用于屏幕導(dǎo)航，Model用于存儲(chǔ)應(yīng)用程序數(shù)據(jù)，而View則是各個(gè)Displayable對(duì)象，Controller需要單獨(dú)的一個(gè)類實(shí)現(xiàn)。由于MIDlet類本身在生命周期內(nèi)就只有一個(gè)實(shí)例，因此MIDlet類就非常適合作為Controller。SUN在bluePRints示例程序SmartTicket中應(yīng)用了非常復(fù)雜的MVC，完全可以滿足MIDP應(yīng)用程序的導(dǎo)航需要，但是可以看出，缺點(diǎn)是很明顯的：

一是每一個(gè)事件都需要一個(gè)唯一標(biāo)識(shí)，switch-case語句會(huì)隨著屏幕的增加而增加，Controller變得難以維護(hù)。二是Controller引用了所有的View，這些View在程序啟動(dòng)時(shí)就被初始化導(dǎo)致很大的內(nèi)存開銷，而不管它們是否會(huì)被顯示。三是大量的Model對(duì)象以及異常處理都使得整個(gè)應(yīng)用程序的邏輯大大復(fù)雜。

實(shí)際上，MIDP應(yīng)用程序的很多屏幕并不需要復(fù)雜的Controller和Model，我們的目標(biāo)是滿足基本的靈活性的同時(shí)保持結(jié)構(gòu)簡單。因此，另外兩種導(dǎo)航方法是用二叉樹和堆棧實(shí)現(xiàn)，這里我們只討論用堆棧實(shí)現(xiàn)的MIDP導(dǎo)航框架，其基本思想是：每當(dāng)前進(jìn)到下一個(gè)屏幕時(shí)，先將下一個(gè)屏幕壓棧，然后再顯示；當(dāng)返回到上一個(gè)屏幕時(shí)，先從堆棧中彈出當(dāng)前屏幕，再從堆棧中取出上一個(gè)屏幕并顯示。因此，每個(gè)屏幕只需要指定要顯示的下一個(gè)屏幕，而不需記住上一個(gè)屏幕。這種堆棧導(dǎo)航模型特別適合有規(guī)律的“前進(jìn)”、“后退”屏幕。

由于MIDlet類運(yùn)行期只有一個(gè)實(shí)例，因此，使用MIDlet類作為控制器相當(dāng)合適。此外，我們?cè)谝粋€(gè)靜態(tài)變量中保存了MIDlet實(shí)例，使得訪問MIDlet更加方便：

public class ControllerMIDlet extends MIDlet {
    private static ControllerMIDlet instance = null;

    private Display display = null;
    private Stack ui = new Stack();

    public ControllerMIDlet() { instance = this; }

    protected void startApp() {}
    protected void pauseApp() {}
    protected void destroyApp(boolean unconditional) {}

    public static void goBack() {
        instance.ui.pop();
        Object obj = instance.ui.peek();
        instance.display.setCurrent((Displayable)obj);
    }

    public static void forward(Displayable next) {
        instance.ui.push(next);
        instance.display.setCurrent(next);
    }
}

讓我們更詳細(xì)地研究一下實(shí)際的應(yīng)用程序可能出現(xiàn)的幾種屏幕跳轉(zhuǎn)情況。最簡單的情況是，從一個(gè)屏幕前進(jìn)到另一個(gè)屏幕，且返回時(shí)仍回到原先的屏幕，這種情況完全符合堆棧的FIFO特點(diǎn)，可以直接調(diào)用ControllerMIDlet的forward和goBack方法即可。例如，要顯示一個(gè)幫助屏幕：

對(duì)于一個(gè)聯(lián)網(wǎng)的應(yīng)用程序，另一種情況是有一個(gè)暫時(shí)的等待屏幕。下面是一個(gè)在線瀏覽圖片的屏幕：

與上面的情況所不同的是，如果用戶在屏幕3選擇“返回”，則應(yīng)當(dāng)回到屏幕1而不是屏幕2，因此，對(duì)于屏幕2到屏幕3的切換，就不能forward，我們使用replace，拋棄屏幕2，從而實(shí)現(xiàn)屏幕3直接可以goBack到屏幕1：

public static void replace(Displayable next) {
    instance.ui.pop();
    instance.ui.push(next);
    instance.display.setCurrent(next);
}

堆棧的變化如下：

對(duì)于某些更為復(fù)雜的情況，例如，登錄過程，如果允許用戶選擇自動(dòng)登錄，則屏幕跳轉(zhuǎn)如下：

如果用戶不選擇自動(dòng)登錄，則屏幕跳轉(zhuǎn)如下：

對(duì)于這種情況，解決方案是，即使用戶選擇了自動(dòng)登錄，LoginUI屏幕也要被壓入堆棧中，但是不顯示出來，因此，我們定義了另一個(gè)forward(Displayable d1, Displayable d2)方法，它將d1和d2依次壓入堆棧，但只顯示d2。在返回時(shí)，如果用戶取消，則返回到LoginUI。總之，通過定義多個(gè)導(dǎo)航方法，就可以實(shí)現(xiàn)各種操作。

這種基于堆棧的導(dǎo)航模型非常適用于有規(guī)律的“前進(jìn)”，“后退”屏幕，而且只在需要的時(shí)候生成新的屏幕。無需關(guān)心屏幕狀態(tài)，因?yàn)榉祷貢r(shí)上一個(gè)屏幕的狀態(tài)被完整地保存在堆棧中。

堆棧模型的缺點(diǎn)是數(shù)據(jù)由不同的屏幕處理，對(duì)于一些流程而言，可能需要將每個(gè)屏幕的數(shù)據(jù)依次傳遞給下一個(gè)屏幕，越往后的屏幕其構(gòu)造方法的參數(shù)可能也越多。

對(duì)于聯(lián)網(wǎng)操作等涉及到多線程等待屏幕的情況，我們將在后面給出一個(gè)完整的解決方案，并集成到堆棧導(dǎo)航框架中，使應(yīng)用程序本身完全不用涉及到多線程聯(lián)網(wǎng)操作，只需專注于自身邏輯。

（出處：http://m.survivalescaperooms.com）