Автор неизвестен - Платформа J2Me

На рисунке 4.4 показан главный экран HelloWorld2. Обратите внимание, что теперь справа появилась экранная клавиша под названием «Alert Me». На этом устройстве недостаточно места, чтобы показать полное сообщение «Alert Me!», которое установлено в исходном коде — так что восклицательный знак пропущен.

Это первая проблема транспортабельности, с которой вы столкнулись, и она имеет практическое значение. К счастью, эмулятор поддерживает четыре различных устройства. Вы можете выполнить ваши MID-леты с помощью любого из четырех эмуляторов устройств, поддерживаемых эмулятором J2ME Wireless Toolkit Emulator, чтобы посмотреть, как они выглядят на каждом. Таким образом вы можете обнаружить множество потенциальных проблем, связанных с транспортабельностью.

Рисунок 4.3.Добавление нового MID-лета к набору приводит в резул: тате к тому, что AMS отображает меню, из которого вы выбираете приложение, которое хотите запустить

Рисунок 4.4. Основной экран MID-лета HelloWorld2

Ha рисунке 4.5 показан основной экран HelloWorld2, как он появляется при имитировании устройства Motorola i85s. Обратите внимание, что в отличие телефона со стандартными настройками, он способен отображать полный текст команды на экранной клавише. Есть также вторая Command с меткой «Say Hi», которая появляется на экранной клавише слева.

Нажатие на экранную клавишу «Alert Me!» отображает экран уведомления, показанный на рисунке 4.6. Действие отображения этого экрана является поведением, которое HelloWorld2 определило для команды, связанной с выбором экранной клавиши.

Взглянув на исходный код HelloWorld2, вы увидите, что, за исключением нескольких изменяющихся объявлений, логическая схема, которая формирует эту возможность обработки команд, находится в методе startApp(). Приложение создает экземпляр CommandListener. HelloWorld2 определяет внутренний класс, MyCommandListener, для выполнения обязанностей блока прослушивания команд. Он реализует интерфейс CommandListener.

Вам не придется делать это таким способом. Вы можете, например, создать подкласс класса Form и заставить его реализовать CommandListener. Ваш подкласс является Form, который является разновидностью Screen, и поэтому он способен получать уведомления о вызове команды.

Рисунок 4.5.Изображение первого экрана МID-лета HelloWorld2 с добавленной экранной клавишей на эмуляторе Motorola i85s

Рисунок 4.6. Нажатие на экранную клавишу «Alert Me!» отображает это уведомление. Уведомления являются типом отображаемых экранов

Определение CommandListener как интерфейса дает возможность использовать этот второй подход. Каждый тип Screen уже имеет класс более высокого уровня и поэтому не может наследовать от второго родительского класса. Использование интерфейсов Java особенно полезно в данном случае.

После создания экземпляра MyCommandListener экземпляр регистрируется в Form. Затем приложение создает объект Command, чью метку заголовка «Alert Me!» вы видели в эмуляторе. Эта команда затем добавляется в форму. Когда пользователь нажимает экранную клавишу «Alert Me!» на работающем MID-лете, реализация «посылает» уведомление блоку прослушивания, экземпляру MyCommandListener, вызывая метод commandAction() . Метод commandAction () затем создает объект Alert и отображает его.

Существует несколько важных теоретических моментов, связанных с этим примером. Обратите внимание, что я создал Command, но я не связал его с какой-либо определенной клавишей клавишной панели, кнопкой или экранной клавишей на устройстве. В действительности, при использовании высокоуровневого API ваше приложение не имеет способа получения информации о том, какая физическая клавиша нажата. Реализация присваивает Command специфическую клавишу — в этом случае экранную клавишу справа на дисплее устройства.

Активизируйте экранную клавишу «Say Hi», расположенную слева в MID-лете HelloWorld2, и вы увидите, что в результате поведение будет тем же самым, как и если бы вы нажали кйопку «Alert Me!», появится то же самое уведомление. Конечно, это поведение неправильно, поскольку Alert показывает, что была активизирована клавиша «Alert Me!».

Из-за абстракции высокоуровневого API, определяющего связи между ключами и командами, вы не можете присвоить блок прослушивания определенному ключу. Поскольку может быть больше одной команды на экран, вы должны использовать другую технику для того, чтобы дать возможность вашему блоку прослушивания команд идентифицировать источник команды и убедиться, что в ответ на события были выполнены нужные действия.

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

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

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

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

public void commandAction(Command c, Displayable d)

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.