Je pense qu'il est utile pour les membres de la communauté que l'équipe Xamarin.Forms rédige plus de documents sur l'architecture Xamarin.Forms, le principe de conception et son flux de travail dans Github ou MS docs.
De mon point de vue, j'utilise Xamarin.Forms pour créer mes produits, j'aurai 2 choix lorsque je rencontrerai les bogues, l'un est de soumettre le problème à github et attendre qu'il soit corrigé pour un jour et un autre est de soumettre le problème à github et réparé par moi-même.
Après avoir cloné le code source et l'avoir débogué, il est difficile de comprendre comment fonctionnent les fonctionnalités. Par exemple https://github.com/xamarin/Xamarin.Forms/issues/8521
Un autre exemple est la fonctionnalité de navigation de page de Xamarin.Forms côté Android. Il est facile de comprendre la fonction de navigation parmi les activités sur Android natif. Mais sur Xamarin.Forms, il semble qu'il utilise une activité principale pour gérer toutes les pages (peut-être) (à l'exception des formulaires natifs et de la vue native).

Je pense que c'est génial.

Diviser la galerie et les vitrines pour les spécifications/problèmes, etc. en projets plus petits qui peuvent être travaillés et présentés plus facilement est un gros avantage dans le cycle de développement.

L'une des choses les plus problématiques à faire est d'avoir plusieurs versions différentes dans lesquelles les bogues sont corrigés ou les fonctionnalités introduites dans, puis lors de l'amélioration.
Avoir plusieurs instances plus petites aide beaucoup à cela.

Une autre chose à laquelle je pense est d'utiliser des espaces de code et à l'avenir des espaces de code github, où l'on peut joindre des fichiers dotfiles pour un problème (y compris la bonne version de xamarin, etc.), puis nous pourrions simplement utiliser des espaces de code ou extraire cette version.

Le mieux serait que les plus petites parties de la galerie de contrôle puissent ensuite être disponibles en tant que projets disponibles séparément et pouvant simplement être ouverts dans des espaces de code. Je peux voir beaucoup d'avantages dans la combinaison d'applications de contrôle et d'espaces de code plus petits.

Je suppose que ce que j'essaie de dire est :

• Galerie de contrôle en plusieurs parties
• prise en charge des espaces de code
• dotfiles en cause

Edit : troisième point ajouté.

Je suis d'accord, j'ai eu quelques problèmes ouverts pendant des mois à la fois. J'ai cloné XF mais je m'y perds.
Donc, un doc pour vidéo montrant simplement comment fonctionne la solution serait génial.

Plus cela peut être .Netty, mieux c'est.

1. Supprimez les chaînes magiques et les liaisons non typées du noyau. N'exigez pas que les contributeurs au référentiel écrivent une liaison non typée ou une chaîne dont le type n'est pas vérifié. Cela réduira considérablement les bogues, rendra la correction des bogues beaucoup plus facile et facilitera la refactorisation afin que de nouveaux bogues n'apparaissent pas.
2. N'exigez pas des contributeurs qu'ils traitent avec une couche de balisage. Certains développeurs voudront utiliser XAML ou CSS, mais les contributeurs qui corrigent les bogues ne devraient pas avoir à se soucier de ces choses. Seules les personnes travaillant sur les langages de balisage, qui devraient être une couche au-dessus des vraies classes .Net, devraient se soucier de cette couche.
3. L'approche du moteur de rendu doit être structurée de manière à ce que l'échec de la mise en œuvre d'un changement de propriété (ou une erreur de type en le faisant comme ci-dessus) soit une erreur de type.
4. Le cas échéant, il devrait y avoir une tolérance pour l'implémentation de certaines fonctionnalités sans aucune liaison spécifique à la plate-forme, par exemple en utilisant SkiaSharp ou Shapes ou des objets MAUI composites, pour des implémentations multiplateformes fiables qui affichent la même chose et n'introduisent pas de nouveaux bogues.

À un moment donné, nous testions une direction pour avoir une SLN simplifiée à laquelle les utilisateurs peuvent contribuer comme ceci

https://github.com/PureWeen/Xamarin.Forms.Sandbox

Fournissez simplement un "Contributor.sln" très ciblé où les contributeurs peuvent démontrer un correctif ou une API

Supprimez toutes les galeries actuelles et concentrez-vous simplement sur les plates-formes et une page principale

Un filtre de solution serait-il meilleur ? Vous n'avez pas à maintenir deux solutions.

Nous verrons ce que tout est développé avec les filtres de solution

AFAIK actuellement, ils ne fonctionnent pas sur vsmac et ils sont un peu bizarres lorsque vous avez des projets multi-cibles. Une fois que nous pouvons avoir un support de première classe pour le ciblage multiple et que les projets principaux peuvent simplement être de style sdk, je pense que le besoin de filtres de solution n'est pas aussi élevé.

L'autre chose ennuyeuse est que VS pour Windows construit actuellement toutes les cibles lorsque vous avez un ciblage multiple alors que vsmac ne construit que celle pour la tête de plate-forme que vous exécutez.

L'autre chose ennuyeuse est que VS pour Windows construit actuellement toutes les cibles lorsque vous avez un ciblage multiple alors que vsmac ne construit que celle pour la tête de plate-forme que vous exécutez.

Obtenir de l'aide pour cela dans VS pour Windows serait génial ! Je pourrais me débarrasser de toutes ces configurations supplémentaires que j'ai faites pour ne construire que la plate-forme avec laquelle je travaille en ce moment.

Convenez que l'histoire actuelle du multi-ciblage sur VS pour mac est incroyablement frustrante. Malheureusement, le multi-ciblage est une si bonne option que je le choisis toujours comme approche et que je ne fais que servir de support technique aux autres membres de l'équipe qui rencontrent des problèmes. C'est un flux de frustration sans fin.