J2ME學習過程中的一點心得整理

關於MIDlet的生命週期
當MIDlet被應用程式管理器成功地初始化之後，就開始展開了它的生命週期。

基本上MIDlet有三個狀態：停止狀態（Paused），啟用狀態（Active）和消滅狀態（Destroyed）。

MIDlet的生命週期完全由應用程式管理器控制，只有當應用程式管理器認為MIDlet的狀態必須改變時，才會調用相關函數。

MIDlet一開始一定是先進入停止狀態，然後應用程式管理器再將他轉換為啟用狀態，然後調用startApp（）。

以啟用狀態來說，應用程式管理器先將MIDlet轉換為啟用狀態，然後才調用startApp（）。而應用程式管理器會先調用pauseApp（）或destroyApp（），然後再將MIDlet轉換為停止狀態或消滅狀態。這就是Active沒有被動式（字尾沒有加ed），而Paused和Destroyed都是被動式（字尾加ed）的真正涵義。

如果MIDlet自己調用這些函數，通常不會發生錯誤，但是也不會造成狀態的改變（MIDlet的生命週期完全由應用程式管理器控制），只能當成一個單純的函數調用而已。

startApp（）每次從停止狀態重新回到啟用狀態的時候都會被應用程式管理器調用。所以只需要被初始化一次的動作就不適宜放在startApp（）中，應該用建構函式做初始化動作。

除了由應用程式管理器來控制MIDlet的生命週期之外,MIDlet本身也可以軟性的決定自己的狀態,但是不是自己來改變自己的狀態,而是MIDlet先調用相對應的請求狀態改變函數（resumeRequest（）－－請求啟用，notifyPaused（）－－通知停止，notifyDestroyed（）－－通知消滅），這些函數會嚮應用程式管理器發出訊息，請它來協助改變狀態，但是決定權在應用程式管理器，不保證一定可行。

由MIDlet自己調用請求狀態改變函數與應用程式管理器要求改變狀態，兩者是不一樣的。

以停止狀態為例：應用程式管理器要求停止時，pasueApp（）會調用，而MIDlet調用notifyPaused（）時，pauseApp（）不會被調用，但是兩者都會使MIDlet進入停止狀態，所以再MIDlet自己調用notifyPaused（）時最好也先調用pauseApp（）比較合適。同樣的情況也發生在notifyDestroyed（）和destroyApp（）。除非是系統強制關閉MIDlet，否則最好MIDlet先調用destroyApp（），再調用notifyDestroyed（），請應用程式管理器幫我們將MIDlet轉到消滅狀態，最後結束MIDlet的運行。單單MIDlet自己調用destroyApp（）是沒用的。

從這裡我們可以看出startApp（），pauseApp（）以及destroyApp（）並非控制MIDlet生命週期的函數，它們只是一個提供我們初始化資源釋放資源的地方而已！