Une application, plusieurs APK ?

Tout à fait d'accord. Cet ajout a été demandé par les développeurs conscients du surpoids le leur application incluant _toujours_ des graphismes inutiles pour un utilisateur final. Ce n'est pas _la_ règle à suivre quand on développe que de scinder son application, juste une possibilité de plus pour les développeurs voulant optimiser l'espace disque de son application.

Ahahah , j'ai toujours adoré ce genre de réponse pourrie : "si d'abord , moi je sais mais je le dirai pas , nananère"...grandis un peu minot...

T'aurais pas du, je suis persuadé qu'il avait raison...

En fait, je reviens sur ce que nous venons de dire : Le multiple Apk ne prend pas en compte la langue :)

J'avais pas pensé au piratage, mais c'est un bon point. Par contre, j'avais pensé aux autres markets. S'ils ne font pas la même chose, ils ne pourront pas proposer les applis pensées en multi apk, ou alors à un nombre plus limité de clients. Et s'ils veulent faire la meme chose, ils vont souffrir du temps de retard.

oh putain, le premier commentaire de Dralliw argumenté, bon sur une erreur de frappe mais il faut souligner l'exploit.  Pour info "rajouté en plus" n'est pas français (tu as déjà rajouté en moins?)

Pourquoi il marque Willard ! J'ai mis mon pseudo "Obvius" ... Ôo

"pourquoi Google n’exige pas de réellement valider l’implémentation d’Android sur un terminal avant de lui donner accès à l’Android Market ? Je suis quasiment certain que le nombre de bugs serait moindre !" Oui c'est vrai ! Pourquoi Google ne vérifie pas comme Apple que l'application fonctionne sur les plus de 200 Mobiles Android hein ? POURQUOI !

Ça se voit que tu es encore à l'école pour apprendre l'orthografffff

Près de 300 tweets sur les dernières 24 heures...y'a comme une odeur de nolife :p Y prends le temps de se laver au moins? Ou il pousse le mot troll jusqu'à son paroxysme et vit dans sa chambre qu'il appelle "sa grotte"?

Je ne connais pas ce jeu mais c'est une évidence. Je suis dev iOS, pas de jeu cela dit, d'appli "classiques", et je te garanti que le poids explose avec l'appli universelle. Après si le jeu que tu cites est mal optimisé sur Android ou mal géré...

Ce que vous demandez dans cet article est que google instaure un système de validation d'application comme le fait apple ?

Bonne Idée, d'un point de vue développement il est parfois plus "facile" de générer plusieurs APK que de gérer les différents version d'affichage même si la gestion des "ressources" (ressource du dossier res, hdpi, ldpi etc...) est quand même pas trop mal foutue, il arrive bien souvent que des implémentations différentes soit faites au niveau du code surtout pour de l'affichage généré qui est bien souvent différent entre tablettes et smartphones. @Tijee je veux bien essayer, mais pour cela une version gratuite serait sympa ;) Sinon une version française serait plus qu'appréciable, tudieu !

Il faut savoir que Apple a fait une distinction bien clair entre les appli iphone et les appli ipad. Et on voit pas les devs se plaindre au contraire. On exploite pas un écran de 4.5" et 9 - 10" de la même manière. Après si y'a des devs qui font je dirai les cons a faire des apps en fonction de la mise à jours ou des tels ben faut les laisser... Mais le but de google n'était de faire tout ce que t'as écrit. A google de mieux contrôler les appareils certifier...

Pourquoi ne pas bannir son IP (si possible après tout j'y connais rien moi) ? Franchement ça irait beaucoup plus vite et il pourra arrêter de nous casser les cou**les. Va juste falloir qu'il trouve quelqu'un d'autre à aller faire chier s'il à que ça à faire de sa vie...

Je cherchais quelque chose à répondre, mais finalement non, je me contenterai de lire les commentaires faits au tien comme tu me le suggères.

Hello, moi je n'y connais rien, j'attends juste GB sur mon Desire, mais quand je vois le nombre de fautes d'orthographe ou de frappe, j'ai envie de vomir. Donc, je vous encule tous avec une poignée de graviers.

Les devs pouvaient déjà faire ça.  L'objectif des APK multiples c'est plutôt pour contrer la prolifération des apps publiées plusieurs fois dans le Market pour différent types de terminaux.  De cette façon tu peux mettre ton jeu en Standard pour les petits terminaux, HD pour les plus grands et THD optimisé pour Tegra sous la même publication et l'utilisateur n'a pas à chercher laquelle il doit télécharger. Et toi tu ne les oblige pas à télécharger des Textures HD et à remplir la mémoire d'un petit terminal.

La technique du téléchargement au premier lancement a aussi l'avantage pour les éditeurs de consommer la courte période pendant laquelle on peut se faire rembourser le jeu. Dans le cas des jeux payants bien sûr.

Je vois un autre avantage, c'est au niveau des formats de textures. Imaginons un jeu qui ait 10 mo de textures S3TC pour Tegra 2, 10 mo de textures PVRTC pour PowerVR et 10 mo de textures ETC1 pour le reste. Ça va permettre d'alléger le téléchargement :) Certains jeux ont cependant trouvé une solution pour ce problème et n'incluent aucune texture dans l'APK, ils les téléchargent au premier lancement.

Je viens de relire l'article modifié, la plupart des points que je soulevais ne sont plus valables. RAS donc :-)

La version pour smartphone est déjà publiée https://market.android.com/details?id=com.thomasgallinari.dndcharactersheet. Pour la version tablette, il faudra encore attendre un peu ;)

Je sais que fragmentation = duplication du travail. Mais je ne comprends pas cette guerre. Je fais une application, si je veux qu'elle s'affiche différement sur 3" et 10", je DOIS faire du travail. Il n'y a pas à lutter là dessus! Android permet de ne faire qu'une appli qui marchera sur 3 et 10", mais si on veut utiliser l'écran de manière optimale sur 10", il FAUT faire un travail supplémentaire. C'est peut-être de la fragmentation pour toi, mais c'est inévitable! C'est pareil sur iOS d'ailleurs, les applis doivent être développées pour iPhone et iPad de 2 façons différentes. Archos n'a(vait) pas le market car ils n'ont pas les specs demandées par Google. C'est pas une exigence de Google de valider l'implémentation d'Android sur un terminal, peut-être ? Je comprends ce que tu veux dire, que cette nouvelle option sera peut-être mal utilisée par les éditeurs, et que ça va désservir Android. Certes. Mais ton article parle de choses techniques qui sont mal expliquées ou interprétées, et les exemples ne sont pas adéquats. C'est dommage. @e22fe01284fd687de7664eab89fbbbff:disqus : t'es un brin chiant toi non ? Tu veux pas argumenter au lieu de sans cesse critiquer systématiquement tous les posts que tu vois, en finissant par botter en touche du genre "si tu réfléchissais, tu comprendrais" ?

Alors toi tu n'as meme pas compris mon message ... dommage. Ps: "trois franc, six sous" ? Je te rappelle qu'on est passé a l'euros depuis deja longtempss, donc sort dd ton trou stp.

hey bien casses-toi l'ami... Rien ne t'obliges a rester, et nous on sera content :)

Arrêtez de répondre à dralliw svp

Le meilleur moyen d'arrêter les troll de ce genre, c'est de juste les ignorer, même si on a envie de coller des baffes, car ce qui le motive à continuer à polluer c'est justement de pouvoir provoquer les gens. Passez à autre chose ...

Mdr ... tu es le genre de personne qui pense que les gamins c'est con ? Bref ... moi je connais mes applis android et je n'a pas besoin que tu les connaisse. Tu es peut etre bon, je ne sais pas, je ne te connait pas, mais ton article ne fait que crier le contraire

Arrête de nous les briser. Il parle de chez PC, et non pas de chaque plateforme. Toi qui crois mieux savoir que tout le monde, je t'invite a faire un post d'indigne de ce nom (constructif). Plutôt que de faire un coup l'abruti fini, et un coup le p'tit génie a trois franc six sous. Amicalement, Y.

Et puis..6Millions? Ils en avait pas juste vendu 3millions y'a deux semaines?^o)

Personne ne te retient. Si tu ne comprends pas que ma critique est sur le signal envoyé et non sur les réelles capacités techniques des fragments, c'est que tu ne sais pas faire preuve de discernement. Cela viendra avec l'âge. D'ici là, je connais mes applications Android mais pas les tiennes

Lol la vieille excuse ... ce n'est pas a causr d'une insulte en tout cas. Je n'ai jamais eu le motif de ce ban dailleurs.

Je ne sais pas depuis quand tu bosse sur Android, mais le fait que tu n'arrive pas a comprendre qu'il faut savoit commebt ça se passe derriere pour ecrire un billet sur ce genre de sujet .... c'est ça qui me deplait ici.

Tes messages ont été mis hors ligne suite à banissement.

Si tu me montre (et tout le monde peut en temoigner) un seul endroit ou j'ai insulté quelqu'un je retire tout ce que j'ai dis. je suis dur dans mes propos, mais je n'insulte jamais.

Ouais ouais, en manque de recul depuis 2007 ;) T'as juste pas compris que l'article ne parlait finalement pas de dev mais d'image. Vu celle que tu renvois, c'est tout à fait compréhensible.

Tu as la mauvaise definition du terme "fragmentatin" je t'invite donc a faire des recherches sur le sujet

Pourquoi essayer de m'avoir par les sentiments ? Et si tu admettaos que ton article est juste a coté de la plaque et que tu manque visiblement de recul sur le domaine Android pour en ecrire un. Vivement les articles de g123k , au moins il n'essaye pas de faire plus que ce q'il connait. Ne le prend pas mal ceci dit.

Commence par piger la netiquette, après tu viendras me parler. Tu t'es fait bannir combien de fois pour insulte ?

le problème ne s'applique pas à toi, mais il existe des applis qui ont été développé depuis le tout début d'Android, à l'époque les téléphones n'avaient pas de processeur à 1Ghz (et je parle pas des multi coeurs) et peut de RAM (largement inférieure à 512Mo). Hors l'appli a bien évolué et possèdes nouvelle options et fonctionnalité qui ont été permise grâce à de nouvelles fonctions incluses dans les dernières versions de l'OS, le problème des Terminaux qui ne sont plus mis à jour se pose ici car ils ne peuventplus béneficier de cette appli si elles n'ont pas le bon OS, elles sont limité par leur ressource car l'appli a pris de l'embonpoint suite aux nouvelles fonctionalités et les ressource CPU sont très limite pour les vieux processeurs. donc soit le DEV oublis ceux qui ont commencé avec eux (et perd une part des utilisateurs), soit il développe une variante pour eux en parallèle pour quand même faire évoluer certaines fonctions qu'ils peuvent bénéficier et rendre compatible aussi leur version au nouvelle spécificité d'une base de données consulté à distance par exemple. Puis il y a les tablettes qui semble-t-il ont de plus en plus une version dédié, etc donc sur le Market, le fait d'avoir qu'un seul lien pour une appli c'est pas mal, l'utilisateur lambda n'a pas a se soucier de son terminal et connaitre ces spécifications pour charger la bonne version (ni à trouver le bon lien pour son modèle)... N'oubliez pas que les utilisateurs ne sont pas tous spécialistes de technologie, et ils vont être de plus en plus nombreux. Maintenant si tu arrive a développer une appli qui ne nécessite pas de versions différentes, tant mieux car tu n'aura qu'une version à maintenir. Mais malheureusement c'est pas le cas de tous. Cette fonctionnalité ne va intéresser qu'un partie des appli. Certain jeux en font partie,  ceux qui ont une version optimisé Tegra et autres prochains GPU à venir.

Ah un mec qui parle de lui a la troisieme personne ? Ça fait prétentieux pour le coup. Et je répète, si tu t'avance comme ça avec des arguments pareil sur une mailing list de dev Android tu vas juste te faire sortir. Parce que là il y'a trop de truc que t'as pas pigé

Non ça c'est a cause de mon clavier qui s'est cru plus intelligent que moi. Du coup je l'ai viré

Non ça c'est a cause de mon clavier qui s'est cru plus intelligent que moi. Du coup je l'ai viré

Écoute, si t'as pas de copine, c'est pas une raison pour vomir ta haine sur les lecteurs ou les rédacteurs. C'est pas grave, hein, t'as que 15 ans ...

Tu es sur que l'article a été clarifié ? Parce que moi je ne vois que des fautes que tu as rajouté en plus. Ps: on dit "framework" et pas "framwork" merci d'avance pour la correction

T'es sérieux dans ton affirmation ? T'as deja entendu parler des compatibilité 32bits et 64 bits ? Non mis finelement je me demande quel est votre domaine de predilection ici ? Dev android, rien, dev pc, rien, dev web, que dalle... et ça ose venir faire des affirmation. Contentez vous de lire les commentaires sans commentez svp et attendez l'article sur Angry birds .... merci par avance.

Article clarifié.

C'est beaucoup de travail de maintenir plusieurs apk alors je ne pense pas que les développeurs "fainéant" s'y aventurerons.

Heureusement que pour les PC ce chemin n'a pas été pris et qu'il n'y a pas un .exe pour chaque ordi :D

Plusieurs choses mal comprises. Les contacts ne sont pas dans les fragments, point de rupture, etc. J'aurai pas du donner cet exemple sachant qu'il n'est pas couvert. Mais c'est valable aussi pour la version d'OpenGL ES et donc le choix des textures. Euh la fragmentation, ce n'est pas la diversité hein. La fragmentation, c'est quand le développeur doit faire un travail spécifique pour un terminal alors qu'il devrait travailler pour la plate-forme en entier. Archos n'avait pas le market, non pas parce que Google vérifiait techniquement les terminaux. Simplement parce qu'Archos n'avait pas les prérecquis ne serait-ce que sur le papier (appareil photo). Bon ... article pas assez clair. Désolé. J'ai pas été assez clair sur la différence entre ce que Google vient de proposer et la façon dont ça va être pris dans les agences de "dev".

Je respecte ton travail de rédacteur, et j'apprécie ce site et le travail que tu y produis. Ceci dit, ton analyse sur ce sujet est clairement fausse. Tu parles de gestion de contacts, alors qu'il s'agit de gestion des textures openGL, de la taille des écrans ou des versions majeures du système. Ensuite tu parles de fragmentation, en disant "le parc Android est fragmenté". Je trouve que c'est un PLUS. Tu parles de ça comme un inconvénient qu'il faut à tout pris masquer... Non. Ca c'est iOS, 1 appareil par gamme, aucun choix. Avez android on a le choix, donc les appareils sont divers et variés. Les versions d'android sont homogènes:  95% des gens ont android 2 pour les téléphones, et une grande majorité des tablettes ont android 3. Tu parles de jouer à Halo 3 sur un Pentium 2. Encore une fois c'est absolument pas de ça dont il s'agit. Il s'agit d'afficher des images HD sur une tablette et SD sur un téléphone ! De fournir de belles textures openGL pour les appareils costaud, et fournir des graphismes plus light pour les téléphones. Android permet déjà tout ça, seulement avec des APK multiples on peut alléger les packages et simplifier le développement. Si les éditeurs font des conneries, c'est pas forcément de la faute de Google. Ils essaient bcp de corriger ça, et c'est bien pour ça qu'ils ne donnent pas les sources d'Honeycomb: ils ne veulent pas d'Honeycomb sur des téléphones, car c'est pas prêt. Il faut attendre ICS. Enfin, tu dis "pourquoi Google n’exige pas de réellement valider l’implémentation d’Android sur un terminal avant de lui donner accès à l’Android Market". C'est le cas !!! Tu crois que les tablettes Archos première génération avaient l'Android Market ?

Mais. Il ne s'agit pas de critiquer ce dont il s'agit techniquement. Mais le signal que ça envoie. En réalité, et tu vas voir, la plupart des éditeurs vont le faire.

Rassure toi, le "rédacteur" a fait bien plus d'Android dans sa vie que toi. Son boulot, c'est juste de convaincre des entreprises que non, y'A pas besoin de faire 10 000 versions d'une application pour qu'elle marche sur tout les android.

+1

Quel est le rapport ?   ?_?  C'est 500Mo téléchargé après install si je ne m'abuse, donc le "multi APK" ne changera rien ici ... Et qu'est ce qui te dit que les 2 jeux sont identiques ? les 180Mo ne sont pas des contenu compressés pour rentrer dans les contraintes Apple ?   ?_?

" il faut aussi savoir mettre des points de ruptures et ne pas supporter des versions trop anciennes. Et il me semble qu’entre Android 1.x et 2.x le point de rupture est pertinent. " tout est là

Tout à fait, 6 millions de GS2, c'est vraiment "pas grand chose" ... quand on sait qu'il s'active 550 000 peripheriques android par jour, cibler le GS2 c'est se priver d'un paquet de périph ... 

Tu trouves ? Le jeu Galaxy on Fire 2 ne pèse que 180 Mo sur l'Appstore, peu comparé aux plus se 500 Mo que demande la version Android Market. De plus elle est universelle, optimisée pour chaque iDevice .

Ah le lapsus, tu avais commencé à dire "je" ! :D

j'aimerais bien découvrir ton appli :)

Encore une réponse qui tue... Moi au contraire, ça ne me semble pas pourave (mais bon, j'avoue que n'ai sans doute pas l'intelligence de Dralliw). Avec les risques sur le procès avec Oracle, les compléments récent des API en C++, ça fait un moment que je me dis que Google pourrait vouloir se libérer de la dépendance de java. Ce mécanisme peut-être effectivement un moyen de gérer de façon transparante pour l'utilisateur une rupture technologique.

L'open source de c'est pas ma philosophie. Je n'ai qu'une philosophie et la c'est la mienne.

 +1 je pense que aussi que c'est une des raisons principales. aprés je pense pas que tous les dev indépendant vont s'amuser à gerer 4000 apk pour une appli. Surtout si ça bouge au niveau des majs

C'est à son père qu'on aurait du dire ça :P

Ce genre de commentaire est contraire à la philosophie de l'open source...

Autant parfois je trouve tes trolls sympas, autant la je me dis que tu ferais mieux de te retirer.

J'ai des éléments tkt, mais je n'ai pas envie de les détailler réfléchi deux secondes et tu verras. C'est tjours mieu si tu te rend compte de tes erreur toi même.

J'ai des éléments tkt, mais je n'ai pas envie de les détailler réfléchi deux secondes et tu verras. C'est tjours mieu si tu te rend compte de tes erreur toi même.

Écoute moi bonhomme :) , J'ai parlé de débat, et pas de joute verbale. Bien qu'argumenté, mon précédent post n'a semble pas trouvé echo dans ton crane (a moins que ça résonne toujours sur le vide de celui-ci). Mais je ne m’inquiète pas, ce n'est pas évident a comprendre pour un gosse de 12 ans, malgré ton expertise avancé du monde Android. En effet, je ne suis pas un développeur d'APPLICATIONS Android, En revanche, j'ai eu a bosser sur un projet qui introduisait ces nouvelles instructions, avec la modification du SYSTEME Android, le format de fichier DEX, le compilateur dx, et la VM Dalvik. Je ne vais pas m'abaisser à lister mes références; mais la théorie que j'avance est étayée. Aurais tu des éléments permettant de qualifier mon analyse de "pourrave" ? Y.

Quelle bourde?

Un mec pas con... Heureux de te rencontrer. Je commençais à me dire que tous les commentateurs étaient tous pas très cultivés. T'as juste écris une bourde mais dans l'ensemble tu as raisons

Laisse tomber, on a affaire à ze cador, inventeur du TGV (sur son temps libre) et de tous les systèmes de la navette spatiale orbitale (torché à la machine à café en 3 minutes), on peut pas lutter. Sauf peut-être en suffisance.

C'est faux. J'ai une appli, un seul APK, des activity pour android = 3. Il suffit de savoir suivre la doc, faire des layouts selon les versions, et gérer le code pour différentier honeycomb et gingerbread. Le multi-APK n'est absolument pas "Je le sais, les contacts ne sont pas du tout gérés de la même façon entre 1.6 et 2.1. Bon … Soit.". D'ailleurs cette remarque me fait carrément remettre en question mon inscription au RSS de frandroid... lire une connerie aussi grosse... Le multi-APK, il faut lire la doc, n'est fait que pour de TRES petites quantités d'appli. Je conseille à tout le monde de lire : http://android-developers.blogspot.com/2011/07/multiple-apk-support-in-android-market.html http://developer.android.com/intl/fr/guide/market/publishing/multiple-apks.html On peut y lire que c'est principalement pour gérer des ressources différentes selon les plateformes. Un tegra 2 n'affichera pas la même chose qu'un téléphone d'il y a 2 ans. Android permet de ne faire qu'un APK pour les deux, mais si le fichier devient trop gros, ça coince. Pareil pour les différentes résolutions, on n'affiche pas la meme image selon la résolution. Android permet de faire ça dans un seul APK, mais faire deux packages "SD", "HD", c'est plus pertinent. Franchement, lisez la doc avant de publier n'importe quoi.

C'est faux. J'ai une appli, un seul APK, des activity pour android = 3. Il suffit de savoir suivre la doc, faire des layouts selon les versions, et gérer le code pour différentier honeycomb et gingerbread. Le multi-APK n'est absolument pas "Je le sais, les contacts ne sont pas du tout gérés de la même façon entre 1.6 et 2.1. Bon … Soit.". D'ailleurs cette remarque me fait carrément remettre en question mon inscription au RSS de frandroid... lire une connerie aussi grosse... Le multi-APK, il faut lire la doc, n'est fait que pour de TRES petites quantités d'appli. Je conseille à tout le monde de lire : http://android-developers.blogspot.com/2011/07/multiple-apk-support-in-android-market.html http://developer.android.com/intl/fr/guide/market/publishing/multiple-apks.html On peut y lire que c'est principalement pour gérer des ressources différentes selon les plateformes. Un tegra 2 n'affichera pas la même chose qu'un téléphone d'il y a 2 ans. Android permet de ne faire qu'un APK pour les deux, mais si le fichier devient trop gros, ça coince. Pareil pour les différentes résolutions, on n'affiche pas la meme image selon la résolution. Android permet de faire ça dans un seul APK, mais faire deux packages "SD", "HD", c'est plus pertinent. Franchement, lisez la doc avant de publier n'importe quoi.

C'est faux. J'ai une appli, un seul APK, des activity pour android = 3. Il suffit de savoir suivre la doc, faire des layouts selon les versions, et gérer le code pour différentier honeycomb et gingerbread. Le multi-APK n'est absolument pas "Je le sais, les contacts ne sont pas du tout gérés de la même façon entre 1.6 et 2.1. Bon … Soit.". D'ailleurs cette remarque me fait carrément remettre en question mon inscription au RSS de frandroid... lire une connerie aussi grosse... Le multi-APK, il faut lire la doc, n'est fait que pour de TRES petites quantités d'appli. Je conseille à tout le monde de lire : http://android-developers.blogspot.com/2011/07/multiple-apk-support-in-android-market.html http://developer.android.com/intl/fr/guide/market/publishing/multiple-apks.html On peut y lire que c'est principalement pour gérer des ressources différentes selon les plateformes. Un tegra 2 n'affichera pas la même chose qu'un téléphone d'il y a 2 ans. Android permet de ne faire qu'un APK pour les deux, mais si le fichier devient trop gros, ça coince. Pareil pour les différentes résolutions, on n'affiche pas la meme image selon la résolution. Android permet de faire ça dans un seul APK, mais faire deux packages "SD", "HD", c'est plus pertinent. Franchement, lisez la doc avant de publier n'importe quoi.

Je ne parle pas de DL complémentaire. Mais si tu es un dev et que tu ne connais pas les solutions de distribution sur le market, le je ne peux rien pour toi. Je mais sache que c'est gerable

Je ne parle pas de DL complémentaire. Mais si tu es un dev et que tu ne connais pas les solutions de distribution sur le market, le je ne peux rien pour toi. Je mais sache que c'est gerable

C'est pas du tout à l'avantage du développeur de se concentrer sur une seule plateforme. Se concentrer sur Galaxy S2 c'est se priver d'une énorme partie du marché et donc autant de revenu en moins. Donc non, un développeur un minimum professionnel dans ce qu'il fait, ne se limitera pas à 1 ou 2 smartphone.

C'est pas du tout à l'avantage du développeur de se concentrer sur une seule plateforme. Se concentrer sur Galaxy S2 c'est se priver d'une énorme partie du marché et donc autant de revenu en moins. Donc non, un développeur un minimum professionnel dans ce qu'il fait, ne se limitera pas à 1 ou 2 smartphone.

Quoi ? des DL complémentaires ? La belle nouvelle !

C'est quoi ton problème dans la ta vie ? T'as jamais vu un skin d'appli ? Tu crois qu'on fait un skin pour du x10 mini avec les mêmes images que pour une tablette en 2000 x 1600 ? Tu crois qu'un grand écran, c'est forcément 4 petits écrans collés ensemble ? T'as jamais eu peur du ridicule ... mais là c'est impressionnant ce que t'es con.

Trés mauvaise idée ! On a vu la décision sur J2ME, celà fera là même chose. L'étape 2 étant la prise en compte des zones conditionelles par les IDE pour permettre la généralisation du code et la création des multiples variantes d'apk automatiques. On pouvait clairement avoir une API dynamique permettant à l'appli de savoir les capacités du périphèrique et laisser le developpeur prévoir les variantes qu'il souhaite en fonction de ses besoins. Là, c'est de la fragmentation pure est simple. Ah quand le fork tant qu'on y est ? ;-)

J'aimerai que tu aies raison! et je pense qu'à la base ce nouveau système est fait pour ça. J'ai juste un peu peur avec ces gros succès android, que les dev se concentrent sur un tel comme le GS2, qui est très bien soit dit en passant, et qu'ils délaissent d'autres très bon tel comme mon atrix par exemple, alors qu'au final la différence  se fait principalement au niveau de la resolution d'ecran.. enfin la resolution qHD va peut être se démocratiser et les devs adapteront leurs applis..

Tu sais que pour ton pb il existait déjà une solution sur le market avnt?

J'ai exactement la meme situation avec un jeu ou il faut trouver des mots dans une grille de lettre (Chasseur de mots ). J'ai deux langues ( anglais francais), donc deux versions aujourd'hui. Et je suis d'accord avec tous tes points, Atomusk !

Ah ben merci bien tu viens de m'apprendre quelque chose ! :)

Ah ben merci bien tu viens de m'apprendre quelque chose ! :)

?? classe cette remarque. je t'ai volé ta copine dans une autre vie ou quoi?? Non je ne "fouts" pas d'image HD dans mon appli, la dernière version de mon appli fait 462 Ko et c'est parfait pour mon Hero. Mais je comprends aussi que sur un galaxy ou autre, les utilisateurs apprécierait des icones et fond d'écran un peu moins floue. Quant à la qualité de mon appli ou de mon niveau en dev que tu sembles si bien connaitre, je n'ai pas l'impression que tant de monde s'en plaigne.

Corrigé ;)

Corrigé ;)

En tant que développeur, je trouve cette évolution intéressante et pratique mais j'ai peur des dérives qu'elle peut amener. En effet, ce n'est pas tant la fonctionnalité en elle même qui "pose problème" mais plus le message que cela renvoie et la façon dont il peut être interprété. Le risque qu'un raccourci entre Android et J2ME soit fait est grand et cela va rebuter certains développeurs, sans parler de la concurrence qui va pouvoir s'amuser avec ça. De plus, des dérives d'augmentation des coûts de développements et de maintenances sont désormais facilement justifiables en utilisant l'argument du multi-apk et pourrait freiner le développement du market.

sisi : http://android-developers.blogspot.com/2011/03/fragments-for-all.html  Today we’ve released a static library that exposes the same Fragments API (as well as the new LoaderManager and a few other classes) so that applications compatible with Android 1.6 or later can use fragments to create tablet-compatible user interfaces. Donc tu as une librairie dans ton app et ça t'ouvre l'acces aux framgents pour 1.6+. Et ça marche très bien ;)

Si tu foutais des images hd dans tes appli c'est que le problème vient de toi et le marketing ne pourra pas le résoudre. Après on s'étonne de la qualité des applis sur Android. Attention avec des dev comme toi, je on ne vole pas très haut

Je ne suis pas tout à fait d'accord : comme tu dis le market est fragmenté dû aux différentes versions d'Android, et je pense que permettre de fournir plusieurs APK pour un même produit va justement uniformiser les applis sur le market, quel que soit le support utilisé.

Pas besoin de débattre la, la ton analyse est pourrave. Ça se voit que tu n'est pas un développeur Android c'est tout.

Entièrement d'accord avec Acesyde, le multi-APK va permettre de publier un même produit pour différents supports !

Bon débarras.

J'y ai jeté un oeil mais les fragments ne sont disponibles qu'à partir de la version 11 du SDK, donc je ne pourrais pas avoir un seul APK pour Android 2 et 3.

Langage sans "u". ;)

"C’est ce qui petit à petit a tuer J2ME" hmm... Android m'a TUER !

C'est surement une bonne chose dans le fond, mais ce qui me fait peur c'est qu'on risque de se retrouver avec un market différent par téléphone. Je m'explique : le Galaxy S2 s'est vendu à 6millions d'exemplaires. Ne risque-t-on pas d'avoir des développeurs qui vont se consacrer qu'à un seul type de téléphone à succès, sans se soucier de la compatibilité avec les autres? le market est déjà fragmenté par versions d'android, ce serait dommage de le fragmenter en plus par type de téléphone.. l'OS devrait se charger de rendre compatible l'appli. Une appli skype sur windows marchera sur n'importe quel PC ayant la meme version de windows, certes les config feront que le temps d'execution ne seront pas les mêmes, mais l'appli se lancera peu importe la resolution d'ecran, etc. Peut on en dire autant de l'appli skype android? malheureusement non...

La vérité est (peut être) ailleurs ... Ayant travaillé un peu sur le langage Dex, il se peut que prochainement de nouvelles instructions voit le jour. Ces nouvelles instructions seront inhérent au Bytecode Java7 (java.lang.invoke) qui devrait arriver dans les mois à venir. Bref, je vous passe les détails technique compliqués. Un changement de cet ordre forcerait une modification profonde du format de fichier Dex contenu dans les APK. Ce format de fichier étant fortement ancré dans Dalvik (la VM), il n'est pas évident de pouvoir exécuter les 2 versions d'APK sans une modification profonde de la VM. La fragmentation serait une solution (que je n'imaginais même pas à l'époque, mais qui semble la plus raisonnable), : permettre aux anciennes applications d’être disponible sans modif profonde de Dalvik ou  sans avoir besoins de recompiler tous les APK du market ! Analyse ouverte au débat ^^ Y.

En gros on pousse la fragmentation jusqu'au bout quoi. Ça sera le même bordel que les maj Android. Attention : it smells like à ice cream sandwich concept.

Je ne vais pas rentrer dans les détails, ce n'est pas le sujet de l'article mais voici les différents arguments : - poids : mais dans un Apk, la BDD pèse environ 2.5Mo à télécharger "en exterieur" 5Mo - Bande passante : là je m'appuis sur la BP de Google, là c'est de ma BP qu'on parles - Première utilisation : afficher à l'utilisateur pour sa première utilisation : merci de télécharger la BDD n'est pas à mon gout la meilleure manière de "mettre l'utilisateur dans de bonnes conditions" - complexité de programmation : c'est un détail, mais du coup ça rajoute des risques dans mon APP pour vérifier l'intégrité de la BDD en plus de la gestion en elle même du téléchargement (qui peut échouer & co). Donc à choisir, tant que ce n'est pas bien lourd, je reste comme ça pour le moment ^^;

Bon ok le rédacteur à fait du J2ME dans ça vie, et mais qu'est ce que ça vient faire dans cet article? Si il codais sous Android il saurait que ce n'est clairement pas pareil. Par contre Google ne résoud en rien le problème vu que le but c'est de ne pas avoir à développer 2000 apk pour chaque user, il faut juste forcer les constructeur a rester sur les standards. La platform Android m'intéresse de moins en moins en temps que développeur.

Personnellement je trouve ça bien pour éviter de fournir un APK contenant par exemple systématiquement des images HD gonflant la taille des apk et pourtant inutiles pour les petites écrans. Je vais sans doute utiliser cette possibilité pour garder mon appli aussi petite que possible pour petits écrans, mais avoir aussi une version HD. L'idéal serait que le SDK puisse générer automatiquement différentes version d'APK d'un coup, je ne voudrais pas gérer différentes branches parallèle de version logiciel rien que pour ça.

Je pense plutôt que ça a du bon pour faire la rupture justement, il suffira de dire: ok on laisse la version 1 de notre apk pour les anciens modèles, pour les nouveaux on peut fragmenter et sortir la v2, les anciens modèles auront tjs accès à la v1 !

Je ne suis pas développeur et ma vision est peu être trop simpliste mais si je me fie à ce que de grands développeurs proposent (TouchType avec swiftKey par exemple), pourquoi ne pas proposer une application légère sans base de donnée et demander à l'utilisateur de choisir sa langue à la première utilisation ? Il pourrait choisir les langues qui lui plaisent sans qu'on lui impose (pratique pour un français qui vit aux Etats Unis par exemple) et les mises à jour de l'appli seraient bien moins lourdes (un changement dans l'interface ne nécessite pas de retélécharger toute la base de données).

Et moi je suis quasiment certain que c'est également pour limiter le "piratage" des applis. 

Tout à fait d'accord, en règle général le développeur aura besoin de 2-3 apk tout au plus. S'il en a plus c'est que c'est vraiment un manche et il va galérer pour s'organiser.

Je suis d'accord : il faut le voir comme une possibilité, une facilité pour certaines problèmatiques mais pas comme une obligation et un constat d'échec de la part de Google.

D'accord avec Tijee.. beaucoup de cas peuvent demander plusieurs APK..  Et le point de rupture entre 1.6 et 2.x .. pas vraiment d'accord, sur beaucoup d'application "basique", pas besoin de faire ce point de rupture.. entre 1.6, là oui.. Après, c'est sur que le multi-apk risque de rendre certains développeurs fainéant, et vont préférés multipliés les APK plutôt que d'en faire un seul un peu plus complexe pour etre compatible avec tout le monde.. We will see, l'avenir nous le dira !

Je ne suis pas d'accord avec l'article : on n'est pas obligé de faire plusieurs APK et je pense même qu'il n'est pas conseillé de s'y lancer pour "le plaisir". Par contre, dans certaines conditions particulières, faire plusieurs APK est utile : à quoi ca sert pour un même jeu compatible avec un téléphone 320x480 avec mémoire réduite et compatible tablettes 1024x720 + biprox + GPU puissant d'avoir une version unique avec toutes les textures pour la version grande résolution qui vont prendre de la place sur le petit terminal ? Dans ce genre de cas, je suis pour faire 2 ou 3 APK : petits smartphones, smartphones 800x400 et +, tablettes (par exemple).

Je suis de l'avis de AceSyde, avec la diversification des terminaux Android, cette amélioration me parait très importante. C'est toujours mieux que d'avoir 50 fois la même application sur le market. Par exemple avec HomeSwitcher, il lui fallait une version spéciale au passage à FroYo. On s'est retrouvé avec deux appli sur le market : HomeSwitcher et HomeSwitcher For FroYo. Je vois vraiment d'un bon oeil cette amélioration. J'avais le problème des contacts justement pour mon application "ICE". J'ai dû mettre 2.1 minimum et je me prive donc de 6% d'utilisateurs potentiels (soit 2000-3000), alors maintenant ça parait insignifiant mais il y a quelques mois en arrière, c'était bien plus que ça la part de 1.6/1.5. A noter aussi qu'il existe des outils très puissant pour gérer les branches dans des cas de multiples versions. Je vais citer GIT mais il y en a surement d'autres. Aux développeurs de s'organiser au mieux donc et à Google de faire un minimum d'effort pour uniformiser leur plateforme (C'est ce qui arrive avec ICS).

Il arrive que certaines applis aient plusieurs versions sur le market en fonction du terminal (tablette, pas tablette, optimisée pour tel ou tel processeur...). Si on peut regrouper toutes ces versions sous une seule et même description de l'application, c'est plutôt un progrès. Après, il faut quand même que les développeurs n'en profitent pas trop et tentent autant que possible d'avoir des versions uniques pour tous les terminaux.

idiot

pff, décidément le niveau éditorial ne s'arrange pas par ici :  cet ajout est tout à fait pertinent pour ne pas avoir à télécharger une appli énorme parce qu'elle prend en compte tous les supports. J'ai un apk pour smartphone, un seul suffit à priori. Par contre si je rajoute le support des tablettes et/ou télévisions (dans un futur proche) est-ce que ça me va de me retrouver avec un apk énorme parce qu'il prend en compte tout ça ? Sachant que mes clients vont gueuler parce que l'apk est énorme et que ça a bouffé leur forfait. Et qu'en plus la plupart des ressources que je leur fait télécharger n'est pas nécessaire sur leur terminal ?Bah non je préfère de loin scinder mon appli en 3.

pff, décidément le niveau éditorial ne s'arrange pas par ici :  cet ajout est tout à fait pertinent pour ne pas avoir à télécharger une appli énorme parce qu'elle prend en compte tous les supports. J'ai un apk pour smartphone, un seul suffit à priori. Par contre si je rajoute le support des tablettes et/ou télévisions (dans un futur proche) est-ce que ça me va de me retrouver avec un apk énorme parce qu'il prend en compte tout ça ? Sachant que mes clients vont gueuler parce que l'apk est énorme et que ça a bouffé leur forfait. Et qu'en plus la plupart des ressources que je leur fait télécharger n'est pas nécessaire sur leur terminal ?Bah non je préfère de loin scinder mon appli en 3.

Omar m'a tuer. (déclaration de J2ME)

pfff, décidément le niveau éditorial ici 

Tu as essayé de voir si les fragments ne pourraient pas répondre à ton problème ?  Afficher les différentes fiches comme différents fragments les uns à coté des autres ?

Perso, je ne suis pas à 100% convaincu de l’intérêt, mais prenons un exemple simple, avec mon appli. Aujourd'hui je pousse sur 100% des terminaux une base de données de 5Mo avec les traductions des différents idéogrammes Japonais en Français/Anglais et pour certains Allemand et Espagnol. Sachant que les utilisateurs français représentent 7% de mes utilisateurs, est ce que ça vaut le coup que je pousse chez 93% des utilisateurs en français ? Sachant que la seule différence est la base de données (donc simple à changer de mon point de vue), et qu'il y a du coup moyen de gagner 1-2Mo pour 93% des utilisateurs (et même, si je vire l'anglais pour les Français, c'est pour 100% des utilisateurs que je fait gagner du poids). Perso, je ne le vois pas comme un constat d'échec de la part de Google, mais plus comme une solution de plus pour faciliter la vie des développeur tout en cachant la complexité aux utilisateurs. Maintenant je ne vais pas m'ammuser à maintenir 8 APK différents entre les langues, les versions tablet/GalaxyTab7" & co, Car ça serait 10 fois plus de boulo ^^; Mais je trouve que c'est une bonne chose que de laisser ce genre de liberté au développeur.

Je ne suis pas forcément en accord avec vous sur la dernière partie. Imaginons que notre application X doivent fonctionner sur smartphone 1.6 - 2.3 et sur Honeycomb 3.x L'avantage de cette possibilité et de pouvoir distribuer une application totalement différente pour chaque type de support. Une télé, un smartphone, une tablette, un micro-onde, on peut imaginer faire une application avec les mêmes bases mais spécifiques à chaque support.

J'ai publié une application D&D 4 Android, qui consiste en une feuille de personnage pour Donjons & Dragons. La feuille en question est assez conséquente, et j'ai donc dû la scinder en plusieurs onglets, (et donc plusieurs Activities pour ceux qui sont familiarisés au développement Android). Je compte porter cette application sur tablettes, dont les écrans bien plus grands me permettront de tout faire rentrer sur une seule Activity (ce n'est donc pas simplement un problème de layouts ça serait trop simple ^^). Faire tout ceci dans une même application est assez conséquent, et il est plus simple pour moi de créer un deuxième APK. Pourtant il s'agit de la même application... Je pense que le multi-APK sera beaucoup utilisé pour adapter des applis smartphones aux tablettes, sans avoir à déployer un deuxième produit.

Attention ! L'intérêt est aussi au niveau de la place prise par l'application. Les ressources graphiques pour un écran 3,5" et celles pour un écran 7 ou 10" ne sont pas les mêmes ! Dès lors, à quoi bon proposer un unique fichier contentant toutes les ressources pour tous les terminaux alors que les la moitié seront ignorés ? C'est ce qui se passe sur iOS et c'est une véritable catastrophe en terme d'espace disque. Les appli sont de plus en plus lourdes (version iOS low res, version retina, version iPad...) sans réel plus pour l'utilisateur d'un ancien iPhone par exemple. Google propose donc une solution solide à ce problème.