Читаем Платформа J2Me полностью

Блок прослушивания регистрируется с и получает уведомления от Displayable, а не от источника события (такого, как клавиша кнопочной панели). Поэтому блок прослушивания должен идентифицировать и «выбрать» команду, в которой он заинтересован, среди всех возможных Command, связанных экраном, отображаемым в настоящее время.

Вы, программист, должны убедиться, что вы должным образом связали поведение какого-либо блока прослушивания с должными Command. Вы должны использовать ин-. формацию, доступную в объекте Command, для ясной идентификации Command.

Чтобы исправить ошибку в последней версии программы, я переписываю метод commandAction () в классе MyCommandListener, как показано в листинге 4.2.

Листинг 4.2. Блок прослушивания команд теперь различает команды, исследуя их метки

if (c == showAlert)

{

alert = new Alert("Button pressed", «The» + ALERT_LABEL +

" button was pressed", null, AlertType.INFO);) else if (c == sayHi)

alert = new Alert("Button pressed", «The» +

"'Say Hi' button was pressed", null, AlertType.INFO);

}

alert.setTimeout(Alert.FOREVER); display.setCurrent(alert, form);

}

Здесь все еще только один CommandListener на Screen — и может быть только один. Его метод commandAction () вызывается в ответ на нажатие любой клавиши. Но теперь он проверяет контекст уведомления объекта Command и выдает различные уведомления соответственно.

Экранная навигация

Пример HelloWorld2 демонстрирует центральную абстракцию MIDP — Screen. Вы, несомненно, уже обратили внимание, что. можете отображать одновременно только один Displayable — один Screen. Когда приложению необходимо отобразить Alert, ему приходится заменять основной экран.

Причина этой одноэкранной абстракции кроется в ограниченности экранных ресурсов устройства. В отличие от инструментов графических пользовательских интерфейсов для настольных компьютеров, таких, как J2SE Swing toolkit, вы не можете иметь большое количество накладываемых друг на друга окон, всплывающих уведомлений, диалоговых окон и так далее. Хотя внедрение этих абстракций и не невозможно, требования памяти и ЦП на современных мобильных устройствах таковы, что фактически запрещают это. Более того, жидкокристаллические дисплеи с низким разрешением, низким потреблением энергии и маленькой площадью, характерные для большинства мобильных устройств, не приспособлены для этих абстракций. Даже дисплеи «карманных компьютеров» имеют минимально приемлемые характеристики для наложения окон, всплывающих окон и тому подобного. Однако очень вероятно, что примерно через год эти устройства будут иметь значительно большие мощности, порядка 50 МГц и 32 Мб RAM.

Существует простая идиома экранной навигации, связанная с этой абстракцией экранов дисплея. Если вы хотите отобразить новый экран, просто установите, что экран является отображаемым в настоящий момент (current displayable). Чтобы сделать это, вы запрашиваете. объект Display вашего MID-лета на отображение Screen. Вспомните, в главе 2 вы узнали, что каждому MID-лету при запуске присваивается уникальный объект Display реализацией MIDP. Вы никогда не создаете объект Display, но вы можете получить ссылку на него, сделав следующий вызов со ссылкой на ваш MID-лет как на аргумент: Display.getDisplay(midlet);

Затем вы просто делаете вызов метода, показанный далее, с аргументом, который ссылается на Displayable, который вы хотите отобразить:

Вы можете найти эти две строчки кода в методе startApp() обеих версий приложения HelloWorld.

Разработка навигации и перемещений в вашем МЮ-лете включает следующие этапы:

1. Создание экранов.

2. Создание команд, которые вам нужны для каждого экрана.

3. Присвоение команд экранам.

Для каждой команды каждого экрана определите следующий экран для отображения результата выполнения каждой команды.