2009-06-19 7 views

Répondre

4

Cela ne va pas être possible pour autant que je comprends votre question - le format binaire pour l'iPhone et Java ne sont pas compatibles - et même pour une bibliothèque native sur un appareil BlackBerry. Ce n'est pas comme construire pour OS X où vous pouvez utiliser Java de manière impromptue, l'iPhone ne supporte pas Java.

La meilleure idée est probablement de vous construire la bibliothèque en Objective-C, puis le port à Java qui est une transition plus facile que d'aller dans l'autre sens. Si vous programmez pour Objective-C et assurez-vous que le code n'a pas de fuites de mémoire, les modifications ne sont pas si complexes.

Si vous gardez la structure de vos classes même alors vous devriez trouver l'entretien beaucoup plus simple - Correction d'un bug dans Java et vous devriez trouver facile à vérifier pour le même bogue dans les méthodes ObjC etc.

J'espère que cela aide - désolé que ce ne sont pas toutes de bonnes nouvelles.

+0

Cela aide. J'ai édité mon message un peu. Je suis plus à la recherche d'une meilleure pratique que la possibilité de partager un binaire. Le guide de fuite de mémoire est exactement le genre d'information que je cherche. –

+0

Je suis d'accord avec teabot - tout ce que vous pouvez faire pour rendre le design similaire sera une grande victoire. – Grouchal

4

Comme Grouchal l'a mentionné - vous ne pourrez pas partager les composants physiques de votre application entre les deux plates-formes. Cependant, vous devriez être capable de partager la conception logique de votre application si vous la séparez soigneusement en couches hautement découplées. C'est toujours une grande victoire car la conception de l'application logique représente probablement une grande partie de votre effort de développement.

Vous pouvez viser à envelopper les sections des API spécifiques de la plate-forme (iPhone SDK, etc.) que vous utilisez avec vos propres interfaces. Ce faisant, vous cachez efficacement les bibliothèques spécifiques à la plate-forme et simplifiez la gestion de votre conception et de votre code lorsque vous gérez les différences entre les plates-formes.

Avec cela en place, vous pouvez écrire votre code d'application de base de sorte qu'il semble très similaire sur deux plates-formes - même si elles sont écrites dans des langues différentes. Je trouve Java et Objective-C très similaires sur le plan conceptuel (au moins au niveau auquel je l'utilise) et je pense être en mesure d'atteindre la parité avec au moins les éléments suivants:

  • Un ensemble presque identique Java et les classes Objective-C avec les mêmes noms et responsabilités
  • Java/classes Objective-C avec des méthodes de même nom
  • Java/méthodes Objective-C avec les mêmes responsabilités et les implémentations logiques

Ce seul rendre l'application plus facile à comprendre plates-formes croisées. Bien sûr, le code sera toujours très différent sur les bords - c'est-à-dire lorsque vous commencerez à traiter la vue, le thread, le réseau, etc. Ces problèmes seront traités par vos enveloppes API qui, une fois développées, devraient avoir des interfaces relativement statiques.

Vous pourriez profiteront également si vous développeurs plus tard, d'autres applications qui doivent être livrés aux deux plates-formes que vous trouverez peut-être que vous pouvez réutiliser ou étendre vos emballages API.

3

Si vous écrivez une application de type client-serveur, essayez de garder autant de logique que possible sur votre serveur. Conservez la quantité de logique métier supplémentaire sur l'appareil au minimum. Plus vous pouvez simplement traiter l'appareil en tant que couche de vue, moins vous devrez faire de portage.En outre, suivre les mêmes conventions de nommage et la même structure de paquets sur tous les projets est d'une aide précieuse, en particulier pour votre code de structure. Les paradigmes de l'interface utilisateur et de l'utilisabilité pour BlackBerry et iPhone sont si différents qu'il ne sera pas possible dans la plupart des cas de porter directement ce type de logique entre les applications. La plus grosse erreur que l'on puisse faire (à mon avis) est de tenter de transposer une expérience utilisateur conçue pour une plate-forme mobile à une autre. La façon dont les gens interagissent avec BlackBerry vs iPhones est très différente, alors préparez-vous à réorganiser votre expérience utilisateur pour chaque plate-forme mobile sur laquelle vous souhaitez déployer.

J'espère que cela vous sera utile.

+0

Vous avez raison sur la grosse erreur et en vous assurant que l'interaction de l'utilisateur est cohérente sur chaque plate-forme. Vous remarquez que mettre autant de code sur le serveur que possible ne fonctionne pas toujours - cela dépend de la bonne connexion de l'utilisateur. Je pense que si votre solution consiste à faire en sorte que le serveur continue de fonctionner, il vaut mieux écrire une application Web. Si vous allez avoir une application locale, l'expérience de l'utilisateur n'est pas bonne si le serveur a besoin de faire des choses essentielles et que l'utilisateur n'a aucun signal. – Grouchal

0

Il est possible d'écrire du code C++ qui fonctionne à la fois dans une application native BB10 et une application iOS. XCode aurait besoin de voir les fichiers C++ comme du code ObjectiveCPP.

Je travaille actuellement sur une telle tâche dans mon temps libre. Je ne l'ai pas encore suffisamment complété pour montrer ou savoir si c'est vraiment possible, mais je n'ai pas encore rencontré de barrages routiers.

Vous devrez vous discipliner pour écrire de bonnes abstractions w/abstraction multi-plateformes conçues pour des fonctionnalités spécifiques à la plate-forme. Mon modèle général est que j'ai "classe Foo" pour faire des choses multi-plateforme, et une "classe FooPlatform" pour faire des trucs spécifiques à la plate-forme. La classe "Foo" peut appeler la classe "FooPlatform" qui résume tout ce qui est spécifique à la plate-forme.

Le code multiplate-forme brut n'est pas compilable par lui-même. Des projets BB10 et XCode distincts sont créés dans leurs IDE respectifs. Chaque projet implémente une "classe FooPlatform" fine (quelques [douzaines] lignes) et référence le code multiplate-forme brut.

Lorsque je reçois quelque chose qui fonctionne que je peux montrer, je vais poster à nouveau ici ...

+0

Voir aussi la page officielle de RIM «Porting apps from iOS to BB10»: http://developer.blackberry.com/native/beta/documentation/porting_ios_intro.html Lisez les sous-sujets de cette rubrique ... – swooby

Questions connexes