J2Me: Что К Чему? Все О Мобильной Java — Русским Языком

ЧТО ТАКОЕ JAVA MICRO EDITION

Главная проблема мобильных телефонов — все они работают под управлением прошивки. Если в смартфоне функциональность устройства можно расширять (на том смартфоны и стоят), то в обычных мобильниках это невозможно. Тут и вступает в дело Java.

Идея состоит в том, что команды отдаются не напрямую процессору, а виртуальной Java-машине (JVM — Java Virtual Machine). На Java ME ее еще называют KVM, Kilobyte Virtual Machine. Вместо команд процессора программа на Java представляет собой байт-код — команды, которые и должна выполнять Java-машина. Для того чтобы программа заработала, достаточно, чтобы на системе была установлена эта самая Java-машина. На компьютерах она ставится отдельной программой, а в большинстве телефонов является частью прошивки.

Для программ, которые рассчитаны на Java ME, есть особое название — мидлет. Их очень часто путают с апплетами, но это совершенно разные понятия. Апплеты — это программы на Java, которые рассчитаны на запуск в рамках других программ, например в интернет-браузере, а мидлет — это вполне самостоятельная программа. Игра, «читалка», ICQ-клиент — все что угодно.

Мобильные программы распространяются не в виде разрозненных файлов, а в виде специальных архивов и файлов описания. Это файлы JAR и JAD. JAR расшифровывается как Java Archive. На самом деле это самый обычный архив Zip, просто с другим расширением. В нем хранятся все файлы программы: .class (они содержат байт-код), файлы ресурсов (например, картинки или звуки) и файл-манифест. Последний описывает программу: название, производитель, версия и другие данные. JAD — это файл описания (расшифровывается как Java Application Descriptor). Он содержит все те же сведения, что и файл манифеста, плюс размер архива и путь к нему (URL-адрес). Для чего же он нужен, если вся информация уже содержится в файле манифеста? А для того, чтобы можно было посмотреть сведения о мидлете, не качая архив, который может быть достаточно велик.

Понятно, что для установки обязательно нужен файл JAR. JAD-файл на некоторых старых телефонах тоже требовался, но практически любой современный телефон без него спокойно обходится.

Одно из главных понятий, которые есть в программировании, — это API (Application Programming Interface), интерфейс прикладного программирования. Это набор команд, которые программа может отдать устройству. Например, большинство современных телефонов обладает камерой. Но одного ее наличия для съемки из Java-приложения недостаточно. Нужно, чтобы был API управления камерой — иначе телефон просто «не поймет», чего от него хотят. API и определяет функциональность устройства.

Самый базовый API, на котором строятся все остальные, — это либо CDC (Connected Device Configuration), либо CLDC (Connected Limited Device Configuration). Оба представляют собой сильно урезанные наборы команд из «большой джавы». CDC предназначается для смартфонов, коммуникаторов и КПК (как более мощный), а для мобильников остается CLDC, конфигурация попроще. Сейчас существуют две версии CLDC: 1.0, которая уже практически нигде и не используется, и 1.1, главное отличие которой от предыдущей версии — поддержка расчетов с плавающей точкой. Обе из них созданы уже достаточно давно, но замену им пока почему-то не готовят.

Поскольку мобильники сильно отличаются по устройству от компьютеров, понадобился API, который может дать программисту средства сделать удобные меню, хранить настройки приложений и другие специфические для мобильников возможности. Эту задачу берет на себя API под названием MIDP. Это слово, наверное, видел каждый, кто брал в руки каталог телефонов. Расшифровывается оно как Mobile Information Device Profile. данный момент существует несколько версий. MIDP 1.0 создан очень и очень давно, в 2000 году. Он накладывал много ограничений на программы — его возможности были очень небольшими. Поэтому в 2002 была выпущена новая версия, MIDP 2.0. Эта версия используется и по сей день, причем практически во всех новых телефонах. Так что сейчас слова «Java ME» и «MIDP 2.0» — почти синонимы. По сравнению с предшественницей, эта версия дает куда больше возможностей: приемлемое звуковое сопровождение, расширенные сетевые возможности, богатые средства для создания интерфейса и игровой графики. Именно MIDP 2.0 дал толчок к развитию мобильного игростроя.

Стоит также упомянуть MIDP 2.1, который был разработан относительно недавно, в 2006 году. Он не дает каких-либо новых возможностей, зато в этой версии уточнены некоторые особенности реализации Java на телефонах. Ее уже встраивают в конкретные телефоны, хоть это и не афишируется. Например, она стоит во всех последних телефонах Sony Ericsson.

Еще существует MIDP 3.0, эта версия достаточно давно находится в разработке, ее выход запланирован на первую половину нынешнего года. Список изменений впечатляет: многозадачная Java-машина (несколько одновременно работающих мидлетов с возможностью взаимодействия), программы без интерфейса, работающие в фоновом режиме, автозапуск приложений вместе с включением телефона, специальные библиотеки (либлеты), которые могут использоваться несколькими программами, и многое другое.

Все версии обратно совместимы друг с другом. Если поставить программу для MIDP 1.0 на телефон с MIDP 2.1, она будет работать, но, разумеется, не будет использовать новые возможности.

В каталогах, кроме версии MIDP, обычно никаких других характеристик J2ME не пишут, но список встраиваемых в телефоны API далеко не ограничивается CLDC и MIDP. Чаще всего, когда перечисляют поддерживаемые API, пишут номера, например, 184, 75, 82 и так далее. Откуда эти номера берутся? Дело в том, что большинство стандартов, включая API, разрабатывается особым сообществом , где различные компании разрабатывают стандарты Java, в том числе и мобильные. Каждый новый API разрабатывается по JSR — Java Specification Request, («Запрос на спецификацию Java»). Каждому JSR присваивается свой номер, он проходит несколько стадий разработки, и в конце концов остается финальный вариант, который могут встраивать производители.

ВОЗМОЖНОСТИ JAVA ME

Какими бывают API?

Возможности каждого отдельного телефона можно описать несколькими параметрами, самым главным из которых будут поддерживаемые API. Основные API — это уже описанные CLDC и MIDP. Но кроме них есть и множество других. Некоторые используются широко, некоторые — не очень.

Очень часто в характеристиках телефона пишут, что поддерживается Java 3D. Это тоже отдельный API, под которым обычно подразумевают JSR 184 — Mobile 3D Graphics API (сокращенно M3G). Это — стандарт де-факто для трехмерных приложений: большинство 3D-игр разработаны именно с его использованием. Этот API поддерживают аппараты Nokia, и Motorola, и Sony Ericsson...

Но трехмерная графика может быть создана и другими средствами. Есть трехмерный движок от компании HI Corp. под названием MascotCapsule. Его предпочитает ставить в телефоны наряду с JSR 184 в основном шведо-японский концерн. В отличие от JSR 184, он разработан под несколько «спартанский» набор возможностей, но все базовые в наличии, а оставшиеся можно дописать самому по мере надобности. Под MascotCapsule создано меньше игр, однако и под него есть очень известные, например игры от компании Fishlabs. И нельзя не признать, что они обладают самой передовой мобильной трехмерной графикой на нынешний день.

Еще есть относительно недавно созданный JSR 239: Java Binding for the OpenGL ES API. Этот интерфейс представляет собой поднабор OpenGL, используемого на компьютерах. В принципе, все то, что он может, можно реализовать и через JSR 184. Но OpenGL ES лучше — программы, написанные под «большой» OpenGL, можно с минимальными усилиями переносить на «маленький», и наоборот. Сейчас этот API еще только начинают понемногу встраивать в мобильники.

Здесь нужно развести понятия «движок» и «API» — их часто путают. Движок — он отрисовывает трехмерные объекты на экране. API — это интерфейс, набор команд, которые можно отдать движку. Если провести аналогию с машиной, то движок, собственно, приводит машину в движение, а функцию API будет выполнять педаль газа. JSR 184 — это просто API, через который можно управлять любыми совместимыми с ним движками, а MascotCapsule — это движок со своим собственным API.

Какие еще API существуют для мобильных устройств? Вот список тех API, которые стандартизированы JCP.

JSR 135: Mobile Media API (MMAPI). Он отвечает за базовые мультимедийные функции, например воспроизведение видео или запись звука. От него зависит, можно ли сделать под конкретную модель, например, диктофон.

API построен очень гибко. Есть какой-то источник звука одного из трех типов: ресурс на мобильнике, файл в интернете, запись с камеры или с микрофона. Для источника создается плеер, который им управляет, а для плеера можно получить разные виды контроля. Например, можно контролировать скорость, темп или звук.

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

JSR 120 и 205: Wireless Messaging API 2.0. Эти API дают возможность посылать и принимать сообщения. Первая версия давала возможность посылать только SMS или бинарные данные, а во второй можно посылать MMS.

JSR 75: PDA Optional Packages. Под этим невнятным названием скрываются два пакета: Personal Information Management (PIM) и FileConnection API. Последний является одним из самых важных API в принципе. Почему? Потому что именно он дает доступ приложениям к файловой системе телефона и используется в самых разных приложениях. Если его нет — ни архиватор, ни плеер, ни редактор изображений на J2ME не запустятся.

Функция второго пакета, PIM, — доступ к телефонной книге и календарю, но она практически не востребована, потому что как правило встроенные телефонные книги и календари неплохо справляются со своими функциями и замены не требуют, а других программ, которым понадобились бы такие данные, очень немного.

JSR 82: Java APIs for Bluetooth. С этим API все ясно уже из названия: если он есть, можно будет соединять два телефона по Bluetooth. Обычно это используется для совместной игры — соревноваться вдвоем куда интереснее. Игр с режимом мультиплеера пока не очень много, но их количество растет довольно быстро.

Можно использовать Bluetooth и для других целей, например для прослушивания музыки через гарнитуру (если телефон поддерживает такую функцию) или передачи файлов.

JSR 172: J2ME Web Services Specification. Этот API тоже делится на два пакета, хотя здесь они друг с другом связаны более тесно: оба дают возможность работать с веб-сервисами.

Первый пакет — Remote Procedure Call (RPC) Package, который фактически позволяет послать на сервер какие-то данные в специальном протоколе и получить некий результат их обработки.

А вот второй пакет, XML Parser Package, имеет очень широкое применение. Его назначение — распознавание документов в формате XML, а этот формат становится все более и более популярным. (На всякий случай стоит пояснить: XML — это формат хранения данных, который может читаться и редактироваться пользователем без особых усилий.) Этот API понемногу начинают встраивать в новые мобильники, поэтому вполне возможно, что очень скоро многие мидлеты начнут хранить все свои параметры в XML.

JSR 234: Advanced Multimedia Supplements API. JSR 135 создан уже достаточно давно, и в какой-то момент его возможностей стало не хватать. Для этого и предназначен этот API: дополнить мультимедийные возможности мобильной Java. Их список впечатляет: есть виды контроля над эффектами изображений, аудиоэффектами (например, эквалайзер, которого многим не хватало в JSR 135), над сохранением в различные форматы, есть управление камерой, FM-тюнером и даже поддержка трехмерного звука.

Как и в случае с JSR 135, каждый производитель решает, какие виды контроля встраивать, а какие — нет. Пока этот API используется не очень широко, но ситуация уверенно движется в лучшую сторону.

JSR 226: Scalable 2D Vector Graphics API. Смысл этого API — дать возможность мидлетам «на лету» создавать изображения в формате SVG. У этого формата есть несколько очень важных преимуществ. Во-первых, он векторный, это означает, что изображения состоят не из точек, а из кривых, которые рисуются при отображении. Благодаря этому изображения легко и без потери качества масштабируются, что очень важно. К тому же эти изображения описываются с помощью все того же XML — поэтому их легче редактировать вручную. Зачем все это? Чтобы создавать красивый и масштабируемый пользовательский интерфейс приложений.

JSR 177: Security and Trust Services APIs. Этот API создан для шифрования информации и управления сертификатами. Суммарно в нем насчитывается четыре пакета, которые можно встраивать по отдельности:

CRYPTO. Название вполне понятное: задача этого пакета — шифровать данные, а алгоритмы шифрования определит производитель. Здесь: если нужно применить шифрование информации — для этого есть специальный API.

APDU. Этот API нужен для того, чтобы работать со смарт-картами по специальному протоколу APDU. Что понимать под смарт-картой? В случае GSM-телефона — это SIM-карта. С помощью этого API можно, например, поменять PIN-код прямо из Java-приложения точно так же, как из меню телефона.

PKI. Пакет для работы с сертификатами, управления цифровыми подписями и так далее. Это, пожалуй, тема для отдельной статьи — очень уж она широкая и сложная.

JCRMI. Этот API во многом схож с APDU: с его помощью тоже можно работать со смарт-картами, но на этот раз по тому же принципу, по которому работает JSR 172. То есть, посылаются данные по специальному протоколу, они обрабатываются — и получается некий результат.

JSR 179: Location API. Последнее время в телефоны все чаще и чаще стали встраивать GPS. А раз есть возможность узнавать свои координаты, то почему бы не сделать такой API, чтобы Java-приложения могли их обрабатывать? С помощью такого API можно без особого труда сделать интерактивную карту, которая использует GPS-чип.

JSR 180: SIP (Session Initiation Protocol) API. В наши дни общение через интернет-пейджеры — самое обычное дело. На компьютере ли, на мобильнике — везде находятся программки, которые позволяют заняться электронной перепиской. А вот этот API упрощает создание подобных программ, потому что дает возможность обмениваться сообщениями по протоколу SIP. Сам протокол был разработан в 2002 году. Его самое заметное отличие, например, от протокола ICQ заключается в том, что обмен сообщениями идет в рамках сессии (приглашаем — на приглашение отвечают — разговариваем). Получается этакий телефонный разговор, но посредством текста.

Впрочем, обмен сообщениями можно использовать и не только как «мобильную асю», это и просто удобный инструмент. На компьютерах протокол используется в основном для VoIP, а вот на мобильниках интересно будет понаблюдать, что же сотворят программисты с таким API под рукой. Ведь SIP годится далеко не только для VoIP.

JSR 229: Payment API. Тут ничего хитрого: такой API позволяет создать электронный кошелек на мобильнике или просто проводить какие-то транзакции. Насколько активно будут использовать этот API, пока сказать сложно: с одной стороны, пользоваться такими кошельками очень удобно, с другой — разработчики, операторы и контент-провайдеры уже наладили свои системы оплаты, и не факт, что будут их менять. Здесь все рассудит время.

JSR 238: Mobile Internationalization API. Это, наверное, самый компактный API из всех. Однако занимается он очень и очень нужным делом — локализацией, то есть адаптацией приложения под разные языки, валюты, форматы времени и дат в разных странах. В принципе, его возможности можно реализовать и вручную, но все же его наличие заметно упрощает жизнь разработчикам, которые хотят продавать приложения не только в своей стране.

JSR 211: Content Handler API. А вот это очень интересный и многообещающий API. Как следует из названия, его цель — управление контентом, который закачивается в телефон. При этом даже приложение не нужно запускать — все произойдет автоматически.

Вот, к примеру, сейчас игры, как правило, нерасширяемые: сколько уровней разработчики заложили в игру — столько и будет, возможность качать дополнительные не предусмотрена. А с таким API процесс намного упрощается: щелкаешь на ссылку, телефон понимает, что пользователь собирается скачать уровень к игре, дальше запускается приложение и устанавливает нужный файл.

Возможности этого API ограничиваются только фантазией программистов. Захотелось автоматически рассортировывать закачиваемую музыку? Пожалуйста: когда качается музыкальный файл, тут же читаются теги и файл идет в нужную папку. Хочется, чтобы zip-файлы открывались архиватором на Java? Нет проблем: архиватор дает знать, что хочет открывать определенный тип файлов. И так далее. Впечатляет? Не то слово.

JSR 256: Mobile Sensor API. Этот API выполняет специфическую функцию, но уж если она нужна, то без этого API никуда. Что же он делает? Он позволяет получать данные с аппаратных датчиков телефона (если такие имеются). Допустим, если в телефоне есть акселерометр (устройство для определения положения телефона в пространстве), без этого API его не получится задействовать в приложении.

Это те API, которые были совместно разработаны и стандартизированы производителями телефонов и другими компаниями. Но есть и другие API, проприетарные, которые компании разрабатывают «под себя». Например, этим грешила Siemens, когда для доступа к файловой системе телефона использовала собственный API.

Обычно такие API встраиваются только в телефоны компании-создателя, но есть и исключения. Например, Sony Ericsson встраивает в свои телефоны API Nokia, который управляет пользовательским интерфейсом. Он был разработан для того, чтобы программы, рассчитанные на Nokia, запускались и на SE, когда MIDP 2.0 еще не был в ходу. Сейчас он уже утратил свою актуальность, но в нем есть функция включения подсветки экрана, которую в MIDP 2.0 так и не сделали.

Другие параметры

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

В первую очередь большую роль играет такой параметр, как Java Heap. Если проводить аналогию со смартфонами, то это — оперативная память. Казалось бы, написал объем оперативки — и дело с концом. Но не так-то все просто.

Во-первых, иногда бывает так, что разработчики телефона решили разделить Heap на несколько частей: например, одна для графики, а другая — для других объектов. И вот вроде Heap достаточно, а игра не запускается. Не хватает памяти, и все тут. Увы, узнать о том, как управляется память, можно только из документов компании-производителя, у любых серьезных компаний такие должны быть. И тут уж должны позаботиться разработчики мидлета — составить точный список телефонов, где Heap хватит, а где нет.

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

Другой важный параметр, о котором вообще не пишут в описаниях телефонов, — процессор. А ведь от его тактовой частоты зависит скорость обработки команд. Если процессор слабенький, игры вряд ли будут бегать быстро, да и архиватор будет долго думать. Процессор к тому же может поддерживать технологии, которые позволяют исполнять байт-код программы быстрее. Одна из таких технологий — Jazelle DBX, которую применяют в моделях процессоров ARM, очень популярных в мобильных устройствах. Ее преимущество в том, что процессор исполняет команды байт-кода напрямую — вместо того, чтобы ждать, пока Java-машина превратит байт-код в машинный, процессор сразу же приступает к делу. Остается только контролировать исполнение программы.

Еще один параметр, который пока очень редко встречается в телефонах, — 3D-ускоритель. Одним из самых известных аппаратов с ускорителем стал Sony Ericsson W900 (на борту он нес NVIDIA GoForce 4800). Аппарат хоть и нашел своего покупателя, массовым не стал. Как и мобильные ускорители. Дело в том, что ускоритель на одном аппарате не имеет смысла: если не будет программ под него, то он и не понадобится. А кто же будет писать программу под один-два телефона? Пока что просто рынок, видимо, не дозрел до этого решения, но в будущем ситуация еще вполне может измениться.

Кроме уже перечисленных параметров есть и другие, которые можно назвать «особенностями реализации». Такими особенностями часто «грешат» аппараты Sony Ericsson, выпущенные за последние пару лет. Например, на них первых реализовали возможность работы нескольких мидлетов одновременно.

Другая интересная возможность, опять же, никем, кроме Sony Ericsson, не реализованная — установка мидлетов на экран ожидания. Например, ничего не стоит сделать так, чтобы по рабочему столу бежали буковки а-ля «Матрица». Или, как вариант, показать на рабочем столе органайзер. Еще на SE есть возможности запуска мидлетов вместе со включением телефона, это может быть полезно для интернет-пейджеров.

Многозадачную Java-машину и автозапуск мидлетов обещают стандартизировать в MIDP 3.0, но телефоны с ним появятся еще нескоро, вот производителем и остается экспериментировать с тем, что уже есть.

ПРЕИМУЩЕСТВА И НЕДОСТАТКИ JAVA

Обычно говорят только о недостатках Java, потому создается впечатление, что Java существует только за неимением лучшего. Но это не так — многие мифы о недостатках J2ME тянутся за технологией с незапамятных времен. Но обо всем по порядку.

Плюсы Java

Самый главный, пожалуй, плюс Java — полное отсутствие вирусов и червей и очень небольшие возможности для троянских программ. Напомню: вирус старается заразить другие программы, чтобы при их исполнении запускался вредоносный код, а черви размножают себя всеми средствами, какими возможно. В отличие от них, троян — это программа, которая должна одурачить пользователя и выполнить вредоносные действия с его разрешения. Так вот, на Java ME существование вирусов и червей принципиально невозможно (разумеется, исключая случаи некорректной реализации Java-машин). Для того чтобы ответить, почему так происходит, нужно вспомнить, как работает Java. Любая программа исполняется Java-машиной, а значит, только Java-машина может решить, выполнять ту или иную команду. В итоге мидлет просто не сможет отдать «неправильную» команду.

И размножать себя у гипотетического J2ME-червя тоже не получится. Сразу встанет вопрос, как мидлет будет себя рассылать. Не по SMS ведь. Через MMS приложение передать тоже нельзя. Значит, единственный путь — Bluetooth. Но приложение не может само запуститься и получить доступ к Bluetooth, это должен разрешить пользователь. Допустим, пользователь запустил и разрешил. Но на другом конце владелец телефона тоже должен принять приложение, установить и запустить. И при этом каждое действие выполняется владельцами. Если владелец не захочет ставить программу, все ее усилия тут же и закончатся. А весь смысл червя в том, что он распространяется сам по себе.

А как же трояны? Были ведь приложения, которые посылали SMS на платные номера. Но тут опять вступает в дело идеология Java. Приложение не может само по себе послать сообщение, все, что оно может, — «сказать» Java-машине: «Хочу послать сообщение туда-то». А все Java-машины на современных телефонах реализованы так, что подобные действия должны подтверждаться пользователем (это стандартизировано в MIDP). Только приложение захотело выполнить какое-то подозрительное действие — Java-машина даст ему по усам и спросит пользователя. И все, вредоносные усилия программы упираются в решение владельца телефона. И тут уж виноват только пользователь, если он разрешил незнакомой программе посылать сообщения бог знает куда. Чтобы свести к минимуму такие опрометчивые решения, телефоны по умолчанию меньше доверяют приложениям, которые не подписаны сертификатом (а их подписывают после платного тестирования). И даже подписанные программы не могут творить что угодно без спроса. Обойти такую защиту средствами самой программы невозможно принципиально. Конечно, теоретически можно представить ситуацию, когда Java-машина не выдает запрос (что по стандарту Java ME и MIDP делать нельзя), или недоработка в прошивке позволяет обойти защиту. Но если уж так происходит, значит это неполадки в работе JVM телефона, которые производитель должен устранить.

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

Мифы и легенды Java

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

Удручающее быстродействие Java ME

Этот миф тянется уже из давних-давних времен и неверен для многих современных аппаратов. Откуда он берется? Все очень просто: раз код программы исполняется не процессором, а Java-машиной, то все это начинает сильно тормозить. Логично? Более чем, когда все так и было.

Но времена меняются, процессоры адаптируются под исполнение байт-кода напрямую (например, та же технология Jazelle), увеличивается быстродействие телефонов само по себе. На сегодняшний день из производителей «большой пятерки» проблемы со скоростью работы J2ME только у LG и Samsung, причем вторая компания активно наверстывает упущенное.

У Java ME есть серьезные ограничения, которые не дают возможности писать мощные приложения

Миф возник во времена MIDP 1.0, слабых процессоров и ограниченной памяти. Когда стоит процессор ниже 100 МГц, Heap составляет несколько сотен килобайт, а никакого доступа к файловой системе нет и в помине — тут и правда особо не разгуляешься. Но теперь мощность продвинутых телефонов вполне сравнима со смартфонами и КПК, возможности API все больше и больше совершенствуются, так что разработчикам не на что жаловаться.

До определенного времени еще были серьезные проблемы с размером JAR-файлов. Дело в том, что их очень часто ограничивали, и лимит составлял обычно либо 300 Кбайт (это еще туда-сюда), либо 64 Кбайт. 64 Кбайт — это уже совсем грустно, потому что в такие рамки не то что графику, даже объемный программный код не засунешь. И все, начинались урезки, иногда версии для аппаратов с ограничением и без него отличались очень разительно. Сплошь и рядом была такая ситуация, что в нормальной версии игры в наличии красивая графика и толковый ИИ, а на облегченную — смотреть без слез уже нельзя.

Современная Java-игра может весить 1-1,5 Мбайт, и это не предел. Сейчас все в основном тормозится тем, что игры приходится скачивать через GPRS или EDGE, а большие объемы не каждый захочет качать — денежки утекают. Но тут уж Java не виновата.

Под каждый телефон программу приходится чуть ли не писать заново

И этот миф пошел оттуда же, из дремучих времен MIDP 1.0. Возможности этого API были настолько ограниченны, что программировать даже простенькую игру — уже целая проблема. Проблемы MIDP понимали не только разработчики, но и производители телефонов, отчего стали массово плодиться проприетарные API, которые восполняли то, чего не хватало в MIDP 1.0. В основном это были графические и звуковые средства. Конечно, это лучше, чем ничего, но у такого подхода есть большой недостаток: приложения начинали целиком зависеть от наличия конкретного API в модели. А раз все компании делают API по принципу «кто во что горазд», то в итоге получалось, что либо приложение пишется под какие-то определенные телефоны одной фирмы, либо под куцый MIDP 1.0.

MIDP 2.0 свел на нет необходимость проприетарных API, но все старые программы и телефоны никуда не делись. Разработчики оказались перед нелегким выбором: либо писать под новые телефоны, забросив поддержку старых, либо опять химичить с MIDP 1.0 и специфическими API, чтобы не обижать владельцев старых телефонов. Многие разработчики так и продолжали писать мидлеты по старинке, плюнув на новый стандарт. Свою порцию неудобств прибавляли разные размеры экранов (тут дело даже не в разрешении, а в соотношении сторон) — это сильно затрудняло написание мидлетов.

Все это привело к полной неразберихе. Ситуация начала выправляться только к 2004-2005 годам. Свою роль сыграл JSR 75 с доступом к файловой системе — его разработчикам не хватало больше всего. Теперь аппараты поголовно выпускаются с MIDP 2.0, и о поддержке MIDP 1.0 можно не беспокоиться.

Но оставалась еще одна проблема: если использовать только стандартизированные API, как определить, в каком телефоне есть все необходимые? Ведь их число может отличаться. Если разработчик еще может смотреть спецификации телефонов по отдельности (хоть это и утомительно) и составлять список поддерживаемых моделей, то пользователь это делать не будет. Что же тогда делать?

И вот тут к проблеме подошли с двух сторон. У производителей появилось такое понятие, как платформа (сейчас оно у всех на слуху). Преимущество такого подхода очевидно: характеристики всех телефонов определенной платформы совершенно одинаковы, и пользователю достаточно знать, на какую платформу рассчитано приложение. Разделением на платформы славятся Nokia и Sony Ericsson. У Sony Ericsson платформы просто имеют порядковые номера, от JP-1 до JP-8 (JP расшифровывается как Java Platform). У Nokia разделение чуть сложнее: указывается принадлежность к телефонам (S40) или к смартфонам (как правило, S60), затем редакция платформы, и потом набор возможностей платформы (к примеру, S40 3rd Edition Feature Pack 2). Таким образом, вместо длинного списка поддерживаемых телефонов достаточно писать что-нибудь вроде: требуется JP-5 и выше. Примерно так же решили и проблему с экранами: сделали несколько стандартных разрешений, под которые можно написать универсальную программу.

А что же сделали в JCP? Там пытаются стандартизировать не какие-то отдельные API, а создать базовые требования к устройствам, которым все аппараты должны соответствовать. Первой ласточкой стал JSR 135: Java Technologies for Wireless Industry (JTWI). Вышел он вскоре после MIDP 2.0 и решил проблемы с проприетарными API путем обязательного встраивания нескольких стандартных API, которые могли бы его заменить. Первым в списке шел, разумеется, MIDP 2.0, а вот список остальных был очень невелик: всего-то JSR 135 и JSR 120, которые отвечали соответственно за воспроизведение звука и пересылку сообщений. Несмотря на такую лаконичность, на тот момент это был уже заметный шаг вперед от засилья проприетарных API.

Но время не стоит на месте — возможностей базовых API стало не хватать. Ну а раз JTWI поощряет ставить дополнительные стандартные API, в конце концов разномастных программных платформ стало слишком много. Да, во всех стоят только стандартные API, но вот как определить, пойдет ли приложение или нет, не сверяя списки требуемых и поддерживаемых API?

Тогда разработали новый стандарт — JSR 248: Mobile Service Architecture (MSA). Он вышел в самом конце 2006 года и борется с самой главной проблемой предшественника — немощностью базового набора API. На этот раз есть два набора, урезанный и полный. В неполный набор входят:

• JSR 75 (File & PIM)


• JSR 82 (Bluetooth)


• JSR 135 (Mobile Media)


• JSR 184 (3D Graphics)


• JSR 205 (Messaging)


• JSR 226 (Vector Graphics)
  

  Это уже дает достаточно неплохие возможности, а полный набор добавляет еще следующие API:

  
  


• JSR 172 (Web Services)


• JSR 177 (Security & Trust)


• JSR 179 (Location)


• JSR 180 (SIP)


• JSR 211 (Content Handler)


• JSR 229 (Payment)


• JSR 234 (Multimedia Supplements)


• JSR 238 (Internationalization)

И, что радует больше всего, этот JSR начинают встраивать в самые новые аппараты Nokia и Sony Ericsson, так что в ближайшем будущем можно будет не волноваться, пойдет или не пойдет приложение на том или ином телефоне.

Еще была проблема с тем, как реализовывают API (например, какие пакеты встраивают в мультимедийные API), но MSA и здесь все четко контролирует: про каждый JSR четко написано, что в нем должно быть встроено и как именно. К тому же JSR 248 не признает MIDP 2.0 — как минимум MIDP 2.1, а в нем многие недомолвки были устранены. Точку в проблеме размеров экранов должен поставить MIDP 3.0: он просто не позволяет использовать разрешение меньше 176х220. итоге получается очень четко описанная платформа, на которой все приложения работают очень предсказуемо. Конечно, какие-то мелочи еще остаются, но глобальной проблемы уже нет. Времена, когда программы под каждый телефон приходится писать отдельно, уходят в прошлое и больше не вернутся.

Минусы Java

Вот я все пишу, того минуса в Java нет, этого нет, — может показаться, что у Java нет минусов вовсе. Но, увы, некоторые проблемы остаются, и с ними приходится мириться.

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

Другой минус кроется в CLDC. Напомню, что он представляет из себя урезанные API Java SE. Увы, не просто урезанные, а крайне урезанные. Иногда настолько сильно, что даже непонятно, чем то или иное средство не угодило создателям CLDC. Конечно, этот API был разработан как самое базовое, что должно быть в телефоне, и, как следствие, должен быть нетребователен. Но если уж MIDP 2.0 предъявляет к телефону заметно большие требования, чем CLDC, почему нельзя было сделать CLDC мощнее? Часть недостающих средств можно написать самостоятельно, но что мешало перенести их сразу? Совершенно непонятно.

Ну и последний камень в огород: на Java SE постоянно совершенствуются сами возможности языка, добавляются новые средства, версия уже добралась до 6-й, а на мобильниках все как было со времени создания версии 3, так и осталось. Между тем новых возможностей иногда очень и очень не хватает. И что хуже всего — создавать новую версию CLDC явно никто не спешит.

Радует только одно: MIDP 2.1 и более поздние версии «не против», если они работают не поверх CLDC, а поверх CDC, а в нем ситуация намного лучше. Несовместимости со старыми приложениями не будет, потому что CDC полностью включает в себя CLDC. Так что есть надежда, что MIDP на мощных аппаратах будут ставить поверх CDC — это исправит положение. Конечно, еще лучше было бы, если бы на телефоны вообще стали ставить наряду с MIDP чисто смартфонные профили (Personal Profile, Personal Basis Profile, Foundation Profile), но их даже не на каждый смартфон-то ставят. Опять же, совершенно непонятно почему...

Остальные «недостатки» платформы вроде недостаточного быстродействия уже скорее бывают у отдельных телефонов по вине их производителей, нежели из-за Java. Java позволяет использовать мощные графические ускорители, никто не запрещает ставить объемистый Heap и быстрый процессор. Кого же винить в их отсутствии, как не разработчиков конкретного устройства? BREW расшифровывается как Binary Runtime Environment for Wireless. Эта программная платформа создана компанией Qualcomm для телефонов стандарта CDMA. Под нее программы пишутся на языке C++. Ситуация со сложностью программирования примерно такая же, как и в случае с Java несколько лет наза