Faisons vibrer cette conversation, car nous avons vraiment besoin de vous entendre, notre communauté de développeurs !

D'ABORD, merci @jassmith d' avoir travaillé pour capturer cela et d'élaborer une proposition pour que nous en discutions ouvertement ici.

Je vais partager certaines de mes réflexions, poser des questions stupides et poser des questions, espérons-le, pas trop suggestives. En tant que gestionnaire de programme pour Xamarin.Forms, je dois souvent poser des questions de manière à donner l'impression que je n'en ai aucune idée (parfois non), mais en réalité, j'ai juste besoin d'entendre des choses de VOUS sans mettre des mots dans sa bouche.

Il y a des choses que j'aime dans cette proposition, parce que je peux voir comment elles pourraient résoudre certains des problèmes dont j'ai parlé à beaucoup, beaucoup d'entre vous, et nous travaillons à les résoudre.

J'ai aussi des réserves.

Je vais commencer ici avec quelques pistes de réflexion générales sur le concept Shell et l'expérience du développeur.

Expérience de l'application

pour obtenir une expérience d'application complète et correctement structurée, utilise les bons éléments, avec très peu d'effort et un chemin clair pour être bon par défaut.

Si j'utilise cette approche pour décrire mon application au plus haut niveau, j'obtiens :

• une application sur le même thème sur toutes les plateformes
• conception matérielle (dans ce cas) modèles activés par défaut
• les derniers modèles de navigation activés avec la configuration
• Je n'ai pas besoin de travailler pour personnaliser l'entrée ou le bouton pour qu'ils soient identiques sur iOS, Android et UWP ?

Est-ce exact? D'autres avantages que je devrais souligner?

Au lieu de App j'ai MaterialShell . J'ai besoin d'apprendre/d'adopter un nouveau paradigme d'application de haut niveau pour en bénéficier ?

Une fois que je suis dans mon application, je suis de retour au pays de ContentPage , n'est-ce pas ? Mais tous mes Button s et Entry s sont matérialisés et jolis. Puis-je encore OnPlatform et autres pour que l'apparence (ou le comportement) soit différente sur une autre plate-forme ?

À quoi ressemble mon chemin de migration d'une application existante à l'utilisation de ce « shell » ? Je présente le nouveau MaterialShell , décris la structure et l'apparence de mon application, et je l'exécute simplement pour voir la nouvelle bonté ?

Personnalisation

Quelles sont mes options si j'aime l'apparence des Flyout ou des éléments de menu, mais que je dois les modifier pour qu'elles correspondent aux compositions de mes concepteurs ? À quel moment est-ce que je dis « Ugh, j'aurais dû tout faire moi-même » et déplacer ce que j'ai vers une structure d'application Xamarin.Forms standard ?

Si je dois abandonner totalement le MaterialShell , est-ce que je perds toute cette qualité de style et je suis de retour là où j'ai commencé (comme aujourd'hui) avec un Entry assez différent entre iOS et Android et UWP ? Je voudrais pas.

Il y a un point de basculement que j'anticipe. Après avoir utilisé cette approche pour démarrer rapidement, je vais atteindre certaines limites et j'ai besoin d'explorer mes options. Quels sont-ils et à quel moment est-il préférable de ne pas utiliser MaterialShell ?

Le problème

Je terminerai ce premier commentaire par quelques questions à tous ceux qui lisent.

• Le problème que cette proposition tente de résoudre est-il bien défini ?
• Est-ce un problème que vous partagez ?
• En lisant cette spécification, quels problèmes avez-vous rencontrés sur des projets précédents pensez-vous que cela résoudrait pour vous ?

Si possible, des captures d'écran / images de conception seraient encore meilleures.

Regarde aussi ceci :

http://www.noesisengine.com/webgl/Samples.Buttons.html

@jassmith Cela aurait été formidable si toute l'idée était présentée sous forme d'images. Bravo pour l'effort de mise en place des spécifications. Mes questions ne sont peut-être pas correctes.

Mes requêtes sont

• Prise en charge des tablettes, la réactivité de l'application s'adaptant à différentes mises en page n'est pas abordée.
• La migration du modèle actuel vers le nouveau modèle sera-t-elle difficile ? Du point de vue du développeur d'applications et du point de vue des contributeurs Xamarin Forms.
• Je suis d'accord que la plupart de l'application a besoin d'une seule interface utilisateur (en raison de la quantité de moteurs de rendu personnalisés que nous devons écrire parfois pour atteindre les mêmes concepts d'interface utilisateur) sans respecter les spécificités de la plate-forme, la nouvelle direction supprimera-t-elle toutes les fonctionnalités existantes, comme si nous continuerons à développer Xamarin.Forms applications avec une interface utilisateur spécifique à la plate-forme, ou tout le monde sera-t-il obligé de respecter de nouvelles normes.
• Les concepts de rendu existeront-ils toujours dans MaterialShell
• Pouvons-nous réellement dire, dans iOS, que nous voulons que cela soit rendu de cette façon ? Flutter a Cupertino Styles (apple UI) qui fonctionne sous Android et Android UI qui fonctionne sous iOS. Dans quelle direction Xamarin Forms se déplacera-t-il. Le développeur aura-t-il ce genre de capacités que Flutter offre maintenant.

Cela inclura-t-il également quelque chose de semblable à TextInputLayout pour prendre en charge les étiquettes/espaces réservés flottants ainsi que les messages d'erreur ? Si oui, alors je pense que Binding devrait être étendu pour inclure 'ValidateOnDataErrors' similaire à wpf.

Voir ma mise en œuvre de ceci ici
https://github.com/XamFormsExtended/Xfx.Controls/blob/develop/src/Xfx.Controls/XfxBinding.cs

De plus, je me demande si MaterialShell devrait étendre Shell afin que l'on puisse créer un HumanInterfaceShell pour l'apparence iOS.

@ChaseFlorell qui allait être mon commentaire aussi. Le matériel est génial, mais c'est autre chose si nous voulons écrire nos propres shells pour répondre aux besoins particuliers de l'interface utilisateur.

@davidortinau , @jassmith ,

Merci d'avoir élaboré cette spécification et de nous avoir permis de fournir des commentaires.

Le problème que cette proposition tente de résoudre est-il bien défini ?

Oui. Le système de navigation n'est pas complètement développé dans Xamarin Forms, il y a donc un problème ouvert sur la façon de le compléter ou de le contourner complètement.

Est-ce un problème que vous partagez ?

Oui.

En lisant cette spécification, quels problèmes avez-vous rencontrés sur des projets précédents pensez-vous que cela résoudrait pour vous ?

Je vais répondre à cette question en disant que je ne pense pas que cela résoudra les problèmes. Nos problèmes particuliers sont que le système de navigation actuel est trop rigide, pas qu'il ne l'est pas assez. L'exemple le plus clair pour nous est la TabbedPage. Il n'y a pas de vue TabbedView, donc si nous voulons des onglets dans notre application, nous devons utiliser TabbedPage. Ainsi, tout l'écran doit être occupé par la TabbedPage et nous ne pouvons pas utiliser d'espace pour nos propres boutons ou d'autres contrôles que nous pourrions vouloir mettre à l'écran. Ma recommandation aurait été de déplacer plus de fonctionnalités hors des pages vers les vues plutôt que de déplacer les fonctionnalités des pages vers une couche encore plus élevée.

Des choses comme FloatingMenu et FlyoutBehavior me font peur car elles impliquent que la navigation sera davantage codée en dur dans le système Xamarin.Forms et qu'un contrôle supplémentaire sera retiré aux développeurs de logiciels. Je peux voir une certaine valeur à avoir une approche plus standardisée, mais cela aura certainement un coût.

Nous avons toujours travaillé dans d'autres technologies basées sur XAML comme Silverlight, WPF et UWP. Dans ces technologies, nous avons une approche beaucoup plus ouverte où nous sommes en mesure de mieux définir le fonctionnement de la navigation. Récemment, nous avons engagé un consultant UI/UX. Il n'était pas au courant des caprices de XF. Nous lui avons juste demandé de nous construire des écrans basés sur les fonctionnalités de notre logiciel. De larges pans de ce qu'il a recommandé n'ont pas pu être mis en œuvre en raison de l'absence de TabbedView. Je crains qu'au lieu de faciliter la navigation, ce qui se passera, c'est que ce framework rendra en fait plus difficile la mise en œuvre des conceptions qui nous sont données par les concepteurs UX/UI.

L'autre chose que je dirais, c'est que ce cadre semble sans précédent dans d'autres plates-formes XAML, et je dirais que la priorité devrait être de fournir une normalisation sur les plates-formes plutôt que de fournir de nouveaux cadres avec lesquels les autres plates-formes ne seront pas compatibles. Nous construisons actuellement pour trois plates-formes : Silverlight, Xamarin.Forms et WPF. Ce dont nous avons besoin, c'est d'une standardisation entre ces plates-formes pour créer moins d'écarts, pas plus.

@dylanberry ,

c'en est une autre si nous voulons écrire nos propres shells pour répondre aux besoins particuliers de l'interface utilisateur.

Oui. C'est ma préoccupation. Chaque application a ses propres cas d'utilisation particuliers, et une plus grande rigidité est susceptible de rendre la tâche plus difficile - pas plus facile à mettre en œuvre.

Il y a aussi ce souci : https://github.com/xamarin/Xamarin.Forms/issues/2452#issuecomment -380991817

Je vais faire écho à ce qui précède, ainsi que demander comment les gestes et les pointeurs fonctionneront avec les primitives de forme irt?

Un commentaire général est que pour chaque ligne de code ajoutée à un système, il y a plus de 3 chances que du code bogué soit ajouté. Il y a déjà beaucoup de bogues dans Xamarin Forms qui doivent être corrigés. Plus de code signifie que les chances que des bogues soient ajoutés augmentent de façon exponentielle. Il y aura plus de bugs. Je pense que l'équipe XF devrait travailler pour réduire la taille de la base de code plutôt que de l'augmenter. Diminuer la base de code est le seul moyen de diminuer la probabilité que des bogues se produisent.

Pourquoi inventer à nouveau une nouvelle chose au lieu de corriger les bogues existants et de s'assurer d'abord que tout est solide comme le roc ?

Pour moi, cela a été évoqué, mais la navigation est la plus grande pierre d'achoppement de Xamarin Forms et m'a causé le plus de chagrin au cours des trois dernières années.

La navigation n'est pas cohérente sur les trois plates-formes avec le modèle MasterDetail causant de nombreux problèmes avec le hamburger vous obligeant à pousser les pages modales, vous devez ensuite implémenter une barre de navigation personnalisée car vous ne pouvez pas rajouter mais l'animation est horrible sur Android (même en DM).

• Idéalement, vous devriez pouvoir désactiver et remplacer le contenu de la barre de navigation par votre propre ContentView dans de nombreux cas. PlatformSpecifics a été initialement évoqué comme quelque chose qui aurait permis de positionner des éléments de barre d'outils (il y a longtemps quand je parlais à Bryan), mais il s'est avéré être quelque chose d'une utilité limitée.

• Possibilité de remplacer les éléments du framework comme les animations de page sautées

Une grande partie de ce qui est proposé semble très très utile, tant que vous pouvez simplement utiliser le shell matériel dans des pages spécifiques et que ce n'est pas à l'échelle de l'application, le code sera vraiment utile. C'est certainement quelque chose que nous utiliserions car à l'heure actuelle, je n'arrête pas de dire "C'est une limitation de Xamarin Forms" à notre gars UX (comme je l'ai fait dans mon rôle précédent). Oserais-je le dire, nous devrions obtenir les commentaires d'un point de vue UX qui ont déjà stylisé des applications Forms. Il devrait être opt-in comme XamlC.

Pas sûr du nom cependant, FlexShell aurait plus de sens... mais nous avons maintenant Flexbox (même si nous ne l'avons jamais demandé... désolé David, je n'ai pas pu m'en empêcher )

Aussi, cela signifierait-il que les thèmes sont en quelque sorte morts? jamais utilisé de toute façon.

@mackayn

C'est certainement quelque chose que nous utiliserions car à l'heure actuelle, je n'arrête pas de dire "C'est une limitation de Xamarin Forms" à notre gars UX (comme je l'ai fait dans mon rôle précédent).

D'accord, mais cela n'aurait-il pas plus de sens de corriger ou d'améliorer l'implémentation actuelle au lieu d'en créer une toute nouvelle, qui s'accompagnera également de bogues et de limitations ? Il dit juste là que :

MaterialShell est une API avisée à certains moments"

Sérieusement, dans combien de directions différentes Xamarin Forms peut-il aller ? L'équipe XF est à peine capable de continuer à réparer l'implémentation XF actuelle pour au moins Android et iOS, et maintenant ça ? Qu'en est-il de la correction de bogues, de la prévisualisation XAML, des performances ?

Il y a \ eu un ticket ouvert par quelqu'un avec une proposition pour ajouter un support simple mais très utile pour les pinceaux solides et dégradés multiplateformes , mais la réponse de

@opcodewriter

Oui, je dis que depuis un an, il y a une bizarrerie de navigation qui retient l'équipe Prism par exemple et ils n'ont jamais pu régler les problèmes.

J'essaie juste d'offrir des commentaires constructifs pour l'instant, Xamarin Forms est à un moment critique de son évolution, cette API pourrait résoudre de nombreux problèmes si elle est implémentée de manière flexible et non dans une approche à l'échelle de l'application.

@jassmith cela signifie-t-il que XF adoptera l'approche Flutter (en utilisant un moteur de rendu au lieu de contrôles natifs) pour le Shell ?

Les amis, hier Jason et moi-même avons eu une discussion sur la façon d'améliorer cette spécification et nous allons faire une mise à jour importante, nous divisons cela en différents problèmes.

J'aimerais faire écho à certains des sentiments ci-dessus : s'il vous plaît, améliorons simplement ce que nous avons, à moins bien sûr que vous ayez des ressources illimitées, alors allez-y 😉

Il y a tellement de choses encore laissées de côté : correction de ListView (difficile à croire que cela ne fonctionne toujours pas correctement), implémenter des contrôles comme CheckBox, RadioButton, implémenter la prise en charge des pinceaux (SolidColorBrush, GradientBrush), possibilité d'afficher un Popup basé sur une Page ou ContentView, la correction de bogues (voir le bogue récent signalé sur les vues transparentes), les performances, l'outillage et bien plus encore....

Pourquoi voudriez-vous commencer une nouvelle chose ?????

@TonyHenrique Oui, des photos seraient géniales. Je ne suis malheureusement pas un artiste et je ne possède pas les droits sur les images que j'utilise pour ma propre référence. J'espère qu'un membre de l'équipe de conception aura le temps de m'aider à produire des images appropriées pour la spécification.

@muhaym

• Prise en charge de la tablette. Il est destiné à s'assurer que la mise en page est adaptative aux tablettes. Cela ne couvrira bien sûr pas les cas de mise en page dans vos pages de contenu, ce serait une fonctionnalité différente. En grande partie, je gérerais cela avec le nouveau VSM.
• La plupart du temps, il suffit de placer vos pages de contenu au bon endroit et de vous adapter aux nouveaux concepts de navigation. Je ne dirai pas que ce sera toujours trivial, mais cela ne devrait pas non plus être débilitant.
• Absolument ne supprimera aucune fonctionnalité. En fait, je travaille sur la mise à jour de la spécification pour inclure une classe de base Shell qui manque certaines des fonctionnalités de MaterialShell mais qui est par ailleurs une version d'interface utilisateur spécifique à la plate-forme de Shell.
• Oui. L'ajout d'un dessin change simplement le moteur de rendu que vous obtenez en quelque chose qui sait comment gérer un dessin.
• Oui. Vous pouvez changer le moteur de rendu utilisé à n'importe quel niveau de la hiérarchie. Les moteurs de rendu sont simplement modifiés par des modèles définis avec des clés spéciales dans les dictionnaires de ressources. Vous pouvez modifier ces modèles à votre guise ou les désactiver en leur affectant la valeur null.

@ChaseFlorell non, mais je suis ouvert aux suggestions si vous souhaitez joindre un amendement à la spécification. Quant à la chose Shell vs MaterialShell, j'ai abordé cela ci-dessus. L'étape 1 consistait à s'assurer que MaterialShell avait un sens, puis à le répartir dans une classe de base était l'étape 2.

@dylanberry la classe de base ne rendra pas vraiment cela beaucoup plus facile. Ce n'est pas aussi simple que de changer de DrawingTemplates. J'ai l'intention d'implémenter l'aspect MaterialShell de cela dans un code spécifique à la plate-forme pour des performances optimales.

Les gestes

@mackayn, une API Transitions/Segue arrive et devrait bientôt arriver ici. Je travaille encore sur une partie de ma proposition initiale de nommage. Ce sera certainement quelque chose qui viendra par phases, seules les transitions de page étant en phase 1. Cela vous permettra cependant de remplacer les animations du framework. Quant à l'opt-in. Le Shell doit être la racine de votre application et ne peut pas imbriquer autre chose que TemplatedPage. Cela dit, le thème du contrôle interne est à 100% sous votre contrôle. C'est un peu plus qu'un interrupteur magique pour activer/désactiver les nouveaux modèles et vous pouvez contrôler cet interrupteur de la même manière que nous le ferons. Cela vous permet d'activer et de désactiver le thème au niveau de la page, de la mise en page ou même du niveau de contrôle.

@ encrypt0r pas exactement. Considérez-le comme un hybride. Il permettra le rendu, mais sous le capot, toutes les commandes spécifiques à la plate-forme seront simplement thématiques avec le code de dessin. Cependant, il existe une trappe d'évacuation pour Skia qui pourrait être facilement ajoutée (bien que je doute que cela se rapproche d'une v1).

@opcodewriter ListView2 (il ne sera évidemment pas nommé ainsi) est enfin sur la feuille de route cette année. Pourquoi une nouvelle ListView ? Eh bien, l'API d'origine conduit à un nombre presque illimité de bogues et de problèmes que nous ne pouvons pas vraiment résoudre efficacement sans rompre totalement la compatibilité descendante. Des choses comme Cell/ViewCell et ItemsViewet le TemplatedItemsList bien qu'ils fonctionnent bien pour ce qu'ils étaient destinés à un 1.0, sont loin d'être capables de ce qu'ils doivent être pour l'utilisation moderne de l'API.

Malheureusement, je ne vois aucun moyen de résoudre ce problème dans le type ListView lui-même, et je ne pense pas que la communauté ait pu le faire non plus, malheureusement. La meilleure option pour le moment est de garder ListView tel quel, puis de créer quelque chose de beaucoup plus élégant avec moins de frais généraux, moins de comptabilité, moins de types étranges qui n'ont pas besoin d'exister et de faire confiance aux frameworks cibles pour faire ce qu'ils font le mieux.

Le simple fait de supprimer l'ancienne stratégie de recyclage, ce qui constituerait un énorme changement de rupture de rétrocompatibilité que nous ne pouvons pas faire, supprimerait une partie importante de la base de code Xamarin.Forms. ListView2 vous rapprochera beaucoup plus du métal en supprimant ces éléments qui étaient destinés à être des garde-corps (ou dans le cas de Cell, la fusion impie de 2 projets internes différents) et qui font maintenant du mal à tout le monde.

L'ancienne stratégie de mise en cache a un impact sur CHAQUE moteur de rendu existant aujourd'hui. C'est la raison pour laquelle chaque moteur de rendu prend en charge la modification de son élément. Si cela disparaissait selon ma meilleure estimation, environ 10% de tout le code du projet disparaîtrait. C'est vraiment le plus gros cancer du projet.

@davidortinau, vous obtenez votre propre commentaire simplement parce que le vôtre a une si belle mise en forme !

Si j'utilise cette approche pour décrire mon application au plus haut niveau, j'obtiens :

• une application sur le même thème sur toutes les plateformes
• conception matérielle (dans ce cas) modèles activés par défaut
• les derniers modèles de navigation activés avec la configuration
• Je n'ai pas besoin de travailler pour personnaliser l'entrée ou le bouton pour qu'ils soient identiques sur iOS, Android et UWP ?

Est-ce exact? D'autres avantages que je devrais souligner?

Oui c'est correct. Il existe de nombreux autres avantages que vous pouvez mettre en évidence, mais ils devraient devenir évidents une fois que vous commencerez à jouer avec. Comme vous pouvez le faire en bas de page, avoir un FAB, naviguer à l'aide d'URL (mise à jour toujours à venir) et bien plus encore.

Au lieu d'App, j'ai MaterialShell. J'ai besoin d'apprendre/d'adopter un nouveau paradigme d'application de haut niveau pour en bénéficier ?

Tort. Vos applications MainPage est le MaterialShell. L'application est toujours la racine de votre application.

Une fois que je suis dans mon application, je suis de retour sur ContentPage, n'est-ce pas ? Mais tous mes boutons et entrées sont matérielles et jolis.

À l'exception de l'endroit où vous vous êtes trompé ci-dessus, oui, c'est correct.

Puis-je toujours OnPlatform et autres pour que l'apparence (ou le comportement) soit différente sur une autre plate-forme ?

Oui.

À quoi ressemble mon chemin de migration d'une application existante à l'utilisation de ce « shell » ?

Regardez le cas de reproduction de Google Play Store, imaginez y mettre toutes les pages actuelles de vos applications. Cela remplace uniquement les zones de votre application où vous utilisez directement les pages Nav/Tab/MD. Cela n'a aucun impact sur vos pages de contenu.

Je présente le nouveau MaterialShell, décris la structure et l'apparence de mon application, et je l'exécute simplement pour voir la nouvelle qualité ?

Bingo

Quelles sont mes options si j'aime l'apparence du Flyout ou des éléments de menu, mais que je dois les modifier pour qu'elles correspondent aux compositions de mes concepteurs ?

Vous contrôlez entièrement l'en-tête, la façon dont l'en-tête s'effondre et se cache. Vous contrôlez entièrement l'apparence/la sensation de chacune des « Cellules » (ce ne seront pas des cellules) dans le menu volant. Vous contrôlez également entièrement l'en-tête de chaque groupe. En effet, vous contrôlez le "look" de tout, mais nous devons encore ajouter quelques endroits supplémentaires pour que vous puissiez placer du contenu supplémentaire.

À quel moment est-ce que je dis « Ugh, j'aurais dû tout faire moi-même » et déplacer ce que j'ai vers une structure d'application Xamarin.Forms standard ?

Si le menu volant de la mise en page physique du Google Play Store est complètement différent de ce que vous voulez. Pas légèrement différent, complètement différent.

Si je dois abandonner totalement le MaterialShell, est-ce que je perds toute cette qualité de style et je suis de retour là où j'ai commencé (comme aujourd'hui) avec une entrée assez différente entre iOS et Android et UWP ? Je voudrais pas.

Aucun MaterialShell ne définit simplement des ressources par défaut pour que ses enfants les obtiennent. Vous pourrez le faire vous-même. Vous devrez peut-être le faire de toute façon, nous ne nous sommes pas réellement engagés à faire en sorte que MaterialShell le fasse par défaut. Si nous le faisons opt-in au lieu de opt-out, ce sera un seul appel d'API pour n'importe quel sous-arbre.

Il y a un point de basculement que j'anticipe. Après avoir utilisé cette approche pour démarrer rapidement, je vais atteindre certaines limites et j'ai besoin d'explorer mes options. Quels sont-ils et à quel moment est-il préférable de ne pas utiliser MaterialShell ?

L'intention est que vous ne feriez JAMAIS mieux de ne pas utiliser Shell. Vous ne voudrez peut-être pas Material, mais vous devriez toujours vouloir Shell (encore une fois, la classe de base Shell arrive). Pourquoi? Le look/feeling de shell sera beaucoup plus configurable, l'histoire de navigation sera beaucoup plus unifiée, il ne devrait y avoir rien de sensé que vous puissiez faire avec les autres pages que vous ne pouvez pas faire avec Shell.

Mieux, l'intention est de s'assurer que les moteurs de rendu Shell sont réellement faciles à configurer et sains. Pas de classes cachées magiques, pas de sous-classes de vues natives personnalisées sur lesquelles nous prenons des mesures approfondies. Autant que possible, chaque composant des moteurs de rendu sera composé et échangeable. De cette façon, si cela ne fonctionne pas comme vous le souhaitez, vous pouvez réellement le réparer...

Pourquoi ne l'avons-nous pas fait au début ? Ce n'était pas un objectif de conception au début, puis nous nous sommes juste mariés avec ça... C'est assez grand et assez nouveau pour que nous n'ayons pas à porter cette erreur avec nous.

@opcodewriter

Sérieusement, dans combien de directions différentes Xamarin Forms peut-il aller ? L'équipe XF est à peine capable de continuer à réparer l'implémentation XF actuelle pour au moins Android et iOS, et maintenant ça ?

Qu'en est-il de la correction de bogues, de la prévisualisation XAML, des performances ?

^^ Ceci

@migueldeicaza

Les amis, hier Jason et moi-même avons eu une discussion sur la façon d'améliorer cette spécification et nous allons faire une mise à jour importante, nous divisons cela en différents problèmes.

Miguel, ça va clairement être un gros travail. Je ne peux pas parler au nom de tous les développeurs, mais je peux vous dire que mon équipe veut trois choses : stabilité, performance et flexibilité. Nous voulons que les bogues soient corrigés. Nous voulons que notre application fonctionne correctement et nous voulons pouvoir implémenter les conceptions que nos concepteurs UI/UX nous proposent sans nous retourner et dire "Désolé, ce n'est tout simplement pas possible sur notre plate-forme". Cette spécification semble aller à l'encontre de cet objectif. Cela nécessitera davantage de ressources pour le travail, ce qui signifie que vos ressources ne seront pas libérées pour travailler sur la stabilité, les performances et la flexibilité.

Serait-ce le nouveau comportement/façon par défaut de se développer dans les formulaires xamarin ? Ou aurions-nous toujours la possibilité de créer nos applications avec une apparence et une convivialité spécifiques à chaque plate-forme ?

@DanielCauser, bien que je soupçonne qu'à long terme, cela pourrait devenir la méthode "par défaut", cela ne remplacera en aucun cas la méthode actuelle. Ce sera simplement une manière plus intégrée et moderne qui fournira beaucoup plus de shell que les gens construisent actuellement à la main par défaut. En plus de cela, puisque nous fournirons la coque en tant que contrôle unique, nous pouvons optimiser considérablement la façon dont elle est dessinée et disposée. Vous n'aurez plus 3 passes de dessin juste pour votre coque.

Je suis prudemment favorable à cette idée, à condition que les améliorations qu'elle propose soient élaborées au moyen d'améliorations du code Xamarin Forms sous-jacent. Si cela ajoute plus de complexité aux formulaires, je ne l'utiliserais pas.
Pour mon argent, je préférerais de loin que les ressources des développeurs soient consacrées à rendre les formulaires plus flexibles, plus rapides et plus complets qu'ils ne l'ont actuellement. Si cela se produisait, je pourrais faire toutes les nouvelles fonctionnalités proposées ici pour moi-même. Dans ce cas, il est presque certain que le bricolage conviendra mieux à moi et à mes clients qu'une boîte à outils générique fournie par Xamarin, aussi bonne soit-elle. À quelques exceptions notables près, cette proposition ne résout pas les problèmes auxquels je suis actuellement confronté.

@jassmith

1. Il y a plus de 500 problèmes ouverts.
2. Xamarin Forms a 3 ans et il y a encore des bogues dans les commandes et les fonctionnalités de base, des fonctionnalités importantes font toujours défaut et les performances n'ont pas encore été complètement définies (je sais que certaines améliorations ont été apportées, mais les performances sur Android sont nettement inférieures à la moyenne).
3. L'équipe de développement Xamarin Forms est encore sous-dimensionnée.

Pourquoi voulez-vous commencer à travailler sur cette toute nouvelle fonctionnalité maintenant ? N'est-il pas plus logique de se concentrer d'abord sur ce qui précède ?

À propos de votre commentaire ci-dessus lié à ListView : j'applaudis toute forme d'approche audacieuse, y compris la refonte complète/le remplacement. Ce n'est pas comme si tout était si bien dans Xamarin Forms que les choses ne devraient pas être modifiées.

@opcodewriter

1) Oui, il y en a. Je suis d'accord que c'est un problème et que je continuerai d'être l'élément de travail prioritaire que je préconise personnellement.

2) Les performances sur Android en font partie. Cela donne au framework plus de temps pour les transitions de page afin que nous puissions masquer des choses comme le temps JIT. Nous pouvons charger et conserver de manière proactive les pages de manière beaucoup plus intelligente. Ce que l'équipe XF ne peut pas corriger, c'est le temps JIT global. Si vous exécutez votre application sous Android avec AOT activé et que c'est beaucoup plus rapide, je ne peux rien faire pour vous aider.

3) Aucun argument ici.

Pourquoi voulez-vous commencer à travailler sur cette toute nouvelle fonctionnalité maintenant ? N'est-il pas plus logique de se concentrer d'abord sur ce qui précède ?

Ce travail n'est pas prévu, nous discutons juste d'une spécification ici. Ma direction le programmera quand elle le jugera approprié avec mes conseils.

À propos de votre commentaire ci-dessus lié à ListView : j'applaudis toute forme d'approche audacieuse, y compris la refonte complète/le remplacement. Ce n'est pas comme si tout était si bien dans Xamarin Forms que les choses ne devraient pas être modifiées.

ListView est vraiment le bug bear de Xamarin.Forms. Sur ces 500 problèmes, dont 220 sont marqués comme des bogues (il y a aussi beaucoup de problèmes d'entretien ou d'amélioration), au moins 25 % concernent uniquement ListView. À titre de comparaison, c'est à peu près le même pourcentage que celui de l'ensemble de la plate-forme UWP. Pire encore, un bon nombre de crashers d'Android qui sont essentiellement décrits comme le rendu utilisé après l'élimination sont également des bogues ListView, mais il est peu probable qu'ils apparaissent dans ma recherche, car ListView n'apparaîtra nulle part dans la requête de recherche.

@jassmith en plus de la résolution des problèmes existants (à côté de ListView, il y a d'autres choses qui ne fonctionnent toujours pas correctement), il y a aussi des fonctionnalités importantes qui ont été omises (ordre aléatoire):
- Véritable prise en charge des popups (fonctionnalité de base et commune toujours manquante)
- Annuler la navigation de la page lors de la navigation arrière (problème en suspens depuis longtemps)
- Contrôles de base manquants (pas de CheckBox, RadioButton, etc.)
- Dessin multiplateforme (contrôle de la toile ou autre)
- Prise en charge du dessin multiplateforme de pinceaux solides/dégradés (SolidColorBrush, GradientBrush)

Je souhaite que plus de travail soit fait dans le sens de rendre le framework vraiment plus riche, et de ne pas ajouter de trucs comme le style CSS ou Flexbox (qui sont venus avec leurs propres problèmes).

@opcodewriter

Véritable prise en charge des popups (fonctionnalité de base et commune toujours manquante)

Juste, il ne semble jamais être assez prioritaire pour devenir réel. Cela est en fait allé assez loin à un moment donné.

Annuler la navigation de la page lors de la navigation arrière (problème en suspens depuis longtemps)

C'est en fait quelque chose que MaterialShell est destiné à résoudre. Il y a des raisons assez solides pour que cela ne puisse pas être fait dans NavigationPage.

Contrôles de base manquants (pas de CheckBox, RadioButton, etc.)

Certains d'entre eux font partie de l'initiative F100 en cours.

Dessin multiplateforme (contrôle Canvas ou autre)

Ce serait l'API sœur de celle-ci, comme spécifié dans le #2452

Prise en charge du dessin multiplateforme de pinceaux solides/dégradés (SolidColorBrush, GradientBrush)

Même réponse que ci-dessus.

@jassmith

Juste, il ne semble jamais être assez prioritaire pour devenir réel. Cela est en fait allé assez loin à un moment donné.

OK, j'ai hâte de le prioriser d'ici fin 2018 :)

C'est en fait quelque chose que MaterialShell est destiné à résoudre. Il y a des raisons assez solides pour que cela ne puisse pas être fait dans NavigationPage.

Pourriez-vous s'il vous plaît donner plus de détails pourquoi cela ne peut pas être fait dans la mise en œuvre actuelle ?

Certains d'entre eux font partie de l'initiative F100 en cours.

Je vois. Doigts croisés..

Pourriez-vous s'il vous plaît donner plus de détails pourquoi cela ne peut pas être fait dans la mise en œuvre actuelle ?

Je n'entrerai pas plus dans le détail ici car nous nous écartons massivement de la piste, mais l'essentiel est le suivant :

• Vous ne pouvez pas annuler le geste de balayage arrière dans iOS de manière réactive. Comme il s'agit de la principale méthode que les gens utilisent pour revenir en arrière avec les téléphones plus gros, cela devient une omission flagrante.
• Bien qu'il soit techniquement possible de remplacer ce comportement dans iOS, cela nécessite d'approfondir les éléments internes du UINavigationController d'une manière dont nous ne pouvons pas être sûrs qu'il sera réellement pris en charge ou fonctionnera lorsqu'une nouvelle version d'iOS sortira. En bref, Apple ne semble pas vraiment apprécier les gens qui font cela.

Il y a aussi d'autres préoccupations mineures concernant son impact sur le style. C'est la longue histoire courte cependant. Si vous souhaitez toujours discuter de cette fonctionnalité particulière, je vous suggère d'ouvrir un nouveau numéro :)

@jassmith
Je pensais que le simple fait de gérer gestureRecognizerShouldBegin et d'appeler quelque chose comme OnBackButtonPressed devrait suffire.

Dans l'ensemble, j'aime beaucoup ce que je lis, mais cela ne ressemble pas à quelque chose qui devrait être fait dans le nuget/repo de Xamarin Forms.

Il s'agit d'une approche avisée qui devrait être construite sur Xamarin Forms, et non intégrée. Je vois cela comme une bibliothèque distincte qui permet aux développeurs d'adopter une approche différente. Les parties requises de Xamarin Forms qui doivent être exposées devraient l'être, et cela devrait être construit au-dessus de ces bits.

Tout comme lorsque les développeurs prennent la décision d'utiliser Xamarin Classic/Native ou Xamarin Forms, je peux voir une décision similaire d'opter pour Xamarin Forms ou Xamarin Forms with a Shell.

Xamarin Forms doit se concentrer sur la création du meilleur framework d'interface utilisateur multiplateforme sans essayer de conformer les plateformes pour qu'elles se ressemblent. Aujourd'hui, Xamarin Forms fait un excellent travail pour s'assurer que la sensation de la plate-forme est respectée.

Je pouvais voir un Shell de base dans le référentiel Xamarin Forms et du code autour de la gestion des Shells, mais Material Shell semble trop étroitement couplé à un langage de conception et à un modèle de navigation spécifiques pour que je pense qu'il devrait être dans le référentiel Xamarin Forms.

@MonsieurJimson
Merci pour votre avis. L'emplacement exact de la surface publique de l'API n'est pas encore décidé. Il y a des avantages et des inconvénients des deux approches.

La spécification sera mise à jour (espérons-le très prochainement) pour avoir à la fois une classe Shell et une classe MaterialShell. La classe MaterialShell serait la partie que nous envisageons de sortir du noyau. Shell serait ce que vous avez décrit.

Mise à jour avec Shell Breakout et mise à jour des spécifications de navigation

J'aimerais vraiment que l'implémentation XF existante soit rendue... plus forte et meilleure pour permettre à quelque chose comme ça d'exister en tant qu'addon, pas dans le cadre de BCL. Ainsi, le fait d'avoir une plate-forme sous-jacente solide, correcte et stable profitera aux applications existantes et à toutes les nouvelles couches comme celle-ci.

J'attends avec impatience l'évolution de cette chose.

@jassmith @brianlagunas

Juste quelques remarques.

• BackButtonBehavior, il devrait sûrement y avoir une propriété de visibilité au cas où vous n'en voudriez pas du tout ?
• Le schéma de navigation Materialshell est comme Prism, fonctionnera-t-il avec ces frameworks existants ? (Prisme, FreshMVVM, MVVMCross)
• Pouvez-vous remplacer complètement la mise en page dans la barre de navigation ? dans l'état actuel des choses, Forms est extrêmement limité à cet égard et vous vous retrouvez avec des barres de navigation maladroites qui vous obligent à emprunter la route du rendu client, sachant qu'une nouvelle version de Forms cassera très probablement votre code personnalisé.
• MasterDetail n'est pas beaucoup abordé, pourrez-vous personnaliser le menu volant ?
• Quel contrôle aurons-nous sur le hamburger ?

Je veux juste m'assurer que les points faibles et les limitations existants sont traités ainsi que les nouvelles fonctionnalités ayant de nouvelles capacités.

Super.

Je suis très nouveau sur XF mais le framework a un peu la réputation d'être un peu fragile, bien que certainement cela s'améliore rapidement grâce à vos efforts.

Donc pour ce que ça vaut, c'est mon avis :-)

C'est bien que Xamarin reçoive beaucoup d'amour en ce moment, mais je suis d'accord avec @opcodewriter , à la fois l'outillage et le framework pourraient faire avec un remboursement de la dette technique.

J'aime aussi les réflexions de @MisterJimson selon lesquelles cela devrait être une couche différente - mais vous devez être honnête avec vous-même au sujet de votre capacité et du nombre de frameworks que vous pouvez prendre en charge. Nous sommes tous enclins à coder de nouvelles choses brillantes et passionnantes et à éviter les décisions difficiles, mais nous comptons sur vous pour développer une base solide pour notre code.

J'ai assez de problèmes pour faire fonctionner mon code sans me soucier de celui de quelqu'un d'autre :-)

XF est dans une bonne position en ce moment, il a le potentiel pour devenir un ensemble d'outils vraiment solide.

Merci pour tout votre travail acharné là-dessus, ça se voit.

@mackayn

BackButtonBehavior, il devrait sûrement y avoir une propriété de visibilité au cas où vous n'en voudriez pas du tout ?

Définissez la commande avec CanExecute renvoyant false. J'ai choisi de ne pas ajouter de méthode secondaire pour le moment.

Le schéma de navigation Materialshell est comme Prism, fonctionnera-t-il avec ces frameworks existants ? (Prisme, FreshMVVM, MVVMCross)

Je l'espère bien ! Je ne peux pas être sûr mais je pensais à eux et à tous leurs problèmes. C'est pourquoi toute navigation passe par un seul événement par exemple.

Pouvez-vous remplacer complètement la mise en page dans la barre de navigation ? dans l'état actuel des choses, Forms est extrêmement limité à cet égard et vous vous retrouvez avec des barres de navigation maladroites qui vous obligent à emprunter la route du rendu client, sachant qu'une nouvelle version de Forms cassera très probablement votre code personnalisé.

Cette partie est plus difficile. J'aimerais permettre ici autant d'extensibilité que possible, mais je suis vraiment ouvert aux suggestions sur la façon d'améliorer cela de manière saine et raisonnable.

MasterDetail n'est pas beaucoup abordé, pourrez-vous personnaliser le menu volant ?

Vous pouvez définir l'en-tête sur n'importe quelle vue arbitraire, vous contrôlez le modèle utilisé pour les en-têtes de groupe et les éléments et vous pouvez ajouter des éléments de menu. Vous contrôlez certains aspects de la mise en page mais pas à 100 %. Encore une fois, il serait bon d'avoir quelques idées sur ce dont vous pensez avoir besoin d'autre. Je vois clairement le besoin d'un pied de page avec une propriété de comportement de pied de page.

Quel contrôle aurons-nous sur le hamburger ?

BackButtonBehavior remplace également le hamburger. Il faudrait peut-être le renommer. Encore une fois, je suis ouvert aux suggestions ici. À l'origine, je l'appelais LeftBarButton, mais dans les situations RTL, ce n'est pas à gauche...

La récupération technique de

Les interactions étroites entre la barre d'onglets et la barre de navigation sont l'un de ces domaines, s'assurer que la navigation entre les onglets ou les éléments du MDP est sans problème est un autre domaine. Il existe de nombreux domaines où de petits problèmes se produiront, car chaque élément n'est pas en mesure d'avoir une vue holistique du shell de votre application.

En ce qui concerne l'outillage, il y a une équipe entièrement distincte dédiée à cela et ils font d'énormes progrès. L'outillage interne s'est considérablement amélioré au cours des 6 derniers mois et j'ai vraiment hâte que vous puissiez l'essayer !

@mackayn

Le schéma de navigation Materialshell est comme Prism, fonctionnera-t-il avec ces frameworks existants ? (Prisme, FreshMVVM, MVVMCross)

N'ayez crainte, tient à cœur autant que nous. Vous pouvez être sûr que ce sera quelque chose que nous chercherons à soutenir. Quelque chose de cette ampleur nécessitera certainement beaucoup de dialogues entre équipes pour s'assurer qu'il répond aux besoins du développeur Forms dans son ensemble, ainsi qu'aux besoins des frameworks MVVM comme Prism.

@dansiegel

Bon à savoir que les deux équipes sont en dialogue, c'est tout ce que j'avais besoin de savoir

@jassmith Il est maintenant évident que la façon dont certaines choses fonctionnent ou ont été architecturées dans XF n'est pas la meilleure. Alors au lieu de mettre du rouge à lèvres sur le cochon (sans vouloir être impoli ici), pourquoi ne pas recréer un nouveau cadre à partir de zéro ou refactoriser massivement celui existant. Je sais, cela semble très effrayant, mais je suis à peu près sûr que la grande majorité des développeurs Xamarin Forms ne s'en soucierait pas, nous serions tous ravis de refactoriser nos applications ou quoi que ce soit juste pour que nous ayons des applications qui fonctionnent beaucoup mieux.
J'ai vu des relations publiques rejetées avec une bonne refactorisation parce que "nous ne voulons pas de ce genre de changements". Je ne sais pas qui a établi cette règle, mais il devrait prendre une profonde inspiration, se détendre et peut-être reconsidérer la « règle ».
Quel est le meilleur : continuer à avoir des développeurs frustrés en utilisant un framework qui ne peut pas le maintenir ou avoir des développeurs frustrés qui ont besoin de faire un travail de refactorisation ? Juste mes 2 centimes...

@opcodewriter vous et moi sommes d'accord mais c'est hors-sujet pour cette spécification.

Je viens de lire le nouveau matériel sur la navigation et je l'aime vraiment. Aimer avoir une sorte de main pour lier les commandes de navigation et orienter la navigation autour des URL (comme et je suppose influencé par Prism) est intelligent.

Ironiquement, le schéma de navigation URI était quelque chose que nous voulions faire il y a longtemps et avons commencé à pousser Prism à implémenter parce que nous ne pouvions pas raisonnablement l'intégrer dans le cadre. Pour ne pas prendre leur crédit, ils méritent 100% de ça :)

La sémantique exacte de la sténographie est toujours à saisir.

Je pense que cela finira probablement plus comme:

<Button Command="{segue:Uri}" CommandParameter="app://Foo/Bar/Baz" />

ou

<Button Command="{segue:Push}" CommandParameter="{DataTemplate local:MyPage}" />

Ainsi, les extensions peuvent être plus précises sur les paramètres qu'elles prennent. L'espace de noms est principalement utilisé pour que les choses soient faciles à découvrir avec intellisense.

@jassmith J'aime vraiment ce truc de segue. Puis-je vous demander comment vous comptez prendre en charge le mode push ?

Je n'ai pas tous les détails, mais je pourrais imaginer la navigation d'url comme un prisme, enveloppé dans des extensions de balisage.

<!-- push -->
<Button Command="{segue:Uri}" CommandParameter="path/to/page" />

<!-- push modal -->
<Button Command="{segue:Uri Modal='true'}" CommandParameter="path/to/page" />

<!-- reset stack -->
<Button Command="{segue:Uri}" CommandParameter="app://root/path/to/page" />

La première chose à noter est que la navigation URI ne fonctionnera qu'avec Shell. C'est le seul endroit où nous pouvons systématiquement donner un sens à la pile sans avoir de cas particuliers étranges et nous pouvons concevoir les interactions de navigation pour prendre en charge le concept.

Pour l'instant, nous ne prenons en charge que les URI complets. Les partiels sont beaucoup plus difficiles à gérer car ils sont contextuels.

Vos 3 exemples seraient alors, en supposant que l'emplacement actuel est : app://Shell/Apps/Games/Details

En particulier, cela signifie que vous êtes dans un Shell, dont le ShellItem actuel a la route Apps, dont le ShellTabItem actuel a la route Games, qui a une ContentPage poussée sur sa pile qui a les détails de la route.

<!-- push -->
<Button Command="{segue:Uri}" CommandParameter="app://Shell/Apps/Games/Details/page" />

<!-- push modal -->
<Button Command="{segue:Uri}" CommandParameter="app://page" />

<!-- reset stack -->
<Button Command="{segue:Uri}" CommandParameter="app://Shell/Apps/Games" />

Dans un shell uri, le premier emplacement est toujours un shell. Si ce n'est pas le cas, il s'agit d'une poussée modale. Vient ensuite le ShellTab, puis le ShellTabItem. Après cela suit la pile de navigation de ShellTabItem. Je n'ai pas l'intention de rétroporter la navigation URI vers tous les contrôles de page possibles pour le moment. Cela devient VRAIMENT poilu avec les personnes qui utilisent MasterDetailPage...

Avec l'enregistrement de la route et les propriétés de la route, il n'y a pas besoin de routage basé sur le type. Je vais le supprimer de la spécification.

@jassmith réfléchit davantage à ce truc de navigation, et j'ai quelques questions

1. comment pouvez-vous gérer CanExecute
2. comment pouvez-vous donner à l'utilisateur le contrôle (lire empêcher) plusieurs robinets ?
3. comment gérez-vous la navigation relative? C'est-à-dire que vous avez 3 pages de profondeur et que vous devez aller à la quatrième, mais la pile est entièrement dynamique ?
4. prism a cette notion fantastique de NavigationParameters par laquelle nous pouvons transmettre non seulement des valeurs de base via la chaîne /Navigation/MyPage/MyPageDetails?id=33 requête new NavigationParameters {{nameof(MyObject), MyObject}} . Envisagez-vous de soutenir quelque chose de similaire ?

@ChaseFlorell

1) Avec des séquences ? Vous ne pouvez pas actuellement. Il faut absolument y réfléchir davantage. Il y a un moyen de faire une commande de segue mais c'est... nul. Cela vous permettrait de le gérer, mais à ce stade, cela n'en vaut vraiment pas la peine.

2) Un Segue se désactivera jusqu'à ce que le push soit terminé. D'autres tentatives d'activation de la commande no-op jusqu'à la fin de la tâche de navigation précédente.

3) Vous pouvez utiliser une navigation traditionnelle comme push/pop avec segues. Ce sont des actions relatives.

4) [QueryParameterAttribute] peut exister ou non déjà, je ne peux ni confirmer ni nier. ;)

Il est peu probable que nous ajoutions la prise en charge d'objets complexes. L'idée est que vous utilisez des convertisseurs pour prendre vos valeurs simples et les transformer en objets complexes.

D'après l'expérience passée en matière de navigation d'applications basée sur URI (de retour dans le bloc d'application CAB-Composite UI pour p&p), je vous suggère fortement de ne pas utiliser le type System.Uri et de faire en sorte que tout ressemble à un URI, mais n'utilisez pas l'implémentation d'URI elle-même. @pprovost peut témoigner des cicatrices à vie que le travail a dû lui laisser. Je me souviens d'avoir rencontré d'innombrables problèmes alors que nous étions confrontés à des restrictions et des erreurs d'

Une partie du mal déjà fait , je suppose.

En fait, System.Uri est le meilleur choix pour prendre en charge un schéma de navigation basé sur URI. Alors que CAB a utilisé la navigation URI, il a également fait ce que vous dites et l'a fait "ressembler" à un URI en vous permettant d'utiliser des chaînes au lieu de l'objet System.Uri. Les noms d'hôte n'ont jamais été requis.

Ce que vous demandez, c'est une API basée sur une chaîne très lâche qui peut accepter n'importe quelle syntaxe de chaîne que vous y mettez, ce qui n'est pas quelque chose qui va produire des résultats prévisibles. Il doit y avoir des règles en place pour qu'un schéma de navigation basé sur un URI/une chaîne fonctionne.

Un URI arbitraire ne fonctionnera pas non plus dans XF. La liste des caractères invalides dans une URL mais qui sont valides dans un système de fichiers n'est pas précisément petite. Ce sont tous des cas où une chaîne aurait fonctionné, et un URI n'aura pas besoin d'être échappé ou de demander à l'utilisateur de comprendre pourquoi les choses ne fonctionnent pas (ou échouent ?)

Vous pouvez créer votre propre abstraction si vous voulez plus de restrictions (ou une meilleure sémantique/analyse/validation ?), mais à mon humble avis, System.Uri apporte beaucoup de bagages Internet qui ne sont FilePath pour représenter les chemins, qui ne sont généralement que des chaînes.

Au moins, il semble que tous les URI soient considérés comme relatifs, ce qui simplifie les choses. Dans CAB, nous avons également utilisé des uri absolus avec des parties de schéma et de nom d'hôte, ce qui était problématique.

Je préférerais de loin quelque chose comme un ResoucePath , disons, qu'un Uri . Mais si tard dans le jeu, je suis presque sûr que c'est fait de toute façon.

Je ne sais pas ce que vous pensez que les chemins du système de fichiers ont à voir avec quoi que ce soit ...

Comment utiliseriez-vous un URI pour confondre le système ? Il va ignorer le schéma et le nom d'hôte et commencer à rechercher des routes (qui sont limitées à [az] uniquement). Si les caractères étranges que vous mettez ne peuvent pas être trouvés, cela s'arrête. Et la chaîne de requête que vous mettez doit être des identifiants C# valides ou elle ne sera tout simplement pas mise en correspondance. Les données échappées dans les données de la chaîne de requête ne seront pas échappées.

@kzu URI fonctionne très bien dans XF et convient mieux à XF qu'un schéma de système de fichiers. En fait, un URI est attendu lors du lancement de votre application à partir d'un site Web. Vous devriez vérifier à quel point la navigation basée sur les URI peut être puissante en examinant l'implémentation de Prism. Parmi toutes les applications créées avec Prism à l'aide d'un schéma de navigation basé sur l'URI, aucun problème lié à des caractères invalides n'a été soumis. Je suis convaincu que vos préoccupations concernant un schéma basé sur URI pour la plate-forme XF ne seront pas un problème.

Logique. Merci pour les informations générales sur Prism @brianlagunas ! Maintenant, je devrais lire attentivement les spécifications et fournir des commentaires réellement utiles ;)

Très bonne initiative, mais j'espère que l'extensibilité et la personnalisation sont prises en compte en créant les méthodes virtuelles appropriées ou d'autres moyens de faire notre chose "spéciale" pour nos clients.

Par exemple sera-t-il possible/comment :

1. Extensibilité des onglets par exemple montrant un badge avec une icône. Ou afficher un tiroir contextuel au-dessus d'un, comme un bouton "plus" ou " * ".
2. Snack-bar personnalisé (par exemple avec le bouton "Annuler" pour une action que vous venez de faire avec des couleurs d'arrière-plan/premier plan personnalisées)
3. Fragment poussant dans Android en utilisant des animations différentes de celles programmées par défaut dans le Shell, comme aucune animation pour donner la navigation la plus rapide possible.

Sur une note technique : le shell recyclera-t-il les pages de sorte qu'une fois qu'il aura navigué deux fois sur une page, les éléments natifs seront réutilisés avec une autre machine virtuelle en dessous ?

Salut @rogihee

J'attends vos commentaires sur la mise en œuvre. Je pense que c'est fou extensible : https://github.com/xamarin/Xamarin.Forms/blob/9558f2837280e02b41848d3a3c3213d49a664751/Xamarin.Forms.Platform.iOS/Renderers/ShellRenderer.cs

Android est encore en plein développement en ce moment, mais il utilise une approche identique.

@rogihee en ce qui concerne le recyclage des pages, j'essaie de trouver une méthode saine pour rendre cela viable. De manière générale, ce n'est pas le cas actuellement, car il devrait être explicitement activé.

Ça a l'air bien ces options "Créer*". C'est bien de voir les progrès rapides sur ce point !

Je me demande s'il y a des implications sur les performances avec la réutilisation d'éléments. Personnellement, je donnerais la priorité à la vitesse et à la sensation "fluide" d'une application par rapport à une utilisation plus élevée de la mémoire / du processeur (bien qu'il y ait une corrélation quelque part à la fin bien sûr). Et priorisez iOS/Android par rapport à tout autre :-).

Shell se concentre beaucoup sur la perception de la fluidité. Ce n'est pas encore en place partout mais c'est en train de se rassembler.

J'ai vraiment besoin de mettre en place certains des premiers utilisateurs qui essaient de faire des choses folles avec Shell pour s'assurer qu'il peut gérer la charge pour laquelle il est conçu.

@jassmith mig vient de mentionner shell pendant 3 minutes dans Build .....

je ne suis pas son papa

+1

API mise à jour pour correspondre à l'état actuel du monde, encore besoin de mettre à jour les échantillons.

Ajout de quelques exemples mis à jour, il reste encore beaucoup de travail à faire pour corriger d'autres exemples et mettre à jour les descriptions des itinéraires lors de l'utilisation de la syntaxe abrégée (car vous obtenez des itinéraires abrégés !)

Mon Dieu, je me sens si tard à la fête. Excellente écriture et discussion. J'ai tout parcouru (désolé à l'aéroport) et j'ai ma propre suggestion. Désolé si cela a été mentionné ailleurs.

@jassmith @migueldeicaza Pouvez-vous s'il vous plaît ajouter un comportement à la barre de navigation afin qu'elle puisse être désactivée lorsque la ListView défile et affichée lorsqu'elle défile dans la direction opposée. Presque toutes les applications professionnelles le font pour montrer plus d'immobilier. Cela serait particulièrement utile sur les petits appareils.

Un autre est pourquoi ne renommez-vous pas les balises XAML afin qu'elles soient plus simples à saisir ? Peut-être utiliser Tab au lieu de ShellSection ? Il y a beaucoup de balises ShellX maintenant.

Pour iOS, je pense qu'il existe une propriété pour activer/désactiver le mode de défilement sur la barre de navigation. Pour Android, vous devez commencer à utiliser les nouvelles mises en page (CoordinatorLayout, AppBarLayout, etc.). L'implémentation Android de XF est assez obsolète à cet égard car elle utilise toujours un RelativeLayout comme conteneur principal. Je pense qu'il y a un ticket d'amélioration quelque part sur ce problème spécifique. J'aimerais voir Shell prendre en charge différents modes de défilement.

De plus, nous devons souvent implémenter un comportement personnalisé pour afficher des erreurs/d'autres types de fenêtres contextuelles sur la page. Shell devrait prendre en charge cette fonctionnalité prête à l'emploi afin que nous n'ayons pas besoin de recourir à des plug-ins tiers ou de créer une hiérarchie d'interface utilisateur complexe.

@adrianknight89

Pouvez-vous s'il vous plaît ajouter un comportement à la barre de navigation afin qu'elle puisse être désactivée lorsque la ListView défile et affichée lorsqu'elle défile dans la direction opposée. Presque toutes les applications professionnelles le font pour montrer plus d'immobilier. Cela serait particulièrement utile sur les petits appareils.

C'est quelque chose que j'essaie vraiment de trouver la bonne façon de faire. Malheureusement, toutes les plates-formes ne prennent pas en charge cette fonctionnalité, il s'agira donc probablement d'un accord spécifique à la plate-forme. Android à tout le moins a été conçu pour prendre en charge cela, je l'allume de temps en temps pour m'assurer qu'il fonctionne toujours.

Un autre est pourquoi ne renommez-vous pas les balises XAML afin qu'elles soient plus simples à saisir ? Peut-être utiliser Tab au lieu de ShellSection ? Il y a beaucoup de balises ShellX maintenant.

Le nom ici est VRAIMENT difficile. ShellTab est un peu déroutant pour le haut et le bas. J'ai plutôt opté pour des noms hiérarchiques plus génériques, mais je dois admettre que je ne suis pas satisfait des noms. Les suggestions sont les bienvenues à 100%... pas vraiment hâte de remanier leurs noms ENCORE, mais que pouvez-vous faire...

Pour iOS, je pense qu'il existe une propriété pour activer/désactiver le mode de défilement sur la barre de navigation. Pour Android, vous devez commencer à utiliser les nouvelles mises en page (CoordinatorLayout, AppBarLayout, etc.). L'implémentation Android de XF est assez obsolète à cet égard car elle utilise toujours un RelativeLayout comme conteneur principal. Je pense qu'il y a un ticket d'amélioration quelque part sur ce problème spécifique. J'aimerais voir Shell prendre en charge différents modes de défilement.

Shell utilise CoordinatorLayout + AppBarLayout et "désactive" essentiellement la prise en charge du défilement pour le moment, cela fonctionne cependant. Le défilement iOS est également facile à mettre en œuvre. Malheureusement, NavigationView d'UWP ne prend pas en charge cette fonctionnalité.

De plus, nous devons souvent implémenter un comportement personnalisé pour afficher des erreurs/d'autres types de fenêtres contextuelles sur la page. Shell devrait prendre en charge cette fonctionnalité prête à l'emploi afin que nous n'ayons pas besoin de recourir à des plug-ins tiers ou de créer une hiérarchie d'interface utilisateur complexe.

Des exemples, j'ai besoin d'exemples :)

@jassmith

J'utilise le plugin de connectivité de James Montemagno pour écouter les changements d'état de la connexion de données. Lorsque la connexion Internet est interrompue, il est recommandé d'afficher une notification qui glisse/s'efface ou reste immobile jusqu'à ce qu'Internet se reconnecte.

Sur Instagram, cette notification est placée juste en dessous de la barre de navigation. Sur Tumblr, c'est juste au-dessus de la barre de navigation inférieure. Sur YouTube, étrangement, c'est sous la barre de navigation inférieure. Peut-être que quelque chose comme ça peut faire partie de Shell ?

Le contrôle Popup proposé est, pour autant que je sache, recouvrant la fenêtre existante bien qu'il puisse être légèrement révocable. La notification que je viens de mentionner et potentiellement d'autres types de notifications n'ont pas besoin de superposer leur fenêtre parent (c'est-à-dire que l'arbre visuel parent est toujours sensible aux gestes), donc je ne sais pas si Popup est la bonne solution.

Shell peut avoir une propriété pour nous de définir à quoi ressemblera cette vue (appelez-la Notification[View]) ainsi que son placement et son comportement d'animation d'entrée/sortie. Donc, essentiellement, une implémentation de toast/snackbar multiplateforme intégrée à Shell, INavigation ou autre chose. Cela ne serait pas forcé d'avoir l'air natif par plate-forme, mais le même pour toutes.

En ce qui concerne les arguments avancés autour de la stabilité, de la flexibilité, etc., sans se débarrasser de l'architecture obsolète venant de la version 1.0, je ne pense pas qu'il soit possible de réaliser ces choses. Je suis très favorable à ListView2.

@jassmith

• Avez-vous déjà un ticket d'amélioration pour le nouveau ListView ?
• Quand pensez-vous que la v1.0 sortira ? Une chance que nous puissions le voir par EOY?

De plus, j'ai le même souci que l'équipe soit sous-dimensionnée. En fait, j'en ai déjà parlé dans le passé. J'espère que l'équipe pourra grandir beaucoup plus à l'avenir. 🙏 @davidortinau @migueldeicaza

@jassmith Je pense depuis un certain temps que si nous avions un moteur de rendu pour la classe App, nous pourrions faire beaucoup de choses qui nécessitent actuellement un piratage tiers. Par exemple, le plugin RgPopups saisit la vue principale de l'application et y injecte des vues rendues pour fournir une apparence contextuelle sur tout l'écran. Ceci est actuellement impossible à réaliser avec des formulaires Xamarin « purs ». Cependant, si App avait un moteur de rendu, nous pourrions le faire nous-mêmes.

Je suis tout à fait pour ajouter ce genre de notifications toast à Shell, essayant juste de comprendre comment cela devrait être fait.

Pouvez-vous s'il vous plaît faire en sorte que vous puissiez mettre des pages arbitrairement où vous voulez dans une application ? Ceci est particulièrement important sur les tablettes/ordinateurs de bureau/ordinateurs portables (appareils à écran plus grand), où vous souhaitez afficher plusieurs pages à l'écran en même temps et ne souhaitez pas nécessairement les organiser en utilisant une vue fractionnée (page de détail principale). Exemple, voir Google Maps :

Remarquez comment le contenu « flotte » au-dessus de la carte (pas de vue fractionnée). Si vous souhaitez utiliser des éléments tels que des onglets ou la navigation à l'intérieur de la zone flottante, vous ne pouvez pas accomplir ce genre de chose avec Xamarin Forms, prêt à l'emploi, en raison de la hiérarchie extrêmement limitée avec les pages (impossible d'imbriquer une page à l'intérieur d'une vue). Nous avons en fait développé notre propre vue personnalisée qui offre des fonctionnalités similaires à NavigationPage mais est une vue, juste pour que nous puissions accomplir ce type de mise en page, mais c'était beaucoup de travail / dur à faire.

Il devrait être possible de mettre du contenu (y compris des pages) n'importe où dans une application.

Pouvez-vous s'il vous plaît faire en sorte que vous puissiez mettre des pages arbitrairement où vous voulez dans une application ?

Je suis un peu curieux @jsiemens car cette vue n'aurait probablement pas l'air correcte sur un téléphone, mais aurait

@dansiegel Au moins personnellement, j'utiliserais probablement VSM ou un équivalent pour déplacer et compacter la vue de défilement en bas lorsqu'elle est inférieure à un certain seuil de fenêtre d'affichage (comme le fait GMaps actuellement). Ce serait curieux de voir comment la navigation et la gestion de l'état fonctionneraient pour cela.

Navigation : je suis sûr que ce n'est pas un problème insurmontable si vous partez du point de vue du parcours de l'utilisateur et que vous regardez ensuite comment l'utilisateur s'attend à ce que cela fonctionne. La navigation devrait être réactive à la nature plein écran d'un téléphone par rapport à une vue plus petite sur un écran plus grand, par exemple.

L'utilisateur « voit » la tablette et la vue plus petite comme une étape de navigation unique. Sur un petit écran, il pourrait y avoir deux étapes importantes. La navigation devrait, en quelque sorte, être réactive.

En tant que développeurs, nous devons sûrement gérer cette nature réactive car c'est une chose contextuelle. Nous ne pouvons pas compter sur le cadre pour gérer cela pour nous, mais le cadre doit le prendre en charge.

@jsiemens @dansiegel La façon dont je gère cela actuellement utilise ControlTemplate s. Je construis mon contenu de type "page" en tant que ContentView s et les héberge dans un ContentPage (à l'intérieur d'un NavigationPage ) qui est approprié à la plate-forme. Utiliser ControlTemplates signifie que je peux avoir plusieurs ContentViews liés (généralement dans un Grid pour que je puisse superposer des éléments) qui sont activés/désactivés en fonction des propriétés pouvant être liées dans le ControlTemplate lui-même (vous pouvez également utiliser des DynamicResource s). Le résultat final fonctionne un peu comme les panneaux CSS sur un site Web, où tout le contenu est dans la page mais tout n'est pas visible tout le temps. ControlTemplate s sont magiques pour cela et je voudrais que leurs capacités soient préservées dans Shell.

@dansiegel, je le

@jsiemens c'est bien, mon commentaire est uniquement destiné à stimuler la conversation et la réflexion critique pour affiner davantage votre idée. À certains égards, je dirais presque, étant donné votre concept ici, que chaque page pourrait essentiellement être une multipage où une page pourrait être attachée à un contrôle donné et traitée davantage comme une autre vue que comme une navigation normale.

@dansiegel Oui, je pense que c'est ce que je recherche, c'est de pouvoir simplement ajouter une page n'importe où dans l'application. Il est étrange que Xamarin Forms impose cette limitation lorsque les plates-formes sous-jacentes ne le font pas (par exemple, iOS n'est qu'une arborescence de vues - vous pouvez ajouter la vue de NavigationController littéralement n'importe où dans l'application). De plus, mon commentaire visait à indiquer qu'il n'est pas nécessaire que la spécification Shell couvre cela - je ne pense pas que la mise en page "responsive" doive être un problème. Je pense que tant qu'il est possible de construire la mise en page, nous pouvons nous occuper du chargement conditionnel des shells en fonction du facteur de forme, et c'est assez bien.

Je suppose que ce n'est pas entièrement sur le sujet de cette spécification, mais je l'ai mentionné ici parce que nous parlons de la façon de construire des mises en page complexes (par exemple, la 3ème priorité de @MelbourneDeveloper - flexibilité), et c'est certainement une mise en page qui est au sommet de l'esprit pour moi et mon équipe (nous construisons une application de cartographie où nous voulons pouvoir faire flotter des panneaux de contenu au-dessus de la carte, qui pourraient contenir du contenu «page uniquement» comme des pages de navigation et des onglets).

Je ne sais pas comment cela serait résolu en utilisant shell, mais ma première réaction à shell est qu'il ne semble pas faire quelque chose que je ne puisse pas déjà faire. J'ai généralement l'impression que l'équipe Xamarin Forms continue de créer des fonctionnalités qui me permettent de faire des choses que je pouvais déjà faire, mais juste d'une manière différente (par exemple, CSS, Visual State Manager, et maintenant les spécifications Drawing et Shell). Donc ça ne m'apporte pas grand chose. Je préfère avoir de nouvelles fonctionnalités qui me permettent de faire des choses que je ne pouvais pas auparavant (en dehors des contrôles personnalisés et/ou des moteurs de rendu). Si le shell est la réponse pour accomplir cela parce que la syntaxe est plus élégante, alors je suis tout à fait d'accord, mais en fin de compte, j'aimerais qu'il soit plus puissant et plus expressif que la hiérarchie Page/View actuelle car cela apporte vraiment de la valeur.

Pourriez-vous dissocier la création d'une vue native par vue xamarin si toutes les sous-vues d'une mise en page peuvent être rendues sans utiliser de widgets natifs ? Une sorte d'approche hybride automatique flutter/xamarin dans laquelle des groupes de vues XF sont rendus sur une seule surface et simplement blittés sur une seule vue native. Éviter la création/mise en page de la vue Android c# -> coût d'interopérabilité Java serait utile.

en cours!!

@jassmith une fois le shell terminé, le tirage sera-t-il valable ensemble ?

Shell va-t-il prendre en charge macos et wpf ?

@juepiezhongren les cibles initiales sont iOS et Android. D'autres plates-formes seront prioritaires par la suite.

Le dessin n'est pas en cours de développement. Dans sa spécification actuelle, ce serait valable avec Shell. Tout comme aujourd'hui, vous pouvez utiliser des contrôles basés sur SkiaSharp et Skia dans Xamarin.Forms.

Nous travaillons sur d'autres stratégies natives pour prendre en charge une conception cohérente pour les matériaux et d'autres styles de conception.

@davidortinau Le shell améliore-t-il la prise en charge de RTL ?

Mieux dans quel sens ? Qu'est-ce qui vous manque aujourd'hui dans le support RTL ? Nous devrions l'aborder partout.

Pour être honnête, je n'ai pas fait de développement XF depuis un moment, mais la plupart des limitations sont connues : jetez un œil à #1222 et #2448

Peut-être que shell peut vous aider avec ces limitations générales :

• L'emplacement du bouton NavigationPage, l'emplacement de l'élément de barre d'outils et l'animation de transition sont actuellement contrôlés par les paramètres régionaux du périphérique, et non par le paramètre FlowDirection.
• Paramètre d'application global pour FlowDirection

Et quelques autres limitations spécifiques à la plate-forme

Fonctionnalité la plus importante de Xamarin.Forms. Il aurait dû être construit comme ça en premier lieu.

sans dessin, il manque encore pas mal de xf

@juepiezhongren

Utilisez simplement Skiasharp

@mackayn je l'
https://github.com/xamarin/Xamarin.Forms/issues/1789
l'aspect universel est un must

Adam est allé flotter, c'est vraiment un signe triste pour xf, où xamarin à l'origine pouvait assez facilement atteindre une bien meilleure réputation

xamarin.native est beaucoup plus solide pour xf que toute autre solution multiplateforme, quelle que soit la réaction native ou flutter. En tant qu'amateur de dotnet, la situation actuelle de xf est toujours un peu décevante pour moi.

@juepiezhongren

Cette discussion est inutile, si elle ne répond pas à vos besoins, utilisez Flutter, elle nous permet de fournir des applications sur plusieurs plates-formes (iOS et Android uniquement avec Flutter, etc.), ces modifications rendront une apparence cohérente plus réalisable.

simple petite plainte, tellement. Encore hourra pour shell!

Je conviens qu'il serait plus agréable d'avoir Skia beaucoup plus intégré à l'API Forms (comme Telerik l'a fait). Je suis d'accord.

Je suis heureux qu'ils investissent cependant dans Shell & CollectionView.

salut, s'il vous plaît, dites à tout le monde, comment puis-je utiliser la mise en page à droite, pour la langue de droite à gauche.

Salut,

J'adore l'idée, mais j'ai juste quelques petites entrées.
Je suppose que je suis un peu en retard, mais la dénomination est un peu confuse, je pense.

1. L'élément, la section et le contenu sont tous des noms vraiment généraux. Il n'est pas tout de suite clair dans quelle relation il s'agit. Is it Content => Section => Item ou Section => Content => Item, ou Item => Section => Content.
   Nous pouvons donc peut-être préciser un peu plus quelles sont les différentes "choses", en trouvant un nom plus spécifique.

2. Cela m'amène à la prochaine entrée. Nous avons un Shell comme conteneur pour tous les articles intérieurs. Ne pouvons-nous donc pas simplement utiliser des noms simples comme "Item" au lieu de "ShellItem" à l'intérieur. Il me semble un peu inutile d'appeler toutes les "choses" Shelltem, ShellSection etc. mais ok. c'est discutable.

Aie

Sortira-t-il encore en 2018 ?

Nous avons une version préliminaire disponible MAINTENANT ! Jetez un œil à https://blog.xamarin.com/connect-2018-xamarin-announcements/ pour d'excellents échantillons.

Avons-nous vraiment besoin d'Android 9 ? Cela semble être un peu une limitation.

Tout semble plutôt bien, mais semble être basé uniquement sur l'interaction de l'interface utilisateur.
Je suppose que je le saurai en l'essayant, mais ma première préoccupation est de savoir comment piloter la navigation à partir d'une logique métier ou d'un code, par exemple la messagerie reçue d'un appareil connecté Bluetooth déclenchant un changement de page, tout en maintenant une séparation décente des préoccupations ?

@hassanrahimi

salut, s'il vous plaît, dites à tout le monde, comment puis-je utiliser la mise en page à droite, pour la langue de droite à gauche.

Bien que RTL soit pris en charge, le menu déroulant apparaît toujours sur la gauche. Il s'agit d'une limitation actuelle.

Est-il possible de personnaliser l'interface utilisateur de la barre d'onglets inférieure ?

Est-il possible d'ajouter un contrôle au shell qui n'est pas rechargé lors de la navigation à l'intérieur du shell ? Par exemple un FAB..

L' interface utilisateur de la barre d'

L'ajout de contrôles globaux comme vous le décrivez comme un FAB est prévu pour MaterialShell. Pouvez-vous fournir des scénarios supplémentaires qui en bénéficieraient en plus du FAB ?

Premièrement: j'ai déjà utilisé mon propre shell, maintenant je peux assez facilement remplacer le mien par le vôtre et c'est beaucoup mieux. J'aime vraiment ça.

Mes cas sont probablement personnalisés et non liés au shell, mais :

Cas un :
Si je veux créer une application avec un menu très personnalisé, un bouton de menu dans chaque coin de l'application, comment puis-je ajouter les boutons pour qu'ils fassent partie du shell (comme une superposition ou un panneau d'affichage). Je ne veux pas qu'il s'affiche à chaque fois que je navigue.

Deuxième cas :
Je souhaite utiliser le shell mais je souhaite personnaliser la barre d'onglets inférieure afin que le bouton du milieu soit plus haut (appelé bouton central surélevé). Dois-je utiliser le moteur de rendu et personnaliser la vue de navigation inférieure ?

Pensez-vous que je devrais utiliser le shell pour des cas particuliers comme celui-ci?

Bien sûr, j'envisage de le faire sur chaque plate-forme, mais les menus doivent être identiques sur toutes les plates-formes, vous souhaitez donc partager le code.

Voici mon retour d'expérience. Je fais ce test ( Xamarin.Forms 4.0.0.8055-pre1 ):

   <Shell.FlyoutHeader>
        <local:FlyoutHeader />
    </Shell.FlyoutHeader>

    <ShellItem Title="Home" Icon="home.png">
        <ShellSection>
            <ShellContent>
                <local:MainPage />
            </ShellContent>
        </ShellSection>
    </ShellItem>

    <ShellItem Title="Notifications" Icon="notification.png">
        <ShellSection>
            <ShellContent Title="Recent">
                <local:NotificationPage />
            </ShellContent>
        </ShellSection>
    </ShellItem>

    <ShellItem Title="Test" Icon="icon.png">
        <ShellSection Title="Home" Icon="home.png">
            <ShellContent>
                <local:MainPage />
            </ShellContent>
        </ShellSection>

        <ShellSection Title="Notifications" Icon="notification.png">
            <ShellContent Title="Recent">
                <local:NotificationPage />
            </ShellContent>

            <ShellContent Title="Settings">
                <local:SettingsPage />
            </ShellContent>
        </ShellSection>
    </ShellItem>

Tout fonctionne lorsque nous appuyons sur le menu hamburger. Cependant, si nous allons au menu Test et tapotons sur Home et Notifications dans les deux sens et choisissons entre Recent ou Settings , la page s'ouvriront respectivement. Mais ensuite, lorsque nous appuyons à nouveau sur le menu hamburger, l'application se bloque.

Comment pouvons-nous utiliser GroupHeaderTemplate pour afficher un titre pour un groupe de ShellContent dans un ShellItem ?

Il est clair pour de nombreux utilisateurs que Xamarin Forms n'est pas maintenable à sa taille et à sa complexité actuelles, donc tout nouveau devrait réduire la complexité plutôt que l'augmenter.

@jassmith L'intention est que vous ne feriez JAMAIS mieux de ne pas

Si Shell est terminé, qu'est-ce qui peut être amorti à l'avenir, et lorsque cela est fait, la complexité globale de Xamarin Forms est-elle réduite ? Toutes les autres pages, à l'exception de ContentPage, seront-elles dépréciées ?

La stratégie devrait consister à tirer le meilleur parti possible du repo. La stabilité et la maintenabilité du référentiel principal sont la chose la plus importante.

De plus, s'il y a une raison pour laquelle Shell ne s'appelle pas ShellPage ? Les autres classes Page ont des noms se terminant par "Page".

L'annonce actuelle pour Shell (dans https://blog.xamarin.com/xamarin-forms-4-0-preview/ ) n'est pas prometteuse.

1. Une manière simplifiée d'exprimer le haut niveau de votre architecture applicative

Cela amène Xamarin au-delà de son objectif réel. Xamarin n'est pas nécessaire pour l'architecture de l'application. Cela devrait concerner uniquement la mise en page.

1. Une hiérarchie de modèles de navigation d'interface utilisateur communs qui conviennent à vos plates-formes mobiles cibles

J'espère que "mobile" est une faute d'impression ici, car Xamarin.Forms couvre également les ordinateurs de bureau.

1. Un service de navigation robuste

Xamarin.Forms n'a pas besoin de navigation. Si la navigation actuelle ne fonctionne pas, elle peut simplement être dépréciée car il existe de nombreuses bonnes approches de la navigation qui ne nécessitent rien à intégrer.

Salut @charlesroddie , merci pour le retour.

Il semble que Shell ne vous convienne pas en ce moment, et ce n'est pas grave. Vous n'avez pas besoin d'utiliser Shell s'il n'apporte pas de valeur à vos applications. Cela dit, la spécification Shell est fortement influencée par les commentaires des développeurs, et servir notre communauté de développeurs est au cœur de notre objectif.

Dans Xamarin.Forms aujourd'hui, vous décrivez déjà votre architecture d'application, la hiérarchie du contenu, à l'aide de TabbedPage, MasterDetailPage, avec des onglets et des éléments de menu, et différentes combinaisons. C'est ce que j'entends ici par « architecture ». Shell simplifie et remplace ces modèles (si vous choisissez d'utiliser Shell).

"Mobile" n'est pas une faute d'impression et il est utilisé très délibérément. Shell est destiné à iOS et Android. Si vous ciblez le bureau, vous n'utiliserez pas Shell. J'ai entendu des contributeurs s'intéresser à l'ajout de la prise en charge de Shell aux backends de bureau, et ces relations publiques seraient bien reçues. Je pense que Shell est très bien placé pour amener des applications sur n'importe quelle plate-forme et être flexible (résilient) pour s'adapter même aux changements radicaux de modèle d'interface utilisateur (qui sait quelles futures interfaces adopteront). Pour aujourd'hui, le terrain d'essai est iOS et Android.

Alors que nous parlions de Shell aux développeurs, j'ai été surpris d'apprendre que la navigation Shell figurait en haut de la liste des fonctionnalités qu'ils appréciaient. Le routage, les liens profonds, la possibilité d'interrompre la navigation, de décrire instantanément la pile arrière, de transmettre les données et le chargement paresseux des pages sont des attributs très convaincants pour les développeurs qui résolvent les problèmes qu'ils rencontrent aujourd'hui.

Si vous ciblez le bureau, vous n'utiliserez pas Shell... Je pense que Shell est très bien placé pour transférer des applications sur n'importe quelle plate-forme.

Je ne veux tout simplement pas que Xamarin s'effondre sous son propre poids. Jusqu'à ce que Shell atteigne toutes les plates-formes, vous avez un problème de maintenance, car il s'agit alors d'un ajout et non d'un remplacement pour d'autres pages. Vous avez également un problème de messagerie pour les développeurs de bureau, à une époque où beaucoup cherchent évidemment à adopter un framework multiplateforme.

Xamarin montre beaucoup de fluage de fonctionnalités, par exemple css. Cela pourrait menacer l'ensemble du projet et j'espère que certains décideurs de l'organisation le comprendront.

Je ne veux tout simplement pas que Xamarin s'effondre sous son propre poids. Jusqu'à ce que Shell atteigne toutes les plates-formes, vous avez un problème de maintenance, car il s'agit alors d'un ajout et non d'un remplacement pour d'autres pages. Vous avez également un problème de messagerie pour les développeurs de bureau, à une époque où beaucoup cherchent évidemment à adopter un framework multiplateforme.

Xamarin montre beaucoup de fluage de fonctionnalités, par exemple css. Cela pourrait menacer l'ensemble du projet et j'espère que certains décideurs de l'organisation le comprendront.

Je suis d'accord. Si une fonctionnalité n'est pas prise en charge sur le bureau (UWP), elle ne nous est d'aucune utilité. Je suis également d'accord à propos de CSS - cela semble être une complexité supplémentaire et une surcharge de maintenance pour une fonctionnalité qui ne me permet pas de faire quelque chose que je ne pouvais pas déjà faire auparavant. Ce dont nous avons besoin bien plus que toute autre chose, ce sont simplement plus de contrôles - pour toutes les plates-formes, et plus de capacités pour les contrôles existants. Shell a toujours les mêmes limitations que l'infrastructure de la page dans la mesure où vous devez l'adopter complètement ou vous ne pouvez pas l'utiliser du tout, et il ne peut vivre qu'au niveau racine de votre application. Non seulement cela, mais maintenant vous avez deux façons de faire la même chose, et c'est compliqué et déroutant. Donc, si je veux juste avoir un menu volant sans utiliser de shell, je ne peux pas le faire. Et le nombre de contrôles auxquels les éléments du shell sont mappés est extrêmement limité - les onglets, les pages de navigation et les menus volants ne nous suffisent pas. Si Xamarin Forms pouvait offrir l'étendue des contrôles qu'un framework comme UWP a, exposé comme un ensemble de contrôles, tout comme dans UWP, et sans le gonflement inutile (par exemple, css), alors je serais heureux.

Je pense que vous soulevez des points valables, mais en tant que personne qui gère une application UWP/iOS/Android et a été légèrement déçu quand j'ai appris que Shell ne prenait pas en charge UWP, avec seulement un "peut-être" à l'avenir. Puis j'ai réalisé que je manquais le point de Shell. C'est un moyen très simple pour quelqu'un de créer une application pour les deux principales plates-formes mobiles. En tant que développeur d'entreprise... j'ai besoin d'UWP, j'ai attendu qu'il y ait un support UWP pour même envisager XF... mais je soupçonne que beaucoup de développeurs n'en ont pas besoin... J'ai aussi besoin d'une navigation beaucoup plus complexe, etc. Shell fournit.

Mais je me souviens aussi avoir passé beaucoup de temps à essayer de démarrer avec la navigation et les pages... ce qui peut prendre un certain temps à comprendre. Mais je crée également une application commerciale très complexe, il existe des tonnes d'applications simples qui n'ont tout simplement pas besoin de ce niveau de complexité. XF doit évoluer pour s'adapter à des choses comme Flutter, etc. Il doit également continuer à amener de nouveaux développeurs à l'adopter. Et il me semble que l'utilisation de la plate-forme aidera à sécuriser les ressources nécessaires à la maintenance de la plate-forme.

J'ai également quelques projets futurs pour lesquels je n'ai pas besoin d'UWP et j'ai hâte d'utiliser Shell dessus, car je pense que cela accélérera leur production.

Je n'utilise XF que depuis environ la version 2.3 et bien qu'il y ait certainement plus de travail à faire... la plate-forme telle qu'elle existe maintenant s'est considérablement stabilisée... du moins pour moi... donc je ne suis pas concerné par la maintenance supplémentaire et, historiquement, il me semble que l'équipe XF est très consciente de la charge de la maintenance... alors j'espère qu'ils la maîtrisent.

Merci pour l'excellent ajout à la plate-forme !

L'ajout de nouvelles façons de faire les choses embrouillera les nouveaux développeurs jusqu'à ce que les anciennes méthodes soient dépréciées et que les anciens documents soient supprimés.

Flutter est beaucoup plus simple. Pas de langage de balisage, tout en code. Xamarin ne va pas rivaliser en devenant plus complexe et bogué. Il rivalisera en faisant plus que Flutter (plus de plates-formes), avec le même objectif.

Nous arrivons au point où nous avons besoin d'un Xamarin.Core, n'incluant pas XAML ou CSS ou les liaisons de propriété, n'incluant pas les pages ou les shells au-delà des classes de base, en mettant l'accent sur les performances et la stabilité de ce Core. Si certains développeurs veulent ces fonctionnalités au prix d'accepter le taux actuel de bogues, ils peuvent utiliser Xamarin.Extensions où toutes ces choses vivraient.

L'ajout de nouvelles façons de faire les choses embrouillera les nouveaux développeurs jusqu'à ce que les anciennes méthodes soient dépréciées et que les anciens documents soient supprimés.

Flutter est beaucoup plus simple. Pas de langage de balisage, tout en code. Xamarin ne va pas rivaliser en devenant plus complexe et bogué. Il rivalisera en faisant plus que Flutter (plus de plates-formes), avec le même objectif.

Nous arrivons au point où nous avons besoin d'un Xamarin.Core, n'incluant pas XAML ou CSS ou les liaisons de propriété, n'incluant pas les pages ou les shells au-delà des classes de base, en mettant l'accent sur les performances et la stabilité de ce Core. Si certains développeurs veulent ces fonctionnalités au prix d'accepter le taux actuel de bogues, ils peuvent utiliser Xamarin.Extensions où toutes ces choses vivraient.

@charlesroddie Rien de ce qu'ils ont fait ci-dessus ne vous oblige à utiliser XAML. XAML dans Xamarin.Forms est facultatif - il l'a toujours été. Je fais toujours mon interface utilisateur d'applications Xamarin.Forms en utilisant uniquement du code - chaque "balise" que vous voyez ci-dessus est une classe qui peut être créée et ajoutée au parent concerné.
Si les interfaces utilisateur codées n'étaient pas possibles avec Xamarin.Forms, je ne l'utiliserais pas - point final !

Re Flutter en général - c'est très bien, mais le problème est uniquement iOS et Android - cela ne fonctionne pas non plus pour moi car je dois cibler macOS, Windows 7/8.1 et Linux. Rien ne vaut Xamarin.Forms à ce sujet !

puis-je définir une vue personnalisée en tant que page maître, c'est une chose très importante à inclure, nous ne préférerons pas seulement MenuItem ou pages

Prise en charge de Xamarin Mac et uwp ?

Comment vous connecteriez-vous au processus de navigation ? Je suppose que vous en êtes conscient, mais si vous prenez Prism par exemple, les modèles de vue sont créés par un conteneur DI et sont automatiquement définis comme BindingContext pour la page demandée.

Vous pouvez également implémenter INavigatedAware pour un modèle de vue et gérer des cas d'utilisation spécifiques tels que le chargement de données, l'activation / la désactivation de services, etc.

Je voulais ajouter quelque chose de similaire donc ma première supposition était l'événement Shell OnNavigating et OnNavigated mais Current et Target n'exposent pas un ShellItem donc ce n'est pas possible définir le BindingContext par convention ou déclencher des événements de modèle de vue ?

Des suggestions pour cela?

EDIT : suivi par #5166.

Pour les icônes de ce shell, est-il possible d'utiliser "Icon Font" au lieu d'une image ? Il est difficile de changer de couleur pendant l'exécution de l'image et il est également difficile de les gérer pour différentes résolutions sur différentes plates-formes. Puis-je suggérer de créer une classe d'icônes en utilisant la police Material Design rendue avec la bibliothèque SkiaSharp ? La classe est relativement simple et créera de nombreuses icônes prêtes à l'emploi sur le shell.

@vincentwx je suis d'accord. Les polices d'icônes sont tellement plus faciles à utiliser et sont également familières.

@vincentwx @stevehurcombe absolument. Je fais ça dans une application en ce moment :

<ShellItem>
    <ShellContent Title="Upcoming" 
                      ContentTemplate="{DataTemplate pages:UpcomingPage}">
            <ShellContent.Icon>
                <FontImageSource Glyph="{x:Static local:IconFont.Rocket}" 
                                 FontFamily='{OnPlatform iOS="Font Awesome 5 Free", Android="fa-solid-900.ttf#Font Awesome 5 Free"}'
                                 Size="18"/>
            </ShellContent.Icon>
        </ShellContent>

        <ShellContent Title="Latest" 
                      ContentTemplate="{DataTemplate pages:LatestPage}">
            <ShellContent.Icon>
                <FontImageSource Glyph="{x:Static local:IconFont.Book}" 
                                 FontFamily='{OnPlatform iOS="Font Awesome 5 Free", Android="fa-solid-900.ttf#Font Awesome 5 Free"}'
                                 Size="18"/>
            </ShellContent.Icon>
        </ShellContent>

        <ShellContent Title="Company" 
                      ContentTemplate="{DataTemplate pages:CompanyPage}">
            <ShellContent.Icon>
                <FontImageSource Glyph="{x:Static local:IconFont.Building}" 
                                 FontFamily='{OnPlatform iOS="Font Awesome 5 Free", Android="fa-solid-900.ttf#Font Awesome 5 Free"}'
                                 Size="18"/>
            </ShellContent.Icon>
        </ShellContent>
    </ShellItem>

J'ai utilisé ceci pour créer une classe statique de tous les glyphes : https://andreinitescu.github.io/IconFont2Code/

Il y a un bug avec la couleur iOS qui doit être corrigé. #5071

Prise en charge de Xamarin Mac et uwp ?

Pas pour le moment @mdonogma. Nous recueillons un intérêt/une demande pour la prise en charge de plates-formes supplémentaires, mais pour le moment, ce n'est pas sur notre feuille de route.

@davidortinau Merci pour le code et le lien.

Dans Android 8.0, je ne peux pas faire défiler la page Web dans l'élément WebView hébergé dans Shell Content. Mais cela fonctionne bien sans Xamarin Shell.

Formulaire Xamarin 4.0.0.135214-pre4

Existe-t-il un moyen simple de modifier la FontFamily des onglets inférieurs et de la vue du titre ?

@varyamereon Je l'ai fait hier. Étendez le Shell pour pouvoir définir FontFamily.
Je publierai bientôt mon Shell étendu sur GitHub mais :

Créez un Shell personnalisé :

<Shell
    x:Class="X.Mobile.App.Features.AppShell.AppShell"

Créez ensuite un moteur de rendu personnalisé Shell :

[assembly: ExportRenderer(typeof(AppShell), typeof(AppShellRenderer))]

namespace X.Mobile.App.iOS.Renderers
{
    [Preserve(AllMembers = true)]
    public class AppShellRenderer : ShellRenderer
    {
        protected override IShellItemRenderer CreateShellItemRenderer(ShellItem item)
        {
            return new CustomMenuRenderer(this)
            {
                ShellItem = item
            };
        }

Puis:

 namespace X.Mobile.App.iOS.Renderers
 {
     [Preserve(AllMembers = true)]
     public class CustomMenuRenderer : ShellItemRenderer
     {
         private SKCanvasView _skiaSharpPaintView;
         public CustomMenuRenderer(IShellContext context) : base(context)
         {
         }

public override void ViewDidLoad()
{
}           
public override void ViewWillLayoutSubviews()
{
{

Ensuite, pour définir la famille de polices : _(ne le faites pas trop souvent)_

var txtAttributes = new UITextAttributes
            {
                Font = UIFont.FromName("MyriadPro-Semibold", 12.0F)
            };
            foreach (var uiTabBarItem in TabBar.Items)
            {
                uiTabBarItem.SetTitleTextAttributes(txtAttributes, UIControlState.Normal);
            }

Quiconque a étendu le Shell avec la prise en charge d'une fenêtre contextuelle ci-dessous (feuille de fond) ?

J'ai déplacé beaucoup de code de mon ancien Shell vers le nouveau (composition bien sûr), j'aime vraiment ça. Je l'utilise même pour une application qui sortira sur prod en mai :-) (je débogue même le code Xamarin)

Existe-t-il un support pour lier une liste à Shell.MenuItems ? Ou dois-je utiliser BindableLayout ? Parfois, j'ai besoin de charger une liste à partir de la base de données et de les utiliser comme menus. Ils ont la même vue, mais chargent des données différentes selon le menu sélectionné.

Existe-t-il un moyen de modifier OffscreenPageLimit dans Android lors de l'utilisation du shell ? C'est malheureusement très important pour mon application et m'empêche d'avancer avec Shell.

Merci!

Quelques demandes de fonctionnalités :

1. Au niveau du shell, définissez la FontFamily pour tous les titres de page.
   par exemple

2. Au niveau du shell, définissez l'image d'arrière-plan Titre/Nav pour tous les titres de page/barres de navigation, etc.
   par exemple

GroupBehavior ne fonctionne pas pour moi en pre4 :

<ShellItem GroupBehavior="ShowTabs" FlyoutIcon="stuff.png" Title="Discussion">...
résulte en:

xxx/Shell/Shell.xaml(14,14) : Erreur : Position 108 :14. Aucune propriété, propriété pouvant être liée ou événement trouvé pour 'GroupBehavior', ou type incompatible entre la valeur et la propriété.

et GroupHeaderTemplate ne semble rien faire, mais je ne sais pas comment il est utilisé ou activé.

J'essaie d'ajouter/supprimer des MenuItems, qui ajoute avec succès des éléments via MenuItems.Add(item), mais aucun résultat ne s'affiche lorsque le menu volant s'affiche à nouveau. Est-ce la bonne approche pour faire cela?

Je ne vois aucune mention de la manipulation d'éléments de menu, mais le Shell m'est à peu près inutile (et je pense à beaucoup d'autres, y compris @puppetSpace ci-dessus) à moins que ces éléments ne puissent être maintenus dynamiquement en fonction de votre logique métier.

Je suis d'accord avec dbwelch pour dire qu'il est très important de pouvoir changer de shell par programmation dans le fichier cs. Non seulement pour les éléments de menu, mais aussi pour les ShellItems & ShellSections.

Lorsque j'active Flyout et que j'ajoute des éléments de menu, j'obtiens un menu hamburger dans Android, et dans iOS, si je clique à cet endroit, cela fonctionne, mais il n'y a pas d'icône. Des idées?

@KyleTraynor, il y a un problème ouvert quelque part pour cela. Vous devez copier manuellement les images 3bar.png et [email protected] dans votre dossier Ressources iOS et vous assurer qu'elles sont incluses dans le projet en tant qu'éléments

Les images que j'ai trouvées dans la source sont jointes:

@melucas Merci pour l'aide ! Je devenais fou en essayant de réparer ça. Fonctionne très bien.

Savez-vous comment je peux définir OffscreenPageLimit pour Android lors de l'utilisation de Shell ?

J'ai des pages à onglet supérieures créées en ayant 4 ShellContents à l'intérieur de 1 ShellSection, et cela fonctionne très bien sur iOS, mais sur Android, les pages se rechargent lors de l'échange entre elles, ce que je ne veux pas. Normalement, avec ma propre page à onglets, je pourrais définir OffscreenPageLimit pour résoudre ce problème, mais je ne trouve pas de moyen de le faire avec Shell.

@davidortinau pourrions-nous avoir la possibilité de définir la famille de polices sur les titres de page, les onglets inférieurs et supérieurs ? Dans chaque projet, je dois créer des moteurs de rendu personnalisés pour iOS et Android afin de changer les polices.

Donc, étant donné qu'il n'y a pas eu de réponse à mon message sur la possibilité de modifier réellement les éléments dans le Flyout Shell, peut-être que cette fonctionnalité n'est pas dans le champ d'application, ou peut-être, espérons-le, considérée comme un bogue ?

Je ne sais pas comment une application sérieuse peut utiliser ce Shell sans cette fonctionnalité. Seules les applications très simples ne nécessitent pas la possibilité d'ajouter/modifier/supprimer/désactiver des éléments dans leurs menus en fonction soit a) du contexte de l'utilisateur (c'est-à-dire authentifié/non authentifié), soit b) des états variables de l'application qui l'exiger.

Juste curieux @jassmith , les personnes qui ont créé la spécification sont-elles entrées dans ce forum ou est-ce juste pour les commentaires des développeurs ?

Au fait, à part cet élément majeur, j'ai implémenté le Shell dans mon code pour une application et cela fonctionne très bien, merci ! Mais, malheureusement, je devrai le retirer et implémenter mon propre flyout si le Shell n'a pas cette fonctionnalité fonctionnelle/implémentée.

@dbwelch , quelques choses.
Vous publiez sur les spécifications, vous n'obtiendrez donc probablement pas de réponse comme vous l'avez écrit en ouvrant un nouveau problème. De plus, Jason ne travaille plus sur Forms, donc l'appeler est un peu inutile.

En bout de ligne, déposez un problème

@dbwelch @ChaseFlorell J'ai ouvert un problème ici : https://github.com/xamarin/Xamarin.Forms/issues/5428

@davidortinau pourrions-nous avoir la possibilité de définir la famille de polices sur les titres de page, les onglets inférieurs et supérieurs ? Dans chaque projet, je dois créer des moteurs de rendu personnalisés pour iOS et Android afin de changer les polices.

@jamiewest Soumettez une demande de fonctionnalité ! Merci! https://github.com/xamarin/Xamarin.Forms/issues/new?assignees=&labels=t%2Fenhancement+%E2%9E%95&template=feature_request.md&title=%5BEnhancement%5D+YOUR+IDEA%21

La fonctionnalité UseSwipeGesture pourrait-elle être implémentée ?
Il semble que maintenant la classe ShellItem n'ait pas la propriété ShellAppearance à l'opéra.
Mais maintenant, dans Android, les onglets du Shell ne ressemblent pas à TabPage (TabPage peut balayer par défaut.)

    <ShellItem.ShellAppearance>
      <MaterialShellAppearance NavBarCollapseStyle="Full" TabBarCollapseStyle="Full" UseSwipeGesture="false">
    </ShellItem.ShellAppearance>

@jingliancui , Frère Cui, y a-t-il qq ou WeChat ?

@juepiezhongren Salut, vous pouvez rejoindre ce groupe qq pour discuter avec moi 313308215

Verrons-nous Shell et le support visuel venir pour UWP sur RTM ?

Je me réjouis de cette idée, peu importe ce que cela rend plus difficile, car travailler avec des pages de navigation, des pages maître-détail, etc. semble trop compliqué. C'est peut-être parce que je viens d'un environnement Web (je n'ai pas beaucoup travaillé avec les API natives). La personnalisation de la barre de navigation, des titres de page, du bouton Précédent, des éléments de la barre d'outils, des en-têtes et pieds de page (ListView), etc. me vient à l'esprit ici.

Je suppose que ce que je demande, c'est que les nouvelles fonctionnalités, comme *Shell, soient livrées avec la personnalisation et l'extensibilité à l'esprit. Il y a très peu de situations dans lesquelles nous n'avons pas eu besoin de créer une série de moteurs de rendu, de comportements, de déclencheurs, etc. pour effectuer des choses apparemment simples.

Quoi que vous fassiez, faites tout ce que vous pouvez pour nous aider à rendre nos applications Xamarin.Forms aussi belles que les autres applications natives ! Il semble que cette fonctionnalité nous donnera une meilleure rampe de lancement pour les applications XForms d'apparence moderne !

Existe-t-il un code source disponible pour voir comment fonctionne ce Shell, au lieu d'avoir à deviner les spécifications ? Par exemple, quel style est utilisé pour colorer l'icône du hamburger, s'il est disponible. Désolé, nouveau chez C#/Xamarin, mais, si le code était visible quelque part, cela aiderait énormément.

@dbwelch, vous pouvez parcourir le code source ici même sur GitHub. Appuyez sur "T" et tapez Shell pour voir les classes associées. Ce n'est peut-être pas le meilleur point de départ si vous débutez avec C#/Xamarin. Je recommande de vérifier certains de mes exemples jusqu'à ce que nous obtenions plus de documentation :

https://github.com/davidortinau/Gastropods
https://github.com/davidortinau/ShellGallery
https://github.com/davidortinau/TheLittleThingsPlayground

Documents : https://docs.microsoft.com/en-us/xamarin/xamarin-forms/app-fundamentals/shell?tabs=android
Article MSDN : https://msdn.microsoft.com/en-us/magazine/mt848639
Blog : https://blog.xamarin.com/xamarin-forms-4-0-preview/

@davidortinau merci, mais je pensais que c'était juste un code disponible qui était disponible, où est le code Shell ? J'ai regardé sous branches pour 4.0, Shell, d'autres, mais ça me cache ! Merci!

@dbwelch https://github.com/xamarin/Xamarin.Forms/search?q=shell&unscoped_q=shell

Shell.cs par exemple est ici

@pauldipietro Merci, voyez-le maintenant. @davidortinau J'ai en fait passé beaucoup de temps sur tous les liens (sauf LittleThings, que je viens de télécharger), mais je ne vois pas comment changer une chose aussi simple que la couleur de l'icône du hamburger. Il apparaît en violet dans mon application, mais je n'ai de couleur violette définie nulle part (que je puisse voir). Un peu frustrant ;-).

MISE À JOUR : je viens de trouver le problème et, bien sûr, c'est un code dégoûtant qui existe dans FinishedLaunching pour ajouter TintColor. DOH !

Merci messieurs, appréciez l'aide!

J'ai des éléments qui s'affichent dans le panneau volant, ce qui est bien. Cependant, il existe déjà un moyen de masquer/ne pas afficher un élément Shell (pas le contenu de l'élément). Exemple, j'ai un ContentPage et je veux juste avoir la navigation à l'intérieur du Shell.

<local:DetailPage />

Il semble qu'il ajoute toujours l'élément dans le panneau/la liste Flyout. Et s'il n'y a pas de titre, alors il aura une pile/espace réservé vide de l'élément. J'ai essayé de nombreuses façons de masquer l'article, toujours sans succès. Quelqu'un peut probablement vous aider ou la fonctionnalité n'est toujours pas disponible.

Préface : Je suis un nouveau distributeur de billets. Essayer de ne pas l'être.

@davidortinau Donc, j'ai essayé d'apprendre cette fonctionnalité Shell pour ajouter la navigation, etc. dans notre premier projet Xamarin.Forms pour notre entreprise (woot!) ou plusieurs paramètres d'un ShellItem vers d'autres parties de l'application via la nouvelle fonctionnalité de routage. Est-ce une chose du tout ? Ou devons-nous nous en tenir à la commande en utilisant MenuItems dans une collection MenuItem à la place ? Si nous devons utiliser un MenuItem pour transmettre 1 ou plusieurs valeurs du niveau Flyout, il semblerait que nous ne puissions plus structurer notre application avec la hiérarchie Shell puisque nous utilisons plutôt des MenuItems ? Ne perdons-nous pas cela en utilisant MenuItems avec des paramètres de commande ?

Y a-t-il quelqu'un qui peut intervenir là-dessus? Si c'est le cas, je l'apprécierais grandement. Fondamentalement, j'adorerais utiliser Shell, mais je serais toujours en mesure de marquer quel ShellItem l'utilisateur a sélectionné en cliquant sur l'un pour le transmettre à une page ContentTemplate ou à tout ce qui est approprié, car de nombreux ShellItems navigueront vers une page intermédiaire similaire pour créer un OrderType et la sélection déroulante OrderDepartment avant d'accéder à l'écran principal de commande avec les données appropriées pour le bon type et le bon département.

Aussi, je m'excuse si ce n'est pas le bon endroit pour cela. Si oui, merci de m'indiquer le bon endroit. Merci!

Mettre à jour:
Peut-être que je vais simplement utiliser les MenuItems pour le moment et passer un paramètre de commande à un ShellViewModel pour naviguer avec les bonnes valeurs pour la page cible. Maintenant que j'y pense, je n'aurai vraiment pas besoin de naviguer vers une structure à onglets à partir de ces MenuItems poussant vers la page ContentTemplate.

Je me demandais aussi si nous pouvions définir où se trouvent les MenuItems dans le Flyout afin que les ShellItems n'apparaissent pas tous en haut; et si un jour nous n'avons pas à définir nos MenuItems dans le cadre d'une collection afin qu'ils puissent se mêler aux ShellItems comme :
MenuItem
ShellItem
ShellItem
MenuItem
ShellItem
MenuItem
...
Cela, ou simplement rendre ShellItems capable de transmettre des paramètres à un moment donné s'ils ne le peuvent pas déjà.

Je suis avec @anthcool et

@anthcool essaie juste d'aider et de donner des suggestions ici comme ce que j'ai fait pour le moment. Créez une classe de paramètres de navigation qui a un readonly Stack<NavigationParameter> comme liste de pile, c'est-à-dire

public class Navigation
{
    readonly Stack<NavigationParameter> _stack = new Stack<NavigationParameter>();
...
    public Stack<NavigationParameter> Parameters => _stack;
}

Le paramètre de navigation est :

public class NavigationParameter : NameValueCollection { }

Vous pouvez ajouter des paramètres avant le push lors de la navigation, ex :

    var p = new NavigationParameter { { nameof(SomePage), SomeObject } };
    Navigation.Parameters.Push(p);

Une fois que vous dans l'autre page, juste Peek ou Pop la valeur et la vérification de la clé.
Quelque chose comme ci-dessus. J'espère que cela pourra aider.

@anthcool essaie juste d'aider et de donner des suggestions ici comme ce que j'ai fait pour le moment. Créez une classe de paramètres de navigation qui a un readonly Stack<NavigationParameter> comme liste de pile, c'est-à-dire

public class Navigation
{
    readonly Stack<NavigationParameter> _stack = new Stack<NavigationParameter>();
...
    public Stack<NavigationParameter> Parameters => _stack;
}

Le paramètre de navigation est :

public class NavigationParameter : NameValueCollection { }

Vous pouvez ajouter des paramètres avant le push lors de la navigation, ex :

    var p = new NavigationParameter { { nameof(SomePage), SomeObject } };
    Navigation.Parameters.Push(p);

Une fois que vous dans l'autre page, juste Peek ou Pop la valeur et la vérification de la clé.
Quelque chose comme ci-dessus. J'espère que cela pourra aider.

Merci pour l'idée @rizamarhaban ! J'apprécie vraiment que vous soyez intervenu là-dessus. Merci! Je vais vérifier ça ici bientôt. Encore une fois, appréciez-le!

Très déçu d'apprendre que Shell et Visual ne prennent pas en charge UWP.

Cette spécification est-elle vraiment terminée ?
Pourquoi fermer cela simplement parce qu'il y a maintenant une implémentation Tizen ?
J'avais l'impression que la fonctionnalité de navigation était encore en cours de révision.

Toujours pas de support UWP. La plus grande déception que j'aie jamais eue de Xamarin.

@weitzhandler S'il [email protected] si vous souhaitez en discuter et UWP en général. Nous n'ignorons pas activement la plate-forme, mais Android et iOS reçoivent la mise en œuvre initiale et les enquêtes sur la prise en charge de Shell pour UWP sont en cours.

@mrlacey Nah, c'est loin d'être fini ! Il ne cesse de se fermer par des problèmes connexes. ??

Pour tous ceux qui demandent le support UWP, j'ai essayé : https://github.com/xamarin/Xamarin.Forms/pull/6015

Existe-t-il un moyen d'implémenter un modèle de barre de navigation sur la page de contenu ?
La spécification de NavigationPage.TitleView ne s'applique pas comme avant.
Repo pour référence:
https://github.com/InquisitorJax/Xamarin-Forms-Shell

ÉDITER:
Murphy frappe à nouveau - utilisez simplement Shell.TitleView au lieu de NavigationPage.TitleView :)

Bonjour,
Dans mon nouveau projet, j'utilise Shell et CollectionView, et je dois dire que c'est génial !
Une question sur Shell

• il existe un moyen d'ajouter un élément du bas fixe (exemple de renard un bouton pour la déconnexion de l'utilisateur)

Je vois qu'il est possible d'ajouter un en-tête fixe (FlyoutHeader et FlyoutHeaderBehavior) mais je ne trouve aucune information sur le pied de page inférieur
Merci!

Bonjour,
J'ai une autre question sur RegisterRoute.
Mon application est assez grande, avec un nombre considérable de pages, environ 30...
Est-ce vraiment la bonne façon d'ajouter le RegisterRoute pour chacun d'eux ?
Routing.RegisterRoute("blabla", typeof(BlaBlaPage)); ... ...
Ou est-il préférable d'utiliser l'ancienne méthode?
var blaPage = new BlaBlaPage (); await Navigation.PushAsync (blaPage);

@matteopiccioni Je recommanderais de le faire comme ça

Routing.RegisterRoute("blabla", typeof(BlaBlaPage));

et en utilisant
gotoasync("blabla")

Je me rends compte en ce moment que c'est la même chose, mais à mesure que les fonctionnalités se développent, il sera plus pertinent de faire fonctionner toutes ces choses via le système Shell

Est-ce vraiment la bonne façon d'ajouter le RegisterRoute pour chacun d'eux ?

si cela devient un problème, nous envisageons d'ajouter des fonctionnalités qui ne feront qu'analyser l'assemblage des pages ou peut-être même des fonctionnalités de compilation qui généreront ces routes.

Le principal problème ici est que tout type de réflexion va ralentir votre application, donc le faire au démarrage coûtera

@PureWeen merci pour la réponse
Le temps de démarrage lent est l'un des problèmes les plus ennuyeux de xf (pour Android)
Au démarrage, pourrais-je ajouter au routage uniquement le premier niveau de pages (les pages shellitems) et ajouter les autres uniquement après le démarrage de l'application (une sorte de chargement paresseux de RegisterRoute) ?

@matteopiccioni

Alors si tu fais comme ça tout d'un coup

Routing.RegisterRoute("blabla", typeof(BlaBlaPage));

C'est bon. Tout ce dont je parlais, c'est que si nous finissons par créer quelque chose qui permet aux utilisateurs de ne pas avoir à le faire, nous devrons le comparer aux performances. À l'heure actuelle, Routing.RegisterRoute("blabla", typeof(BlaBlaPage)); ne fait aucune réflexion, donc tout faire en même temps est bien.

tout ce qu'il fait est d'ajouter une chaîne et un type à un dictionnaire

@jassmith @jamesmontemagno @pierceboggan Wow a fière allure. Avez-vous vu l'application Google Contacts utilisant Pie SDK sur un Google Pixel ? J'adore l'UI/UX, sans barre de titre et le hamburger intégré au sommet de l'application.

Cette suggestion peut-elle être envisagée pour votre Shell puisque c'est un modèle que Google utilise, avec Contacts et Maps, et peut-être d'autres ?

Merci pour votre temps et votre considération,

Karl

Notez que tous les exemples qui suivent n'utilisent pas de modèles de ShellContent, qui sont abordés ailleurs dans la spécification. Si vous n'utilisez pas correctement ShellContents avec un ContentTemplate, toutes les pages seront chargées au démarrage, ce qui aura un impact négatif sur les performances de démarrage. Ces exemples sont uniquement à des fins d'apprentissage.
Heureusement, utiliser ShellContents avec ContentTemplates est généralement plus concis que de ne pas les utiliser.
[...]
Un problème majeur avec l'utilisation du Shell est la facilité avec laquelle un utilisateur peut charger toutes les pages au début de l'exécution de son application. Cette importante allocation en amont peut entraîner des performances de démarrage assez médiocres si un grand nombre de pages de contenu est nécessaire. Afin de corriger ce modèle, il convient d'utiliser autant que possible.

Pour moi, cela donne l'impression que vous ne devriez jamais utiliser de contenu directement, mais utiliser des modèles. Cela a du sens pour moi, alors pourquoi soutenir l'approche de contenu direct ? (à part la simplicité, mais c'est laisser les gens se tirer une balle dans le pied). On a l'impression que pouvoir utiliser du contenu direct est plutôt une fonctionnalité "géniale pour faire une démo - sinon horrible".

Salut,
Je suis nouveau ici. Je ne sais pas si c'est le bon endroit pour poser des questions, sinon veuillez m'indiquer où demander :
J'ai essayé de faire quelque chose de similaire à l'exemple spécifié ci-dessus :

  <ShellItem Title="My music" ItemsSource="{x:Bind MyMusicModels}" TabLocation="Bottom">
    <ShellItem.ItemTemplate>
      <local:MyMusicItemTemplateSelection />
    </ShellItem.ItemTemplate>
  </ShellItem>

Mais j'ai les erreurs suivantes :

Erreur XLS0413 La propriété 'ItemsSource' n'a pas été trouvée dans le type 'ShellItem'.
Erreur XLS0415 La propriété pouvant être jointe 'ItemTemplate' n'a pas été trouvée dans le type 'ShellItem'.

@Elashi alors
https://docs.microsoft.com/en-us/xamarin/xamarin-forms/user-interface/layouts/bindable-layouts

Avec ShellItem ?

@PureWeen J'espérais utiliser cette idée :) .
Êtes-vous en train de suggérer que cette idée n'est pas encore mise en œuvre?
S'il n'est pas encore implémenté, je pourrais être intéressé à travailler dessus.

Ce n'est pas implémenté, j'aimerais qu'il le soit !

Envoyé de mon iPhone

Le 5 mai 2019 à 11h59, Elashi < [email protected] [email protected] > a écrit :

@PureWeen https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FPureWeen&data=02%7C01%7C%7C5a4c31a04c6541d6080608d6d172b36a%7C84df9e7fea7af6401%afb4357 %
Êtes-vous en train de suggérer que cette idée n'est pas encore mise en œuvre?
S'il n'est pas encore implémenté, je pourrais être intéressé à travailler dessus.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fxamarin%2FXamarin.Forms%2Fissues%2F2415%23issuecomment-489439176&data = 02% 7C01% 7C% 7C5a4c31a04c6541d6080608d6d172b36a% 7C84df9e7fe9f640afb435aaaaaaaaaaaa% 7C1% 7C0% 7C636926687892536099 & sdata = RdPBMt9fPqsPC1x0FlJ1MQzn8BK6m9lfg7nsT09YIN8% 3D et réservé = 0 , ou couper le fil https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F% 2Fgithub.com% 2Fnotifications% 2Funsubscribe-auth% 2FAABUHE2I4F33TX2SZJE2RVDPT377JANCNFSM4EZ4GB5Q & data = 02% 7C01% 7C% 7C5a4c31a04c6541d6080608d6d172b36a% 7C84df9e7fe9f640afb435aaaaaaaaaaaa% 7C1% 7C0% 7C636926687892546103 & sdata = UXiXgRiTo4pAjJVraUqmJmYZibiWMdh9htX2SeFG4JM% 3D et réservé = 0 .

@Elashi ce n'est pas le cas, mais je pouvais voir que c'était une fonctionnalité vraiment puissante pour les scénarios MVVM

Si vous voulez travailler dessus, pouvez-vous créer un problème avec les bases de ce que vous pensez ?

Donc par essais et erreurs... Même s'il y a des commentaires sur les gestes dans le shell 3.2 et dans TheLittlePlayground, je ne peux pas pour la vie faire fonctionner Gestures sur ANDROID avec le package visuel.

Est-ce que je manque quelque chose dans les notes que les gestes Shell + ne fonctionnent qu'avec l'iphone ?

@davidortinau Je sais qu'il ne s'agit que de quelques spécifications, et qu'elles sont fermées depuis un certain temps, mais j'espérais que vous pourriez

• Ajouter une API pour les éléments de "sous-menu" pour l'ala GPS de ShellContent -> Musique -> Ouvrir l'application Musique

Actuellement, comme je ne parviens pas à faire fonctionner les GroupHeaders, je cherche à retravailler mon FlyoutMenu pour le trier en 6 groupes principaux, puis à faire apparaître un sous-menu rempli de FlyoutItems qui me dirigent vers le routage que j'ai prédéterminé.

Mon cas d'utilisation est que j'ai plus de 50 options à afficher et que les mettre dans un état de défilement n'est pas convivial pour l'interface utilisateur, mais chaque option à afficher est quelque chose dont j'ai besoin pour permettre à mes utilisateurs d'accéder efficacement sans avoir à faire défiler sans fin. Le tri en groupes en fonction du thème général de chaque option est le plus logique d'un point de vue UI/UX.

Pouvez-vous nous éclairer sur la situation en termes de développement/production ? - ou m'orienter vers une base de code qui l'implémente pour que je puisse apprendre ? (Je ne suis avec Xamarin que depuis 1 mois, donc je suis encore nouveau sur certaines des ressources disponibles).

@TheBaileyBrew

Je viens de rechercher sur Google ce référentiel avec quelque chose qui pourrait très probablement fonctionner pour votre scénario. Ce ne sera pas Shell, mais vous pourriez probablement l'utiliser dans une configuration MasterDetailPage.

https://github.com/ishrakland/ListViewWithSubListView/

De plus, ils viennent de déplacer et de mettre à jour une grande partie de leur matériel de cours vers MSFT Learn (que je suis en train de parcourir moi-même pour combler les lacunes). Cela se trouve ici : https://docs.microsoft.com/en-us/learn/browse/?products=xamarin

J'essaierais de parcourir ce qui précède. Bonne chance et bienvenue à bord !

Salut les gars, je veux choisir un fichier ou des photos de la galerie ou du stockage externe dans
xamarin formulaires qui choisir ? Le fichier n'a qu'une extension .PDF. À
sélectionnez les deux fichiers j'utilise un seul bouton alors s'il vous plaît aidez-moi !!!

Le jeu. 23 mai 2019, 19:41 Anthony Cool [email protected] a écrit :

@TheBaileyBrew https://github.com/TheBaileyBrew

Je viens de rechercher sur Google ce référentiel avec quelque chose qui pourrait fonctionner pour votre scénario
probablement. Ce ne sera pas Shell, mais vous pouvez l'utiliser dans une MasterDetailPage
configuration probablement.

https://github.com/ishrakland/ListViewWithSubListView/

-
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/xamarin/Xamarin.Forms/issues/2415?email_source=notifications&email_token=AK7KSYK4N3XIVP3IHOBE2P3PW3CKJA5CNFSM4EZ4GB52YY3PNVWWK3TUL52HS4DFVREXG43VMVBJW63LNMVX29
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AK7KSYI5XKMXD7FC7HZH45LPW3CKJANCNFSM4EZ4GB5Q
.

Hé les gars, je veux ajouter des onglets en fonction de la condition, alors comment puis-je ajouter des onglets dans Shell en utilisant C # pas dans Xaml ainsi que comment ajouter des éléments de menu.

@TheBaileyBrew

c'est ça que tu cherches ?
https://docs.microsoft.com/en-us/xamarin/xamarin-forms/app-fundamentals/shell/flyout#flyout -display-options

@BeleShew, votre question est probablement mieux adaptée pour stackoverflow ou sur forums.xamarin.com

@PWaliaDev, vous le feriez à travers les différentes collections d'éléments qui font partie de shell

Shell.Items.Add (nouveau ShellItem())
new ShellItem().Items.add(new ShellSection())
nouveau ShellSection().Items.Add(nouveau ShellContent())

Bien que je suppose que si nous avons résolu ce problème
https://github.com/xamarin/Xamarin.Forms/issues/5428

cela conviendrait à votre scénario?

@PureWeen -- J'ai les options d'affichage définies par votre lien, mais ce avec quoi je me bats est plus proche de ce à quoi

La correction #5428 correspondrait à ce que je cherche à réaliser.

Mon application a des utilisateurs avec une multitude de rôles/accès et je dois afficher par programmation les options de menu uniquement aux utilisateurs autorisés (je ne veux pas que les utilisateurs voient ce qu'ils _ ne peuvent pas _ faire, seulement ce qu'ils peuvent.

Bien que j'aie joué avec cela, j'essaie de déterminer s'il est possible d'inspecter mes options de menu et d'ajouter plutôt que de masquer comme le fait ce code (mais je devrais itérer sur chaque itinéraire et option de menu possibles qui mangeraient temps de chargement:

foreach (var item in this.Items)
        {
            if (item is FlyoutItem)
            {
                var removeSections = new List<ShellSection>();
                var fi = item as FlyoutItem;
                foreach (var child in fi.Items)
                {
                    if (child.Route == "NOT_AUTHORIZED_KEY")
                        removeSections.Add(child);
                }
                foreach (var s in removeSections)
                    fi.Items.Remove(s);
            }
        }

Shell est génial en théorie mais pas en pratique sans ces fonctionnalités indispensables.

1. Ajouter/supprimer des éléments du shell de manière dynamique en fonction du rôle de l'utilisateur
2. Scénario de connexion/déconnexion ou deux itinéraires de navigation distincts en fonction des conditions.
3. En option, prise en charge d'autres frameworks MVVM comme Prism

Impossible d'utiliser les applications orientées Shell dans les entreprises tant que les fonctionnalités 1 et 2 ne sont pas fournies.

@Im-PJ Pourquoi pensez-vous que 1 et 2 ne sont pas possibles ? (à peu près sûr qu'ils le sont)

3 est en cours et suivi ici .

Est-ce que quelqu'un sait s'il est possible d'obtenir un événement tap à partir d'un onglet App Shell ?
question connexe du forum : https://forums.xamarin.com/discussion/159748/app-shell-pop-to-root-on-tab-tap

Entièrement d'accord avec @Im-PJ, et je ne comprends pas en quoi ces fonctionnalités ne sont pas spécifiquement prévues. C'est une raison principale pour un outil comme Shell. Tout le monde peut créer un menu coulissant !

@dotMorten peut-être que vous pouvez faire 1 ou 2 grâce à C# et au piratage étendus, mais il n'y a AUCUN exemple ou mention de liaison/désactivation/masquage/ajout d'éléments Shell au moment de l'exécution que je puisse trouver. Il semble que les capacités dynamiques auraient été un objectif majeur de cet outil. La création d'une représentation XML, ainsi que de certaines fonctionnalités de cheminement, est un strict minimum, suffisant pour être donné aux spécialistes du marketing, mais pas suffisant pour être réellement utilisé dans une application mobile réelle et complète.

@Im-PJ

pouvez-vous développer un peu sur la façon dont ils sont différents?

Ajouter/supprimer des éléments du shell de manière dynamique en fonction du rôle de l'utilisateur
Scénario de connexion/déconnexion

Actuellement, vous pouvez créer un scénario de connexion/déconnexion en utilisant une barre de tabulation ou en masquant la navigation volante si vous êtes sur une page de connexion.

<TabBar Route="LoggedOut">
<LoginPage>
</TabBar>

<FlyoutItem Route="LoggedIn"></FlyoutItem>
<FlyoutItem></FlyoutItem>
<FlyoutItem></FlyoutItem>
<FlyoutItem></FlyoutItem>

Si vous êtes sur la page de connexion, le seul moyen de s'éloigner est de passer par le code.

Des travaux sont en cours ici pour exposer une propriété pouvant être liée IsVisible
https://github.com/xamarin/Xamarin.Forms/tree/shell_isvisible

Il a juste besoin d'un peu de raffinement avant de créer un PR

deux itinéraires de navigation distincts en fonction des conditions.

Pouvez-vous fournir des exemples de ce que vous essayez de faire et ne pouvez pas faire actuellement ?

J'utilise le Xamarin.Form Shell

Exemple de lien : https://docs.microsoft.com/en-us/xamarin/xamarin-forms/app-fundamentals/shell/flyout

Aidez-moi, s'il vous plaît. Comment afficher la barre d'onglets dans la page À propos ?

J'ai besoin d'avoir deux pages shell en même temps.
Un pour un menu déroulant avec page d'accueil, paramètres, déconnexion, etc.
Un pour les pages à onglets qui devraient être poussées depuis la maison
Pour l'instant, je dois utiliser "l'ancienne méthode"

J'ai besoin d'avoir deux pages shell en même temps.
Un pour un menu déroulant avec page d'accueil, paramètres, déconnexion, etc.
Un pour les pages à onglets qui devraient être poussées depuis la maison
Pour l'instant, je dois utiliser "l'ancienne méthode"

Si vous utilisez Tabbedpage, vous ne pouvez pas afficher Flyout . Je veux afficher Flyout et Tabbar cette fois-ci.

J'ai mis toutes les pages dans lepour que les pages affichent la barre d'onglets, mais je souhaite n'avoir que 4 éléments dans la barre d'onglets (je ne veux pas afficher plus d'onglets). Comment faire ?

<shell>
<flyoutitem route="animals" flyoutdisplayoptions="AsMultipleItems">
<shellcontent route="cats"/>
<shellcontent route="dogs"/>
<shellcontent route="monkeys"/>
<shellcontent route="elephants"/>
<shellcontent route="bears"/>
<shellcontent route="about"/>
</flyoutitem>
</shell>

J'ai besoin d'avoir deux pages shell en même temps.
Un pour un menu déroulant avec page d'accueil, paramètres, déconnexion, etc.
Un pour les pages à onglets qui devraient être poussées depuis la maison
Pour l'instant, je dois utiliser "l'ancienne méthode"

Si vous utilisez Tabbedpage, vous ne pouvez pas afficher Flyout . Je veux afficher Flyout et Tabbar cette fois-ci.

J'ai mis toutes les pages dans le pour que les pages affichent la barre d'onglets, mais je veux n'avoir que 4 éléments dans la barre d'onglets (je ne veux pas afficher plus d'onglets). Comment faire ?

<shell>
<flyoutitem route="animals" flyoutdisplayoptions="AsMultipleItems">
<shellcontent route="cats"/>
<shellcontent route="dogs"/>
<shellcontent route="monkeys"/>
<shellcontent route="elephants"/>
<shellcontent route="bears"/>
<shellcontent route="about"/>
</flyoutitem>
</shell>

Malheureusement, je ne peux pas utiliser Shell
J'ai toujours MasterDetailPage et TabbedPage dans la même application (dans iOS, j'ai les premières pages à onglets utilisant le plugin Naxam.TopTabbedPage.Forms)
C'était mon ancien billet