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

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

Автор: Алексей Стародымов

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

Конечно, реализация этих программных фишек не может устроить всех и каждого: зачастую их качество оставляет желать лучшего, а некоторая крайне полезная для современного человека функциональность, вроде поддержки 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. Оно уже не за горами…