В 1999 году Sun Microsystems представила всему миру новую программную технологию, предназначенную для создания приложений, работающих на мобильных устройствах — сотовых телефонах, КПК и др. J2ME - это "Java 2 Micro Edition". Язык Java изначально планировался, как кросс-платформенный язык, способный работать на устройствах с ограниченными возможностями. Строго говоря, технология эта не совсем новая — она стала преемницей J2SE, которая используется для создания «больших» приложений. Фактически J2SE несколько упростили, убрали лишнее и добавили специфические, важные для мобильных устройств функции. Особенностью Java-программ является то, что они выполняются на так называемой виртуальной машине Java, а сама технология задумывалась как платформонезависимая. Если мобильный телефон обладает поддержкой Java, на нем должны запускаться любые Java-программы.
Изначально язык не планировался для игр, поэтому его возможности несколько слабее возможностей инструментов, которые были созданы специально для игр. Однако, платформа J2ME появилась первой и сумела получить быстрое распространение. Поэтому на данный момент эта платформа является фактически стандартом на рынке мобильных игр.
Но не все так просто — виртуальная машина одна, а технические возможности мобильников разные. Да и на телефонах разных производителей одна и та же программа вполне может не запускаться — различаются реализации Java на разных аппаратных платформах, и проблема совместимости программного обеспечения и устройств разных производителей в Java-мире все еще актуальна. Поэтому в случае, например, с играми можно видеть, как одну и ту же игру адаптируют для различных аппаратов.
Производители мобильных телефонов, понимая, что повышение уровня совместимости Java-приложений с устройствами разных производителей очень важно, делают определенные шаги в этом направлении. В частности, Nokia и Vodafone занимаются разработкой новых спецификаций для Java-приложений, призванных повысить совместимость программного обеспечения и аппаратов разных производителей. В результате этого можно ждать еще более обширного распространения Java в мире и снижения цен на программы. Помимо попыток сторонних разработчиков улучшить положение дел, компания Sun тоже не прекращает работы над этим стандартом. Например, было объявлено о разработке новых API, реализующих поддержку Java-программами web-сервисов.
Что такое технология Java?
Технология Java состоит из двух элементов: языка программирования и операционной среды, в которой могут запускаться программы, написанные на этом языке. Синтаксис языка программирования Java похож на синтаксис C++ - оба языка объектно-ориентированы. Основное отличие между C++ и Java заключается в том, что разработчику приложений на C++ необходимо скомпилировать исходный код специально для конкретного устройства, для которого предназначено приложение. Java-код интерпретируется непосредственно самим устройством при помощи так называемой Java Virtual Machine. Этот механизм делает возможным свободное распространение Java-приложений, так как они работают на всех устройствах с аналогичной Java-платформой.
Какие бывают версии технологии Java?
Чтобы избежать негибкости решения - попытки создать единую технологию для всей устройств - платформа Java 2 была разработана в трех версиях. Версия Java 2 Enterprise Edition (J2EE) создана специально для сложных серверных решений, Java 2 Standard Edition (J2SE) предназначена для настольных компьютеров, а Java 2 Micro Edition (J2ME) разработана специально для небольших потребительских электронных устройств, таких как мобильные телефоны. Такой подход гарантирует необходимую функциональность различных видов устройств.
Что такое Java 2 Micro Edition (J2ME)?
J2ME - это не отдельная спецификация конкретного программного обеспечения. Это набор технологий и спецификаций, предназначенных для различных частей рынка небольших пользовательских электронных устройств. Основная часть платформы J2ME состоит из двух конфигураций: Connected Device Configuration (CDC) и Connected Limited Device Configuration (CLDC). Конфигурация определяет центральные библиотеки технологии Java и возможности Java Virtual Machine. Конфигурация CDC предназначена для портативных устройств типа high-end, например, коммуникаторов. Конфигурация CLDC создана для недорогих портативных устройств, таких как популярные модели мобильных телефонов. Специальные режимы позволяют определять функциональность конфигураций для различных типов устройств. Режим Mobile Information Device Profile (MIDP) предназначен для основанных на CLDC портативных устройств с возможностью коммуницировать - к таким устройствам относятся мобильные телефоны. Режим MIDP определяет функциональность - работу пользовательского интерфейса, сохранение настроек, работу в сети и модель приложения. CLDC и MIDP закладывают основу реализации J2ME.
Что такое Java Community Process (JCP)?
Java Community Process - это организация, состоящая из Java-разработчиков и владельцев патентов. Она было создана компанией Sun Microsystems. Цель JCP - разрабатывать и усовершенствовать спецификации технологии Java, а также расширять ее совместимость. Java Community Process управляется двумя исполнительными комитетами. Один фокусируется на J2EE и J2SE, другой занимается J2ME.
[colr=green]В чем преимущества технологии Java для пользователей телефона?[/color]
Традиционно мобильные телефоны поставлялись с ограниченным числом предустановленных приложений, таких как календарь, часы и несколько игр. Технология Java координально меняет ситуацию. Она позволяет пользователям скачивать новые приложения непосредственно на свой телефон. Таким образом, владельцы телефонов могут воспользоваться креативным потенциалом тысяч разработчиков приложений. Скачиваемыми Java-приложениями могут быть игры, календари спортивных занятий, двуязычные разговорники, карты и так далее. Технология Java делает телефон более развлекательным устройством и позволяет владельцу персонализировать телефон, подбирая необходимые имеено ему приложения.
Откуда можно загружать Java-приложения?
Многие компании создают Java-приложения для мобильных телефонов. Распространение приложений происходит в основном посредством скачивания на телефон через WAP-соединение. Таким образом, операторы играют важную роль в распространении, помогая пользователям быстро получить доступ к скачиваемым приложениям, предоставляя им ссылки на сайты с Java-приложениями. Все телефоны, поддерживающие J2ME, поддерживают также загрузку Java-приложений через WAP-браузер. Многие модели телефонов также поддерживают загрузку Java-приложений через Программное обеспечение. Пользователи телефонов с возможностью загрузки java с ПК, могут находить в интернете Java-приложения, которые возможно установить в телефон, и могут отправлять приложения по электронной почте своим друзьям.
Что представляет собой Java игра?
Это набор файлов (обычно два), которые содержат указатель (jad) и архив (jar) игры. Jad-файл иногда называют дескриптором, в котором указывается ссылка на архив, размер архивного файла и другая справочная информация. Порядок загрузки таков, - сначала загружается jad файл, который потом сам вызывает архив игры (jar). Некоторые телефоны позволяют загружать jar файл сразу без указателя.
ЧТО ТАКОЕ JAVA MICRO EDITION
Главная проблема мобильных телефонов — все они работают под управлением прошивки. Если в смартфоне функциональность устройства можно расширять (на том смартфоны и стоят), то в обычных мобильниках это невозможно. Тут и вступает в дело Java.
Идея состоит в том, что команды отдаются не напрямую процессору, а виртуальной Java-машине (JVM — Java Virtual Machine). На Java ME ее еще называют KVM, Kilobyte Virtual Machine. Вместо команд процессора программа на Java представляет собой байт-код — команды, которые и должна выполнять Java-машина. Для того чтобы программа заработала, достаточно, чтобы на системе была установлена эта самая Java-машина. На компьютерах она ставится отдельной программой, а в большинстве телефонов является частью прошивки.
Для программ, которые рассчитаны на Java ME, есть особое название — мидлет. Их очень часто путают с апплетами, но это совершенно разные понятия. Апплеты — это программы на Java, которые рассчитаны на запуск в рамках других программ, например в интернет-браузере, а мидлет — это вполне самостоятельная программа. Игра, «читалка», ICQ-клиент — все что угодно.
Siemens SL45i и Nokia 6310i – первые европейские телефоны с поддержкой J2ME.
Мобильные программы распространяются не в виде разрозненных файлов, а в виде специальных архивов и файлов описания. Это файлы 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.
Motorola i85. Первый в мире мобильный телефон с поддержкой мобильной Java (MIDP 1.0). Продавался только в США.
Sony Ericsson K850i. На сегодняшний день это самый продвинутый Java-фон. Большего набора API (плюс MIDP 2.1) нет ни в одном другом мобильном телефоне.
На данный момент существует несколько версий. 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-машина (несколько одновременно работающих мидлетов с возможностью взаимодействия), программы без интерфейса, работающие в фоновом режиме, автозапуск приложений вместе с включением телефона, специальные библиотеки (либлеты), которые могут использоваться несколькими программами, и многое другое.
это максимум, на что способны телефоны с поддержкой J2ME MIDP 1.0.
Все версии обратно совместимы друг с другом. Если поставить программу для MIDP 1.0 на телефон с MIDP 2.1, она будет работать, но, разумеется, не будет использовать новые возможности.
В каталогах, кроме версии MIDP, обычно никаких других характеристик J2ME не пишут, но список встраиваемых в телефоны API далеко не ограничивается CLDC и MIDP. Чаще всего, когда перечисляют поддерживаемые API, пишут номера, например, 184, 75, 82 и так далее. Откуда эти номера берутся? Дело в том, что большинство стандартов, включая API, разрабатывается особым сообществом (www.jcp.org), где различные компании разрабатывают стандарты 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...
JSR184 (он же M3G) в действии. Впервые на экранах мобильных телефонов появилось нормальное 3D.
Но трехмерная графика может быть создана и другими средствами. Есть трехмерный движок от компании 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 из всех. Однако занимается он очень и очень нужным делом — локализацией, то есть адаптацией приложения под разные языки, валюты, форматы времени и дат в разных странах. В принципе, его возможности можно реализовать и вручную, но все же его наличие заметно упрощает жизнь разработчикам, которые хотят продавать приложения не только в своей стране.
завтрашний день мобильного 3D: набор API под названием JSR 239: Java Binding for the OpenGL ES.
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, но телефоны с ним появятся еще нескоро, вот производителем и остается экспериментировать с тем, что уже есть.
Sony Ericcson не стали ждать, пока поддержка многозадачности будет реализована в MIDP и реализовали ее в своих телефонах самостоятельно.
ПРЕИМУЩЕСТВА И НЕДОСТАТКИ 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 нет, этого нет, — может показаться, что у 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 и быстрый процессор. Кого же винить в их отсутствии, как не разработчиков конкретного устройства?
АЛЬТЕРНАТИВЫ JAVA
BREW
BREW расшифровывается как Binary Runtime Environment for Wireless. Эта программная платформа создана компанией Qualcomm для телефонов стандарта CDMA. Под нее программы пишутся на языке C++. Ситуация со сложностью программирования примерно такая же, как и в случае с Java несколько лет назад: нестандартные API заметно усложняют жизнь.
Nokia 6301
Nokia 8800 Arte
Nokia 7500 Prism
Nokia 5310 XpressMusic
Nokia 6500 classic
Nokia 6500 slide
Все телефоны Nokia с Series 40 5th Edition, Feature Pack 1 поддерживают профиль MIDP 2.1
На первый взгляд у платформы много плюсов, во многом благодаря тому, что вся платформа жестко контролируется одной и той же компанией. Есть изначально мощные API, которые задаются исключительно версией BREW. Никакой мороки со стандартизацией: если знаешь, под какую версию программа пишется, можно не беспокоиться, — запустится она везде. Программы исполняются процессором — еще одно достоинство платформы. Почему же тогда так мало аппаратов с поддержкой BREW, раз у нее все так чудесно? Есть две причины.
Во-первых, любую программу на BREW написать можно запросто, а вот запустить на реальном телефоне можно только после тестирования и подписывания сертификатов. Стоит эта процедура немало. Ситуация смешная: просто писать бесплатные программы не получается — разоришься на тестировании.
Во-вторых, CDMA-телефоны (на них и рассчитана платформа), распространены только в определенных странах и регионах. А там, где мало таких телефонов, BREW непопулярен — вполне закономерно. Вот так и получается, что платформа предназначена «для избранных».
Mophun
Если в случае с BREW мы имеем дело с малораспространенной, но «живой» платформой, то Mophun — самый настоящий «мертвец». Изначально он разрабатывался как «быстрая» альтернатива Java, специально для игр. Создатель этой программной платформы — Synergenix Interactive (разработка началась в самом конце 90-х годов).
Как и BREW, программы под Mophun писались на C++ и исполнялись напрямую процессором. В то время как Java еще страшно тормозила, эта платформа уже резво бегала — неудивительно, что ей предсказывали неплохое будущее. Но что-то помешало ей стать популярной игровой платформой. Из всех производителей в основном только Sony Ericsson реализовали поддержку Mophun в своих аппаратах, это были аппараты из серии T: T290, T300 и некоторые другие. А разработчиков ПО отпугнула обязательная сертификация программ (как в BREW). Какие-то игры для платформы были (и неплохие для своего времени!), но их количество удручало.
А потом производители телефонов вместо того, чтобы возиться с Mophun, стали совершенствовать быстродействие и возможности Java. Даже SE вскоре выпустили T610 с поддержкой Java ME, а в следующем флагманском аппарате концерна, K700, Mophun уже нет. И на этом история платформы закончилась. Сейчас уже нет ни новых программ, ни новых телефонов с поддержкой Mophun.
Таким образом, у Java ME прямых конкурентов сейчас нет. Mophun почил в бозе, а BREW занял узкую нишу, которую вряд ли покинет. Java ME — стандарт де-факто для мобильных устройств, и он не собирается сдавать свои позиции. Более того, платформа живет и развивается. А MIDP 3.0, который вот-вот выйдет, и вовсе грозит подтянуть возможности простых телефонов на качественно новый уровень. Никак, революция на носу?
1. В 1998 году произошло разделение языка Java на Standard Edition (J2SE), который предназначался для обычных компьютеров, Enterprise Edition (J2EE), используемый на серверах, и Micro Edition (J2ME), который и устанавливается в мобильные устройства
2. В большинстве телефонов Java-машина является частью прошивки
3. API (Application Programming Interface) — это набор команд, которые программа может отдать устройству. Без соответствующего API невозможно, например, сделать снимок фотокамерой телефона, даже если она в нем установлена
4. Самый главный плюс Java — полное отсутствие вирусов и червей и очень небольшие возможности для троянских программ
5. Мобильные программы распространяются не в виде разрозненных файлов, а в виде специальных архивов и файлов описания. Это файлы JAR и JAD. В первом хранятся все файлы программы: .class (они содержат байт-код), файлы ресурсов (например, картинки или звуки) и файл-манифест. Во втором — описание программы, плюс размер архива и путь к нему (URL-адрес)
6. API, который может дать программисту средства сделать удобные меню, хранить настройки приложений и другие специфические для мобильников возможности, называется MIDP. Эту аббревиатуру знает каждый владелец мобильного телефона
7. В настоящее время существует несколько версий MIDP: устаревшая уже MIDP 1.0, используемая во всех современных телефонах MIDP 2.0 и относительно свежая MIDP 2.1, почти не отличающаяся от предшественницы по возможностям. Выпуск сильно обновленной версии MIDP 3.0 запланирован на первую половину этого года
8. На сегодняшний день из производителей «большой пятерки» проблемы со скоростью работы J2ME встречаются только у LG и Samsung, причем вторая компания активно наверстывает упущенное
9. В отличие от Java, альтернативная платформа BREW (Binary Runtime Environment for Wireless) не снискала должной популярности — она рассчитана только на CDMA-телефоны
10. Сейчас прямых конкурентов у Java ME нет: Mophun давно уже не развивается, а BREW занял узкую нишу. Java ME — стандарт де-факто для мобильных устройств, и он не собирается сдавать свои позиции.
21 марта 2010 18:22
