Des moyens recommandés de produire une application portable entre Android et "autres plates-formes"

Je développe une application pour Android, et je pense que sa fonctionnalité pourrait être utile sur d'autres plates-formes Java-running (disons une application de bureau ordinaire – bien que j'espère que les autres plates-formes impliquées ne sont pas pertinentes pour La question à portée de main).

Il est peu probable que l'interface utilisateur soit d'une manière ou d'une autre portable (il y a juste une grande différence entre une interface utilisateur UI de 4 po et une interface utilisateur UI de souris et clavier), donc je suis assez content de ré-exécuter cela séparément.

  • L'application Android se bloque sur Lollipop
  • En attente d'un rappel asynchrone dans IntentService d'Android
  • Utilisation de ADB pour capturer l'écran
  • Exportation et exécution d'un projet Unity3D vers Android Studio
  • Quelle est la différence entre commit () et commitAllowingStateLoss () en Fragments
  • Peindre un texte bordé dans un Android Canvas
  • Cependant, les classes fondamentales de «logique métier» (ugh, horrid word) et de modèle (stockage de données) pourraient, en théorie, être réutilisées dans la gestion de l'application principale. J'ai remarqué qu'il n'y a pas beaucoup de cours que j'écris qui ne finissent pas par référencer certains bits spécifiques à l'Android (j'ai des fichiers de ressources XML, des images et des bases de données SQLite, par exemple). Fondamentalement, tout ce que j'ai écrit jusqu'ici a au moins une importation liée à Android.

    Ma question est double:

    • Quels outils sont disponibles là-bas pour m'aider à utiliser des classes et des fonctionnalités liées à Android (p. Ex., Ressources, bases de données) sur des plates-formes non-Android; et
    • Quelles classes, fonctionnalités, etc. de la plate-forme Android devrais-je éviter complètement d'utiliser (par souci de simplicité, excluons les éléments liés à l'IU) en raison de la non-portabilité, et que dois-je utiliser plutôt pour améliorer la portabilité.

    Les réponses qui consistent en "hahahaha, vous êtes condamné" sont OK, pourvu qu'il y ait une justification fournie.

    (PS, je ferais ce wiki de la communauté si cela était encore disponible, cela me semble être une question CW parfaite – une liste de conseils et d'outils de portabilité d'Android)

  • Le serveur NanoHttpd ne peut pas diffuser de grandes vidéos sur Android
  • Recommander une bibliothèque de jeux Java / Android - carte, carte, etc.?
  • View.OnClickListener, méthode ou classe?
  • Obtenir la liste de contacts et le statut de Skype dans Android
  • Y a-t-il déjà une bibliothèque OAuth2 pour Java / Android?
  • Essayer d'utiliser le thème holo dans Android ne fonctionne pas
  • 8 Solutions collect form web for “Des moyens recommandés de produire une application portable entre Android et "autres plates-formes"”

    On dirait que vous avez déjà identifié le point clé en gardant l'interface utilisateur et la logique / le modèle d'entreprise séparés. Également, sqlite est utilisé non seulement dans Android. Mais bien sûr, la façon dont vous interagissez avec lui (par exemple, SQLDBOpenHelper) est encore différente.

    Je suppose donc avoir la logique et le modèle d'entreprise aussi séparés que possible est le chemin à parcourir. Vous pouvez ensuite mettre un wrapper autour de lui (p. Ex., Le modèle "Objet d'accès aux données" qui parle du DB spécifique).

    Toujours garder à l'esprit que l'expérience des utilisateurs est la meilleure lorsque vous êtes aussi spécifique à une plate-forme que possible sur le côté de l'interface utilisateur. Exemple: il existe une application (Push & Ride) sur le marché Android, qui semble fonctionner dans un émulateur J2ME. Ainsi, l'entrée d'écran n'utilise pas le clavier normal (ou dur) de l'appareil, mais un clavier de téléphone simulé avec les combinés "abc" "def" sur les touches numériques, ce qui rend l'entrée de données un peu étrange. Cette application est surement très portable (et sa fonctionnalité est vraiment géniale), mais ça ne se sent pas juste.

    Lorsque vous voulez aller en multi-plate-forme, vous pouvez peut-être aussi regarder comme Appcelerator ou Adobe AIR

    J'ai commencé à faire quelque chose de similaire – Je voulais écrire une application pour Android, Blackberry et J2ME. De manière conceptuelle, vous pouvez calquer votre conception de sorte que les composants spécifiques à la plate-forme (UI, accès au réseau, stockage de données) soient séparés de la logique métier de base.

    En pratique, je ne trouve pas cela satisfaisant. Les problèmes auxquels j'ai été confronté tous liés à la version de base de Java sont différents dans les différentes plates-formes (dans Blackberry, il est basé sur J2Se 1.4, tandis que Android utilise Java 6 comme base). Cela a entraîné des ennuis comme

    • Ne peut pas réutiliser le code qui utilise des génériques
    • Mes classes préférées ne sont pas disponibles uniformément (par exemple, obligées d'utiliser Vector over List )

    J'ai ouvert des discussions en ce qui concerne SO ( ici et ici ), mais je n'ai pas pu aboutir à une conclusion.

    La couche de journalisation peut être rendue portable en utilisant la Façade d'enregistrement simple pour Java (SLF4J) qui est disponible pour java / log4j et pour Android .

    De plus, vous pouvez essayer cela

    http://wp7mapping.interoperabilitybridges.com/Home/Library?source=Android

    Contient de la documentation et des outils pour mapper votre application Android vers le téléphone Windows

    Aussi lisez ceci, même s'il contient des instructions spécifiques à l'interopérabilité du téléphone Android, je suis sûr qu'ils s'appliquent également à d'autres plates-formes.

    http://windowsphone.interoperabilitybridges.com/media/49652/wp7_guide_for_android_application_developers.pdf

    Ce que je fais, c'est créer un service Web en dehors de l'application Android qui peut être utilisée par l'application Android ainsi que d'autres systèmes (sites Web, applications Windows, applications iphone, etc.).

    Un simple service Web REST qui prend en charge JSON est un bon exemple pour récupérer des données et également insérer / mettre à jour des données. JSON est particulièrement adapté car il est si léger et ne nécessite pas beaucoup de bande passante, ce qui est idéal pour les connexions mobiles lentes.

    De cette façon, vous pouvez stocker vos modèles / stockage de données en dehors de l'application Android, et cela peut être utilisé par d'autres applications très facilement.

    La couche de base de données peut être rendue plus portable en utilisant le jdbc Android ou en utilisant une implémentation relationnelle d'objet / couche d'abstraction de base de données / application ActiveRecord .

    Est-ce que quelqu'un a essayé de créer android.database (.sqlite) exécutable sur un système non-Android?

    Si vous séparez soigneusement la logique métier de l'interface utilisateur et des avantages Android, vous pourrez la réutiliser dans un environnement de bureau. L'Android est tout à fait différent de celui de l'intialisation et du cycle de vie de l'application: la création et la configuration abstraite de BL sont également nécessaires.

    Un motif utile à cette fin serait l'injection de dépendance. Il existe différents cadres, et certains sont plus adaptés à l'Android (comme la roboguice) ou au bureau (Spring ou Picocontainer ou Guice).

    Les applications Android sont très limitées en mémoire, ce qui limite les frameworks que vous pouvez utiliser là-bas. Ainsi, vous devrez peut-être également abstraire le stockage des données (hibernate est pratique sur le côté du bureau / serveur, mais trop lourd pour les périphériques mobiles)

    Je suis enclin à suggérer d'essayer les nouvelles extensions natives pour Adobe Air. Il vous permet de créer un morceau de code natif spécifique à un périphérique et de le connecter à la structure Air, en l'accédant comme vous voudriez d'autres objets dans Air. (Voir http://www.adobe.com/devnet/air/articles/extending-air.html ). Cela vous permet de conserver le code Android seulement, puis de le remplacer par le code iOS, Windows DLL, etc., au besoin.

    Cela ne résout pas le problème de la traduction du code Java dans d'autres langues / plates-formes, bien sûr. Pourtant, une partie de la logique que vous faites de manière native peut très bien exister déjà en plate-forme en avion. Par exemple, vous pouvez accéder à la caméra dans Air dans tous les systèmes d'exploitation pris en charge sans écrire de code spécifique à l'appareil.

    Vous devrez probablement aller au-delà des classes Air actuelles, donc certains exemples peuvent aider:

    • Reconnaissance vocale Android
    • Batterie iOS
    • Didacticiel Windows et Mac
    • Tutoriel NE
    coAndroid est un fan Android de Google, tout sur les téléphones Android, Android Wear, Android Dev et Android Games Apps.