J'ai trouvé un peu gros, alors que tu débutes, que tu accuses le langage plutôt que ta propre compétence.
Tu confonds peut-être le fait que je débute avec Basic4Android et le fait que je sois compétent. Je ne vais pas te donner mon CV, mais ça fait plus de 25 ans :
- Que je fais du développement informatique depuis des langages de base comme l'assembleur jusqu'à des langages orientés objets purs comme Smalltalk en passant par tous les hybrides plus ou moins objets comme PowerBuilder, Visual Basic, PHP et certains Pascal
- Que j'ai dirigé des équipes informatiques et que j'ai pu voir les problèmes de maintenance qui se posent lorsque tu commences à gérer des applications qui font plusieurs centaines de milliers de lignes et qu'il y a 20 personnes qui sont intervenues dessus pendant 5 ans.
- Que des langages, j'en ai vu et utilisé beaucoup, que pas un seul n'est parfait et que je me permet d'émettre des critiques sur chacun d'entre eux
si tu veux me fermer la porte au nez [...] Si tu nous épargnes tes jugements à deux balles [...] ce serait amusant d'en émettre aussi quelques-uns histoire de te montrer un peu l'impression que ça fait.
Le meilleur moyen que tu as trouvé pour ouvrir la porte et coopérer, c'est de parler de mon code qui ressemble à un plat de spaghetti et inefficace.
Ce qui n'est d'ailleurs pas de ta part un jugement à deux balles de ta part bien entendu...
Alors mon gars, l'agressivité, elle se trouve de ton côté et je te la renvoie. J'ai émis des critiques (justifiées ou pas) à l'encontre du langage et de l'outil. Mais ce n'est pas toi que j'ai critiqué (d'ailleurs je ne savais même pas que tu existait). Et toi au lieu de répondre à ces critiques sur le langage et éventuellement de m'expliquer en quoi elles étaient injustifiées, tu t'es senti personnellement responsable et tu m'es rentré dans le lard avec des attaques personnelles. Un comportement de fanboy plutôt qu'un comportement d'entraide.
Alors, ne viens pas me reprocher une attitude que tu as toi même initiée.
Donc, même si cela te déplaît et que tu me trouves incompétent, je renouvelle mes critiques à l'encontre de Basic4Android (bien qu'il t'a certainement échappé que j'ai dit que je trouvais ce langage génial)
- L'absence d'une documentation digne de ce nom
- La difficulté de segmenter son code dans plusieurs fichiers afin de faciliter la lecture et la maintenance
Et j'en rajoute deux.
- Dans le designer : quand on sélectionne plusieurs Views dans le designer, les seuls attributs présentés sont EventName, Parent, Top, Left, ... Donc pas possible de passer tout un lot de views en invisible, de changer leur police de caractères ou leur alignement.
- Le designer propose parfois les couleurs sous une forme nommée, parfois sous forme RGB sans avoir la correspondance. J'avais mis un objet dans un gris nommé. Deux jours après, j'ai voulu mettre un autre objet dans le même gris (dont j'avais oublié le nom bien entendu). Sauf que pour le premier, je n'avais plus que sa valeur RGB sans le nom et que pour le deuxième j'avais le nom mais pas le RGB.
Quand au coup des tableaux de views, c'est pouvoir nommer les objets dans le designer lbl(1), lbl(2), lbl(3), ... au lieu de lbl1, lbl2, lbl3. Ce qui permettrait dans le code source de pouvoir accéder directement à un tableau de views.
Enfin à propos des classes, Basic4Android permet de faire pas mal de choses, mais exclusivement sous forme programmatique d'après ce que j'ai pu en voir, donc sans profiter des avantages d'un designer.
Il me semble qu'on est très loin de ce que pouvait faire un langage tel que PowerBuilder où tu pouvais poser des objets à l'écran, leur assigner leurs attributs visuels, mettre en place leurs méthodes (click, changed, ...) et les enregistrer en tant qu'objets à part entière utilisables directement. Par exemple, tu pouvais faire un objet EditTextemail qui vérifie qu'une adresse email est valide (objet hérité d'un objet simple), un objet EditTextemailVerif qui combine les deux précédents et qui vérifient que les emails sont identiques et un objet FormulaireAdresse qui combine un champ pour le nom, le prénom, ... les deux adresses emails, ... (objets composés de plusieurs objets simples).
Ces objets pouvaient alors être utilisés dans le designer : c'est-à-dire qu'ils seraient apparus dans le menu AddView et que leurs propriétés accessibles dans le panneau. En un clic dans AddView (ou son équivalent), on pouvait ajouter un formulaire de saisie d'adresse.
Je viens de regarder le code ClsWheel, un objet que je vais utiliser(*). Mais ce qui me choque, c'est que la puissance du designer n'est pas utilisée. A quoi cela sert-il d'avoir un designer visuel si c'est pour tout faire de manière programmatique. Initialiser le bouton OK, sa taille, sa position, sa police de caractères, ... placer les roues, ... tout ça en code alors qu'une grande partie pourrait être faite sous forme visuelle (ce qui allègerait le code).
Idem à l'utilisation : pouvoir placer l'objet clsWheel directement à l'écran et indiquer ses propriétés dans le designer. Là aussi, cela allègerait le code source.
Donc les classes pour répondre à mon problème, je ne trouve cela pas particulièrement adapté car globalement je vais perdre en efficacité à la fois en développement initial qu'en debugging et ensuite en maintenance et évolutions.
Poste-le histoire qu'on te montre comment l'écrire de façon plus efficace et comment le réorganiser. Un module de code n'est pas forcément la bonne solution. Utiliser une classe est peut-être plus intéressant, surtout qu'on peut créer et partager des vues avec les classes.
