Application unique pour plusieurs appareils mobiles

Question

Est-il possible de créer une seule application binaire pour plusieurs appareils mobiles (sur la plate-forme BREW ) , plutôt que de créer une construction distincte pour chaque périphérique à l'aide d'un script de construction avec une compilation conditionnelle.

En particulier, est-il possible d'utiliser une seule application BREW pour plusieurs résolutions d'écran?

Notez que l'objectif est d'avoir une seule construction binaire . S'il ne s'agissait que d'une base de code unique, une compilation conditionnelle et un script de construction intelligent feraient l'affaire.

Answer 1

Oui, c’est possible, nous avons pu le faire sur mon ancien lieu de travail. Ce qui est nécessaire est cependant délicat:

1. Compilez pour obtenir la version BREW du plus petit commun dénominateur. La version 1.1 est la base de tous les combinés actuels.
2. Votre code doit pouvoir gérer plusieurs résolutions. Les méthodes de détection de la largeur et de la hauteur de l’écran sont précises pour tous les combinés, selon mon expérience.
3. Toutes vos ressources doivent être chargées sur tous les appareils. Cela nécessiterait de créer votre propre chargeur d'images personnalisé pour résoudre certains problèmes liés aux périphériques. Pour le son, je sais que le type MIDI simple 0 fonctionne sur tout, mais le QCP devrait également fonctionner (aucune expérience de ce type moi-même).
4. Utilisez des polices bitmap. Il y a trop de problèmes de périphérique avec les polices pour que cela vaille la peine d'utiliser les polices système.
5. Concevez votre structure de code comme une machine à états finis. Je ne saurais trop insister là-dessus. Faites ceci et de nombreux problèmes ne se matérialiseront jamais.
6. Disposez de solutions de contournement pour chaque problème lié à un périphérique. C'est la partie difficile! C'est possible mais ce trou de lapin est incroyablement profond ...

Au final, plus l’application est complexe et avancée, moins vous aurez de chances de choisir cette voie. Certaines propriétés de périphérique ne peuvent tout simplement pas être détectées de manière fiable au moment de l'exécution (telles que l'ID de la plate-forme). Plusieurs générations sont alors nécessaires.

Answer 2

J'ai écrit une conversion J2ME à Brew utilisée par Javaground. Il est tout à fait possible d'écrire plusieurs résolutions, un seul code binaire. Nous disposons d'une base de données de bogues de périphériques, de sorte qu'elle puisse détecter le périphérique via la plate-forme id, puis générer une série de drapeaux indiquant les bogues marqués. Par exemple, la plupart (sinon tous) des téléphones Motorola Brew ont un bogue dans lequel un appel entrant n'interrompt pas l'application jusqu'à ce que vous répondiez à l'appel. J'utilise donc TAPI pour surveiller un appel entrant et générer un événement hideNotify (car nous sommes émulant Java, bien que le code généré soit pur C ++). Je fais quelques vérifications au moment de l'exécution pour la version Brew et désactive certaines API s'il s'agit de Brew 2 plutôt que de Brew 3.

Les jeux de type 3D sont plus faciles à rendre indépendants de la résolution puisque vous effectuez une mise à l'échelle dans un logiciel.

De plus, il existe deux API distinctes pour le son, IMEDIA et ISOUNDPLAYER. ISOUNDPLAYER est l'ancienne API. Elle est prise en charge sur tous les appareils mais ne dispose pas de autant d'installations (vous pouvez uniquement utiliser l'audio multicanal avec IMEDIA). Je crée un objet IMEDIA et il en résultera un objet ISOUNDPLAYER s’il ne parvient pas à obtenir l’objet IMEDIA.

Le problème avec une version totalement universelle est qu’il existe une grande différence de capacité. Il peut donc être intéressant de disposer de quelques versions, les appareils plus anciens n’ayant que moins de 1 Mo de heap (et une petite taille d’écran), obtenez beaucoup avec 6 Mo + (176x204 à plus grand).

Avec Brew, vous disposez d’un ensemble relativement cohérent de valeurs de clé (contrairement à Java), bien que certains des nouveaux périphériques soient un écran tactile (vous devez gérer la saisie par pointeur) et des écrans en rotation.

Certains anciens téléphones Nokia utilisent également le mode big endian, ce qui signifie que les fichiers ne sont pas identiques aux fichiers mod classiques (à moins que vous ne souhaitiez écrire un en-tête de préfixe de langage assembleur vraiment cool qui décode le fichier)

Answer 3

Une autre idée pourrait être de diviser les combinés en 2 à 4 catégories en fonction des dimensions de l’écran et de créer des versions correspondantes. C’est également un itinéraire beaucoup plus rapide, car vous pourrez prendre en charge tous les combinés que vous souhaitez prendre en charge avec une complexité bien moindre.

Une autre chose à voir est la version de BREW sur les combinés que vous souhaitez lancer. Si BREW 1.1 concerne un seul appareil et qu’il appartient à un petit pourcentage de votre marché cible, il n’a aucun sens de travailler pour le prendre en charge.