В общем и целом
принцип работы Java на конкретном
устройстве таков: в программное
обеспечение телефона разработчик
встраивает виртуальную Java-машину, с
помощью которой выполняются, а затем
выводятся на дисплей загруженные
мидлеты. Вроде бы все просто? Отнюдь. На
практике картина выглядит далеко не так
радужно: если некая виртуальная машина
абстрактного устройства с большой долей
вероятности может обеспечить выполнение
кода, то с выводом информации на дисплей
и управлением программой могут
возникнуть (и зачастую возникают)
проблемы - вновь встает вопрос о
совместимости: хорошо, если конкретный
мидлет разработала крупная компания,
которая в состоянии протестировать его
на совместимость с большинством
актуальных моделей мобильных телефонов
или же выпустить его версии для
аппаратов различных брэндов (с
различными схемами софтклавиш, разными
разрешениями и ориентациями дисплеев),
учтя при этом особенности реализации их
Java-машин. Однако массу интересных
Java-приложений пишут
программисты-одиночки, которые
разрабатывают их "с прицелом" на свой
собственный аппарат или же линейку
"соплатформников" одного производителя.
И дать гарантию, что такой мидлет будет
корректно работать на телефоне другой
модели, не может никто.
Более
того, основная проблема заключается в
так называемых наборах API (Appli cation
Programming Interface - программный
интерфейс приложения), отвечающих за
доступ к каким-либо программным или
аппаратным функциям устройства
непосредственно из Java-приложения,
исполняемого виртуальной Java-машиной.
Приведем пример из жизни: есть такой
мидлет - BT Info, предназначающийся для
Blue-Jack’инга. На Sony Ericsson W880i
он получает доступ к Bluetooth-модулю,
отыскивает устройства и обменивается с
ними информацией, а вот MOTOROKR Z6 при
попытке запуска мидлета выводит на
дисплей сообщение об отсутствии
поддержки JSR-82.
Что это значит?
Виртуальная Java-машина, которой
оснащена Z6, не имеет доступа к
Bluetooth API устройства, то есть
соответствующие Java-приложения
функционировать не будут. Аббревиатура
JSR расшифровывается как Java
Specification Request - фактически это
модули/конфигурации/профили/спецификации,
реализуемые на основе дополнительных
библиотек (классов) и призванные
улучшить функциональность платформы в
целом. Одни из них являются
специфическими, другие применяются почти
повсеместно и уже стали ее "костяком",
благо отсутствие некоторых интересных
API было обнаружено производителями
устройств и ОПСОСами (желающими
использовать новую платформу для
внедрения своих дополнительных услуг)
еще в первые годы существования Java
2ME. Полный же список модулей, которые
реально поддерживаются представленными
на рынке аппаратами, можно отыскать на
www.jcp.org/en/jsr/all.
"Почему
мобильные телефоны не оснащаются
одинаковым набором API? Ведь так было бы
проще и разработчикам ПО, и
пользователям…" - примерно такой вопрос
был недавно задан на одном из
интернет-форумов, посвященных мобильным
технологиям. Попробуем ответить. Дело в
том, что сама архитектура Java 2ME не
может обеспечить полной
стандартизации.
Допустим, есть
набор основных библиотек, конфигураций и
профилей, поддержка которых присутствует
в Java-машинах устройств в обязательном
порядке, а есть и дополнительные (а
порой и "экзотические") элементы,
добавляемые разработчиками "по желанию"
или по необходимости. А поскольку
аппаратные/программные характеристики
устройств отличаются, разработчики
встраивают ровно те возможности,
которые, по их мнению, будут
востребованы пользователями и в то же
время поддерживаются на уровне железа.
Зачем, например, бюджетному телефону
поддержка JSR-184 (Mobile 3D Graphics
API), если его процессор все равно не
справится с обработкой трехмерной
графики? Посему такая возможность в
Java-машину и не закладывается. Свою
роль здесь играет и маркетинг: почему бы
дополнительно не разделить устройства на
классы по их Java-функциональности?
Возьмем те же игры: если пользователя
устроят простенькие 2D-игрушки, пусть
покупает аппарат за сот ню долларов, а
если ему хочется насладиться 3D-графикой
- пусть поднакопит денег и возьмет
аппарат подороже.
