6
votes

Quel type d'applications Android sont les plus difficiles à soutenir (l'inquiétude de fragmentation)

a vu un blog intéressant et un peu effrayant poster l'autre jour. C'était une collection d'appareils Android de Développeur mobile qu'ils testent. C'était environ 400. -> http://feedproxy.google.com.com / ~ r / techcrunch / ~ 3 / 0lyGozd0l0u /

Je suis un gars solo, il n'ya aucun moyen de soutenir une application s'il a fallu même une fraction de ce type de test et de soutien. Je sais que vous pouvez imiter de nombreux appareils, mais il y aurait encore beaucoup de temps à tester sur plus d'une poignée d'AVD. On dirait que cela pourrait être un cauchemar.

Pour ceux qui ont été à mâcher sur Android pendant un certain temps, toutes les données ou conseils sur les applications gérent les différents appareils les plus faciles? Le développeur dans le blog a fait beaucoup de jeux, sont ceux qui sont les plus difficiles?

Je suis sûr que Hello World fonctionne très bien sur tous les appareils Android, mais il n'y aura pas de nombreux preneurs, vous savez?

Il serait bon de savoir avant de commencer une application ambitieuse qui, par exemple, GPS est facile, cohérent, mais le code natif pourrait être un cauchemar, ou des images fixes sont correctes, la vidéo est désagréable. SMS, base de données, accès SDCard? OpenGL, gestes, etc. Ce genre de chose ...

Si quelqu'un a des conseils généraux ou surtout une liste la plus facile à la plus difficile qui pourrait être très utile pour les débutants américains.

merci

P.s. Et s'il vous plaît ne dites pas "Développer sur iOS ...", ce n'est pas la question et pire qu'il est trop prévisible. ; -)


4 commentaires

Cette question n'appartient pas à Stackoverflow. Je ne pense pas que vous trouverez n'importe où dans ce type de lignes directrices, vous devriez être plus préoccupé par la suite de bonnes règles de construction d'applications Android. Ne commencez pas à vous inquiéter de supporter chaque appareil jusqu'à ce que vous construisiez réellement quelque chose qui pousse les limites de la plate-forme Android.


L'endroit le plus facile pour se tromper ici n'est pas tant avec des appareils différents comme avec différentes versions. Tant que vous vérifiez les API que vous utilisez pour vous assurer que vos versions MIN / Max SDK sont correctes (et coller des API documentées plutôt que d'être tentées par des hacks), les choses devraient aller bien.


Aussi: android.stackexchange.com est un meilleur forum pour discuter de dispositifs particuliers. Il est donc ciblé de questions de programmation spécifiques. Aussi programmeurs.stackexchange.com est bon pour les questions d'assurance qualité et les conseils de programmeur.


L'article suivant peut éventuellement répondre à votre question. À la fin de l'article, les options QA sont mentionnées: Blog. lemberg.co.uk/android-apps-qa#.ub3-z-z-d7kso


3 Réponses :



0
votes

Les conseils généraux déjà donnés, construisant quelque chose de solide et qui a l'air bien, c'est un bon point de départ. En général, plus votre application est la plus facile, il est plus facile de convaincre qu'il fonctionnera sur un grand nombre d'appareils après avoir testé sur un sous-ensemble principal des meilleurs vendeurs.

La zone principale qui devient difficile est lorsque vous interagissez avec d'autres applications telles que la galerie, le carnet d'adresses, etc. Toute place L'OEM peut / modifiera les applications intégrées que vous souhaitez intégrer avec peut entraîner des problèmes. Ce n'est pas un problème pour la plupart des applications. Spécifiquement, j'ai travaillé sur une application de messagerie qui nécessitait des tests sur tous les combinés d'un transporteur spécifique; Ce qui n'est pas le genre de projet que je m'attendais à ce que quelqu'un solo prenne de toute façon.

La réponse simple est donc évitée l'intégration avec d'autres applications, le traduisant plus comme la boîte à sable iOS. Malheureusement, cela supprime une partie de la valeur Android, mais c'est le moyen le plus simple d'éviter les problèmes de fragmentation.

De manière réaliste, bien que vous ayez besoin de tester sur certains appareils réels s'il est important que votre réussite commerciale avec votre demande. Personnellement, je dirais que le minimum des tests serait au combiné de chaque major OEM à la fois de pain d'épice et de ICS, et s'il s'agit d'une application en réseau sur chaque porteur. Ce niveau d'obligation financière n'est pas réaliste pour une personne qui commence à commencer, à quel point vous venez de finir par utiliser vos utilisateurs en tant que testeurs.


0 commentaires

0
votes

Eh bien, puisque vous aimez les articles effrayants, voici 2 autres articles effrayants (et informatifs):

http://opensignalmaps.com/reports/fragmentation.php
http://burnsmod.com/development/2012/05 / 01 / Android-fragmentation-Hurts - tout le monde /

En règle générale, tout ce qui utilise un accès matériel à bas niveau est un cauchemar, donc dans la mesure du possible, collez avec les API Java pour accéder à la fonctionnalité matérielle.

Les API de la caméra, qu'il soit haut de niveau ou de niveau bas peut être problématique. Par exemple, j'ai expérimenté des problèmes spécifiques à un appareil avec les API de l'appareil photo de haut niveau lorsqu'ils sont invoqués via starttactivityForresult avec android.media.action.image_capture . .

Plus d'infos sur les bugs spécifiques à un périphérique ici:

y a-t-il une compilation de bugs spécifiques à un appareil pour Appareils Android?
Bugs spécifiques à l'appareil Android

Votre meilleur pari est de construire pour les périphériques "normaux", puis en fonction de la fréquence des plaintes des utilisateurs d'enquêter sur des périphériques spécifiques.


0 commentaires