Salut

Je suis un développeur C#/Java et si y'a un truc que j'adore faire c'est les applications androids.
Mais ca me saoule un peu
Voilà j'ai déjà faites deux applications, (Ex : https://play.google.com/store/apps/details?id=com.coruscant11.noelshackimageupload / https://www.jeuxvideo.com/forums/1-1000005-1408090-1-0-1-0-stable-pictures-upload-noelshack.htm )
J'y arrive .. mais bon

J'ai jamais vraiment suivis de tutoriel, je sais bien programmer en java, là n'est pas le problème, mais en faites sur android j'ai jamais vraiment bien appris, du coup a chaque fois que je veux faire un truc je regarde sur google et je C/C, pour les graphiques j'utilise l'editeur graphique (pas le xml ..) fin j'ai juste les connaissances basiques quoi. Je suis pas très autonome concernant android.

Donc voilà, vous aurez pas un tutoriel, par forcément réservé au debutant (Pour ceux qui ont aquis le java quoi), pour bien reprendre mes bases a zero ?

Merci

Je ne développe plus sous Android depuis un certain temps (en fait j'en ai essentiellement fait pour un projet durant mon année scolaire), mais les étapes à suivre ici sont cohérentes: https://developer.android.com/training/index.html
Ça + le guide et quelques morceaux de la référence, c'est ce qui m'a appris à faire ce que tu demandes (a.k.a concevoir des interfaces en XML plutôt que via l'outil graphique, faire une appli qui tient la route au niveau cycle de vie Android...).

Merci Google, tu gère comme toujours.

J'ai pas fait grand-chose, mais c'est gentil

Franchement j'ai rarement trouvé une doc aussi bien foutue que celle d'Android justement

Le site officiel d'Android suffit et rempli très très bien son rôle de référence.
A côté de ça sinon, niveau bouquins, je recommandais "L'Art du développement Android", mais sa dernière édition commence à dater...

Si tu as des questions, n'hésites pas

J'ai vu, plus parfait y'a pas

Et puisque tu fais du C# et du Java peux tu nous dire les principales différences entre les deux

La notion d'accesseurs n'est pas présente en Java
Ni la surcharge d'opérateurs
Pour les lambda-expressions je ne sais pas mais il me semble que ça n'est pas présent en Java non-plus
La notion de méthode virtuelle n'est pas non-plus présente en Java (pas de mot-clé pour décider de l'aspect virtuel ou non d'une méthode)
Le mot-clé "var" pour gérer automatiquement le type lors de l'affectation non-plus

Etc.

Sinon pour moi la principale différence, c'est le framework .net
Déjà que la librairie standard java est incroyablement complète, mais alors .net c'est hallucinant, tu trouve absolument tous dessus

Sinon les vrais différences sont ce que Google a dis

Aussi un truc que j'ai bien aimer c'est Xamarin.Android, en gros tu fais tes apps android et utilisant la librairie standard java et .net en même temps c'est enorme
Par contre l'IDE est a chier

En faites les vrais différences dont ceux que Google a dit
Il sait toujours tout lui aussi, tu coder avec le même language toute ta vie lui il code avec le même 1 jour et ils est 10x plus expérimenté que toi

Bof, le C# j'ai dû en avoir 20 heures de cours cette année + un partiel de quatre heures, on peut pas vraiment dire que je "maîtrise" le langage (je n'ai réalisé aucun gros projet avec, et je ne sais pas à quoi ressemble du C# pondu en entreprise).
J'avoue que j'ai bien aimé ce langage, il pallie à mon goût certains manques de Java et les petits extras directement importés de chez C++ ne sont clairement pas de refus. Pour l'instant j'ai choisi de me concentrer sur le C++ car j'y vois un langage plein de potentiel pour une infinité de projets (avec à la clé une portabilité assez exemplaire), mais il n'est pas exclu que je fasse quelques bricolages en C# plus tard dans mon temps libre.

Même chose avec Android, j'ai eu un mini-projet à réaliser cette année comme je disais dans mon premier post, et quelques cours d'initiation avant pour expliquer les grandes lignes (pour le reste on se démerde, c'est là que je suis allé lire la documentation de Google). C'est sûr que ça m'a donné une vision d'ensemble correcte, de quoi ne pas dire trop de conneries quand je m'avance sur le sujet mais encore une fois je n'ai pas idée de l'allure d'un "gros projet Android".
Mais ce que j'ai vraiment retenu, c'est que Google déroule clairement le tapis rouge aux développeurs pour sa plateforme, avec une politique très attractive, c'est assez agréable.

Pour la "notion d'accesseur", j'imagine que c'est mettre une annotation sur une variable d'instance pour dire "dispo en lecture, dispo en écriture", "dispo en lecture", "dispo en écriture".
Tu as cette possibilité avec des bibliothèques tierces. AndroidAnnotations et Lombok. La première permet de se passer de findViewById, setOnClickListener, setOnItemClickListener... La seconde permet de se passer des getter/setter.
Ces deux bibliothèques fonctionnent à base d'annotation et inspectent le code AVANT qu'il ne soit compilé pour en générer une nouvelle version contenant les méthodes et liaisons qui vont bien.

Concernant les lambda, ça vient avec Java 8, qui vient de sortir et qui n'est pas supporté par Android (ni Dalvik, ni ART). Peut-être que Google prévoira son support, mais je trouve plus plausible qu'il change de langage (idée qui me trotte depuis que j'ai vu certains partenariats y'a 1-2 ans).

Pour les méthodes virtuelles, elles le sont toutes par défaut en Java. Le seul moyen de ne pas les rendre virtuelles, est de les déclarer "final".

Pour "var", je n'en vois pas l'utilité, mais ça doit venir de mon aversion pour les typages faibles. En lisant la documentation, on connait le type de retour, ou en foutant un type débile, mon IDE me propose de corriger en mettant le bon.

Google_Bot : "Mais ce que j'ai vraiment retenu, c'est que Google déroule clairement le tapis rouge aux développeurs pour sa plateforme, avec une politique très attractive, c'est assez agréable. "
Tu n'as pas encore vu l'envers du décor ^^
Pour réaliser des tests unitaires ou fonctionnel facilement, Android n'est pas encore mature de ce côté-là.
De même, avoir migré sous Gradle, c'est cool... mais la documentation ne suit pas vraiment, malheureusement. Celle de Gradle est très complète, mais celle du plugin Android de Gradle... il faut un peu batailler avec pour vraiment la comprendre.
De même, la très grande variété de terminaux pose problème, non pas pour les tailles/densité, mais pour les surcouches constructeurs/opérateurs qui modifient les comportements standard dans certains cas...
Ajouter à ça en, prime qu'il en existe de rares qui sont en paysage par défaut, et non portrait... cela pose des problèmes pour toutes application business ayant vocation a être portrait (et je m'escrime à faire comprendre qu'il vaut mieux prévoir les 2 orientations... ainsi que de ne pas mettre en place de splashscreen...).

Intéressant concernant Gradle, j'avais pas du tout suivi cette histoire (et je n'ai jamais été confronté à sa doc).

« Pour "var", je n'en vois pas l'utilité, mais ça doit venir de mon aversion pour les typages faibles. En lisant la documentation, on connait le type de retour, ou en foutant un type débile, mon IDE me propose de corriger en mettant le bon. »
C'est pas du typage faible, une fois que mon "var foo" a été affecté, il a un type et il le garde définitivement (on est pas en Javascript non-plus...)
Pour moi le principal exemple vient en C++ avec les itérateurs utilisés ça et là pour parcourir un même conteneur (genre un std::vector<T> ou une std::map<T>). Si en cours de route tu décides de changer ton vector<T> en map<K,T>, tu peux laisser tout ce qui a utilisé "auto" (l'équivalent de "var" mais chez C++) tel quel. Pratique pour ne pas avoir à se taper un gros sed sur tous les itérateurs éparpillés dans le code.
Et même d'un point de vue esthétique (mais là c'est surtout C++ qui est concerné), je préfère instancier un itérateur avec
auto monIterateur = maMap.begin();
plutôt que
map<pair<int,int>, list<char>>::iterator monIterateur = maMap.begin()
ça, couplé avec une syntaxe foreach (dispo en C++ aussi avec for(iterator : container)), ça permet de ne plus perdre un temps inutile à flanquer "le bon type" dans une boucle, sachant que ça n'influe pas sur le bon déroulement de ce qui est à l'intérieur.

« Ajouter à ça en, prime qu'il en existe de rares qui sont en paysage par défaut, et non portrait... cela pose des problèmes pour toutes application business ayant vocation a être portrait (et je m'escrime à faire comprendre qu'il vaut mieux prévoir les 2 orientations... ainsi que de ne pas mettre en place de splashscreen...). »
Copain!
Je me suis cassé le cul à rendre mon application "orientation-proof" (car comme en plus j'utilisais des fragments, il fallait faire tout un souk pour sauver les meubles lors de la rotation, puis tout réinstancier comme il faut...), et même "auto-kill proof" (enfin pas kill... mais quand Android manque de mémoire et finit par mettre le process au cagibi là, et que tout ce qui dépasse est détruit).
Ça m'a pris du temps mais bon c'était formateur, plutôt que d'interdire bêtement le mode paysage (vu dans la promo...).

Pas faux pour le var.
Le mieux que je puisse faire est de changer le type d'une variable est de propager via les erreurs détectées avec les suggestions auto.

C'est ce que je faisais avant de découvrir auto, et c'était chiant