Zvers, После того, как на объект теряется ссылка, он считается мусором. Следовательно твое предложение даже хуже, чем первое, динамическое

Нашел очень хорошую статью про оптимизацию J2ME приложений.

aNNiMON (06.02.2011/11:24)
Нашел очень хорошую статью про оптимизацию J2ME приложений.aNNiMON [i] [16.01.11 17:53]
* - Не перестараться, а то прога будет маленькой и глючной)
[ответить] [жалоба] [удалить]
У мя эти статьи в пдф были. Они с какой-то конференции.

ух ты спасибо! +

Я вот нашол сколько ставить паузу в игре.
Тестируя на эмуляторе ставлю Thread.sleep(20),результат хороший,но у меня на реальном телефоне это слишком медленно... а у когото на мошьном мобильнике всё слишком быстро двигается и играть невозможно.
Вот моё решение как контролировать fps.

Бывает к примеру, когда во время игры вам позвонили или пришло смс. То когда вы возвращаетесь в игру если ее написал непрофессиональный программист, то она начинается с нуля. Я расскажу вам как сделать фильтр, чтобы после того как вы ответили/завершили вызов мидлет продолжился. Главный класс midlet имеет 3 метода : startApp, pauseApp и destroyApp. Когда вам позвонили автоматически вызывается метод pauseApp, когда вы закончили то снова startApp. Но если у вас в startApp написано например:
canvas canvas = new canvas();
display.setCurrent(canvas);
то если после паузы заново вызовется startApp то canvas создастся 2 раз и его текущее состояние аннулируется. По этому мы:
инициализируем булеан например private boolean fc = false;
и в методе startApp ставим фильтр:

public static startApp();
{
if (!fc) {
canvas canvas = new canvas();
fc = true;
}
display.setCurrent(canvas);
}

теперь если приложение запустится 1 раз то поставит fc на true а если этот метод запустится 2 раз то если параметр fc будет true то метод просто передаст управление canvas и он дальше будет продолжать работать.
вроде все

nitsu, так вот оно что... А я всё ломал голову, почему на Nokia такие проблемы.

Предлагаю два варианта:

Не только Нокиа. Последние Семены, Флай. Это с чем сам сталкивался

Маленькое исправление (из личного опыты):
Метод setCurrent(canvas) достаточно вызвать в startApp() один раз. При сворачивании приложения текущий Displayable некуда не улетучивается. Он как был в памяти приложения на экране, так там и остался. Если только в методах pauseApp() или destroyApp() будет смена текущего кьюрента, тогда надо будет выводить каждый раз canvas при вызове startApp()'а.