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

Question

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

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

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

Answer 1

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

1. Компиляция для версии BREW с наименьшим общим знаменателем. Версия 1.1 является основой для всех существующих телефонов.
2. Ваш код должен обрабатывать несколько разрешений. Методы определения ширины и высоты экрана являются точными для всех телефонов в моем опыте.
3. Все ваши ресурсы должны загружаться на все устройства. Это потребует создания собственного пользовательского загрузчика изображений для решения определенных проблем с устройством. Что касается звука, я знаю, что простой 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 МБ кучи (и небольшой размер экрана), а затем вы получить много с 6MB + (176x204 и более).

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

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

Answer 3

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

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