Java наконец-то стала Mobile

Язык Java, как известно, изначально создавался для мобильных клиентов, работающих в гетерогенной среде. Проблема была в самой среде, точнее в ее отсутствии... но ситуация наконец-то изменилась.

В последнее время появилось огромное количество моделей мобильных телефонов, оснащаемых новыми модными возможностями. Если рассмотреть хронологию появления этих функций, можно отметить, что первым (ну, первым вряд ли, но главным — это точно. Прим. ред.) стало то, что практически все телефоны, стали оснащаться JVM, точнее сказать ее урезанной версией (J2ME). Таким образом производители этих устройств заявили, что телефон перестал быть ограниченным в своих возможностях устройством с жестко заданной функциональностью — пользователь может самостоятельно добавить то программное обеспечение, которое сочтет необходимым.

На практике это было больше похоже на PR-акцию. Мало кому приходило в голову искать дополнительные игры для своего мобильного устройства — слишком уж некрасивой и угловатой была графика на черно-белом экране телефона.

Вторым шагом в этом направлении было добавление GPRS-модема и широкое распространение этого стандарта в мире. Таким образом мобильные телефоны получили возможность выхода во всемирную паутину по сравнительно дешевым тарифам.

Последним — и, пожалуй, самым желанным для потребителей — стало появление моделей с цветными экранами с разрешением 128х128 пикселей и улучшенным звуком (так называемой полифонией). Несмотря на внушительные цены этих устройств, они пользуются фантастической популярностью у потребителей. Для них появилось великое множество новых java-игр и полезных программ.

Словом, с появлением такого рода устройств с уверенностью можно говорить о рождении нового рынка для программного обеспечения.

Последним шагом стало скрещивание классического PDA с мобильным телефоном. То есть теперь внутри мобилки находится полноценная операционная система Symbian — и программисты, естественно, не ограничены больше java-«песочницей», а могут писать для этих устройств C++ приложения. Эта ОС так же пришла из мира PDA.

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

Несмотря на появление возможности написания C++ приложений для отдельных hi-end моделей, Java остается и останется основной платформой. Для такого положения вещей существует несколько причин.

1. Java-приложения являются более переносимыми с устройства на устройство, чем приложения, реализованные с помощью С++. Если вы не будете использовать специальные расширения Java API, выходящие за стандарт, и будете так кодировать ваши приложения, чтобы они были независимы от разрешения экрана, то переносить их не потребуется вообще. Что касается практики создания коммерческих приложений, то такие условия невыполнимы. Так что при переносе с платформы на платформу, как правило, придется потрудится.
2. Устройства с отсутствием встроенных операционных систем будут существовать, поскольку большинству потребителей вполне достаточно уже реализованных возможностей, и они не собираются переплачивать за ненужную функциональность. То есть Java-приложения остаются единственным способом расширить функциональность таких телефонов.
3. Последний стандарт MIDP2.0 значительно расширяет возможности Java-приложений, и практически возможности при написании таких приложений ничем не отличаются от возможностей для написания приложений с помощью C++. К сожалению, устройств, которые поддерживают этот стандарт, пока еще очень мало. Мне известно всего две модели: Nokia 6600 (последняя из 60-й серии) и Ericsson P800/P900. Кстати, на форумах было много нареканий относительно качества реализации стандарта MIDP2.0 в этих устройствах. Цены на такие телефоны просто фантастические. Но постепенно парк таких устройств будет расширяться, все дефекты будут устранены, а цены упадут до приемлемого уровня.
4. Вследствие специфики мобильных устройств нет значительной разницы в скорости выполнения java- и native-приложений. Не зря большинство игр для мобильных устройств hi-end класса (где возможно использование C++ приложений) все же выполнены в виде java-приложений.

Программа для выполнения под управлением JVM мобильного телефона или другого мобильного устройства, называется Midlet. Для разработки таких программ нам также потребуется специальный инструментарий. Следуя ссылкам на Java Developer Connection с адреса http://java.sun.com, вы можете скачать J2ME Wireless Toolkit, там же вы найдете полную API-документацию для CDC, профиля Foundation Profile и CLDC/MIDP. Это все что вам потребуется для разработки своих приложений.

Существует достаточно много SDK, ориентированных на разработку приложений конкретно для той или иной мобильной платформы. Отличаются они, главным образом, разрешением экрана эмулятора, а также поддержкой дополнительного Java API, характерного для той или иной платформы. Прежде чем скачивать инструментарий, проверьте, нет ли в вашей среде разработки предустановленного J2ME Wireless Toolkit. Кроме того, некоторые среды разработки имеют plug-ins для работы с J2ME Wireless Toolkit. К примеру, все последние версии JBuilder обладают такой функциональностью — и, следовательно, скачивать вам ничего не придется. Просто создайте новое приложение на базе заготовки, входящей в среду разработки, и приступайте к работе.

В поставке с J2ME Wireless Toolkit идет несколько демонстрационных приложений, что значительно упрощает ознакомление с принципами разработки подобных приложений. Мы рассмотрим создание собственного приложения классической игры «крестики-нолики». Вообще-то, реализация этой игры уже присутствует в Nokia SDK, но я решил сделать собственную, оригинальную версию. Тем более что и алгоритм несложен, и реализация его не займет много времени.

Минимальное Midlet-приложение состоит из двух классов. Первый — это класс, наследующий функциональность класса MIDlet. Главный класс, в котором присутствует точка входа в приложение. Второй — это экран приложения. Класс, поддерживающий интерфейс Displayable.

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

Классы, реализующие интерфейс Displayable, могут быть двух типов:

• форма — предназначена для расположения на ней немногочисленных, но, тем не менее, весьма полезных контролов;
• Canvas.
  В этом примере мы используем два класса унаследованных от Canvas. Как следует из названия, этот класс предназначен для рисования на нем. Класс, наследующий свою функциональность от MIDlet, приведен ниже:

public class MIDletHello extends MIDlet {
  public void startApp() {
    // В момент старта приложения нужно произвести
    // определенные действия
  }

  public void pauseApp() {
    // Пользователь переключился на другое приложение и
    // работа временно приостановлена
  }

  public void destroyApp(boolean unconditional) {
    // Завершение работы приложения, в том числе
    // обусловленное каким-либо непредвиденным событием
  }

  public static void quitApp() {
    // Пользователь нажал команду Exit
  }
}

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

Типичный класс Canvas выглядит так:

  pr
public class MyCanvas extends Canvas implements CommandListener {
  public MyCanvas() {
    // Инициализация необходимых переменных происходит
    // здесь. Например, мы хотим создать еще одну команду
    // меню:
     addCommand(new Command("Exit", Command.EXIT, 1));

  }

  public void commandAction(Command command, Displayable displayable) {
    // Здесь происходит обработка команд меню.
  }

  protected synchronized void keyPressed(int keyCode) {
    // Здесь происходит перехват нажатий клавиш управления
    // телефона
  }

otected void paint(Graphics g) {
    // Рисуем здесь
  }
} // end of class

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

Логика игры реализована в классе Engine. Алгоритм игры достаточно прост, мы обходим все варианты комбинаций в двумерном массиве, отражающем текущее состояние игрового поля. При этом, анализируя массив из трех полей — сечение (две диагонали, три вертикали и три горизонтали), мы расставляем приоритеты. Если приоритет встретившейся комбинации выше приоритета текущей комбинации, то встретившаяся комбинация становится текущей.

Ниже, c краткими пояснениями, приведено тело функции, которая является сердцем алгоритма:

  protected boolean analaize()
  {
    // считаем,сколько в одном ряду крестиков, ноликов, пустых мест:
    int x_counter = 0;
    int o_counter = 0;
    int e_counter = 0;
    for (int i = 0; i < buffer.size(); i++)
    {
      Cell cell = (Cell)buffer.elementAt(i);
      if (cell.value == STATE.E)
      {
        e_counter++;
      }
      if (cell.value == STATE.O)
      {
        o_counter++;
      }
      if (cell.value == STATE.X)
      {
        x_counter++;
      }
    }
// В зависимости от количества крестиков, ноликов или пустых
// мест определяем комбинацию (тип состояния) — searchState
    int _searchState = SEARCH_STATE.ANY;
    // user win
    if (x_counter == 3)
    {
      _searchState = SEARCH_STATE.X_X_X;
      this.gameState = GAMESTATE.USERWIN;
      return true;
    }
    // engine can win :
    if ((o_counter == 2)&&(e_counter == 1))
    {
      _searchState = SEARCH_STATE.O_O_E;
    }
    // danger - user can win :
    if ((x_counter == 2)&&(e_counter == 1))
    {
      _searchState = SEARCH_STATE.X_X_E;
    }
    // good combination :
    if ((o_counter == 1)&&(e_counter == 2))
    {
      _searchState = SEARCH_STATE.O_E_E;
    }
    // also good combination :
    if (e_counter == 3)
    {
      _searchState = SEARCH_STATE.E_E_E;
    }
    // Если приоритет новой комбинации больше приоритета
    // текущей комбинации,определяем новую комбинацию как
    // текущую и запоминаем ее в переменных класса:
    if (this.searchState < _searchState)
    {
      this.searchState = _searchState;
      this.searchBuffer = new Vector();
      // copy vector:
      for (int i = 0; i < this.buffer.size(); i++)
      {
        this.searchBuffer.addElement(this.buffer.elementAt(i));
      }
    }
    return false;
  }

После завершения обхода ставим нолик в последней запомнившейся комбинации с наивысшим приоритетом. Логика сделана с тем расчетом, чтобы при желании ее можно было использовать в более сложной игре Go. Класс Fields отвечает за рисование игрового поля и содержит экземпляр класса Engine. Класс MyCanvas отвечает за перехват событий клавиатуры и меню, всю логику прорисовки экрана он делегирует экземпляру класса Fields.

Олег Ремизов, "Комиздат"