Возможности 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, но телефоны с ним появятся еще нескоро, вот производителем и остается экспериментировать с тем, что уже есть.