Один за всех и все за одного!

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

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

Конечно, реализация этих программных фишек не может устроить всех и каждого: зачастую их качество оставляет желать лучшего, а некоторая крайне полезная для современного человека функциональность, вроде поддержки ICQ-подобных сервисов, отсутствует практически в любом "устройстве из коробки". Хорошо, если мы имеем дело с КПК или смартфоном, где на выручку приходит масса качественного (и дорогого) специализированного софта, написанного сторонними разработчиками; а вот если нам нужно "облагородить" и превратить в рабочую лошадку простой мобильный телефон, в основе интерфейса которого лежит фирменная операционная система закрытого типа?

Как ни удивительно, сегодня с этим проблем едва ли не меньше, чем в случае с аппаратами на базе открытых ОС: поддержка Java в наши дни присутствует практически в каждом телефоне ценой от ста долларов, а гибкость этой платформы позволяет создавать приложения, которые могут быть полезны обладателям телефонов совершенно разных брендов. В этом, собственно, вся соль - приложения и игры, написанные на Java, являются кроссплатформными: один и тот же мидлет может работать, допустим, на телефоне Samsung, смартфоне Nokia и каком-нибудь наладоннике с WM внутри. Естественно, с совместимостью есть определенные проблемы - в каких-то продуктах Java-машины поновее, в каких-то - постарее, да и сами мидлеты нередко оптимизируются разработчиками под конкретные модели телефонов. Визуально разница заключается лишь в способе реализации работы с Java-контентом: некоторые аппараты (как правило, корейского производства) позволяют загружать мидлеты только с помощью WAP-браузера - таким образом демонстрируется борьба с пиратством. В остальных случаях достаточно сбросить jar-файлы по Bluetooth или кабелю; порой достаточно этого самого jar-файла, а кое-где требуется еще и jad, хранящий информацию об инсталлируемом приложении. Некоторые современные мобильные телефоны поддерживают многозадачность: так, аппараты от Sony Ericsson позволяют одновременно запускать до десяти Java-приложений, Motorola Z6/V8/U6 - всего одно, но есть возможность его свернуть или передать по "синему зубу", а вот телефоны Nokia, Samsung и LG допускают лишь один мидлет, уже без возможности работы в фоновом режиме.

Такова теория, которая, как обычно и бывает, пытается идеализировать ту или иную технологию. С технической и исторической точек зрения все гораздо интереснее и… сложнее. Начнем с того, что набор спецификаций, предназначенных для разработки Java-приложений и их запуска на карманных электронных устройствах, получил название Java 2 Micro Edition (Java 2ME), тогда как спецификации для серверных решений называются Java 2 Enterprise Edition (Java 2EE), а для домашних компьютеров - Java 2 Standard Edition (Java 2SE).

При этом, что очень удобно, разработчикам ПО не нужно разбираться в особенностях архитектуры конкретных мобильных устройств и изучать новые малознакомые среды программирования,- SDK (Software Development Kit) для написания софта с учетом различных версий спецификаций Java весьма схожи, и ничто не мешает в кратчайшие сроки научиться писать Java 2ME-приложения, имея опыт работы, скажем, с более сложным Java 2SE. Кроме того, платформа Java 2ME бесплатна, что сыграло важную роль в популяризации технологии: если производитель устройства решает реализовать поддержку Java в своем новом портативном устройстве, то он никому ничего не должен - понятие лицензионных отчислений здесь отсутствует. Полагаю, стоит упомянуть, что огромное количество Java-приложений также распространяется на свободной основе - платить приходится в основном за игры да за что-нибудь совсем уж специфическое. В то же время базовым набором полезных мидлетов можно разжиться, не заплатив ни цента, - скажем, "комплект" для работы в интернете, включающий Opera Mini 4, JIMM, MailMan, ClimateControl, Google Maps и Mail.Ru Agent, не будет стоить ничего: заходишь на официальный сайт разработчика, скачиваешь, устанавливаешь и пользуешься в свое удовольствие.

В общем и целом принцип работы 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-графикой - пусть поднакопит денег и возьмет аппарат подороже.

Впрочем, все относительно, и многое зависит еще и от амбиций производителя. Скажем, LG не считает нужным добавлять поддержку 3D-графики даже в свои топовые продукты, а бюджетные телефоны Sony Ericsson ценят в том числе и за хорошую производительность в 3D-Java.

В основе платформы Java 2ME лежат две основные конфигурации: CDC (Connected De vice Configuration, JSR-36 для версии 1.0 и JSR-218 для версии 1.1) и CLDC (Connected Limited Device Configuration, JSR-30 для версии 1.0 и JSR-139 для версии 1.1).

Разница между CDC 1.0 и 1.1, а также между CLDC 1.0 и 1.1 заключается в возросшем количестве возможностей и, следовательно, в новых требованиях к аппаратной составляющей устройств; причем новые версии не переписаны с нуля, а представляют собой эволюцию (обновление) старых версий. Конфигурация CDC предназначена по большому счету для наиболее сложных мобильных устройств, вроде смартфонов, автомобильных навигационных систем и даже игровых приставок, а CLDC применяется в простых мобильниках. Очевидно, что эти конфигурации как раз и относятся к "костяку" платформы и поддерживаются большинством современных продуктов соответственно их классу и способу применения. Разница между CDC и CLDC заключаются в наличии или отсутствии некоторых библиотек, свойствах языка Java, возможностях виртуальных машин, а также аппаратных требованиях к устройствам. Но для непосредственного написания приложений, предназначенных для работы в устройстве, конфигураций мало, - вот мы и подобрались к вершине "Java-айсберга", которая называется MIDP (Mobile Information Device Profile, JSR-37 - версия 1.0, JRS-118 - 2.0).

Базируется MIDP на CLDC и, собственно, представляет собой эту конфигурацию плюс некоторое количество API, чего уже вполне достаточно для создания мидлетов. MIDP версии 1.0 основывается на CLDC 1.0, MIDP 2.0 - на CLDC 1.0 в случаях устройств, оснащенных от 128 до 512 килобайт встроенной памяти, или же на CLDC 1.1, если в аппарате больше 160 килобайт памяти, к тому же здесь добавлена поддержка операций с плавающей точкой. В связке CLDC+MIDP (в принципе, сегодня она и обозначает поддержку Java 2ME мобильными устройствами) обязанности распределяются следующим образом: CLDC отвечает за математические вычисления (работу с целыми и псевдослучайными числами, функциями, операциями с плавающей точкой), за подключения и сети (будь то Bluetooth-, USB-, COM- или инфракрасное подключение, а также http или TCP), за обработку массивов и векторов и за работу со строками - словом, за то, чего пользователь, загрузивший и запустивший новое Java-приложение, своими глазами не увидит. Другое дело - MIDP: профиль специализируется на обработке графических оболочек приложений, отображении элементов меню и картинок, выводе на экран текста и линий. Что касается версий, то все современные мобильные телефоны поддерживают MIDP 2.0, что обуславливает, например, поддержку технологии Push Registry, полноценную реализацию работы со звуком и доступ к вибромотору аппарата, усовершенствованные игровой и мультимедийный API и возможность использования более гибкого и приятного пользовательского интерфейса. В сравнении с MIDP 1.0, MIDP 2.0 может похвастать гораздо лучшей совместимостью с различными устройствами - теперь не приходится писать мидлеты чуть ли не под каждую конкретную модель мобильника. Отметим также, что MIDP 1.0 обратно совместим с 2.0.

Надеюсь, когда-нибудь Java-приложения догонят по функциональности софт для открытых операционных систем: хотелось бы рано или поздно увидеть мидлет, который мог бы сохранять SMS в текстовый файл, или, скажем, мидлет, который бы заменял собой интерфейс камеры… Думается, в ближайшем будущем нас ждет много чего интересного - мегапикселы мегапикселами, музыка музыкой, а возможность самостоятельно улучшить программную функциональность своего мобильного любимца должна стоять на первом месте. К счастью, производители устройств и разработчики ПО в этом случае находятся с нами по одну сторону баррикад. В то же время аппаратные характеристики гаджетов постоянно совершенствуются - если необходимым условием для реализации в устройстве CLDC является 16- или 32-разрядный процессор с тактовой частотой 8–32 МГЦ, то частота "камушка" современного мобильника нередко превышает 200 МГц.

Простенькие приложения запускаются так быстро, словно они висели в оперативной памяти, а софт потяжелее - буквально в течение двух-трех секунд. Недурно, правда? Остается расслабиться и получать удовольствие, ожидая, когда придет время еще более мощных "камней" и профиля MIDP 3.0. Оно уже не за горами…