經典的mvc模式可用於螢幕導航，model用於儲存應用程式資料，而view則是各個displayable物件，controller需要單獨的乙個類實現。由於midlet類本身在生命週期內就只有乙個例項，因此midlet類就非常適合作為controller。sun在blueprints示例程式smartticket中應用了非常複雜的mvc，完全可以滿足midp應用程式的導航需要，但是可以看出，缺點是很明顯的：
一是每乙個事件都需要乙個唯一標識，switch-case語句會隨著螢幕的增加而增加，controller變得難以維護。二是controller引用了所有的view，這些view在程式啟動時就被初始化導致很大的記憶體開銷，而不管它們是否會被顯示。三是大量的model物件以及異常處理都使得整個應用程式的邏輯大大複雜。
實際上，midp應用程式的很多螢幕並不需要複雜的controller和model，我們的目標是滿足基本的靈活性的同時保持結構簡單。因此，另外兩種導航方法是用二叉樹和堆疊實現，這裡我們只討論用堆疊實現的midp導航框架，其基本思想是：每當前進到下乙個螢幕時，先將下乙個螢幕壓棧，然後再顯示；當返回到上乙個螢幕時，先從堆疊中彈出當前螢幕，再從堆疊中取出上乙個螢幕並顯示。因此，每個螢幕只需要指定要顯示的下乙個螢幕，而不需記住上乙個螢幕。這種堆疊導航模型特別適合有規律的「前進」、「後退」螢幕。
由於midlet類執行期只有乙個例項，因此，使用midlet類作為控制器相當合適。此外，我們在乙個靜態變數中儲存了midlet例項，使得訪問midlet更加方便：
讓我們更詳細地研究一下實際的應用程式可能出現的幾種螢幕跳轉情況。最簡單的情況是，從乙個螢幕前進到另乙個螢幕，且返回時仍回到原先的螢幕，這種情況完全符合堆疊的fifo特點，可以直接呼叫controllermidlet的forward和goback方法即可。例如，要顯示乙個幫助螢幕：
與上面的情況所不同的是，如果使用者在螢幕3選擇「返回」，則應當回到螢幕1而不是螢幕2，因此，對於螢幕2到螢幕3的切換，就不能forward，我們使用replace，拋棄螢幕2，從而實現螢幕3直接可以goback到螢幕1：
public static void replace(displayable next)
堆疊的變化如下：
對於某些更為複雜的情況，例如，登入過程，如果允許使用者選擇自動登入，則螢幕跳轉如下：
如果使用者不選擇自動登入，則螢幕跳轉如下：
對於這種情況，解決方案是，即使使用者選擇了自動登入，loginui螢幕也要被壓入堆疊中，但是不顯示出來，因此，我們定義了另乙個forward(displayable d1, displayable d2)方法，它將d1和d2依次壓入堆疊，但只顯示d2。在返回時，如果使用者取消，則返回到loginui。總之，通過定義多個導航方法，就可以實現各種操作。
這種基於堆疊的導航模型非常適用於有規律的「前進」，「後退」螢幕，而且只在需要的時候生成新的螢幕。無需關心螢幕狀態，因為返回時上乙個螢幕的狀態被完整地儲存在堆疊中。
堆疊模型的缺點是資料由不同的螢幕處理，對於一些流程而言，可能需要將每個螢幕的資料依次傳遞給下乙個螢幕，越往後的螢幕其構造方法的引數可能也越多。
對於聯網操作等涉及到多執行緒等待螢幕的情況，我們將在後面給出乙個完整的解決方案，並整合到堆疊導航框架中，使應用程式本身完全不用涉及到多執行緒聯網操作，只需專注於自身邏輯。
J2ME程式設計最佳實踐之靈活的RMS應用
midp應用程式的標準持久化方案就是使用rms。rms類似於乙個小型資料庫，recordstore相當於資料庫的表，每個 表 由若干記錄 record 構成，一條記錄就是乙個用int表示的記錄號recordid和用byte表示的內容。記錄號可以看作是 主鍵 byte陣列儲存內容。rms提供的記錄操作...
J2ME手機程式設計的啟示
最近空閒的時間學了一下遊戲程式設計，感覺還是很有意思。看了很多 後才發現很多東西的不變的 1.對作業系統的了解 不了解作業系統也可以程式設計序，但是，也許在效率上也許會有點的偏差。同時對執行緒的理解也是編好遊戲的關鍵。2.物件導向程式設計 理解設計模式，框架會對我們理解遊戲程式設計有很大的用處，如何...
J2ME經驗總結之漢字轉拼音
在網上參考了一些漢字轉換到拼音的資料。思路應該只有以下兩種。1，查表法。這樣做需要乙個龐大的對映表，在j2me環境下不大合適。不過效果好，有些還支援多音字。2，使用gb字型檔的對映關係。因為gb2312及其擴充套件gbk的漢字編碼都根據區位於拼音存在對映關係。實際上網路上的大部分文章都是根據第二種方...