9
votes

Android SDK vs. Adobe Air: Avantages et inconvénients?

Quelqu'un a-t-il blogué à propos de cette comparaison ou quelqu'un veut-il lui donner un tir ici? Serait bien de voir des réflexions sur Adobe Air sur Android par rapport au SDK Android "Native" (en Java).

EDIT: malgré quelques points de vue et aucune réponse, je quitte cette question ici puisque c'est un sujet qui doit être couvert à un moment donné ... mais si cela ne fait aucune attention, je n'ai aucune attention ll le supprimer dans quelques jours.


0 commentaires

3 Réponses :


11
votes

Je pense que cela est finalement très similaire à la question de savoir s'il faut utiliser Air ou Java pour une application de bureau. En fin de compte, cela revient à trois points:

  1. L'air fait-il tout ce dont vous avez besoin? Évidemment, le SDK Android vous donne un accès complet aux capacités de l'appareil, mais vous ne le faites pas, afin de rester portable. Par exemple, l'air peut ne pas supporter d'intention, du moins initialement (je ne pense pas qu'Adobe a annoncé encore une voie ou l'autre). En outre, l'air nécessite Android 2.2. Si ces limitations sont gênantes, le SDK Android et régulier peut être le meilleur.

  2. cherchez-vous à faire quelque chose qui serait bien adapté à faire en flash? Si vous planifiez une application de design-lourd avec des animations, une vidéo, un son ou similaire, puis la construire en flash peut être significativement plus facile que d'utiliser Java. D'autre part, si votre application sera pure du code en utilisant uniquement des composants visuels standard, il pourrait ne pas faire une lèche de différence quelle plate-forme que vous utilisez. Ou sur la main de préhension, si vous auriez des animations flash existantes ou similaires, essayez de les chaussettes dans une application Java sera gênante.

  3. ciblez-vous d'autres plates-formes en plus d'Android? Si tel est le cas, l'air peut être une grosse victoire, car le contenu de l'application de la même application doit fonctionner sous Windows, Mac, Linux et plus loin, d'autres périphériques qui envisagent de soutenir l'air, comme Blackberry, des téléviseurs, des joueurs de disques Blu-ray, etc. Si vous ne ciblez que Android, l'air peut perdre une partie de son appel.

    J'espère que cela aide certains. De manière réaliste, sauf si vous êtes effectivement verrouillé d'utiliser de l'air, car vous avez besoin de quelque chose qu'il ne vous donne pas, ou bien verrouillé efficacement dans l'utilisation de l'air, car vous faites du travail lourd-lourd et vous avez besoin de l'outillage, puis je pense que les avantages et Les inconvénients des deux SDK sont en grande partie des questions de commodité. L'une ou l'autre plate-forme fonctionnera, il est donc simplement simplement qui vous mènera à la ligne d'arrivée le plus rapide et le plus fiable.


1 commentaires

Très bonne réponse. En ce qui concerne votre conclusion, j'espérais que vous ne diriez pas que :) +1



5
votes

Un problème à considérer est la compatibilité avec les appareils Android. Les téléphones intelligents fantaisistes et les téléphones bon marché courent à Android, mais ils n'ont pas les mêmes capacités. Même si l'application est simple ou peut être faite magnifiquement dans l'air, il est pertinent de mentionner que l'air n'est pas compatible avec tous les appareils Android.

Certains dispositifs très populaires sont vendus (tels que Samsung Ace et d'autres périphériques «pas chers») utilisent des puces armv6, ainsi que de l'air ou du flash ne sont pas compatibles avec ces architectures, même lorsqu'elles fonctionnent sur Android 2.2 ou plus.

Air est intéressant car le même développement fonctionne dans différentes technologies, mais considérons que l'air ne fonctionne pas non plus sur des iPhones "anciens", sa seule garantie de travailler sur de nouvelles technologies avec de gros processeurs.

Cochez cette page Adobe Link http://www.adobe.com/flashplatform/certified_devices/

Air doit être exclu dans votre décision de technologie si dans vos exigences que vous ciblez autant de téléphones que possible, y compris celles qui ne sont pas si fantaisistes ou nouvelles.


0 commentaires

5
votes

J'ai de l'expérience avec l'air surtout et peu avec Android SDK lorsque je construisais une extension indigène à l'air. Mon plus grand obstacle avec l'air est l'immaturité, ce sont des insectes et c'est un comportement incohérent. Oui, vous pouvez aller à la page brillante sur adobe.com et voir à quel point l'air est cool ... toutes lumineuses avec des tonnes de fonctionnalités qui semblent couvrir tous vos besoins. Pourtant, une fois que vous commencez à construire votre application, vous trouverez de nombreuses surprises laides:

  1. texte étape dans ne fonctionne pas de manière appropriée. lien Outre ce bogue Stetageext a peu d'autres bugs, comme le comportement dans Scroller pour instance.

  2. Le son () ne joue pas le flux (il ne fait que sur l'émulateur). Link

  3. manque de fonctionnalités telles que AEC rend l'air inutile dans une liste complète des applications de discussion, car vous entendrez l'écho et le bruit de hurlement. Lien

  4. SDK surchargé (et immature pour mobile) Flex SDK (J'espère que les gens de Apache le réécrireont de 0 et le rendent plus gérable).

  5. No H264 Support sur les périphériques iOS: lien ( Oui, je sais que c'est un problème d'Apple, qu'ils veulent contrôler la livraison HD sur leur plate-forme, c'est toujours un problème d'Adobe, car ils ne pouvaient pas se battre correctement d'apporter leur technologie à l'avant-plan).

  6. L'objet sonore ne prend pas de bidon variable (seulement 44,1 kHz est possible). Échantillons de codec SpeeX flash "de la deuxième génération" à 16 kHz. Maintenant, essayez de jouer à cet endroit et vous apprécierez un cirque drôle. À la fin, vous devrez écrire votre propre algorithme de mise à l'échantillon.

    Je suis sûr que les gens vont ajouter davantage à cette liste. Donc, ma réponse serait SDK natif est plus préférable pour tout ce qui est grave. Vous ne travaillerez pas comme une personne d'assurance qualité avec elle - essais d'innombrables petits exemples essayant de comprendre pourquoi une fonctionnalité aérienne ne fonctionne pas, une connexion Internet se déplaçant pour des réponses et une base de données d'Air Bug: seulement pour trouver que des bugs critiques sont assis à partir de la libération libérer. C'est mon expérience avec l'air. SDK natif rend votre candidature non vraiment "plate-forme inter-plate-forme", mais Air SDK ne peut pas réclamer ce titre de toute façon pour quelque chose de plus sérieux que quelques exemples de "répertoire des employés". Et si vous devrez construire pour l'autre plate-forme, vous allez simplement utiliser des outils natifs.

    GL.


0 commentaires