Создание единого приложения для нескольких мобильных устройств

Question

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

В частности, возможно ли использовать единую сборку приложения BREW для нескольких разрешений экрана?

Обратите внимание, что цель состоит в том, чтобы иметь один двоичный код строить.Если бы это было просто для того, чтобы иметь единую кодовую базу, то условная компиляция и сценарий интеллектуальной сборки сделали бы свое дело.

Answer 1

Да, это возможно, мы смогли сделать это на моем предыдущем месте работы.Однако то, что требуется, довольно сложно:

1. Скомпилируйте версию BREW с наименьшим общим знаменателем.Версия 1.1 является базовой для всех существующих телефонов.
2. Ваш код должен быть способен обрабатывать несколько разрешений.По моему опыту, методы определения ширины и высоты экрана точны для всех телефонов.
3. Все ваши ресурсы должны быть загружены на все устройства.Для этого потребуется создать собственный загрузчик изображений, чтобы обойти определенные проблемы с устройством.Что касается звука, я знаю, что simple MIDI type 0 работает на всех, но QCP также должен работать (сам с этим не сталкивался).
4. Используйте растровые шрифты.Существует слишком много проблем со шрифтами на устройствах, чтобы было целесообразно использовать системные шрифты.
5. Разработайте структуру вашего кода как конечный автомат.Я не могу достаточно подчеркнуть это - сделайте это, и многие, очень многие проблемы никогда не материализуются.
6. Есть обходные пути для решения каждой отдельной проблемы с устройством.Это самая трудная часть!Это возможно, но эта кроличья нора невероятно глубока...

В конце концов, чем сложнее и продвинуто приложение, тем меньше вероятность, что вы сможете пойти этим путем.Некоторые свойства устройства просто не могут быть надежно обнаружены во время выполнения (например, идентификатор платформы), и поэтому требуется несколько сборок.

Answer 2

Я написал преобразование J2ME в Brew, которое используется в Javaground.Вполне возможно написать одиночный двоичный код с несколькими разрешениями.У нас есть база данных ошибок устройств, так что она может обнаруживать их с помощью идентификатора платформы устройства, а затем генерировать серию флагов, которые отмечают, какие ошибки помечены.Например, в большинстве (если не во всех) телефонов Motorola Brew есть ошибка, из-за которой входящий вызов не прерывает работу приложения до тех пор, пока вы не ответите на вызов, поэтому я использую TAPI для отслеживания входящего вызова и генерации события hideNotify (поскольку мы эмулируем Java, хотя сгенерированный код является чистым C ++).Я делаю некоторые проверки во время выполнения для версии Brew и отключаю определенные API, если это Brew 2, а не Brew 3.

Игры 3D-типа легче сделать независимыми от разрешения, поскольку вы масштабируете их с помощью программного обеспечения.

Также есть 2 отдельных API для звука, IMEDIA и ISOUNDPLAYER, ISOUNDPLAYER - более старый API и поддерживается на всех устройствах, но не имеет такого количества возможностей (вы можете воспроизводить многоканальный звук только с помощью IMEDIA).Я создаю объект IMEDIA, и он вернется к созданию объекта ISOUNDPLAYER, если не сможет получить объект IMEDIA.

Проблема с полностью универсальной сборкой заключается в том, что существует большая разница в возможностях, поэтому может стоить иметь несколько сборок, на старых устройствах объем кучи составляет всего 1 МБ (и небольшой размер экрана), и тогда вы получаете много с 6 МБ + (от 176x204 до большего).

С Brew у вас есть довольно согласованный набор ключевых значений (в отличие от Java), хотя некоторые из новых устройств имеют сенсорный экран (и вам приходится обрабатывать ввод указателя) и вращающиеся экраны.

Есть также несколько старых телефонов Nokia, которые используют режим big endian, что означает, что файлы не совпадают с обычными файлами mod (если только вы не хотите написать какой-нибудь ДЕЙСТВИТЕЛЬНО классный заголовок с префиксом языка ассемблера, который декодирует файл)

Answer 3

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

Еще одна вещь, на которую стоит обратить внимание, - это версии BREW на телефонах, на которых вы хотите запустить.Если, скажем, BREW 1.1 установлен на одном телефоне и принадлежит небольшому проценту пользователей вашего целевого рынка, нет смысла работать над его поддержкой.