Javaфон

Javaфон самый продвинутый

Искать среди Sony Ericsson, Nokia и Motorola.

Наилучшая поддержка, по всей видимости, у Sony Ericsson (из-за «особенностей реализации» — расширении производителем возможностей).

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

MIDP 3.0 — с этой спецификацией не вышло ни одного телефона.

Итак, у Sony Ericsson платформа с номерами от JP-1 до JP-8.

Последняя, наиболее продвинутая платформа — JP-8 (8.5).
Выпущенные модели на ней — Yari, Aino, Hazel, Elm, Cedar, Zylo.
По другим данным — Yari(U100), Aino(U10), Pureness(X5), J10i/J10i2(Elm), J20(Hazel), W20(Zylo), J108(Cedar).

Из камерофонов наилучший K850i.

3D-ускоритель — в W900 (и, возможно, в нек. др. моделях).

http://en.wikipedia.org/wiki/Sony_Ericsson_Java_Platform
http://en.wikipedia.org/wiki/List_of_Sony_Ericsson_products
https://ru.wikipedia.org/wiki/Sony_Mobile_Communications
http://topse.ru/forum/showthread.php?t=23944

Поддержка Java в мобильных ОС

Изначальная поддержка производителем: Symbian и Asha Platform, Bada.

Есть эмуляторы с разной степенью эффективности: WinCE, Windows Mobile, Android.

Нет: Windows Phone (все версии).

BlackBerry: ранее — да, изначально, в BlackBerry 10 — нет.

Смартфон на Java

Несмотря на абсурдность идеи, попытки осуществления были:
LG Jasper S20 — якобысмартфон, основан на SavaJe OS на базе платформы Java, представлен в 2006 году;
— китайфоны с сомнительной функциональностью. Производят, по-видимому, в основном копии брендов (с Java — подешевле, и с Android — подороже).

O Java

В 1998 году произошло разделение языка на Standard Edition (J2SE), который предназначался для обычных компьютеров, Enterprise Edition (J2EE), используемый на серверах, и Micro Edition (J2ME), который и устанавливается в мобильные устройства.

команды отдаются не напрямую процессору, а виртуальной Java-машине (JVM — Java Virtual Machine).

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

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

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

Поскольку мобильники сильно отличаются по устройству от компьютеров, понадобился 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 1.0 на телефон с MIDP 2.1, она будет работать, но, разумеется, не будет использовать новые возможности.

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

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

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

Пресловутая переносимость Java в случае разработки ПО для мобильных телефонов пока остается мифом. Причина — особенности реализации многих функций и наличие специализированных программных модулей, предоставляющих программисту доступ к нестандартным функциям телефонов, и различное разрешение экранов у разных моделей телефонов.
Различия вынуждают разработчиков создавать отдельные версии чуть ли не для каждой модели телефона.
Правда, есть и перспективы изменения жизни к лучшему. Сегодня в разработке находится стандарт MIDP 3.0, который серьезно расширяет возможности Java-телефонов. В частности, планируется реализация средств тонкой настройки мидлетов с учетом типа устройства, на котором они работают, взаимодействие между несколькими запущенными мидлетами, совместно используемые библиотеки, доработки в интерфейсе, работа на больших экранах или более чем с одним экраном (учитывая, что сегодня большинство «раскладушек» имеют по два экрана, это актуально), улучшения в сетевой подсистеме, постоянной памяти, SyncML, Bluetooth и т. д.
Как очень надеются и изготовители телефонов, и разработчики, внедрение MIDP 3.0 позволит решить проблемы стандартизации и сэкономить им время и силы на разработку новых игр. Если они смогут избавиться от бесконечного портирования существующих программ для потока новых телефонов, то и к мобильной 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.

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

MIDP 3.0
Эта спецификация, появившись в 2009 году, не вышло так и ни одного телефона с ней (на 2011г.).

В конце 2009 года вышла финальная спецификация MIDP 3.0, только средств для разработчика MIDP 3.0 и эмулятора, а также реальных устройств с поддержкой этого стандарта до сих пор нет (2011г.). Смартфоны мигрировали на Android, а для бывших разработчиков JavaME оказался простым переход на него.

На Oracle Developer Day 2011 вопрос MIDP-3.0… хм… не то чтоб обсуждался… как бы это правильно сказать? Слушателям дали понять, что Оракл просто не смог договориться с держателями спецификаций (формулировка моя, возможно я что-то не так понял). Так что проблема MIDP-3.0 не в области технологии, а в корпоративных «войнушках» между Ораклом и другими производителями виртуальных машин
На Sun Tech Days 2008 бурно рассказывали о фичах MIDP 3.0, об открытой phoneME. Но потом как-то все прошло. Думаю новые заметные проекты уже не появятся, но поддерживать существующие будут ещё долго.
На Oracle Developer Day 2011 тоже про мобильную жаву много чего рассказывали, обещали скоро запустить новый sdk, с новыми фичами, а к концу года первые телефоны с их поддержкой, в целом впечатление от конференции было приятным, ребята поняли что потеряли рынок, но очень хотят вернуть хотя бы его часть.

Другим популярным профилем для CLDC является DoJa, разработанный фирмой NTT DoCoMo для её собственного сервиса iMode. iMode весьма распространён в Японии, и в меньшей степени в Европе и на Дальнем Востоке.
Изначально профиль DoJa был создан для местного японского рынка под версией 1.0, а затем 2.0, что примерно соответствовало MIDP 1.0 и MIDP 2.0. В настоящее время в Японии доступна версия DoJa 5.0. Для рынков за пределами Японии было сознано новое API, названное «Заграничной Версией» (DoJa Overseas Edition). В настоящее время на мобильных устройствах, продаваемых в Европе и СНГ, устанавливается DoJa 1.5oe и DoJa 2.5oe.

J2ME не актуальна, т. к. современные устройства уже способны запускать полную J2SE. Была попытка прикрутить JavaFX к мобильным платформам как подмножество J2SE, но с выходом JavaFX 2.0 Oracle объявила, что основная их цель — десктопы.

Альтернативы Java

BREW

BREW расшифровывается как Binary Runtime Environment for Wireless. Эта программная платформа создана компанией Qualcomm для телефонов стандарта CDMA. Под нее программы пишутся на языке C++. Ситуация со сложностью программирования примерно такая же, как и в случае с Java несколько лет назад: нестандартные API заметно усложняют жизнь.

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

Недостатки: Любую программу на BREW написать можно запросто, а вот запустить на реальном телефоне можно только после тестирования и подписывания сертификатов. Стоит эта процедура немало.
CDMA-телефоны (на них и рассчитана платформа), распространены только в определенных странах и регионах. А там, где мало таких телефонов, BREW непопулярен — вполне закономерно.
Она не поддерживает многозадачности. (?)

В настоящее время платформа также доступна для телефонов стандарта GSM.
Все приложения распространяются исключительно через операторов связи, являющихся партнёрами Qualcomm. BREW-сервисы доступны в более чем 25 странах: Бразилия, Вьетнам, Индия, Италия, Канада, Китай, Мексика, США, Япония и др. В России они были доступны в сетях Skylink до марта 2010 года.

Платформа BREW получила своё дальнейшее развитие в виде платформы Brew Mobile Platform.
Первая версия платформы вышла 17 ноября 2008 года. В мае 2010 года в России в продажу поступил первый телефон, работающий под управлением Brew MP — HTC Smart.

Ориентирована на игры и простенькие программные приложения, среди которых не последнюю роль играют программки, связанные с интернетом и телефонной связью.

Mophun

Если в случае с BREW мы имеем дело с малораспространенной, но «живой» платформой, то Mophun — самый настоящий «мертвец». Изначально он разрабатывался как «быстрая» альтернатива Java, специально для игр. Создатель этой программной платформы — Synergenix Interactive (разработка началась в самом конце 90-х годов).

Как и BREW, программы под Mophun писались на C++ и исполнялись напрямую процессором. В то время как Java еще страшно тормозила, эта платформа уже резво бегала — неудивительно, что ей предсказывали неплохое будущее. Но что-то помешало ей стать популярной игровой платформой. Из всех производителей в основном только Sony Ericsson реализовали поддержку Mophun в своих аппаратах, это были аппараты из серии T: T290, T300 и некоторые другие (Ericsson T310 и T610) (Sony Ericsson T230, Z600 и др.) (Полноценная Mophun-машина и лишь номинальная поддержка J2ME были в мобильном телефоне Sony Ericsson T610.). А разработчиков ПО отпугнула обязательная сертификация программ (как в BREW). Какие-то игры для платформы были (и неплохие для своего времени!), но их количество удручало.

А потом производители телефонов вместо того, чтобы возиться с Mophun, стали совершенствовать быстродействие и возможности Java. Даже SE вскоре выпустили T610 с поддержкой Java ME, а в следующем флагманском аппарате концерна, K700, Mophun уже нет. И на этом история платформы закончилась. Сейчас уже нет ни новых программ, ни новых телефонов с поддержкой Mophun.

Нет бесплатных приложений Mophun, потому что они все должны быть сертифицированы.
Дальнейшее развитие — MoSync.

Javaфон самый продвинутый

Sony Ericsson K850i. На сегодняшний день (2008 г.) это самый продвинутый Java-фон. Большего набора API (плюс MIDP 2.1) нет ни в одном другом мобильном телефоне.

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

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

«недостатки» платформы вроде недостаточного быстродействия уже скорее бывают у отдельных телефонов по вине их производителей, нежели из-за Java. Java позволяет использовать мощные графические ускорители, никто не запрещает ставить объемистый Heap и быстрый процессор. Кого же винить в их отсутствии, как не разработчиков конкретного устройства?

наиболее богатые списки (телефоны с поддержкой Java) у Motorola и Nokia. Именно эти корпорации являются инициаторами продвижения MIDP. Motorola является лидером экспертной группы при разработке MIDP 3.0.

поддержка Java в платформах

Что бы запустить Java-программы, созданные для мобильных телефонов, приходится использовать эмуляторы мобильных телефонов. Например: TAO Intent Java MIDlet manager, IBM J9 WEME MIDP20 JMM, Coretek Delta java manager, CrEme JVM, Esmertec Java.

WinCE
Есть эмуляторы с разной степенью эффективности

Windows Mobile
На коммуникаторах и смартфонах с операционной системой Windows Mobile, игры и другие программмы, написанные для мобильных телефонов, обычным способом запустить невозможно.
Есть эмуляторы http://www.fxeuroclub.ru/mobilehelp/installhelp/Windows_Mobile.php

Windows Phone
Нет

BlackBerry
Ранее — да, изначально
BlackBerry — нет

Asha Platform
Да, изначально

Symbian
На Symbian тоже поддерживается java, но не всегда корректно и так быстро, как на некоторых телефонах. Но у них есть свой специальный формат приложений, имеющий то самое злополучное расширение «.sis».
Многие спрашивают, какой прогой перегнать sis в jar. Ответ один: никак, уже хотя бы потому, что возможности sis-приложений и jar-приложений очень различаются, поэтому даже если и появится вдруг где-нибудь такая перегоняющая программа, то толку с неё будет мало, т.к. то, что умеет смартфон, телефон сделать не сможет. Исключение составляют такие приложения, которые пишутся и в формате jar и в формате sis, но это двойная работа, и я, честно говоря, таких экземпляров не встречал.
http://topse.ru/forum/showthread.php?t=2734

Bada
Да, изначально

Android
Есть эмуляторы

смартфон на Java

Jasper S20
LG представила первый в мире смартфон, работающий под управлением открытой операционной системы SavaJe OS на базе платформы Java.
Основными особенностями операционной системы являются многопоточность, многозадачность и повышенная функциональность при работе с мультимедийными и веб-приложениями.
Устройство воспроизводит музыку в форматах MP3, AAC и AAC+ и видео в форматах H.263 и MPEG4.
Операционная система от SavaJe поддерживает Java ME Connected Limited Device Configuration (CLDC), Java Virtual Machine, улучшенный графический интерфейс от Sun и пр.
Аппарат оснащён джойстиком, цветным TFT-экраном (176 на 220 пикселей), 1,3-мегапиксельной камерой, слотом для SD карточек, поддержкой Bluetooth интерфейса и USB.

Представлен в 2006 году.
Jasper S20 – первый Java-телефон с поддержкой спецификации JSR-209, созданный на базе Java Platform Micro Edition. Платформа позволит создавать пользовательские интерфейсы для мобильных телефонов, используя Swing и Java2D
Jasper S20 создан гонконгской компанией Group Sense Limited и вскоре поступит в продажу в Азии.

Операционная система SavaJe OS закрытая, но основанная на открытых стандартах. Судя по сайту конторка студенческая.(http://www.savaje.com/)

Китайфоны
По-видимому, ранее производились, в т. ч. копии брендов.
Так, есть сведения о клоне Samsung i9100.

Дополнение
Что могут Java приложения?

В связи с участившимися вопросами, типа «дайте прогу, которая бы мой телефон превратила в смартфон», решил я создать тему, прочтя которую юзер сможет понять, есть ли смысл искать прогу, которая бы реализовала те или иные возможности.

Итак, для начала нужно чётко осознавать, что телефон и смартфон — кардинально разные вещи. Вкратце могу лишь сказать, что смартфон позволяет менять очень и очень многое, перехватывать практически все события, менять некоторые менюшки, стандартные возможности и т. д. Это обусловлено тем, что на смартфонах стоит специальная «расширенная» так сказать операционная система (на нокиах это например Symbian), которая обладает повышенным функционалом. На телефонах стоит «простая» операционная система, позволяющая использовать только то, что нам предоставили разработчики, не позволяя менять ничего кроме настроек, разрешённых ими же.

Теперь о возможностях java-платформы. Вообще язык Java богатый, но большинство его возможностей направлено на разработку игр.
Возможности программ (т. е. приложений, направленных не на развлечение, а на выполнение некоторых функций, типа переводчика, диктофона и т. д.) на разных телефонах разные. Чем новее телефон — тем у него больше возможностей.

Некоторые из наиболее полезных функций java, которые могут облегчить вам жизнь:

  1. Файловая система: чтение, запись. Java приложения могут читать\писать информацию из\в файл на телефон. Так же есть возможность открытия изображений, проигрывания мелодий, но это ограничивается доступной памятью, т. к. для этого нужно весь файл загрузить в память. Так же возможны программы, шифрующие файлы под код. Именно работа с файловой системой является более-менее перспективной возможностью приложений, т. к. она позволяет делать программы-редакторы. К этому же можно отнести программы-архиваторы.
  2. Bluetooth: Java-приложения могут использовать Bluetooth и Инфракрасный порт для связи с другими телефонами, обмениваться через них данными.
  3. Интернет: Java-приложения могут подключаться к Интернету через GPRS\EDGE\HSDPA\UMTS.
  4. SMS: Java-приложения могут отправлять SMS-сообщения, спрашивая при этом у вас, стоит ли это делать. Поэтому про вирусы дружно забыли.
  5. Контакты и органайзер: Java-приложения могут читать и писать (создавать, редактировать) информацию о ваших контактах и событиях календаря.
  6. Камера: Java-приложения могут делать снимки камерой и даже записывать видео. При это стоит отметить то, что качество камеры при этом ухудшается, т.к. например нельзя включить подсветку, макрорежим, ночной режим и т. д.
  7. Аудиозапись: Java-приложения могут записывать звук с микрофона (и конечно проигрывать его потом).
  8. Прочие мелкие возможности заключаются в хранении любый файлов в самом Java-приложении и их чтение. Эта возможность реализована на всех телефонах, поэтому распространены программы вроде тех же переводчиков, хранящих базы слов, слайд-шоу приложений — программы, содержащие фотографии и отображающие их и т.д., но возможности этих программ обычно ограничены.
  9. Хранение информации: практически все телефоны умеют хранить информацию в специальной секции под названием RecordStore, куда можно поместить всё что угодно. Единственный недостаток этого «хранилища» в том, что каждая программа хранит свою информацию отдельно от других, и вне этой программы её прочитать невозможно. Так же после удаления программы удалится и всё то, что она хранила в RecordStore.

Конечно, это не все возможности Java-приложений, но они наиболее востребованы и интересны.

Внимание! Старые модели телефонов имеют урезанные возможности java-машин, или, попросту говоря, приложения могут выполнять не все команды на всех телефонах. Вспомнить хотя бы Bluetooth. Далеко не все старые телефоны, на которых есть Bluetooth, позволяют играть через него в java-игры. Например:
K500 — нет файловой системы. Другими словами, приложения не смогут загрузить файл, сохранённый на телефоне.
K700 — нет Bluetooth (имею ввиду не вообще, а нет в Java) и файловой системы.

Новые телефоны (от 2005-го года) этим не страдают.

Теперь о тех функциях, которые многие так хотят получить, но пока что (а может и никогда) не смогут получить из Java:

  1. Защита смс от просмотра: Java не имеет доступа к SMS.
  2. Фильтр звонков: Java не может отлавливать звонки и тем более блокировать их.
  3. Зашита папок паролем: Java может работать с папками и файлами. Но она НЕ МОЖЕТ перехватывать обращение телефона к ним, поэтому никаких паролей на их чтение поставить НЕЛЬЗЯ. Единственный выход — шифрование ФАЙЛОВ. В этом случае каждый файл в отдельности будет модифицироваться так, что его чтение станет бесполезным, до обратного преобразования (для которого обычно и нужен пароль).
  4. Антивирусы: во-первых, возможностей Java недостаточно для того, чтобы написать более-менее работоспособный вирус, т.к. при любом обращении к файловой системе, Bluetooth, Интернет или отправкой SMS у вас будет спрошено, стоит ли это делать. Думаю никто не будет слать SMS на неизвестные номера? Это раз. Во-вторых, Java не имеет возможности так же отлавливать события, чтобы блокировать их. Единственное, что может такой «антивирус» — так это сканировать ваши файлы, но стоит помнить о бесконечных запросах и скорости чтения\записи файлов на телефоне. Так же важно то, что далеко не все телефоны могут запускать одновременно несколько Java-приложений. Последний гвоздь в крышку гроба таких антивирусов — во время работы Java-приложений телефон неплохо использует аккумулятор, что вряд ли стоит «антивируса», от которого нет толка.
  5. Изменение внешнего вида, меню, запрет функций телефона: всё это Java-приложение сделать не может, т. к. у него нету доступа ни к меню, ни к прочим полезностям, вроде замены стандартного окошка информации о состоянии памяти и аккумулятора телефона.
  6. Инфракрасный порт в телефонах Sony Ericsson похоже что тоже недоступен. В любом случае реализовать пульт для телевизора невозможно, т.к. для этого даже не хватит мощности ИК-порта (вспомните, на каком расстоянии нужно держать телефоны при передаче чего-либо через ИК-порт? Вот на таком же расстоянии и к телевизору нужно будет подойти).

Добавить комментарий