ЧТО ТАКОЕ JAVA MICRO EDITION Главная неувязка мобильных телефонов...

ЧТО ТАКОЕ 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 построен чрезвычайно гибко.

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

Это происходит именно из-за ограничения на количество плееров. Впрочем, в ближайшее время это ограничение встречается все реже. JSR 120 и 205: Wireless Messaging API 2.0. Эти API дают возможность посылать и принимать сообщения.

Первая версия давала возможность посылать только SMS или бинарные данные, а во 2-ой можно посылать 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, который практически позволяет отправить на сервер какие-то данные в особом протоколе и получить некоторый результат их обработки. А вот 2-ой пакет, 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 — гибкость реализации.

Каждый производитель может решать, что в телефоне будет, а чего — нет. Правда, тут может возникнуть вопросец, не создает ли это трудности для разработки мидлетов из-за большого контраста аппаратов. Ход мысли верный, но с данной проблемой справились разными методами. Мифы и легенды JavaJava 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 несколько лет наза