Creo que es útil para la gente de la comunidad si el equipo de Xamarin.Forms escribe más documentos sobre la arquitectura de Xamarin.Forms, el principio de diseño y su flujo de trabajo en Github o MS docs.
Desde mi punto de vista, uso Xamarin.Forms para crear mis productos, tendré 2 opciones cuando encuentre los errores, una es enviar el problema a github y esperar a que se solucione algún día y otra es enviar el problema a github y lo arreglé yo mismo.
Después de clonar el código fuente y depurarlo, es difícil entender cómo funcionan las características. Por ejemplo https://github.com/xamarin/Xamarin.Forms/issues/8521
Otro ejemplo es la función de navegación de la página de Xamarin.Forms en el lado de Android. Es fácil comprender la función de navegación entre actividades en Android nativo. Pero en Xamarin.Forms parece que usa una actividad principal para manejar todas las páginas (tal vez) (excepto los formularios nativos y la vista nativa).

Creo que esto es genial.

Dividir la galería y las vitrinas para especificaciones / problemas, etc.en proyectos más pequeños en los que se puede trabajar y mostrar más fácilmente es una gran ventaja en el ciclo de desarrollo.

Una de las cosas más problemáticas es tener varias versiones diferentes en las que se corrigen errores o se introducen funciones y luego se avanza en la mejora.
Tener varias instancias más pequeñas ayuda mucho con esto.

Otra cosa en la que estoy pensando es usar espacios de código y, en el futuro, espacios de código github, donde uno puede adjuntar archivos de puntos para un problema (incluida la versión correcta de xamarin, etc.) y luego podríamos usar espacios de código o verificar esa versión.

Lo mejor sería si las partes de la galería de control más pequeñas pueden estar disponibles como proyectos que están disponibles por separado y simplemente se pueden abrir en espacios de código. Puedo ver muchos beneficios en la combinación de espacios de código y aplicaciones de control más pequeñas.

Supongo que lo que intento decir es:

• Galería de control multiparte
• soporte de codepaces
• dotfiles en cuestión

Editar: se agregó el tercer punto.

Estoy de acuerdo que he tenido algunos problemas abiertos durante meses. Cloné XF pero me perdí en él.
Entonces, un documento para video que solo muestre cómo funciona la solución sería genial.

Cuanto más .Netty esto puede ser, mejor.

1. Quite las cuerdas mágicas y las ataduras sin mecanografiar del núcleo. No requiera que nadie que contribuya al repositorio escriba un enlace sin tipo o una cadena sin verificación de tipo. Esto reducirá drásticamente los errores, facilitará mucho la corrección de errores y facilitará la refactorización para que no aparezcan nuevos errores.
2. No requiera que los contribuyentes se ocupen de ninguna capa de marcado. Algunos desarrolladores querrán usar XAML o CSS, pero los colaboradores que corrigen errores no deberían preocuparse por estas cosas. Solo las personas que trabajan en lenguajes de marcado, que deberían ser una capa sobre las clases .Net reales, deberían preocuparse por esta capa.
3. El enfoque del renderizador debe estar estructurado de tal manera que no implementar un cambio de propiedad (o un error de tipo al hacerlo como se indicó anteriormente) sea un error de tipo.
4. Cuando sea apropiado, debe haber tolerancia para implementar algunas características sin enlaces específicos de la plataforma, por ejemplo, usando SkiaSharp o Shapes u objetos MAUI compuestos, para implementaciones confiables entre plataformas que muestran lo mismo y no introducen nuevos errores.

En un momento dado, estábamos probando una dirección para tener un SLN simplificado al que los usuarios pueden contribuir de esta manera.

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

Simplemente proporcione un "Colaborador.sln" muy específico en el que los colaboradores puedan demostrar una solución o una API.

Elimine todas las galerías actuales y concéntrese en las plataformas y una MainPage

¿Sería mejor un filtro de solución? No tiene que mantener dos soluciones.

Veremos qué se desarrolla con los filtros de solución.

AFAIK actualmente no funcionan en vsmac y son un poco raros cuando tienes proyectos con múltiples objetivos. Una vez que podamos tener un soporte de primera clase para la orientación múltiple y los proyectos principales puedan ser del estilo sdk, creo que la necesidad de filtros de solución no es tan alta.

La otra cosa molesta es que VS para Windows actualmente construye todos los objetivos cuando tiene múltiples objetivos, mientras que vsmac solo crea uno para el cabezal de la plataforma que está ejecutando.

La otra cosa molesta es que VS para Windows actualmente construye todos los objetivos cuando tiene múltiples objetivos, mientras que vsmac solo crea uno para el cabezal de la plataforma que está ejecutando.

¡Obtener soporte para eso en VS para Windows sería increíble! Podría deshacerme de todas estas configuraciones adicionales que hice para construir solo la plataforma con la que estoy trabajando en este momento.

De acuerdo en que la historia actual de múltiples objetivos en VS para mac es increíblemente frustrante. Desafortunadamente, la orientación múltiple es una opción tan excelente que todavía la elijo como mi enfoque y solo sirvo como soporte técnico para otros miembros del equipo que tienen problemas. Es un flujo interminable de frustración.