Application unique pour construire plusieurs appareils mobiles

Question

Est-il possible d'avoir une application build binaire pour plusieurs appareils mobiles (sur BREW plate-forme), plutôt que de faire construire pour chaque appareil à l'aide de construire script avec la compilation conditionnelle.

En particulier est est possible d'utiliser seule application BREW pour construire des résolutions d'écran multiples?

Notez que le but est d'avoir une seule construction binaire. Si ce n'était que d'avoir une seule base de code, une compilation conditionnelle et un script de construction intelligent feraient l'affaire.

Answer 1

Oui, il est possible, nous avons pu le faire à mon ancien lieu de travail. Ce qui est nécessaire est cependant difficile:

1. Compilez pour 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 être capable de 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 faire votre propre chargeur d'image personnalisé pour contourner certains problèmes de périphériques. Pour le son, je sais que le simple type MIDI fonctionne sur tout mais le QCP devrait aussi fonctionner (pas d'expérience moi-même).
4. Utilisez les polices bitmap. Il y a trop de problèmes de périphériques avec les polices pour le rendre utile en utilisant les polices du système.
5. la conception de votre structure de code comme une machine à états finis. Je ne peux pas insister assez sur cela - faire ceci et beaucoup, beaucoup de problèmes ne se matérialisent jamais.
6. Avoir des solutions de contournement pour chaque problème de périphérique. C'est la partie difficile! C'est possible mais ce trou de lapin est incroyablement profond ...

En fin de compte, plus l'application est complexe et avancée, moins il est probable que vous puissiez vous y rendre. 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 (tel que l'ID de plate-forme) et plusieurs builds sont alors requis.

Answer 2

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 builds pour eux. C'est aussi un itinéraire beaucoup plus rapide car vous pourrez supporter tous les combinés que vous voulez supporter avec beaucoup moins de complexité. Une autre chose à voir est les versions BREW sur les combinés que vous souhaitez lancer. Si disons BREW 1.1 est sur un combiné et que cela est détenu par un petit pourcentage dans votre marché cible, cela n'a pas de sens de travailler pour le soutenir.

Answer 3

J'ai écrit un J2ME à la conversion Brew qui est utilisé à Javaground. Il est tout à fait possible d'écrire plusieurs résolutions, un seul code binaire. Nous avons une base de données de bogues de périphériques afin qu'il puisse détecter via l'ID de plate-forme l'appareil et ensuite générer une série de drapeaux qui marquent quels bogues sont marqués. Par exemple, la plupart (sinon la totalité) des téléphones Motorola Brew ont un bug où un appel entrant n'interrompt pas l'application jusqu'à ce que vous répondiez à l'appel, donc j'utilise TAPI pour surveiller un appel entrant et générer un événement hideNotify (puisque nous sommes émuler Java, bien que le code généré soit pur C++). Je fais quelques vérifications à l'exécution pour la version Brew, et je désactive certaines API si c'est Brew 2 plutôt que Brew 3.

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

Il existe également 2 API distinctes pour le son, IMEDIA et ISOUNDPLAYER, ISOUNDPLAYER est l'ancienne API et est supportée sur tous les appareils mais ne dispose pas de toutes les fonctionnalités (vous ne pouvez utiliser l'audio multicanal qu'avec IMEDIA). Je crée un objet IMEDIA, et il retombera pour créer un objet ISOUNDPLAYER s'il ne peut pas obtenir l'objet IMEDIA. Le problème avec une construction totalement universelle est qu'il y a une grande différence de capacité, donc ça peut valoir la peine d'avoir quelques builds, les plus anciens n'ont que moins de 1 Mo de tas (et une petite taille d'écran), et puis vous obtenez beaucoup avec 6MB + (176x204 à plus grand). Avec Brew, vous disposez d'un ensemble de valeurs de clés assez cohérent (contrairement à Java), bien que certains des nouveaux périphériques soient des écrans tactiles (et vous devez gérer l'entrée du pointeur) et des écrans rotatifs.

Il y a aussi quelques anciens téléphones Nokia qui utilisent grand mode endian qui signifie les fichiers ne sont pas les mêmes que les fichiers mod normaux (sauf si vous voulez écrire une tête de préfixe de langage assembleur vraiment cool qui décode le fichier)