Reprise du message précédent :
APN Droid te coupe carrément la 3G/2G non ?

J'ai installé un nouveau thème.
 
Avantages : c'est beau et propre
Inconvénients : j'ai seulement le choix entre Anglais et espagnol pour toute l'IHM android.
 

 
 
LIEN : http://forum.xda-developers.com/sh [...] p?t=701852

Dans switchpro, je viens de réessayer pour pas dire de connerie, tu as un mode "Data connection" (logo E et flèches) qui permet de faire ON/OFF sur la data. Le mode "2G-3G" (logo 3G/E), quand on clique dessus, amène directement  au  fameux menu android qui permet de cocher/décocher 3G/2G.
 
A ma connaissance il n'y a toujours pas de switch dédié à 2G/3G

ça dépend de ta config je crois, si c'est des adresses différentes, tu peux couper l'un et pas l'autre

 
Oui, c'est ça.
'Fin, ça t'envoie direct sur le menu où tu n'as qu'à cliquer sur 2G uniquement pour ne pas pomper la batterie.
Bande de feignasses !
 

 
Ah, possible.
 

Même en foutant en français via MoreLocale 2 ?

Tous les widgets dispos pour ça ne sont que des raccourcis car comme ça a été dit plusieurs fois c'est impossible de faire autrement via l'API Android.

@pigeon_man : avec morelocale 2 je récupère une partie des libellés, mais tout ce qui est lock, date, etc.  est en US

message édité

J'utilise one click widget, et y'a toutes les possibilités pour couper la 3G, le wifi, le bt, le mode avion etc.. indispensable amha.

l'applis google maps est vraiment pas aussi ergonomique que sur iphone, c'est quand même dommage
 
Un truc déjà c'est que ok il y a une boussole avec la fleche bleue qui indique la direction, mais la carte ne pivote pas, contrairement au iphone 3GS.
 
Aussi l'appli est quasi inutilisable à une seule main.
Avec le iphone je pouvais utiliser l'appli en fesant du vélo, là c'est impossible.

Mets google navigation sur ton velo et t'auras pu de soucis

google maps est mort, vive google maps navigation!
 
C'est vrai que c'est con le coup de la boussole

il y a une différence ?

Bah la carte est toujours orientée par rapport à la voie sur laquelle tu es. Comme un logiciel gps quoi  

Je vais repasser sur un système Linux bientot et donc je dois me passer de mon iPhone (et de sa synchro iTunes ..).
 Android fonctionne comment pour la musique ? Juste du transfert direct (le tel est vu comme un peripherique de stockage donc?), l'application de lecture lit les jaquettes/album/lyrics directement dans les tags ?
 
Pour les contacts, calendar ..etc.. çà passe par les applis Google online ?
 
Derniere question : quel est l'équivalent en terme de "valeur" d'un iPhone 3G 16 Go ?

ouais enfin déjà je peux pas l'ouvrir si il me localise pas ...

dans la derniere version d'ubuntu on peut ENFIN synchro l'iphone avec linux
mais j'ai flingué mon iphone peut de temps après

avec android lecture directe comme si c'était un clef usb

Bah si il ne te localise pas, t'as un problème avec ton tel, pas avec gmap....

disons que le message de google disant qu'il va te localiser quand tu active la localisation par gsm est bizarre

en tout cas cette appli navigation vient de faire crasher mon htc desire
sinon la synthèse vocale à l'air pas mal.
 
C'est quand un même naze de pas pouvoir compiler du C alors que c'est un noyaux linux.
Le iphone jailbreaké permet de le faire, c'est ridicule  

quel est-il ? "nous avons les moyens de savoir où vous êtes "

 
Il est formulé bizarrement, on sait pas si il veut dire que le téléphone envoie tes coordonnées directement à google même quand tu n'utilises pas l'applications maps, où si tes coordonnées sont déterminées et stockées plus précisément par les antennes relai gsm de ton opérateur, vu que cette fonction active la localisation assistée par gsm pour permettre au gps d'accrocher le sattelite plus facilement.

 
Oui et le NDK est un palliatif temporaire à une solution plus pérenne... Si la perf est ton dada, le NDK est le chemin obligé à l'heure actuelle pour les trucs OpenGL. Mais d'ici quelques temps ça sera oublié.
 

 
Tout accélérer non. Mais on s'en fou. Enfin il ne faut surtout pas que tu oublies que les ARM ne sont pas les seuls CPU possibles dans Android et surtout que même chez les ARM tu as plusieurs versions de CPU avec des optimisations différentes selon les générations. Du coup une JVM puissante est bien plus maligne que de l'optimisation au cas par cas qui ne fonctionnera plus dans le futur sur de nouvelles architectures.
 

Tout dépend quel code... Un bon compilateur ou une bonne JVM peut optimiser les choses de manière parfois plus intelligentes que ce qu'un dev ASM moyen va faire... Tu peux faire un truc qui rame en ASM hein

 
Les bonnes JVM JIT récentes sont souvent plus rapides que la version C compilée (plein de bench sur le net). Mais oui, un code bien optimisé en ASM peut aller bien plus vite... Quand tu n'as qu'une seule architecture de destination !

Tu as essayé navigation ? lol
 
ps : google maps sur Android a 100x plus de fonctions que sur iPhone.
 

On se tue à te dire que le NDK permet ça depuis 20 messages...

Tu n'as pas l'air de savoir comment sont codées les optimisations asm dans du C.
Le code asm correspondant à ton cpu est exécuté en fonction du cpu, c'est déterminé à la compilation tout betement par des macros, ou alors au runtime pour des extensions spécifiques pour des cpus de même architecture, (genre mmx ou sse etcetera), et Il y a toujours une version initiale en C du code si il n'y a pas de code asm spéficique à ton cpu.

Les distributions linux actuelles gèrent très bien les architectures différentes et la distribution des applis pour ces différentes architectures.
C'est juste à google de mettre en place un système similaire pour son market, ou même de réutiliser les outils debian.
Un truc comme launchpad fonctionne pas mal pour Ubuntu et permet aux devs de compiler leurs paquets sur des serveurs distants.
Les applis utilisant le NDK devront de toutes façons être recompilées si une nouvelle architectures sort, donc rendu à ce niveau l'intérêt de conserver java c'est surtout la simplicité du langage pour les devs.

Mais Google se tire aussi une balle dans le pied en se fermant trop au C, en se privant de tout GNU et de ses développeurs.

parfois t'as pas besoin d'un couteau suisse, juste d'un bon couteau de boucher

le NDK n'offre pas un runtime C sur Androide, tu peux pas développer d'applis native en C, mais ça je pense pas que tu comprennes ce que ça veut dire

Android a les deux.

Je sais comment ça marche mais... Ce que tu ne piges pas c'est que contrairement à Linux :
 
1) l'utilisateur ne compile pas son appli à l'installation
2) le développeur ne peut pas re-compiler à l'infini son appli pour toutes les versions futures des processeurs qui arriveront un jour...
3) sauf dans le cas ou le dev donne son code en auto compilation à google via le cloud (solution possible), mais dans ce cas... Fini la confidentialité du code lol

 
Sauf quand Google Maps sur Android est aussi simple que sur iPhone de base...
 

 
Si je comprends très bien mais tu ne piges pas que c'est s'enfermer dans du court terme...
 
Un Android rooté peut exécuter des appli compilées en C ou C++ directement. Le kernel est un Linux. Android lui même est compilé via ces solutions.
 
Maintenant pour le grand public et le futur, le blocage du C++ natif est peut être chiant dans TA conception du monde, mais une bénédiction pour l'avenir de la plateforme.
 
Pas besoin de se prendre la tête avec un système d'universal binaries à la Apple (voilà le bordel depuis la sortie de l'iPad et le futur iPhone 4, ou encore ce que ça été à la transition du PowerPC au Intel).
 
Pas de prise de tête avec le 32 ou 64 bits... Ou autres...
 
Pas besoin de re-compiler les softs à l'avenir. Une appli qui tourne et que le dev ne met plus à jour marchera encore dans 10 ans sur des architectures qui n'ont rien à voir.
 
C'est une énorme force pour Google, les dev et les fabricants qui ne sont pas enfermés dans une architecture matérielle figée ou il faut tout refaire dans 2 ou 3 ans.
 
Alors oui c'est un petit blocage à court terme, ne pas profiter des milliers d'appli C et C++ existantes. Mais pour le futur...

 
1) sur la large majorité des distributions linux non plus, mais tu peux.
2) si il a le code source et un sdk qui cross compile (ce qui est le cas) il peut le faire.
D'autant que ça reste à lui de s'assurer que son produit fonctionne sur d'autres plateformes et d'en assurer la pérénité, par des mises à jours, des correctifs, des patchs, peut importe comment tu l'appelles, le processus de maintenance est déjà existant et fait partie des habitudes.
3) je pense qu'on donne à google des infos personnelles bien plus confidentielles, et google n'a aucun intérêt à déconner avec
 

 
il est moins ergonomique
 
rien que sur le 3GS la carte tourne suivant ton orientation grâce à la boussole
la gestion de l'échelle est meilleure sur iphone, et l'appli est plus facilement manipulable à une seule main
 

 
Une fois qu'une application est compilée, elle est en code machine, sont langage source n'a aucun importance.
 
La question ici c'est pouvoir ou non lancer du code compilé en natif.
Si le téléphone est rooté on peut, j'ai jamais dit le contraire, mais ce n'est pas un comportement voulu.
 

 
ce n'est pas une bénédiction de se couper d'une source immense de logiciels libres
 

 
Mais tu comprends pas qu'avec le NDK le probleme est déjà le même ?
le paquet de ton logiciel incluera les binaires des différentes architectures en plus du byte code java
 

 
si son appli est obsolète, qu'il ne s'en charge plus, et qu'il ne donne pas le code source, son appli elle peut crever, ça fera ni chaud ni froid à personne lol
 

 
il faut pas tout refaire, il faut créer les drivers et recompiler
c'est ce qui permet à linux de s'adapter à peut près tout type de machines existant sur terre
 
pareil pour les librairies natives de androide
 
ce que google souhaite faire c'est juste faire en sorte que cette tâche soit restreinte aux dev de la plateforme androide et aux éditeurs
 
Si aucune librairie native ne fait ce que tu veux, par exemple du décodage divx, t'es obligé de l'implémenter toi même, et ça il y aucune chance de le faire en java direct et avoir des perfs potables si ça ruine pas l'autonomie de la batterie
 

 
Restreindre tout à du java ça va faire fuire bon nombre de devs expérimentés
Le java c'est bien pour dev sans se prendre la tête je dirais jamais le contraire et ça attire des devs aussi.
Je pense que google attend surtout d'avoir un support java bien rodé avant d'ouvrir les vannes à plus de natif, car de toutes façons ils seront obligés de le faire.
Les éditeurs ont pas envie de développer leur code dans quinze langages différents, et leur choix se porte pas toujours sur java.

Je ne suis pas vraiment un fanboy Google, et je suis parfaitement ton raisonnement. Cependant, je pense que la plupart (allez, 80%) des applis développées sur les plateformes mobiles sont des applis casual, et qui se soucient peu des perfs. Le développement en Java (sur Android) facilite le portage sur toutes les plateformes et ouvre le dev à un grand nombre de développeurs.

Pour des applis plus complexes, ou qui nécessite vraiment une optimisation des perfs (firefox, autres...) Google a fourni un NDK. Développer du code natif suppose que la dev team livre les binaires pour toutes les plateformes souhaitées, ce qui est envisageable sur des projets d'envergure.

Sur iPhone, c'est un peu différent, puisque les utilisateurs ont tous le même hardware.

Ce sont juste 2 marchés différents. Si Google veut rattraper son retard sur ce marché (notamment la bataille du chiffre sur AppStore/Market) il faut que les applis soient faciles* à développer et à déployer.

Edit : *facile pour le petit dev ou le débutant

1) Oui car la majorité des distrib fonctionnent sur le même CPU...
2) Non, tu oublies un détail important. Un dev ne va peut être pas passer sa vie à compiler la même appli qui n'a pas évoluée depuis des années... Pérennité...
3) Je vois bien mal des entreprises fournir à Google leur code propriétaire, même avec toutes les clauses de confidentialité du monde lol

A mon avis le p-code Android doit pas être beaucoup plus compliqué à décompiler que celui de Sun

 
C'est ton avis. J'ai l'avis inverse... Les +/- pour le zoom sont autrement plus efficaces à une main mais bon
 

 
Le seul moyen de faire la même sur iPhone c'est via le Jailbreak, donc... Heu Pareil quoi.
 

 
On ne s'en coupe pas d'une part. Again, bis et repetita, le NDK permet d'intégrer les éléments C aux appli Android.
 
D'une autre part, le monde mobile est totalement différent du monde ordinateur. Même sur iPhone que tu prônes avec son "ouverture" aux appli en C, tu dois l'avoir jailbreaké pour en profiter. Franchement, combien d'appli open source de Linux ont franchies le cap de l'AppStore Apple ? Restons objectif stp
 

 
C'est pour ça que le NDK est une solution transitoire qui n'a pas d'avenir. Je le dis depuis le début.
 

 
C'est TON avis... Si moi je trouve que cette appli est juste parfaite et n'a besoin d'aucune modif, j'ai le droit.
 
Je prends un parallèle simple, sur Windows XP j'avais découvert un freeware appelé RocketDock qui permet d'avoir un dock façon Mac sur Windows. Il tourne parfaitement et rempli tout mes besoins. Tous les autres du genre ne me conviennent pas (et j'en ai testé !). Ce soft n'est plus mis à jour depuis des années (2007), pourtant il fait toujours mon bonheur au quotidien. Il tourne très bien sur Vista et Seven. Et ça me fera chier quand un Windows le rendra inutilisable...
 

 
Non, il faudrait re-compiler TOUTES les applications du Market... Voilà le bordel !
 
Quand à ton DivX, il existe un soft encore en beta, qui lis le DivX à 20 fps (soft pas finalisé), et ça 100% en Java...
 

 
Java est juste le language le plus utilisé au monde actuellement...
 
http://www.tiobe.com/index.php/con [...] index.html

Tu peux toujours dé-compiler, mais ça sera jamais aussi clair que le source réel. Surtout sur certaines appli aux techno propriétaires déposées

oui c'est vrai pour le zoom
mais pour le scrol pas trop
mais je compte sur le fait que ça évolue, je suis allé sur androide par gaitée de coeur parceque apple est trop fermé
c'est juste que je m'attendais à avoir un appareil d'emblée aussi ouvert que peut l'être un iphone jailbreaké

je pense que l'idée du rootage est différente du jailbreak

des éléments, il permet pas de réutiliser tel quel des applis qui pourtant peuvent fonctionner tel quel, genre un serveur openssh

Je ne parlais que du jailbreak
je m'attendais juste à ce que google n'impose pas de telles limitations, mais il faut croire que si.
même si google le fait pas pour les mêmes raisons, vu qu'il est possible d'installer une appli sans passer par le market et que des market alternatifs sont permis

les conditions d'utilisation de l'iTunes store sont incompatibles avec la licence GPL
http://www.igeneration.fr/app-stor [...] erci-11621

tu sais pas de quoi tu parles

on ne peut simplement pas tout faire en java à l'heure actuelle sans se tirer une balle dans le pied niveau perfs pour des parties critiques et consommatrices d'énergies

peut être dans 10 ans

aucun rapport, il n'a pas besoin d'être mis à jour vu qu'il fonctionne toujours
si il devient incompatible avec une nouvelle version de windows tu ne sais pas si le dev ne va pas ressortir du bois avec une nouvelle version

si t'as envie de t'accrocher à des versions qui ne sont plus supportées ça sera ton choix mais ça sera aussi ton problème.

A ton avis quand un developpeur fait une update de son application il fait quoi ?
Si une nouvelle architecture sort, il suffit d'une mise à jour du SDK pour que le developpeur, que le developpeur en soit notifié et fasse une recompile de son application, ce qui n'est pas plus compliqué à faire qu'une update.

Si un dev ne veut pas maintenir son application il perd de l'argent.

t'as pas l'air d'avoir la moindre idée de ce que c'est un codec optimisé en assembleur

car quand bien même tu atteindrais 25fps et une fluidité parfaite en java, tu optimiserais pas l'utilisation des cycles cpu, ce qui signifie que tu n'optimises pas la consommation d'énergie du processeur, et ça pour un appareil mobile c'est tout sauf négligeable.

t'en connais beaucoup des jeux ou des codecs audio/vidéo codés en java ?

 
Il faut pas pousser C'est déjà super ouvert.
 

 
Pas tant que ça en fait.
 

 
On lui dit que OpenSSH est intégré à Android ?
 

 
cf plus haut.
 

 
lol je suis dev iPhone, je connais bien. C'était le sens de ma phrase : 0 appli GPL sur l'AppStore. Question terminée
 

 
Techniquement ? Si on peut. Rien ne l’empêche.
 
Maintenant, avoir le support matériel et le temps de tout refaire, c'est une autre histoire.
 

 
Mais le dev ne l'a pas mis à jour depuis 3 ans et il me va toujours, je m'en fou qu'il y ai un support ou non...
 
Tu crois vraiment que tous les dev vont re-compiler toutes les applis qu'ils ont faites il y a 2 ou 3 ans si les choses changent ? franchement ?
 

 
Lors d'une mise à jour oui, mais si il met pas à jour ?
 
Perdre de l'argent ? Sur une appli gratuite ?
 

 
Il y a des défauts et des inconvénients j'en convient, et je m'y connais suffisamment en vidéo pour le savoir (au cas ou... www.rippack.com ça te parleras peut être ? ). Mais techniquement rien ne l’empêche. Surtout à l'ère des chipset intelligents qui accélèrent les choses matériellement.
 

 
Des jeux ? Oui pas mal Quasiment tous les jeux Android déjà. Check le source de Replica Island par ex.
 
Le portage de quake en Java aussi est un bon exemple (adapté sur Droid et Nexus One, tourne très bien )

 
1) t'as une idée du nombre d'archis supportées par debian ?
non aucune
2) le code source est portable et permet d'assurer la pérénité, pas le binaire compilé
une recompil c'est que dalle
D'ailleurs même avec java du byte code d'une appli ou d'un lib en 1.3 peut ne pas fonctionner sur une version plus récente, ça arrive.
Et même avec le code source ça arrive, par exemple l'introduction du mot clef enum en 1.5 oblige de modifier les noms de variables s'appellant enum dans les applis 1.3, sinon ça compile pas.
3) dans ce cas elles ne verront aucun inconvénient à faire le build elles mêmes sur leurs machines