Xamarin.forms: Uwp Xamarin.Forms.Shell

El soporte de Shell solo se proporciona para Android e iOS en este momento. Evaluamos continuamente los comentarios sobre el posible soporte futuro de UWP y proporcionaremos más información en el futuro a medida que esté disponible.

Normalmente uso iOS y Android para los usuarios de mi teléfono y UWP para los usuarios de mi tableta y escritorio. Por lo tanto, tener soporte para UWP será muy importante para mantener comprometidos a los usuarios de Windows.

¿¿Qué?? MS realmente está abandonando su propia plataforma. ¡Es triste escuchar esto!

¿No hay ninguna visibilidad sobre cuándo se brindará el soporte para UWP? ¿O ya se ha tomado la decisión?

Soporte de Shell para UWP, ¡por favor!

También me gustaría ver la compatibilidad de UWP con Shell.

Para mi empresa, UWP es bastante importante porque nuestros clientes usan tabletas Windows en combinación con algunos teléfonos Android para hacer su trabajo. No podremos migrar a Shell si falta la compatibilidad con UWP.

De acuerdo: la compatibilidad con UWP me permite hornear en la capacidad de la tableta de Windows con mi implementación móvil. Tendría que codificar esto completamente por separado sin él. ¡Qué asco! ¡La compatibilidad con UWP es imprescindible!

No sé si tiene sentido, porque todavía no he usado Shell. Pero tal vez haya una forma de usar todos los demás elementos de la aplicación (además de Shell) para una implementación de UWP. Después de todo, al parecer, usar TabbedPage y MasterDetailPage lograría lo mismo.

También votaría por la capacidad de usar UWP con Shell.

UWP, por favor ... o al menos alguna versión de la API de UX de Microsoft en la que podamos confiar durante unos años. Este enfoque de "le avisaremos si podríamos apoyarlo más adelante" es simplemente mezquino.

Entonces, sí, UWP o lo que sea lo respaldará, pero lo que es más importante: UN COMPROMISO CON CUÁNDO SABEMOS SI O CUÁNDO.

No puedo pasar a Shell sin esa certeza.

No solo UWP sino también MacOS, por favor.

No sé si se dio cuenta de que UWP no solo es una plataforma que todavía es ampliamente utilizada por los desarrolladores, sino también la forma más rápida de poner en funcionamiento aplicaciones XF basadas en Android e iOS. Porque, en comparación, los emuladores proporcionados tanto para Android como para Mac son muy lentos, propensos a problemas y no hablemos de la horrible experiencia de certificación o de que todavía nos vemos obligados a tener una Mac real, ¿de acuerdo? Entonces, aunque después de todo no puede reemplazar el desarrollo en lo real, una aplicación para UWP aumenta la productividad del desarrollador al ofrecer una manera rápida, fácil y completa de hacer ... cosas ... hechas. Y luego: haga lo que sea necesario para que su aplicación esté en funcionamiento en iOS y Android también.

Entonces, ¿podría agregar soporte de shell para UWP?

https://github.com/xamarin/Xamarin.Forms/pull/6015

De acuerdo con @Mephisztoe , realmente es una gran herramienta de productividad y, por supuesto, la opción de hacer que la aplicación esté disponible para Windows también es una buena ventaja :)

No relegue Xamarin.Forms solo a plataformas móviles. Me gustaría ver un soporte continuo para UWP especialmente, pero también para WPF y GTK #.

Entonces, básicamente, cualquier persona que tenga una aplicación que sea multiplataforma para las tres plataformas en Xamarin Forms en este momento no puede actualizar y usar estas funciones. Si el desarrollo futuro en Xamarin Forms para UWP no sucederá, ¿por qué no simplemente eliminar UWP de la lista multiplataforma?

Las diferentes plataformas siempre tendrán diferentes prioridades. Después de todo, dijiste "las tres plataformas", no "las siete plataformas".

@GalaxiaGuy eso es correcto, dije las tres plataformas considerando que si dijera siete plataformas estaría inventando plataformas imaginarias. Según la documentación de Xamarin.Forms:

Xamarin.Forms
Xamarin.Forms expone un completo kit de herramientas de interfaz de usuario multiplataforma para desarrolladores de .NET. Cree aplicaciones de plataforma universal de Windows, iOS y Android completamente nativas con C # en Visual Studio.

Y en el archivo Léame dice:

Xamarin.Forms proporciona una forma de crear rápidamente aplicaciones nativas para iOS, Android, Windows y macOS, completamente en C #.

Eso no significa que no sea compatible con GTK, WPF y Tizen.

Estoy de acuerdo en que esas plataformas son probablemente menos importantes que UWP, pero hay mucha gente que piensa que UWP es menos importante que iOS y Android.

Sin embargo, generalmente estoy de acuerdo con la opinión y tengo que ignorar las funciones más nuevas porque no están en UWP.

Para su información, a menos que esté leyendo las notas de la versión incorrectamente, parece que hay una implementación ShellRenderer para Tizen en la vista previa 4.1. Sin mención de UWP.

Si la solicitud de extracción de

Lamento que esto no se haya movido más rápido. Llegué a algunas regresiones al sincronizarme con el maestro, y me he visto completamente abrumado por el trabajo y las cosas relacionadas con la familia, así que no he tenido mucho tiempo para sentarme y tratar de abordarlo. Sin embargo, estoy más que feliz de tomar relaciones públicas para mi sucursal.

También usaremos el shell tan pronto como esté disponible en UWP. Tenemos el mismo problema que el anterior. Tenemos una combinación de tabletas, teléfonos y portátiles tanto con Android como con Windows. Y también pensamos que el mejor entorno de desarrollo es UWP

Este problema es una de las principales razones por las que renuncié a XF. Para nuestros clientes, las computadoras de escritorio y los dispositivos móviles tienen la misma prioridad.

¿Qué puedo decir que no se haya dicho ya?

así que ¡SIGA CON ELLO!
El soporte para UWP no es opcional para Microsoft. ¿Realmente necesitas que te lo digan?

@papiermache tenga en cuenta que el código de conducta se aplica a todas las comunicaciones, problemas y comentarios sobre este proyecto

También trata esto como una prueba del compromiso de MS Xamarin con los desarrolladores. ¿Alguien del lado de la EM está listo para pesar?

Lo siento todo, atemperaré más pensamientos ... pero me quedé totalmente impresionado al descubrir la falta de soporte para UWP; ni siquiera se me ocurrió que UWP no sería una plataforma incluida desde el principio. Almiar.

De: Jeremy [email protected]
Enviado: 16 de agosto de 2019 2:28 p.m.
Para: xamarin / Xamarin.Forms [email protected]
Cc: Rick Piovesan [email protected] ; Mencione menció[email protected]
Asunto: Re: [xamarin / Xamarin.Forms] Uwp Xamarin.Forms.Shell (# 5593)

@papiermache https://github.com/papiermache tenga en cuenta que el código de conducta se aplica a todas las comunicaciones, problemas y comentarios sobre este proyecto

-
Recibes esto porque te mencionaron.
Responder a este correo electrónico directamente, visualizarla en GitHub https://github.com/xamarin/Xamarin.Forms/issues/5593?email_source=notifications&email_token=ABJC5GJKYHEGIOR3P2UIKX3QE4EVLA5CNFSM4G7ANE7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4PT3PQ#issuecomment-522141118 , o silenciar el hilo https://github.com/ notificaciones / unsubscribe-auth / ABJC5GKCHSPBRJ5JNNEVD5LQE4EVLANCNFSM4G7ANE7A .

Hola @dotMorten , ¿puedes darnos alguna actualización? ¿Sigues pensando en intentar que UPW + Shell funcione? Comprenda que es un acto de bondad y comunidad :) Solo me pregunto, ya que sus esfuerzos parecen estar más cerca de lograr que Shell + UWP funcione. Todavía completamente desconcertado por lo que parece ser un giro de Microsoft alejándose del soporte de Windows con Xamarin. Agradecido por todas las demás bondades, pero aún perplejo y frustrado.

Lo siento. Un poco agotado en este momento, así que no he vuelto a revisar esto. Recuerdo que fusionarme con el último causó muchas regresiones y simplemente no he tenido el tiempo ni la energía para volver a ponerlo al día. También identificó varias cosas que tendrían que cambiar y requerir una mayor aceptación por parte del equipo de XF, pero no obtuvieron mucho apoyo más allá de "seguro, echemos un vistazo" y luego se extinguieron. En general, el apoyo y los comentarios que recibí del equipo de XF fueron solo de aliento, pero con un poco de falta de seguimiento. Todavía estoy esperando comentarios sobre el trabajo que hice, pero en este punto probablemente esté demasiado desactualizado. Con suerte, pronto tendré algo de tiempo y energía para volver a hacerlo.

Este problema se encuentra actualmente entre los 10 elementos abiertos más comentados, pero no está en la hoja de ruta para completar.

@pauldipietro ¿podemos obtener una actualización sobre esto? Me parece que estoy enviando una señal de que el soporte de UWP ya no es una prioridad para el equipo de XF. Si eso es cierto, díganos para que podamos hacer planes al respecto.

Gracias

De acuerdo, solo quiero saber si XF no incluirá soporte para Windows. Si no es así, también quiero saber por qué no. ¿Saben cuál será la "próxima" pila de Windows UX además de UWP y no quieren desperdiciar ciclos? ¿Será algo de Blazor / HTML la próxima pieza? Si es así, házmelo saber (nosotros) para que pueda hacer la transición ... ¿Quizás a la plataforma uno?

De: Scott Kuhl [email protected]
Enviado: jueves 22 de agosto de 2019 1:21:22 p.m.
Para: xamarin / Xamarin.Forms [email protected]
Cc: David Gerding [email protected] ; Comentario [email protected]
Asunto: Re: [xamarin / Xamarin.Forms] Uwp Xamarin.Forms.Shell (# 5593)

Este problema se encuentra actualmente entre los 10 elementos abiertos más comentados, pero no está en la hoja de ruta para completar.

@pauldipietro https://github.com/pauldipietro ¿podemos obtener una actualización sobre esto? Me parece que estoy enviando una señal de que el soporte de UWP ya no es una prioridad para el equipo de XF. Si eso es cierto, díganos para que podamos hacer planes al respecto.

Gracias

-
Estás recibiendo esto porque comentaste.
Responder a este correo electrónico directamente, visualizarla en GitHub https://github.com/xamarin/Xamarin.Forms/issues/5593?email_source=notifications&email_token=AAD7YD4EYE5XBBSXIR6MGV3QF3KKFA5CNFSM4G7ANE7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD456VUI#issuecomment-524020433 , o silenciar el hilo https://github.com/ notificaciones / unsubscribe-auth / AAD7YD42CJSV4KS5ZFWWJU3QF3KKFANCNFSM4G7ANE7A .

Francamente, me parece que la mejor opción sería reemplazar XF con Uno Platform ...

Xamarin ha dejado en claro que su objetivo son principalmente dispositivos móviles (teléfonos, tabletas, relojes), no computadoras de escritorio o portátiles.

No tienen ningún interés en respaldar y mantener UWP por sí mismos, por lo que no es bueno para mí recomendarlo a mis clientes.

Quiero aclarar mi necesidad: no necesito _UWP_ para Xamarin Forms. Necesito _algunos objetivos de Windows_ para Xamarin Forms. UWP parece el candidato más viable. Si tuviera que adivinar, Microsoft eventualmente apostará e irá a HTML y al cliente Blazor para computadoras de escritorio, ya que podría brindarles el alcance de UX más amplio en un mundo posterior a Windows. Eso también podría encajar mejor con una ruta de shell componible (no xf shell). En ausencia de una hoja de ruta coherente para el lado de Windows de UX, no puedo imaginar qué más podrían estar planeando.

Pero para ser claros, eliminar el soporte de Windows para Xamarin sin anunciar en letras grandes y en negrita, "NOSOTROS NO HACEMOS Y NO HAREMOS WINDOWS", es, como mínimo, realmente, realmente cruel. Suena a "viejo Microsoft".

@davidortinau et al: Por favor, haga algo más que señalar a los ahora efectivamente muertos (vea la última publicación de @dotMorten ) "soporte de la comunidad para XF Shell + Windows".

Estoy muy agradecido por todas las cosas nuevas y geniales de Xamarin. Pero necesito una respuesta más honesta sobre la viabilidad futura, si la hubiera, de los objetivos de Windows que usan Xamarin.

Varias cosas que tendrían que cambiar y requerir una mayor aceptación por parte del equipo de XF.

Sé que uno de estos tuvo que ver con WinUI, que esperamos incorporar como una dependencia con este PR.
https://github.com/xamarin/Xamarin.Forms/pull/7214

Ese PR mantiene la compatibilidad 16299 y, según mis pruebas, funciona muy bien cuando se incluye con un nuget y no requiere que el usuario instale WinUI. Todavía necesito hacer girar 16299 en una máquina virtual para asegurarme, pero me mantengo optimista. Sé que @dotMorten ha expresado algunas preocupaciones sobre la incorporación de WinUI, así que si las he ignorado por completo, hágamelo saber :-)

Aquí está ese nuget.

Xamarin.Forms.4.3.0.1853.zip

Si alguien más quisiera probarlo por nosotros y háganos saber si tiene algún problema que sea realmente útil. Lo probé con la plantilla básica de UWP y funciona bien para mí sin fallas.

El camino que veo para esto actualmente es

• Consiga # 7214 fusionado para que nos encarguemos de la dependencia de WinUI
• obtener la base de datos de UWP Shell PR (tenemos esto programado para un sprint futuro, así que lo haremos en ese momento o si alguien más nos adelanta)
• Morten ya lo tiene funcionando con Gastropods, por lo que solo queremos probarlo con algunas muestras más (principalmente Xaminals), una vez que esté funcionando y hagamos los cambios de limpieza de código que sean necesarios, fusionaremos

Si me falta algo con esa ruta, avíseme e intentaremos solucionarlo, por lo que todo lo que se necesita hacer es una nueva base y una verificación contra Xaminals.

@PureWeen ,
Puedo ejecutar App132.zip con el Xamarin Nuget que proporcionaste. La aplicación parece funcionar bien ... asumiendo que se supone que debe agregar elementos con marca de tiempo al control de la lista. Tanto el botón en la parte superior como el comportamiento Pull to Refresh agregan elementos.

No estoy seguro de lo que estoy buscando, pero agradezco sus esfuerzos y trataré de ayudarlo como pueda.

Dave G

@PureWeen Es genial ver que está avanzando con WinUI. La dependencia de WinUI estaba creando comportamientos de ruptura para mí, ya que WinUI estaba agregando una dependencia que no se agregó de manera transitiva. Eso se puede arreglar si usa VS2019, pero no estoy seguro de si WinUI ha aprovechado esa función todavía (y aún afectará a los usuarios de VS2017, pero al menos tiene una solución).
Además, hubo errores en WinUI que me causaron muchos dolores de cabeza, pero he notado recientemente que algunos de los que registré se solucionaron, así que todo eso es alentador. Hazme ping una vez que entre 7214 e intentaré comenzar este esfuerzo.
También me encantaría recibir ayuda para reajustar. La última vez que hice eso, arruiné totalmente este PR :-)

@dotMorten ¡¡ Suena bien !!

Probé la aplicación que incluí anteriormente en VS 2017 y funcionó para mí, así que creo que estamos bien en ese frente

No estoy seguro de lo que estoy buscando, pero agradezco sus esfuerzos y trataré de ayudarlo como pueda.

Lo principal sería agregar el nuget a su proyecto principal de UWP y asegurarse de que todos parezcan compilarse y ejecutarse correctamente.

Solo trato de verificar que agregar una dependencia de WINUI no causará ningún dolor de cabeza :-)

Probé la aplicación que incluí arriba en VS 2017

¿Sin agregar también WinUI al jefe del proyecto? Ese es el problema que encontré: si la gente actualizara a una versión de XF que depende de WinUI, no funcionaría sin agregar también manualmente una dependencia a WinUI. En mi humilde opinión, eso es un cambio radical. WinUI puede cambiar su paquete para que funcione implícitamente, pero requeriría VS2019 ya que se basa en una función de NuGet 5.0 (y, por supuesto, no han realizado este cambio, por lo que no funcionará en ninguno de los dos en este momento).

Aquí está el problema que inicié sesión en WinUI: https://github.com/microsoft/microsoft-ui-xaml/issues/596#issuecomment -524187369

Podría hacer un PR rápido para al menos abordar eso para que los usuarios de VS2019 no tengan que agregar manualmente la dependencia adicional.

Solo agrego que cuando probé la aplicación123 fue con VS2019.

¿Sin agregar también WinUI al jefe del proyecto?

Sí, el proyecto que he vinculado anteriormente puedo abrir dentro de VS2017 y se compila y funciona bien. No tengo el nuget de WinUI agregado al encabezado de UWP, solo se indica como una dependencia dentro del nuspec

Realmente no entiendo cómo funciona eso. Hay un estilo que debe agregarse y un paquete de marco de aplicación adicional que debe instalarse con el paquete, y todo está hecho por .targets. ¿El paquete de marco ya está instalado en su máquina?

Visual Studio Magazine acaba de cubrir este tema en particular. Microsoft, hora de una respuesta oficial.

https://visualstudiomagazine.com/articles/2019/08/23/xamarin-forms-4-2.aspx

@dotMorten Estoy fuera por un par de días, pero lo investigaré cuando regrese. También me comuniqué con el equipo de WinUI para revisar

Este objetivo funciona bien de manera transitiva cuando probé en VS 2017
https://github.com/microsoft/microsoft-ui-xaml/blob/8f8cd0fe32754cfcd83dafb2fc8539703b6aec26/build/NuSpecs/MUXControls-Nuget-Common.targets#L6

Aquí hay un nuget actualizado que le permite anular la configuración en su proyecto de formularios locales
Xamarin.Forms.4.3.0.1853.zip

<SkipMicrosoftUIXamlCheckTargetPlatformVersion>false</SkipMicrosoftUIXamlCheckTargetPlatformVersion>

En el proyecto de formularios, hicimos que esto se hiciera realidad para que no sorprendiera a la gente.

https://github.com/xamarin/Xamarin.Forms/pull/7214/files#diff -5e6292d5925c776aa9aa6d6f8c63ddf6R19

@PureWeen Este es el bit que debería funcionar sin agregar estas líneas explícitamente (ya que todos los usuarios también tendrían que actualizar sus cabezas de proyecto):

Creo que estás diciendo que funciona, pero asegúrate de que estamos en la misma página.

Puede ser que consideres que esto es un cambio radical aceptable, pero recuerdo que esto sucedió recientemente con otra dependencia y desconcertó a mucha gente, ya que la ruta de actualización no es tan limpia como simplemente elegir una nueva versión de XF.

Re: la necesidad de un objetivo de escritorio / portátil / tableta para Xamarin Forms

Para aquellos de nosotros que estamos creando aplicaciones móviles en entornos corporativos, la capacidad de producir un ejecutable de escritorio / portátil "similar al trabajo" a partir de la misma base de código básico que la base de Android / iOS es esencial. No es necesario que sea solo Windows (un objetivo basado en navegador como HTML / JS sería igual de bueno), pero la gran mayoría de nuestros usuarios tienen una computadora de escritorio / computadora portátil con Windows + un teléfono iPhone / Android, por lo que un ejecutable de Windows es bien en su mayor parte.

Hemos descubierto que cuando ponemos a disposición una aplicación móvil dentro de la organización, la mayoría de nuestros usuarios quieren probarla primero en sus computadoras portátiles / de escritorio, y solo si la encuentran útil o se adapta adecuadamente a sus necesidades, se dignarán poner en sus teléfonos. Además, obtener la aceptación (y la retroalimentación) de los usuarios funciona significativamente mejor si pueden ingresar datos o consultar resultados desde el escritorio o el dispositivo, dependiendo de dónde estén trabajando en ese momento en particular.

Xamarin Forms funciona bien para estos escenarios, y realmente nos gustaría usar Shell y CollectionView, pero son una estantería para nosotros hasta que se puedan usar para producir una computadora de escritorio o una computadora portátil.

@dotMorten, por lo que la razón por la que no veo la excepción es que tengo WinUI como una dependencia del nuget, por lo que si instala XF en el cabezal de UWP, WinUI viene y aplica sus objetivos.

Esto hace que el paquete XF en sí tenga que instalarse en el proyecto principal de UWP para que funcione. Probé mi ejemplo anterior con XF solo instalado en el proyecto netstandard y pude recrear su excepción.

Hemos hablado un poco de esto en este número.
https://github.com/xamarin/Xamarin.Forms/issues/4126

Esto se rompe si las personas solo tienen XF instalado en la biblioteca compartida y no en el proyecto principal de UWP. Así que tendremos que discutir esto un poco para ver qué queremos hacer al respecto.

@pureween ok bien. Me alegro de que veamos lo mismo entonces. Algunas cosas a considerar en sus discusiones:

• Si mi PR en WinUI se fusiona, solo afectará a los usuarios de VS2017 (lo que, sin embargo, podría volverse extraño si un equipo usa ambos y solo afecta a algunos usuarios).
• Puede detectar esto durante Init () y lanzar un error que les dice a los usuarios exactamente qué hacer para que el dolor no sea tan grave.
• Estaba jugando con la idea de que XF tiene un archivo de objetivos que agrega la dependencia al proyecto de referencia si aún no está presente, pero podría
  crea una experiencia de desarrollo extraña.
• Todos los proyectos de UWP siempre usarán esta dependencia una vez que WinUI se separe de la plataforma (pero para entonces VS2017 probablemente ya no tenga soporte).
  
  
  
  • Podrá admitir versiones inferiores de Win10 con este cambio, creando un valor agregado que podría justificarlo.
  
  
  • Nadie se dará cuenta porque, según su equipo, nadie realmente usa UWP de todos modos 😜 j / k
  
  

Un enfoque más posible: detecte si se hace referencia a WinUI durante la inicialización, pero deje que la aplicación se ejecute. Cualquier renderizador que se base en WinUI lo lanzaría, por lo que solo afectará a los usuarios de estas nuevas funciones. Entonces, la historia se convierte en "Si desea usar Shell o PullToRefresh, también debe agregar una referencia a WinUI (si está en VS2017)".

@dotMorten ¡ Gracias por todos sus esfuerzos para llevar Shell a UWP! Esto es muy necesario y debería haberlo abordado el equipo principal de Xamarin.

¡Aquí tienes una muestra de Xaminals ejecutándose en UWP con CV y ​​Shell!

¡Buen trabajo!

Trabajo fantástico. Lo incluiremos en nuestro marco para crear aplicaciones de nivel empresarial tan pronto como se publique.

Buen trabajo, lo intentaré en una versión futura de mi aplicación ;)

¡Sí, Xamarin lo hizo! Leí que un chico dice que nos mudamos a Uno. ¡¡¡¡No!!!! Xamarin ha sido genial para nosotros y nos ha ahorrado mucho tiempo para tener que aprender swift + java. Seamos pacientes con el equipo y apoyémoslos

cerrado por # 6015

Buen trabajo, gracias por todo el equipo <3, lo convertiré 💃

Buen trabajo, muchas gracias!

OK, algo extraño está sucediendo, actualicé mi proyecto para usar el 4.3.0.947036, ahora el proyecto falla al llamar a forms.init con
'No se pudo encontrar el tipo de tiempo de ejecución de Windows' Microsoft.UI.Xaml.Controls.XamlControlsResources

Lo que es muy extraño es la cantidad de código que ahora se encuentra en XamlTypeInfo.g.cs, en la versión anterior de Xamarin solo teníamos 13 entradas, ahora tenemos más de 43. Instalé Win.UI Nuget en el proyecto y aún así no ayuda. Algunas ideas

@ abrantie1z - (aunque fuera del tema, pensé en mencionar) Uno y Xamarin Forms ya no tienen que ser una opción mutuamente excluyente - vea https://platform.uno/xamarin-forms/ y https: / /visualstudiomagazine.com/articles/2019/09/19/uno-platform-2.aspx Advertencia: no he usado Uno, así que no tengo idea de lo robusto que es este soporte. Pero cualquier cosa que haga que más personas se interesen en XF en los navegadores es algo bueno.