دعنا نطلق هذه المحادثة ، لأننا نحتاج حقًا إلى الاستماع منك ، مجتمع المطورين لدينا!

أولاً ، شكرًا jassmith على العمل

سأشارك بعضًا من أفكاري ، وأسأل بعض الأسئلة الغبية ، وأسأل بعض الأسئلة التي نأمل ألا تكون إرشادية للغاية. بصفتي مدير برنامج Xamarin ، غالبًا ما يتعين علي طرح الأسئلة بطريقة تجعل الأمر يبدو وكأنني لا أملك فكرة (في بعض الأحيان لا أفعل ذلك) ، ولكن في الحقيقة أنا بحاجة فقط إلى سماع أشياء منك بدون وضع الكلمات في فمك.

هناك أشياء أحبها في هذا الاقتراح ، لأنني أستطيع أن أرى كيف يمكنهم معالجة بعض المشكلات التي تحدثت مع العديد منكم عنها ، ونحن نعمل على حلها.

لدي أيضًا تحفظات.

سأبدأ هنا ببعض الأفكار العامة حول مفهوم شل وتجربة المطور.

تجربة التطبيق

للحصول على تجربة تطبيق كاملة منظمة بشكل صحيح ، واستخدام العناصر الصحيحة ، مع القليل من الجهد ومسار واضح ليكون جيدًا بشكل افتراضي.

إذا استخدمت هذا الأسلوب لوصف طلبي في المستوى الأعلى ، فسأحصل على:

• تطبيق ذو مظهر يبدو متماثلًا على كل نظام أساسي
• يتم تشغيل أنماط تصميم المواد (في هذه الحالة) افتراضيًا
• تم تمكين أحدث أنماط التنقل مع التكوين
• لست مضطرًا إلى العمل لتخصيص Entry أو Button ليبدو كما هو على iOS و Android و UWP؟

هل هذا دقيق؟ الفوائد الأخرى التي يجب أن أبرزها؟

بدلاً من App لديّ MaterialShell . أحتاج إلى تعلم / تبني نموذج تطبيق جديد عالي المستوى للاستفادة من هذا؟

بمجرد وصولي إلى تطبيقي ، عدت إلى أرض ContentPage ، أليس كذلك؟ لكن كل ما عندي من Button s و Entry s مادية وجميلة. هل لا يزال بإمكاني OnPlatform وما شابه ذلك لتباعد المظهر (أو السلوك) لأكون مختلفًا على نظام أساسي آخر؟

كيف يبدو مسار الترحيل الخاص بي من تطبيق موجود إلى استخدام هذه "shell"؟ لقد قمت بتقديم MaterialShell ، ووصف كيف أريد أن يكون تطبيقي هيكليًا ومظهرًا ، وقم بتشغيله فقط لمعرفة الجودة الجديدة؟

التخصيص

ما هي الخيارات المتاحة لي إذا أعجبتني الطريقة التي تبدو بها عناصر القائمة Flyout ، لكنني بحاجة إلى تعديلها لتتناسب مع مجموعات المصممين الخاصة بي؟ في أي نقطة أقول "آه ، كان يجب أن أقوم بتدوير كل هذا بنفسي" ونقل ما لدي إلى بنية تطبيقات Xamarin.Forms قياسية؟

إذا اضطررت إلى التخلي تمامًا عن MaterialShell ، فهل أفقد كل مزايا التصميم هذه وسأعود من حيث بدأت (مثل اليوم) مع Entry يبدو مختلفًا تمامًا بين iOS و Android و UWP ؟ لا أريد ذلك.

هناك نقطة تحول أتوقعها. بعد أن استخدمت هذا الأسلوب للمضي قدمًا بسرعة ، سأواجه بعض القيود وأحتاج إلى استكشاف خياراتي. ما هي وفي أي مرحلة من الأفضل عدم استخدام MaterialShell ؟

المشكلة

سأختتم هذا التعليق الأول ببعض الأسئلة على كل من يقرأ.

• هل المشكلة التي يحاول هذا الاقتراح معالجتها واضحة المعالم؟
• هل هي مشكلة تشاركها؟
• أثناء قراءتك لهذه المواصفات ، ما المشكلات التي واجهتها في المشروعات السابقة هل تشعر أن هذا سيحلها لك؟

إذا كان ذلك ممكنًا ، فإن لقطات الشاشة / صور التصميم ستجعل أفضل.

تحقق أيضًا من هذا:

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

jassmith كان سيكون رائعًا إذا تم تقديم الفكرة بأكملها كصور. مجد لجهود وضع المواصفات. قد تكون أسئلتي غير صحيحة.

استفساراتي هي

• دعم الجهاز اللوحي ، لم يتم تناول استجابة التطبيق للتكيف مع تخطيط مختلف.
• هل سيكون الانتقال من النموذج الحالي إلى النموذج الجديد أمرًا صعبًا؟ من منظور مطور التطبيق ومنظور المساهمين في نماذج Xamarin.
• أوافق على أن معظم التطبيق يحتاج إلى واجهة مستخدم واحدة (بسبب كمية العارضين المخصصة التي يتعين علينا كتابتها في وقت ما لتحقيق نفس مفاهيم واجهة المستخدم) دون احترام تفاصيل النظام الأساسي ، فهل سيؤدي الاتجاه الجديد إلى إزالة جميع الميزات الحالية ، مثل هل سنستمر في تطوير Xamarin. تطبيقات ذات واجهة مستخدم خاصة بالنظام الأساسي ، أو سيتم إجبار الجميع على معايير جديدة.
• هل ستظل مفاهيم العارض موجودة داخل MaterialShell
• هل يمكننا في الواقع أن نقول ، في نظام iOS ، نريد أن يتم عرض هذا بهذه الطريقة؟ يحتوي Flutter على Cupertino Styles (Apple UI) الذي يعمل في Android و Android UI الذي يعمل في iOS. في أي اتجاه ستتحرك نماذج Xamarin. هل سيكون لدى المطور هذا النوع من القدرات التي يقدمها الرفرفة الآن.

هل سيتضمن هذا أيضًا شيئًا مشابهًا لـ TextInputLayout لدعم التسميات العائمة / العناصر النائبة بالإضافة إلى رسائل الخطأ؟ إذا كانت الإجابة بنعم ، فأعتقد أنه يجب تمديد Binding ليشمل "ValidateOnDataErrors" على غرار wpf.

انظر تنفيذي لهذا هنا
https://github.com/XamFormsExtended/Xfx.Controls/blob/develop/src/Xfx.Controls/XfxBinding.cs

أيضًا ، أتساءل عما إذا كان يجب على MaterialShell تمديد Shell بحيث يمكن للمرء إنشاء HumanInterfaceShell لمظهر وشكل iOS.

ChaseFlorell كان ذلك سيكون تعليقي أيضًا. المواد رائعة ، لكنها شيء آخر إذا أردنا كتابة الأصداف الخاصة بنا لتناسب احتياجات واجهة المستخدم الخاصة.

@ davidortinau ، @ jassmith ،

نشكرك على تجميع هذه المواصفات والسماح لنا بتقديم التعليقات.

هل المشكلة التي يحاول هذا الاقتراح معالجتها واضحة المعالم؟

نعم فعلا. لم يتم تطوير نظام الملاحة بالكامل في نماذج Xamarin لذا فهناك مشكلة مفتوحة تتعلق بكيفية إكماله أو التحايل عليه تمامًا.

هل هي مشكلة تشاركها؟

نعم فعلا.

أثناء قراءتك لهذه المواصفات ، ما المشكلات التي واجهتها في المشروعات السابقة هل تشعر أن هذا سيحلها لك؟

سأجيب على هذا السؤال بالقول إنني لا أعتقد أنه سيحل المشاكل. تتمثل مشكلاتنا الخاصة في أن نظام الملاحة الحالي صارم للغاية ، وليس لأنه ليس جامدًا بدرجة كافية. أوضح مثال لنا هو TabbedPage. لا يوجد عرض TabbedView ، لذلك إذا كنا نريد علامات تبويب في تطبيقنا ، فيجب علينا استخدام TabbedPage. لذلك ، يجب استخدام TabbedPage للشاشة بالكامل ولا يمكننا استخدام العقارات للأزرار الخاصة أو عناصر التحكم الأخرى التي قد نرغب في وضعها على الشاشة. كانت توصيتي هي نقل المزيد من الوظائف _ خارج_الصفحات ولأسفل إلى طرق العرض بدلاً من نقل الوظائف في الصفحات إلى طبقة أعلى مرة أخرى.

أشياء مثل FloatingMenu و FlyoutBehavior تخيفني لأنها تشير إلى أن التنقل سيكون مشفرًا بشكل أكبر في Xamarin. سيتم سحب نظام الأشكال والمزيد من التحكم من مطوري البرامج. أستطيع أن أرى بعض القيمة في اتباع نهج معياري أكثر ، لكنه سيأتي بالتأكيد بتكلفة.

لقد عملنا دائمًا في تقنيات أخرى قائمة على XAML مثل Silverlight و WPF و UWP. في هذه التقنيات ، لدينا نهج مفتوح أكثر بكثير حيث يمكننا تحديد المزيد حول كيفية عمل التنقل. في الآونة الأخيرة ، تعاقدنا مع مستشار UI / UX. لم يكن على دراية بمراوغات XF. لقد طلبنا منه فقط إنشاء بعض الشاشات لنا بناءً على وظائف برنامجنا. لا يمكن تنفيذ مساحات كبيرة مما أوصى به بسبب أشياء مثل عدم وجود TabbedView. أخشى أنه بدلاً من جعل التنقل أسهل ، ما سيحدث هو أن هذا الإطار سيجعل من الصعب بالفعل تنفيذ التصميمات التي قدمها لنا مصممو UX / UI.

الشيء الآخر الذي أود قوله هو أن إطار العمل هذا يبدو غير مسبوق في منصات XAML الأخرى ، وأود أن أقول إن الأولوية يجب أن تكون على توفير التقييس عبر الأنظمة الأساسية بدلاً من توفير أطر عمل جديدة لا تتوافق معها الأنظمة الأساسية الأخرى. نقوم حاليًا ببناء ثلاث منصات الآن: Silverlight و Xamarin.Forms و WPF. ما نحتاجه هو توحيد المعايير عبر تلك المنصات لخلق انحراف أقل وليس أكثر.

dylanberry ،

إنه شيء آخر إذا أردنا كتابة أصدافنا الخاصة لتناسب احتياجات واجهة المستخدم الخاصة.

نعم فعلا. هذا هو قلقي. لكل تطبيق حالات استخدام خاصة به ، ومن المرجح أن تزيد الصلابة من صعوبة الأمر - وليس من السهل تنفيذها.

هناك أيضًا هذا القلق: https://github.com/xamarin/Xamarin.Forms/issues/2452#issuecomment -380991817

سأكرر ما ورد أعلاه ، وكذلك أسأل كيف ستعمل الإيماءات والمؤشرات على شكل بدائل؟

تعليق عام هو أنه لكل سطر من التعليمات البرمجية المضافة إلى النظام ، هناك أكثر من 3 فرص لإضافة رمز عربات التي تجرها الدواب. يوجد بالفعل الكثير من الأخطاء في نماذج Xamarin التي تحتاج إلى إصلاح. يعني المزيد من الكود أن فرص إضافة الأخطاء تزداد بشكل كبير. سيكون هناك المزيد من الأخطاء. أشعر أن فريق XF يجب أن يعمل على تقليل حجم قاعدة الشفرة بدلاً من زيادتها. إن تقليل قاعدة الشفرة هو الطريقة الوحيدة لتقليل احتمالية حدوث أخطاء.

لماذا اختراع شيئًا جديدًا مرة أخرى بدلاً من إصلاح الأخطاء الموجودة والتأكد أولاً من أن كل شيء صلب؟

بالنسبة لي ، لقد تم التطرق إليه ولكن التنقل هو أكبر حجر عثرة في نماذج Xamarin وقد تسبب لي في حزن شديد خلال السنوات الثلاث الماضية.

التنقل غير متسق عبر جميع الأنظمة الأساسية الثلاثة مع نمط MasterDetail مما تسبب في العديد من المشكلات مع الهامبرغر الذي يجبرك على دفع الصفحات المشروط ، ثم يتعين عليك تنفيذ شريط تنقل مخصص حيث لا يمكنك الإضافة مرة أخرى ولكن الرسوم المتحركة تبدو مروعة على Android (حتى في MD).

• من الناحية المثالية ، يجب أن تكون قادرًا على إلغاء الاشتراك وتجاوز محتوى شريط التنقل باستخدام ContentView الخاص بك في كثير من الحالات. تم طرح PlatformSpecifics في الأصل كشيء كان من شأنه أن يسمح بوضع عناصر شريط الأدوات (في طريق العودة عندما كنت أتحدث إلى Bryan) ولكن اتضح أنه شيء محدود الاستخدام.

• القدرة على تجاوز عناصر الإطار مثل الرسوم المتحركة المنبثقة في الصفحة

يبدو أن الكثير مما هو مقترح مفيد للغاية ، طالما أنه يمكنك فقط استخدام غلاف مادية في صفحات معينة وليس تطبيقًا واسعًا ، فستكون الشفرة مفيدة حقًا. إنه بالتأكيد شيء سنستخدمه لأنني في الوقت الحالي ما زلت أقول "إنه تقييد لنماذج Xamarin" لرجل UX لدينا كثيرًا (كما فعلت في دوري السابق). أجرؤ على قول ذلك ، يجب أن نحصل على التعليقات من منظور UX الذي صمم تطبيقات النماذج مسبقًا. يجب أن يكون الاشتراك مثل XamlC.

لست متأكدًا من الاسم رغم ذلك ، فإن FlexShell سيكون أكثر منطقية ... لكن لدينا الآن Flexbox (على الرغم من أننا لم نطلبها أبدًا ... آسف ديفيد ، لم أستطع مساعدة نفسي 😄)

أيضا ، هل هذا يعني أن الموضوعات ميتة نوعًا ما؟ لم تستخدمها على أي حال.

تضمين التغريدة

إنه بالتأكيد شيء سنستخدمه لأنني في الوقت الحالي ما زلت أقول "إنه تقييد لنماذج Xamarin" لرجل UX لدينا كثيرًا (كما فعلت في دوري السابق).

حسنًا ، ولكن ، أليس من المنطقي إصلاح أو تحسين التطبيق الحالي بدلاً من إنشاء تطبيق جديد تمامًا ، والذي سيأتي مع الأخطاء والقيود أيضًا؟ تقول هناك ما يلي:

MaterialShell هي واجهة برمجة تطبيقات برأي في بعض النقاط "

على محمل الجد ، في كم عدد الاتجاهات المختلفة التي يمكن أن تذهب نماذج Xamarin؟ فريق XF بالكاد قادر على متابعة إصلاح تطبيق XF الحالي على الأقل لنظامي Android و iOS ، والآن هذا؟ ماذا عن إصلاح الخلل وإصلاح معاينة XAML وماذا عن الأداء؟

كان هناك \ تذكرة فتحها شخص ما مع اقتراح لإضافة دعم بسيط ولكنه مفيد للغاية لفرشاة متدرجة ومتداخلة عبر النظام الأساسي ، ولكن رد

تضمين التغريدة

نعم ، لقد كنت أقول أنه في العام الماضي ، هناك غرابة في التنقل تعيق فريق Prism على سبيل المثال ولم يتمكنوا أبدًا من إغلاق المشكلات.

أحاول فقط تقديم ملاحظات بناءة في الوقت الحالي ، ولكن Xamarin Forms تمر بمرحلة حرجة في تطورها ، ويمكن لواجهة برمجة التطبيقات هذه معالجة العديد من نقاط الألم إذا تم تنفيذها بطريقة مرنة وليس نهجًا واسعًا للتطبيق.

jassmith هل يعني هذا أن XF

الناس ، بالأمس أجرينا أنا وجيسون مناقشة حول كيفية تحسين هذه المواصفات وسنقوم بتحديث كبير ، ونقوم بتقسيم هذا إلى مشكلات مختلفة.

أرغب في ترديد بعض المشاعر المذكورة أعلاه: من فضلك دعنا نحسن ما لدينا ، ما لم يكن لديك بالطبع موارد غير محدودة ، ثم نذهب إليها 😉

لا يزال هناك الكثير من الأشياء المهملة: إصلاح ListView (يصعب تصديق أن هذا لا يزال لا يعمل بشكل صحيح) ، وتنفيذ عناصر التحكم مثل CheckBox ، و RadioButton ، وتنفيذ دعم الفرشاة (SolidColorBrush ، GradientBrush) ، والقدرة على عرض نافذة منبثقة على أساس الصفحة أو ContentView ، وإصلاح الأخطاء (راجع الخطأ الأخير الذي تم الإبلاغ عنه حول طرق العرض الشفافة) ، والأداء ، والأدوات ، وغير ذلك الكثير ....

لماذا تريد أن تبدأ شيء جديد ؟؟؟؟؟

TonyHenrique نعم الصور ستكون رائعة. أنا للأسف لست فنانًا ولا أمتلك حقوق الصور التي أستخدمها كمرجع خاص بي. آمل أن يكون لدى بعض أعضاء فريق التصميم الوقت لمساعدتي في إنتاج صور مناسبة للمواصفات.

تضمين التغريدة

• دعم الجهاز اللوحي. الغرض منه هو التأكد من أن التصميم يتكيف مع الأجهزة اللوحية. هذا لن يغطي حالات التخطيط داخل صفحات المحتوى الخاصة بك بالطبع ، سيكون ذلك ميزة مختلفة. إلى حد كبير سوف أتعامل مع ذلك مع VSM الجديد.
• في الغالب مجرد وضع صفحات المحتوى الخاصة بك في المكان المناسب والتكيف مع مفاهيم التنقل الجديدة. لن أقول أنه سيكون دائمًا تافهًا ولكن لا ينبغي أن يكون منهكًا أيضًا.
• بالتأكيد لن يزيل أي ميزات. في الواقع ، أنا أعمل على تحديث المواصفات لتشمل فئة شل الأساسية التي تفتقد بعض ميزات MaterialShell ولكنها بخلاف ذلك إصدار واجهة مستخدم خاص بمنصة من Shell.
• نعم فعلا. تؤدي إضافة رسم إلى تغيير العارض الذي تحصل عليه إلى شيء يعرف كيفية التعامل مع الرسم.
• نعم فعلا. يمكنك تبديل أي جهاز عرض يتم استخدامه في أي مستوى من التسلسل الهرمي. يتم تغيير العارضين فقط من خلال القوالب التي يتم تعيينها بمفاتيح خاصة في قواميس الموارد. يمكنك تغيير هذه القوالب إلى ما تريد أو تعطيلها عن طريق تعيينها فارغة.

ChaseFlorell لا ، لكني منفتح على الاقتراحات إذا كنت تريد إرفاق تعديل بالمواصفات. بالنسبة إلى شيء Shell vs MaterialShell ، فقد تناولت ذلك أعلاه. الخطوة 1 كانت التأكد من أن MaterialShell منطقية ، ثم تقسيمها إلى فئة أساسية هي الخطوة 2.

dylanberry لن تجعل الطبقة الأساسية ذلك أسهل بكثير. انها ليست بسيطة مثل تغيير قوالب الرسم. أعتزم تنفيذ جانب MaterialShell لهذا في رمز خاص بالنظام الأساسي لتحقيق الأداء الأمثل.

ستأتي إيماءات

mackayn a Transitions / Segue API قادم

@ encrypt0r ليس بالضبط. فكر في الأمر على أنه هجين. سيسمح بالعرض ولكن تحت غطاء محرك السيارة ، يتم تصميم جميع عناصر التحكم الخاصة بالمنصة فقط مع رمز الرسم. ومع ذلك ، هناك فتحة هروب إلى Skia يمكن إضافتها بسهولة (على الرغم من أنني أشك في أنها تجعلها في أي مكان بالقرب من الإصدار 1).

opcodewriter ListView2 (من الواضح أنه لن يتم تسميته بالفعل) على خريطة الطريق هذا العام بعد فترة طويلة. لماذا ListView جديد؟ حسنًا ، تؤدي واجهة برمجة التطبيقات الأصلية إلى عدد غير محدود تقريبًا من الأخطاء والمشكلات التي لا يمكننا إصلاحها بفعالية دون كسر التوافق مع الإصدارات السابقة تمامًا. أشياء مثل Cell / ViewCell و ItemsViewو TemplatedItemsList بينما كانا يعملان بشكل جيد بالنسبة لما كانا يقصدانه لـ 1.0 ، إلا أنهما قريبان من القدرة على ما يحتاجانه للاستخدام الحديث لواجهة برمجة التطبيقات.

لسوء الحظ ، لا يمكنني التفكير في أي طريقة لحل هذا الأمر داخل نوع ListView نفسه ، ولا أعتقد أن المجتمع كان قادرًا على ذلك لسوء الحظ. الخيار الأفضل في الوقت الحالي هو الاحتفاظ بـ ListView كما هو ، ومن ثم عمل شيء أكثر أناقة بكثير بأقل تكلفة ، وأقل مسك دفاتر ، وأنواع أقل غرابة لا تحتاج إلى الوجود وتثق في الأطر المستهدفة للقيام بما تفعله بشكل أفضل.

ببساطة إزالة استراتيجية إعادة التدوير القديمة ، والتي ستكون تغييرًا هائلاً لا يمكننا القيام به ، سيؤدي إلى إزالة جزء كبير من Xamarin. ستقربك ListView2 أكثر من المعدن عن طريق إزالة هذه العناصر التي كان من المفترض أن تكون قضبان حماية (أو في حالة Cell ، الدمج غير المقدس لمشروعين داخليين مختلفين) وهي الآن تؤذي الجميع.

تؤثر إستراتيجية التخزين المؤقت القديمة على كل عارض موجود اليوم. هذا هو السبب الذي يجعل كل عارض يدعم تغيير العنصر الخاص به. إذا اختفى ذلك من خلال أفضل تقديري ، فقد اختفى حوالي 10٪ من جميع التعليمات البرمجية في المشروع. إنه بالفعل أكبر سرطان في المشروع.

davidortinau تحصل على تعليقك فقط لأن تنسيقك رائع للغاية!

إذا استخدمت هذا الأسلوب لوصف طلبي في المستوى الأعلى ، فسأحصل على:

• تطبيق ذو مظهر يبدو متماثلًا على كل نظام أساسي
• يتم تشغيل أنماط تصميم المواد (في هذه الحالة) افتراضيًا
• تم تمكين أحدث أنماط التنقل مع التكوين
• لست مضطرًا إلى العمل لتخصيص Entry أو Button ليبدو كما هو على iOS و Android و UWP؟

هل هذا دقيق؟ الفوائد الأخرى التي يجب أن أبرزها؟

نعم هذا صحيح. هناك الكثير من الفوائد الأخرى التي يمكنك تسليط الضوء عليها ولكن يجب أن تصبح واضحة بمجرد أن تبدأ في العبث بها. كما يمكنك عمل الأوراق السفلية ، لديك FAB ، وتنقل باستخدام عناوين URL (لا يزال التحديث قادمًا) وغير ذلك الكثير.

بدلاً من التطبيق لدي MaterialShell. أحتاج إلى تعلم / تبني نموذج تطبيق جديد عالي المستوى للاستفادة من هذا؟

خاطئ. الصفحة الرئيسية لتطبيقاتك هي MaterialShell. لا يزال التطبيق هو جذر التطبيق الخاص بك.

بمجرد أن أصل إلى تطبيقي ، سأعود إلى ContentPage land ، أليس كذلك؟ لكن كل الأزرار والمداخل الخاصة بي مادية وجميلة.

باستثناء ما كنت مخطئًا أعلاه ، نعم هذا صحيح.

هل لا يزال بإمكاني استخدام OnPlatform وما شابه ذلك لتباعد المظهر (أو السلوك) لأكون مختلفًا على منصة أخرى؟

نعم فعلا.

كيف يبدو مسار الترحيل الخاص بي من تطبيق موجود إلى استخدام هذه "shell"؟

انظر إلى حالة النسخ على متجر Google Play ، تخيل وضع جميع صفحات تطبيقاتك الحالية هناك. يستبدل هذا فقط تلك المناطق في تطبيقك حيث تستخدم صفحات Nav / Tab / MD مباشرةً. ليس لها أي تأثير على صفحات المحتوى الخاصة بك.

أقدم تطبيق MaterialShell الجديد ، ووصف كيف أريد أن يكون تطبيقي هيكليًا وشكلًا ، وأقوم بتشغيله فقط لرؤية الجودة الجديدة؟

بنغو

ما هي خياراتي إذا أحببت الشكل الذي يظهر به Flyout أو عناصر القائمة ، لكنني بحاجة إلى تعديلها لتلائم مجموعات المصممين لديّ؟

أنت تتحكم بشكل كامل في الرأس ، وكيف ينهار الرأس ويخفي. أنت تتحكم بشكل كامل في شكل / إحساس كل من "الخلايا" (لن تكون خلايا) في القائمة المنبثقة. أنت تتحكم بشكل كامل في رأس كل مجموعة هناك أيضًا. في الواقع ، يمكنك التحكم في "مظهر" كل شيء ، ومع ذلك ما زلنا بحاجة إلى إضافة مكانين إضافيين لك لوضع محتوى إضافي.

في أي نقطة أقول "آه ، كان يجب أن أقوم بتدوير كل هذا بنفسي" ونقل ما لدي إلى بنية تطبيقات Xamarin.Forms قياسية؟

إذا كان التخطيط الفعلي لمتجر Google Play Store يبدو مختلفًا تمامًا عما تريده. لا تختلف بشكل هامشي ، مختلفة تمامًا.

إذا اضطررت للتخلي عن MaterialShell تمامًا ، فهل أفقد كل جودة التصميم هذه وأعود إلى حيث بدأت (مثل اليوم) بإدخال يبدو مختلفًا تمامًا بين iOS و Android و UWP؟ لا أريد ذلك.

لا تقوم MaterialShell إلا بتعيين بعض الموارد الافتراضية حتى يتمكن أطفالها من الحصول عليها. ستكون قادرًا على القيام بذلك بنفسك. قد تضطر إلى القيام بذلك على أي حال ، فنحن لم نلتزم فعليًا بجعل MaterialShell تفعل ذلك افتراضيًا. إذا جعلناها تختار الاشتراك بدلاً من إلغاء الاشتراك ، فستكون مكالمة واحدة لواجهة برمجة التطبيقات لأي شجرة فرعية.

هناك نقطة تحول أتوقعها. بعد أن استخدمت هذا الأسلوب للمضي قدمًا بسرعة ، سأواجه بعض القيود وأحتاج إلى استكشاف خياراتي. ما هي وفي أي نقطة من الأفضل عدم استخدام MaterialShell؟

النية هي أنك لست أفضل حالًا أبدًا من عدم استخدام شركة شل. قد لا ترغب في مادة ولكن يجب أن ترغب دائمًا في شل (مرة أخرى ، تأتي فئة شل الأساسية). لماذا ا؟ سيكون شكل / إحساس الغلاف أكثر قابلية للتهيئة ، وستكون قصة التنقل أكثر توحيدًا ، ويجب ألا يكون هناك شيء عاقل يمكنك فعله مع الصفحات الأخرى التي لا يمكنك القيام بها باستخدام Shell.

والأفضل من ذلك ، أن الهدف هو التأكد من أن عارضين Shell يتم تكوينهم بسهولة وعقلانية. لا توجد فصول خفية سحرية ، ولا فئات فرعية مخصصة للعرض الأصلي نأخذها على عاتقنا. بقدر الإمكان ، سيتم تكوين كل مكون من عناصر العارضين وقابل للتبديل. بهذه الطريقة إذا لم يعمل بالطريقة التي تريدها ، يمكنك في الواقع إصلاحها ...

لماذا لم نفعل ذلك في البداية؟ لم يكن هدفًا تصميميًا في الأيام الأولى ، ثم انتهى بنا الأمر للتو متزوجين من ذلك ... هذا كبير بما يكفي وجديد بما يكفي بحيث لا يتعين علينا تحمل هذا الخطأ معنا.

تضمين التغريدة

على محمل الجد ، في كم عدد الاتجاهات المختلفة التي يمكن أن تذهب نماذج Xamarin؟ فريق XF بالكاد قادر على متابعة إصلاح تطبيق XF الحالي على الأقل لنظامي Android و iOS ، والآن هذا؟

ماذا عن إصلاح الخلل وإصلاح معاينة XAML وماذا عن الأداء؟

^ ^ هذا

تضمين التغريدة

الناس ، بالأمس أجرينا أنا وجيسون مناقشة حول كيفية تحسين هذه المواصفات وسنقوم بتحديث كبير ، ونقوم بتقسيم هذا إلى مشكلات مختلفة.

ميغيل ، من الواضح أن هذه ستكون مهمة كبيرة. لا يمكنني التحدث نيابة عن جميع المطورين ، لكن يمكنني إخبارك أن فريقي يريد ثلاثة أشياء: الاستقرار والأداء والمرونة. نريد إصلاح الخلل. نريد أن يعمل تطبيقنا بسلاسة ، ونريد أن نكون قادرين على تنفيذ التصميمات التي يقدمها لنا مصممو UI / UX دون الالتفاف والقول "عذرًا ، هذا غير ممكن في نظامنا الأساسي". يبدو أن هذه المواصفات تتعارض مع هذا الهدف. سيتطلب هذا المزيد من الموارد التي يتم إلقاؤها في الوظيفة مما يعني عدم تحرير مواردك للعمل على الاستقرار والأداء والمرونة.

هل سيكون هذا هو السلوك / الطريقة الافتراضية الجديدة للتطوير في أشكال xamarin؟ أو هل لا يزال لدينا خيار لبناء تطبيقاتنا مع شكل وأسلوب معين لكل منصة؟

DanielCauser بينما أظن أن هذا قد يصبح على المدى الطويل الطريقة "الافتراضية" ، لن يحل هذا بأي حال من الأحوال محل الطريقة الحالية. ستكون ببساطة طريقة أكثر تكاملاً وحداثة والتي ستوفر الكثير من القوالب التي يقوم الأشخاص ببنائها يدويًا حاليًا بشكل افتراضي. علاوة على ذلك ، نظرًا لأننا سنوفر الغلاف كعنصر تحكم واحد ، يمكننا تحسين الكثير حول كيفية رسمه وتخطيطه. لم يعد لديك 3 تصاريح رسم لقشرتك فقط.

أنا أؤيد هذه الفكرة بحذر ، بشرط أن التحسينات التي تقترحها تتم عن طريق التحسينات في كود Xamarin Forms الأساسي. إذا كان هذا يضيف المزيد من التعقيد فوق النماذج ، فلن أستخدمها.
بالنسبة لأموالي ، على الرغم من أنني أفضل أن يكون لدي موارد مطورين موجهة نحو جعل النماذج أكثر مرونة وأسرع وانتهاءً مما هي عليه حاليًا. إذا حدث ذلك ، يمكنني تقديم جميع الميزات الجديدة المقترحة هنا لنفسي. من المؤكد تقريبًا أن DIY في هذه الحالة يناسبني وعملائي بشكل أفضل من مجموعة الأدوات العامة المقدمة من Xamarin ، مهما كانت جيدة. مع وجود بعض الاستثناءات البارزة ، لا يحل هذا الاقتراح المشكلات التي أواجهها في الوقت الحالي.

تضمين التغريدة

1. هناك أكثر من 500 إصدار مفتوح.
2. يبلغ عمر Xamarin Forms 3 سنوات ولا تزال هناك أخطاء في عناصر التحكم والوظائف الأساسية ، ولا تزال الميزات المهمة مفقودة ولم يتم تسمير الأداء بشكل كامل حتى الآن (أعلم أنه تم إجراء بعض التحسينات ، ولكن الأداء على Android لا يزال ملحوظًا).
3. لا يزال فريق تطوير نماذج Xamarin صغير الحجم.

لماذا تريد أن تبدأ العمل على هذه الميزة الجديدة بالكامل الآن؟ أليس من المنطقي التركيز على ما سبق أولاً؟

حول تعليقك أعلاه المتعلق بـ ListView: أحيي أي نوع من الجرأة في التعامل معه ، بما في ذلك إعادة التصميم بالكامل \ استبداله. ليس الأمر كما لو كان كل شيء رائعًا في نماذج Xamarin ، فلا يجب المساس / تغيير الأشياء.

تضمين التغريدة

1) نعم هناك. أوافق على أنها مشكلة وستظل عنصر العمل ذي الأولوية الذي أضغط من أجله شخصيًا.

2) يعد الأداء على Android جزءًا من السبب الدافع وراء ذلك. يمنح هذا إطار العمل مزيدًا من وقت التنبيه لانتقالات الصفحة حتى نتمكن من إخفاء أشياء مثل وقت JIT. يمكننا تحميل الصفحات والاحتفاظ بها بشكل استباقي بشكل أكثر ذكاءً. ما لا يستطيع فريق XF إصلاحه هو وقت JIT الإجمالي. إذا قمت بتشغيل تطبيقك على Android مع تمكين AOT وكان أسرع بكثير ، فلا يوجد ما يمكنني فعله لمساعدتك.

3) لا توجد حجج هنا.

لماذا تريد أن تبدأ العمل على هذه الميزة الجديدة بالكامل الآن؟ أليس من المنطقي التركيز على ما سبق أولاً؟

هذا العمل غير مجدول ، نحن فقط نناقش المواصفات هنا. ستقوم إدارتي بجدولة ذلك عندما تشعر أنه مناسب مع نصيحتي.

حول تعليقك أعلاه المتعلق بـ ListView: أحيي أي نوع من الجرأة في التعامل معه ، بما في ذلك إعادة التصميم بالكامل \ استبداله. ليس الأمر كما لو كان كل شيء رائعًا في نماذج Xamarin ، فلا يجب المساس / تغيير الأشياء.

ListView هو حقًا دب حشرة Xamarin.Forms. من بين 500 إصدار ، تم تمييز 220 منها على أنها أخطاء (هناك الكثير من مشكلات التدبير المنزلي أو التحسين أيضًا) ، شمال 25٪ تتعلق فقط بـ ListView. للمقارنة ، هذا هو نفس النسبة تقريبًا التي تتعلق بمنصة UWP بالكامل. الأسوأ من ذلك هو أن عددًا لا بأس به من المتعطلين في Android الذين تم وصفهم أساسًا على أنه يتم استخدام العارض بعد التخلص منه هم أيضًا أخطاء ListView ولكن من غير المحتمل أن تظهر في بحثي نظرًا لأن ListView لن تظهر في أي مكان في استعلام البحث.

jassmith بجانب إصلاح المشكلات الحالية (بجانب ListView ، هناك أشياء أخرى لا تعمل دائمًا بشكل صحيح) ، وهناك أيضًا ميزات مهمة تم استبعادها (ترتيب عشوائي):
- دعم منبثق حقيقي (الميزة الأساسية والعامة لا تزال مفقودة)
- إلغاء التنقل في الصفحة عند الرجوع للخلف (مشكلة معلقة منذ فترة طويلة)
- الضوابط الأساسية مفقودة (لا يوجد CheckBox و RadioButton والمزيد)
- رسم عبر منصة (تحكم قماش أو بطريقة أخرى)
- دعم الرسم المتقاطع للفرش الصلبة / المتدرجة (SolidColorBrush ، GradientBrush)

أتمنى أن يتم إنجاز المزيد من العمل في اتجاه جعل إطار العمل أكثر ثراءً حقًا ، وعدم إضافة أشياء مثل نمط CSS أو Flexbox (الذي جاء مع مشكلاتهم الخاصة).

تضمين التغريدة

دعم منبثق حقيقي (الميزة الأساسية والعامة لا تزال مفقودة)

عادل ، لا يبدو أبدًا أنه يتم منحه أولوية عالية بما يكفي ليصبح حقيقيًا. لقد حصل هذا في الواقع بعيدًا جدًا في مرحلة ما.

إلغاء التنقل في الصفحة عند الرجوع للخلف (مشكلة معلقة منذ فترة طويلة)

هذا في الواقع شيء يهدف MaterialShell إلى معالجته. هناك أسباب قوية جدًا لا يمكن القيام بذلك في NavigationPage.

عناصر التحكم الأساسية مفقودة (لا يوجد CheckBox و RadioButton والمزيد)

بعضها جزء من مبادرة F100 الجارية الآن.

رسم عبر منصة (التحكم في قماش أو بطريقة أخرى)

سيكون هذا هو API الشقيق لهذا كما هو محدد في # 2452

دعم الرسم المتقاطع للفرش الصلبة / المتدرجة (SolidColorBrush ، GradientBrush)

نفس الإجابة على النحو الوارد أعلاه.

تضمين التغريدة

عادل ، لا يبدو أبدًا أنه يتم منحه أولوية عالية بما يكفي ليصبح حقيقيًا. لقد حصل هذا في الواقع بعيدًا جدًا في مرحلة ما.

حسنًا ، أتطلع إلى منحها الأولوية بحلول نهاية عام 2018 :)

هذا في الواقع شيء يهدف MaterialShell إلى معالجته. هناك أسباب قوية جدًا لا يمكن القيام بذلك في NavigationPage.

هل يمكنك إعطاء مزيد من التفاصيل من فضلك لماذا لا يمكن القيام بذلك في التنفيذ الحالي؟

بعضها جزء من مبادرة F100 الجارية الآن.

أرى. تشابك الاصابع..

هل يمكنك إعطاء مزيد من التفاصيل من فضلك لماذا لا يمكن القيام بذلك في التنفيذ الحالي؟

لن أخوض في هذا أكثر هنا لأننا خرجنا عن المسار بشكل كبير ولكن الجوهر هو كما يلي:

• لا يمكنك إلغاء إيماءة السحب الخلفي في iOS بشكل تفاعلي. نظرًا لأن هذه هي الطريقة الأساسية التي يستخدمها الأشخاص للتنقل مرة أخرى مع الهواتف الأكبر حجمًا ، يصبح هذا إغفالًا صارخًا.
• في حين أنه من الممكن تقنيًا تجاوز هذا السلوك في iOS ، إلا أنه يتطلب التعمق إلى حد ما في الأجزاء الداخلية لـ UINavigationController بطريقة لا يمكننا التأكد من دعمها أو عملها بالفعل عند إصدار إصدار جديد من iOS. باختصار ، لا يبدو أن Apple تستمتع كثيرًا بالناس الذين يقومون بذلك.

هناك بعض المخاوف الثانوية الأخرى هناك أيضًا فيما يتعلق بكيفية تأثيره على التصميم. هذه هي القصة الطويلة باختصار. إذا كنت لا تزال ترغب في مناقشة هذه الميزة المحددة ، أقترح فتح عدد جديد :)

تضمين التغريدة
اعتقدت أن مجرد التعامل مع gestureRecognizerShouldBegin والاتصال بشيء مثل OnBackButtonPressed يجب أن يكون كافيًا.

بشكل عام ، أحب كثيرًا ما أقرأه ، ولكن هذا لا يبدو أنه شيء يجب القيام به في نماذج Xamarin Forms nuget / repo الأساسية.

هذا نهج عنيد يجب أن يتم بناؤه فوق نماذج Xamarin ، وليس مضمّنًا فيه. أرى هذا كمكتبة منفصلة تمكن المطورين من اتباع نهج مختلف. يجب أن تكون الأجزاء المطلوبة من نماذج Xamarin التي يجب كشفها ، ويجب أن يتم بناء ذلك فوق تلك البتات.

تمامًا كما هو الحال عندما يتخذ المطورون قرارًا باستخدام Xamarin Classic / Native أو Xamarin Forms ، يمكنني رؤية قرار مماثل لاستخدام Xamarin Forms أو Xamarin Forms with a Shell.

يجب أن تركز نماذج Xamarin على إنشاء أفضل إطار عمل لواجهة المستخدم عبر الأنظمة الأساسية دون محاولة مطابقة الأنظمة الأساسية لتبدو مثل بعضها البعض. تقوم نماذج Xamarin اليوم بعمل رائع للتأكد من احترام النظام الأساسي.

كان بإمكاني أن أرى قاعدة شل موجودة في Xamarin Forms repo وبعض التعليمات البرمجية حول التعامل مع الأصداف ، ولكن يبدو أن Material Shell مرتبطة بإحكام شديد بلغة تصميم ونمط تنقل معين بالنسبة لي لأعتقد أنه يجب أن يكون في Xamarin Forms repo.

تضمين التغريدة
شكرا لك على ملاحظاتك. لم يتم تحديد الموضع الدقيق لمساحة سطح API العامة بعد. هناك إيجابيات وسلبيات لكلا النهجين.

سيتم تحديث المواصفات (نأمل قريبًا جدًا) للحصول على كل من فئة Shell و MaterialShell. ستكون فئة MaterialShell هي الجزء الذي نعتبره الخروج من المركز. ستكون شل ما وصفته.

تم التحديث مع تحديث مواصفات الاختراق والملاحة في Shell

أرغب حقًا إذا تم تنفيذ تطبيق XF الحالي ... أقوى وأفضل لتمكين شيء مثل هذا من الوجود كملحق ، وليس كجزء من BCL. لذا فإن امتلاك نظام أساسي قوي وصحيح ومستقر سيفيد التطبيقات الحالية وأي طبقات جديدة مثل هذه.

نتطلع إلى تطور هذا الشيء.

تضمين التغريدة

فقط بعض الملاحظات.

• BackButtonBehavior ، بالتأكيد يجب أن تكون هناك خاصية رؤية في حال كنت لا تريدها على الإطلاق؟
• مخطط التنقل المادي مثل Prism ، هل سيعمل مع هذه الأطر الحالية؟ (المنشور ، FreshMVVM ، MVVMCross)
• هل يمكنك تجاوز التخطيط بالكامل في شريط التنقل؟ كما هو الحال ، فإن النماذج محدودة للغاية في هذا الصدد ، وينتهي بك الأمر بأشرطة تنقل ذات مظهر عتيق تجبرك على السير في مسار Customrenderer ، مع العلم أن إصدارًا جديدًا من النماذج سيؤدي على الأرجح إلى كسر التعليمات البرمجية المخصصة الخاصة بك.
• لم يتم التطرق إلى MasterDetail كثيرًا ، فهل ستتمكن من تخصيص القائمة المنبثقة؟
• ما هي السيطرة التي ستكون لدينا على الهامبرغر؟

أريد فقط أن أتأكد من معالجة نقاط الألم والقيود الموجودة بالإضافة إلى القدرات الجديدة ذات القدرات الجديدة.

يبدو عظيما.

أنا جديد جدًا على XF ولكن إطار العمل له سمعة طيبة لكونه هشًا إلى حد ما ، على الرغم من أن هذا بالتأكيد يتحسن بسرعة بفضل جهودك.

إذن لما يستحق ، هذا رأيي :-)

إنه لأمر رائع أن يحصل Xamarin على الكثير من الحب في الوقت الحالي ، لكنني أتفق مع opcodewriter ، يمكن

تعجبني أيضًا الأفكار من MisterJimson بأن هذه يجب أن تكون طبقة مختلفة - لكن يجب أن تكون صادقًا مع أنفسكم بشأن قدرتك وعدد الأطر التي يمكنك دعمها. نحن جميعًا نميل إلى ترميز أشياء جديدة ولامعة ومثيرة ، وتجنب القرارات الصعبة ، لكننا نعتمد عليك لتطوير أساس متين لشفرتنا البرمجية.

لدي مشاكل كافية في تشغيل الكود الخاص بي دون القلق بشأن :-) شخص آخر

XF في مكان جيد في الوقت الحالي ، لديها القدرة على أن تصبح مجموعة أدوات قوية حقًا.

شكرا على كل ما تبذلونه من العمل الشاق في هذا ، وهذا واضح.

تضمين التغريدة

BackButtonBehavior ، بالتأكيد يجب أن تكون هناك خاصية رؤية في حال كنت لا تريدها على الإطلاق؟

قم بتعيين الأمر باستخدام CanExecute إرجاع false. اخترت عدم إضافة طريقة ثانوية في الوقت الحالي.

مخطط التنقل المادي مثل Prism ، هل سيعمل مع هذه الأطر الحالية؟ (المنشور ، FreshMVVM ، MVVMCross)

أنا متأكد من آمل ذلك! لا أستطيع أن أكون متأكداً لكني كنت أفكر فيهم وبكل مشاكلهم. هذا هو السبب في أن كل التنقل يحدث من خلال حدث واحد على سبيل المثال.

هل يمكنك تجاوز التخطيط بالكامل في شريط التنقل؟ كما هو الحال ، فإن النماذج محدودة للغاية في هذا الصدد ، وينتهي بك الأمر بأشرطة تنقل ذات مظهر عتيق تجبرك على السير في مسار Customrenderer ، مع العلم أن إصدارًا جديدًا من النماذج سيؤدي على الأرجح إلى كسر التعليمات البرمجية المخصصة الخاصة بك.

هذا الجزء أصعب. أود أن أسمح بأكبر قدر ممكن من القابلية للتوسع هنا قدر الإمكان ، لكنني منفتح حقًا على الاقتراحات حول كيفية تحسين ذلك بطريقة عاقلة ومعقولة.

لم يتم التطرق إلى MasterDetail كثيرًا ، فهل ستتمكن من تخصيص القائمة المنبثقة؟

يمكنك ضبط الرأس على أي طريقة عرض عشوائية ، ويمكنك التحكم في القالب المستخدم لرؤوس وعناصر المجموعة ، ويمكنك إضافة عناصر قائمة. يمكنك التحكم في بعض جوانب التخطيط ولكن ليس بنسبة 100٪. مرة أخرى ، سيكون من الجيد الحصول على بعض الأفكار حول ما تعتقد أنك بحاجة إليه. أرى بوضوح الحاجة إلى تذييل مع خاصية سلوك التذييل.

ما هي السيطرة التي ستكون لدينا على الهامبرغر؟

يتجاوز BackButtonBehavior أيضًا الهامبرغر. ربما يجب إعادة تسميته. مرة أخرى أنا منفتح على الاقتراحات هنا. في الأصل أسميته LeftBarButton ، لكن في حالات RTL ليس على اليسار ...

stevehurcombe المردود الفني مستمر ومستمر. سيتم تشغيل هذا بالتوازي من قبل وحدة أصغر بكثير من الفريق. لسوء الحظ ، فإن الكثير من هذه المواصفات تدور حول المردود الفني بطريقة غريبة. تكبدت Xamarin.Forms مبلغًا ضخمًا من ديون API مع إصدار 1.0 ، وتحمل هذا الدين منذ ذلك الحين. بعض الأشياء في XF من الصعب جدًا جعل العمل صحيحًا ، أو حتى من المستحيل جعل العمل صحيحًا ، وذلك ببساطة بسبب الطريقة التي تعبر بها واجهة برمجة التطبيقات (API) عنها.

تعد التفاعلات الضيقة بين tabbar و navbar إحدى هذه المناطق ، مع التأكد من أن التنقل بين علامات التبويب أو العناصر في MDP خالٍ من الأخطاء. هناك العديد من المجالات التي ستحدث فيها أخطاء طفيفة لأن كل عنصر غير قادر على إلقاء نظرة شاملة على غلاف تطبيقك.

بالنسبة للأدوات ، هناك فريق منفصل تمامًا مخصص لذلك ويقومون بخطوات كبيرة. لقد تحسنت الأدوات الداخلية بشكل كبير في الأشهر الستة الماضية وأنا أتطلع حقًا إلى تجربة ذلك!

تضمين التغريدة

مخطط التنقل المادي مثل Prism ، هل سيعمل مع هذه الأطر الحالية؟ (المنشور ، FreshMVVM ، MVVMCross)

لا تخف ، فقد

تضمين التغريدة

من الجيد معرفة أن كلا الفريقين في حوار ، هذا كل ما أريد معرفته 👍

jassmith من الواضح الآن أن الطريقة التي تعمل بها بعض الأشياء أو تمت هندستها في XF ليست هي الأفضل. لذا بدلاً من وضع أحمر الشفاه على الخنزير (لا تريد أن تكون وقحًا هنا) ، فلماذا لا تعيد إنشاء إطار عمل جديد من الصفر أو تعيد تشكيل الإطار الحالي بشكل كبير. أعلم أن الأمر يبدو مخيفًا للغاية ، لكنني متأكد تمامًا من أن الغالبية العظمى من مطوري Xamarin Forms لن يمانعوا ، فجميعنا سيكون متحمسون لإعادة تشكيل تطبيقاتنا أو أي شيء آخر حتى يكون لدينا تطبيقات تعمل بشكل أفضل.
لقد رأيت رفض العلاقات العامة مع إعادة هيكلة جيدة لأننا "لا نريد هذا النوع من التغييرات". لست متأكدًا من الذي وضع هذه القاعدة ، لكن يجب أن يأخذ نفسًا عميقًا ، ويستريح وربما يعيد النظر في "القاعدة".
ما هو الأفضل: استمر في إصابتك بالمطورين المحبطين باستخدام إطار عمل لا يمكنه مواكبة ذلك أو وجود مطورين محبطين يحتاجون إلى القيام ببعض أعمال إعادة البناء؟ فقط سنتان ...

opcodewriter أنت وأنا أوافق ولكن هذا خارج الموضوع لهذه المواصفات.

ما عليك سوى قراءة المادة الجديدة حول التنقل وأحبها حقًا. أحب الحصول على يد فرز لأوامر التنقل الملزمة ، وتوجيه التنقل حول عناوين URL (مثل وأعتقد أنه متأثر بـ Prism) أمر ذكي.

من المفارقات أن مخطط التنقل في URI كان شيئًا أردنا القيام به في طريق العودة في اليوم وبدأنا في دفع Prism للتنفيذ لأننا لم نتمكن من إدخاله بشكل معقول في إطار العمل. حتى لا يأخذوا أيًا من رصيدهم ، فهم يستحقون 100٪ من ذلك :)

لا تزال الدلالات الدقيقة للاختزال متاحة.

أعتقد أنه من المحتمل أن ينتهي به الأمر مثل:

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

أو

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

لذلك يمكن أن تكون الإضافات أكثر دقة بشأن المعلمات التي تتخذها. يتم استخدام مساحة الاسم في الغالب للحفاظ على سهولة اكتشاف الأشياء مع التحسس.

jassmith أنا حقًا أحب أن هذه الأشياء segue. هل يمكنني أن أسأل كيف تنوي دعم نموذج الدفع؟

ليس لدي كل التفاصيل ، لكن يمكنني تخيل التنقل في عنوان url تمامًا مثل المنشور ، ملفوفًا في امتدادات الترميز.

<!-- 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" />

أول شيء يجب ملاحظته هو أن التنقل عبر URI سيعمل فقط مع Shell. إنه المكان الوحيد الذي يمكننا من خلاله فهم المكدس باستمرار دون وجود حالات حافة غريبة ويمكننا تصميم تفاعلات التنقل لدعم المفهوم.

في الوقت الحالي نحن ندعم عناوين URL الكاملة فقط. يصعب التعامل مع الأجزاء الجزئية لأنها سياقية.

ستكون الأمثلة الثلاثة الخاصة بك ، على افتراض أن الموقع الحالي هو: app: // Shell / Apps / Games / Details

يعني هذا على وجه الخصوص أنك في Shell ، حيث يحتوي ShellItem الحالي على مسار التطبيقات ، والذي يحتوي ShellTabItem الحالي على مسار الألعاب ، والذي تم دفع ContentPage إلى مجموعته التي تحتوي على تفاصيل المسار.

<!-- 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" />

في قذيفة uri ، يكون الموقع الأول دائمًا هو شل. إذا لم يكن الأمر كذلك ، فمن المفترض أن يكون دفعًا مشروطًا. التالي هو ShellTab ، ثم ShellTabItem. بعد ذلك يتبع حزمة التنقل في ShellTabItem. ليس لدي أي نية لنقل التنقل عبر URI إلى جميع عناصر التحكم في الصفحة الممكنة في الوقت الحالي. هذا يصبح مشعرًا حقًا مع الأشخاص الذين يستخدمون MasterDetailPage ...

مع تسجيل المسار وخصائص المسار ، ليست هناك حاجة للتوجيه المستند إلى النوع. سأقوم بإزالته من المواصفات.

jassmith يعطي مزيدًا من التفكير في عناصر التنقل هذه ، ولدي بعض الأسئلة

1. كيف يمكنك التعامل مع CanExecute
2. كيف يمكنك منح المستخدم التحكم في (منع القراءة) عدة صنابير؟
3. كيف تتعامل مع التنقل النسبي؟ IE لديك 3 صفحات بعمق وتحتاج إلى الانتقال إلى الصفحة السابقة ، لكن المكدس ديناميكي بالكامل؟
4. يحتوي المنشور على هذه الفكرة الرائعة وهي NavigationParameters حيث يمكننا ليس فقط تمرير القيم الأساسية عبر سلسلة الاستعلام /Navigation/MyPage/MyPageDetails?id=33 ، ولكن أيضًا عبر الكائنات المعقدة new NavigationParameters {{nameof(MyObject), MyObject}} . هل تخطط لدعم شيء مشابه؟

تضمين التغريدة

1) مع شرائح؟ لا يمكنك حاليا. بالتأكيد يحتاج إلى التفكير في المزيد. هناك طريقة لعمل أمر segue لكنها ... سيئة. سيسمح لك ذلك بالتعامل معها ولكن في هذه المرحلة لا يستحق كل هذا العناء حقًا.

2) سوف يقوم Segue بتعطيل نفسه حتى يكتمل الدفع. محاولات أخرى لتنشيط الأمر no-op حتى تكتمل مهمة التنقل السابقة.

3) يمكنك استخدام التنقل التقليدي مثل الضغط / البوب ​​مع المقاطع. هذه إجراءات نسبية.

4) [QueryParameterAttribute] قد يكون موجودًا أو غير موجود بالفعل ، لا يمكنني التأكيد أو الرفض. ؛)

من غير المحتمل أن نضيف دعمًا للأشياء المعقدة. الفكرة هي أنك تستخدم المحولات لأخذ قيمك البسيطة وتحويلها إلى كائنات معقدة.

من التجربة السابقة في إنشاء التنقل في التطبيق المستند إلى URI (مرة أخرى في CAB-Composite UI Application Block لـ p & p) ، أقترح بشدة ألا تستخدم النوع System.Uri وبدلاً من ذلك اجعل كل شيء يبدو مثل URI ، ولكن لا تستخدم تطبيق URI نفسه. pprovost يمكن أن يشهد على الندوب التي تدوم مدى الحياة التي تركها العمل فيه. أتذكر أنني واجهت مشكلات لا حصر لها عندما واجهنا قيود وأخطاء URI على الإنترنت (أي على أسماء المضيفين) التي لم نكن نهتم بها كثيرًا بالأشياء داخل التطبيق.

أعتقد أن جزءًا من الضرر الذي حدث بالفعل .

في الواقع ، يعد System.Uri هو الخيار الأفضل عند دعم مخطط التنقل المستند إلى URI. في حين أن CAB استخدمت التنقل عبر URI ، فقد فعلت أيضًا كما قلت وجعلتها "تبدو مثل" URI من خلال السماح لك باستخدام سلاسل بدلاً من كائن System.Uri. لم تكن أسماء المضيف مطلوبة أبدًا.

ما تطلبه هو واجهة برمجة تطبيقات مبنية على سلسلة فضفاضة للغاية والتي يمكن أن تقبل أي بناء جملة جملة تضعه فيه ، وهو ليس شيئًا ينتج عنه نتائج يمكن التنبؤ بها. يجب أن تكون هناك قواعد معمول بها لكي يعمل مخطط التنقل المستند إلى URI / السلسلة.

لن يعمل URI التعسفي في XF أيضًا. قائمة الأحرف غير الصالحة في عنوان URL ولكنها صالحة في نظام الملفات ليست صغيرة تمامًا. هذه هي جميع الحالات التي تعمل فيها سلسلة ، ولن يحتاج URI وسيحتاج إما إلى الهروب أو جعل المستخدم يكتشف سبب عدم عمل الأشياء (أو فشلها؟) وإعادة تسمية الأشياء لتكون "آمنة URI".

يمكنك يشكلون التجريد الخاصة بك إذا كنت تريد أكثر تقييدا (أو أفضل دلالات / توزيع / التحقق من صحة؟)، ولكن IMHO، System.Uri يجلب الكثير من الأمتعة الانترنت ليست مجانا. هذا هو مماثل لكيفية خلق مونو / مونو ديفيلوب الخاص أسم دليل لتمثيل المسارات، والتي عادة ما تكون سلاسل عادلة.

على الأقل ، يبدو أن جميع URIs تعتبر نسبية ، مما يبسط الأمور. في CAB ، استخدمنا uris المطلق مع أجزاء المخطط واسم المضيف أيضًا ، وهو ما كان يمثل مشكلة.

أفضل شيء مثل ResoucePath ، على سبيل المثال ، من Uri . لكن في هذه اللحظة المتأخرة من المباراة ، أنا متأكد من أنها قد تمت الصفقة على أي حال.

لست متأكدًا مما تعتقد أن مسارات نظام الملفات لها علاقة بأي شيء ...

كيف تستخدم URI للتشويش على النظام؟ سوف يتجاهل المخطط واسم المضيف ويبدأ في البحث عن المسارات (التي تقتصر على [az] فقط). إذا لم يتم العثور على أي شخصيات غريبة تضعها ، فإنه يتوقف فقط. ويجب أن تكون سلسلة الاستعلام التي أدخلتها معرّفات C # صالحة أو لن تتم مطابقتها ببساطة. لن يتم إلغاء البيانات التي تم تجاوزها في بيانات سلسلة الاستعلام.

يعملkzu URI بشكل جيد في XF ، وهو مناسب بشكل أفضل لـ XF من مخطط نظام الملفات. في الواقع ، من المتوقع وجود URI عند تشغيل تطبيقك من موقع ويب. يجب عليك التحقق من مدى قوة التنقل المستند إلى URI من خلال النظر في تطبيق Prism. من بين جميع التطبيقات التي تم إنشاؤها باستخدام Prism باستخدام نظام تنقل قائم على URI ، لم يتم إرسال أي مشكلة تتعلق بأحرف غير صالحة. أنا واثق من أن مخاوفك بشأن المخطط المستند إلى URI لمنصة XF لن يمثل مشكلة.

من المنطقي. شكرًا للمعلومات الأساسية حول Prismbrianlagunas! الآن يجب أن أقرأ المواصفات بعناية وأن أقدم بعض التعليقات المفيدة بالفعل ؛)

مبادرة جيدة جدًا ، لكنني آمل أن يتم أخذ التوسعة والتخصيص في الاعتبار من خلال إنشاء الأساليب الافتراضية المناسبة أو طرق أخرى للقيام بأشياءنا "الخاصة" لعملائنا.

على سبيل المثال ، هل سيكون من الممكن / كيف يمكن:

1. قابلية توسيع علامات التبويب على سبيل المثال إظهار شارة بها رمز. أو إظهار درج منبثق فوق أحد الأزرار مثل زر "المزيد" أو " * ".
2. شريط الوجبات الخفيفة المخصص (على سبيل المثال مع الزر "تراجع" لإجراء قمت به للتو باستخدام ألوان خلفية / مقدمة مخصصة)
3. جزء يدفع في Android باستخدام رسوم متحركة مختلفة عن الرسوم الافتراضية المبرمجة في Shell ، مثل عدم وجود رسوم متحركة لتوفير أسرع تنقل ممكن.

في ملاحظة فنية: هل ستقوم shell بإعادة تدوير الصفحات بحيث يتم إعادة استخدام العناصر الأصلية مرة واحدة مع جهاز افتراضي مختلف تحتها بمجرد التنقل مرتين إلى الصفحة؟

مرحبًا rogihee

أرحب بتعليقاتك على التنفيذ. أعتقد أنه قابل للتوسيع بشكل مجنون: https://github.com/xamarin/Xamarin.Forms/blob/9558f2837280e02b41848d3a3c3213d49a664751/Xamarin.Forms.Platform.iOS/Renderers/ShellRenderer.cs

لا يزال Android قيد التطوير المكثف في الوقت الحالي ، ولكنه يستخدم نهجًا متطابقًا.

rogihee فيما يتعلق

تبدو جيدة هذه الخيارات "إنشاء *". من الجيد أن نرى التقدم السريع في هذا الأمر!

أتساءل عما إذا كانت هناك أي آثار على الأداء مع إعادة استخدام العناصر. أنا شخصياً سأعطي الأولوية للسرعة والشعور "السائل" للتطبيق على استخدام Mem / CPU أعلى (على الرغم من وجود ارتباط في مكان ما في نهاية الدورة التدريبية). وامنح الأولوية لنظام التشغيل iOS / Android على أي شيء آخر :-).

تركز شل كثيرًا على إدراك السيولة. انها ليست في مكانها بعد في كل مكان ولكن تتضافر.

أحتاج حقًا إلى الحصول على بعض المستخدمين الأوائل الذين يحاولون القيام بأشياء مجنونة باستخدام shell للتأكد من قدرته على التعامل مع الحمل المصمم من أجله.

jassmith mig ميج الذي تم ذكره للتو لمدة 3 دقائق في البناء .....

أنا لست أبيه

+1

واجهة برمجة التطبيقات المحدثة لتتناسب مع الوضع الحالي للعالم ، لا تزال بحاجة إلى تحديث العينات.

تمت إضافة بعض العينات المحدثة ، وما زلت بحاجة إلى القيام بالكثير من العمل لإصلاح العينات الأخرى وتحديث أوصاف المسارات عند استخدام صيغة الاختزال (كلما حصلت على طرق مختصرة!)

يا إلهي ، أشعر بالتأخر في الحفلة. كتابة ومناقشة رائعة. لقد بحثت في كل ذلك (آسف في المطار) ولدي اقتراح خاص بي. آسف إذا تم ذكر هذا في مكان آخر.

jassmithmigueldeicaza هل يمكنك من فضلك من فضلك إضافة السلوك إلى شريط التنقل بحيث يمكن تمريره قبالة عندما يكون ListView هو التمرير ويظهر عندما يكون تمريره في الاتجاه المعاكس. يقوم أي تطبيق احترافي تقريبًا بهذا لإظهار المزيد من العقارات. سيكون هذا مفيدًا بشكل خاص على الأجهزة الصغيرة.

سبب آخر هو لماذا لا تعيد تسمية علامات XAML حتى يسهل فهمها؟ ربما تستخدم Tab بدلاً من ShellSection؟ هناك الكثير من علامات ShellX الآن.

بالنسبة لنظام iOS ، أعتقد أن هناك خاصية للتشغيل / الإيقاف لتمكين وضع التمرير على شريط التنقل. بالنسبة لنظام التشغيل Android ، تحتاج إلى البدء في استخدام التنسيقات الجديدة (CoordinatorLayout ، AppBarLayout ، إلخ). يعد تطبيق XF لنظام Android قديمًا تمامًا في هذا الصدد لأنه لا يزال يستخدم RelativeLayout كحاوية رئيسية. أعتقد أن هناك بطاقة تحسين في مكان ما حول هذه المشكلة المحددة. أرغب في رؤية شل تدعم أوضاع التمرير المختلفة.

أيضًا ، غالبًا ما يتعين علينا تنفيذ سلوك مخصص لإظهار الأخطاء / أنواع أخرى من النوافذ المنبثقة على الصفحة. يجب أن تدعم شركة شل هذه الوظيفة خارج الصندوق حتى لا نحتاج إلى اللجوء إلى المكونات الإضافية لجهات خارجية أو إنشاء تسلسل هرمي معقد لواجهة المستخدم.

@ adrianknight89

هل يمكنك من فضلك إضافة سلوك إلى شريط التنقل بحيث يمكن تمريره بعيدًا عند تمرير ListView وعرضه عند التمرير في الاتجاه المعاكس. يقوم أي تطبيق احترافي تقريبًا بهذا لإظهار المزيد من العقارات. سيكون هذا مفيدًا بشكل خاص على الأجهزة الصغيرة.

هذا شيء أحاول حقًا اكتشاف الطريقة الصحيحة للقيام به. لسوء الحظ ، لا تدعم جميع المنصات هذه الميزة ، لذا من المحتمل أن ينتهي بها الأمر إلى أن تكون صفقة خاصة بالمنصة. تم إنشاء Android على الأقل لدعم ذلك ، أقوم بتشغيله من حين لآخر للتأكد من أنه لا يزال يعمل.

سبب آخر هو لماذا لا تعيد تسمية علامات XAML حتى يسهل فهمها؟ ربما تستخدم Tab بدلاً من ShellSection؟ هناك الكثير من علامات ShellX الآن.

التسمية هنا صعبة حقًا. يعد ShellTab محيرًا بعض الشيء في الجزء العلوي مقابل الأسفل. بدلاً من ذلك ، اخترت أسماء هرمية أكثر عمومية ، ولكن لا بد لي من الاعتراف بأنني لست سعيدًا بالتسمية. نرحب بالاقتراحات بنسبة 100٪ ... لا يتطلعون بالكامل إلى إعادة هيكلة أسمائهم مرة أخرى ولكن ما الذي يمكنك فعله ...

بالنسبة لنظام iOS ، أعتقد أن هناك خاصية للتشغيل / الإيقاف لتمكين وضع التمرير على شريط التنقل. بالنسبة لنظام التشغيل Android ، تحتاج إلى البدء في استخدام التنسيقات الجديدة (CoordinatorLayout ، AppBarLayout ، إلخ). يعد تطبيق XF لنظام Android قديمًا تمامًا في هذا الصدد لأنه لا يزال يستخدم RelativeLayout كحاوية رئيسية. أعتقد أن هناك بطاقة تحسين في مكان ما حول هذه المشكلة المحددة. أرغب في رؤية شل تدعم أوضاع التمرير المختلفة.

يستخدم Shell CoordinatorLayout + AppBarLayout ويقوم بشكل أساسي "بتعطيل" دعم التمرير بعيدًا في الوقت الحالي ، إلا أنه يعمل. تمرير iOS سهل التنفيذ أيضًا. للأسف ، لا يدعم نظام NavigationView الخاص بـ UWP هذه الميزة.

أيضًا ، غالبًا ما يتعين علينا تنفيذ سلوك مخصص لإظهار الأخطاء / أنواع أخرى من النوافذ المنبثقة على الصفحة. يجب أن تدعم شركة شل هذه الوظيفة خارج الصندوق حتى لا نحتاج إلى اللجوء إلى المكونات الإضافية لجهات خارجية أو إنشاء تسلسل هرمي معقد لواجهة المستخدم.

أمثلة ، أحتاج أمثلة :)

تضمين التغريدة

أنا أستخدم المكون الإضافي للاتصال James Montemagno للاستماع إلى التغييرات في حالة اتصال البيانات. عندما ينقطع الاتصال بالإنترنت ، من الممارسات الجيدة عرض إشعار ينزلق / يتلاشى للداخل والخارج أو يظل ثابتًا حتى يعود الإنترنت عبر الإنترنت.

على Instagram ، يتم وضع هذا الإشعار أسفل شريط التنقل مباشرة. في Tumblr ، يكون أعلى شريط التنقل السفلي مباشرةً. على YouTube ، من الغريب أنه يوجد أسفل شريط التنقل السفلي. ربما شيء من هذا القبيل يمكن أن يكون جزءًا من شركة شل؟

عنصر التحكم المنبثق المقترح ، على حد علمي ، يتراكب على النافذة الحالية على الرغم من أنه يمكن أن يكون قابلاً للإلغاء. لا يحتاج الإشعار الذي ذكرته للتو والأنواع الأخرى من الإشعارات إلى تراكب النافذة الأصلية (أي الشجرة المرئية الأصلية لا تزال تستجيب للإيماءات) ، لذلك لست متأكدًا مما إذا كان Popup هو الملاءمة المناسبة.

يمكن أن يكون لدى Shell خاصية لنا لتحديد كيف سيبدو هذا العرض (أطلق عليه Notification [View]) بالإضافة إلى موضعه وسلوك حركة الدخول / الخروج. لذلك بشكل أساسي ، يتم تنفيذ الخبز المحمص / شريط الوجبات الخفيفة عبر الأنظمة الأساسية المضمنة في Shell أو INavigation أو أي شيء آخر. لن يتم إجبار هذا على أن يبدو أصليًا لكل منصة ولكن نفس الشيء في الكل.

فيما يتعلق بالحجج التي يتم إجراؤها حول الاستقرار والمرونة وما إلى ذلك ، دون التخلص من العمارة القديمة القادمة من 1.0 ، لا أعتقد أنه من الممكن تحقيق هذه الأشياء. أنا أؤيد بشدة ListView2.

تضمين التغريدة

• هل لديك بطاقة تعزيز لـ ListView الجديد حتى الآن؟
• متى تعتقد أن الإصدار 1.0 سيكون بالخارج؟ أي فرصة يمكننا رؤيتها من قبل EOY؟

أيضًا ، لدي نفس القلق بشأن تقلص حجم الفريق. في الواقع ، لقد طرحت هذا من قبل في الماضي. آمل أن ينمو الفريق بشكل أكبر في المستقبل. 🙏davidortinaumigueldeicaza

jassmith لقد اعتقدت منذ فترة أنه إذا كان لدينا

أنا جميعًا لإضافة هذه الأنواع من إشعارات التوست إلى شل ، فقط أحاول معرفة كيف ينبغي القيام بذلك.

هل يمكنك من فضلك أن تجعل حتى تتمكن من وضع الصفحات بشكل تعسفي في أي مكان تريده داخل التطبيق؟ هذا مهم بشكل خاص على الأجهزة اللوحية / سطح المكتب / أجهزة الكمبيوتر المحمولة (أجهزة الشاشة الكبيرة) ، حيث تريد صفحات متعددة على الشاشة في نفس الوقت ، ولا تريد بالضرورة تنظيمها باستخدام طريقة عرض مقسمة (صفحة التفاصيل الرئيسية). على سبيل المثال ، انظر خرائط جوجل:

لاحظ كيف أن المحتوى "عائم" أعلى الخريطة (بدون عرض مقسم). إذا كنت تريد استخدام أشياء مثل علامات التبويب ، أو التنقل داخل المنطقة العائمة ، فلا يمكنك إنجاز هذا النوع من الأشياء باستخدام نماذج Xamarin ، خارج الصندوق ، بسبب التسلسل الهرمي المحدود للغاية للصفحات (لا يمكن تداخل الصفحة داخل عرض). لقد طورنا بالفعل طريقة العرض المخصصة الخاصة بنا والتي توفر إمكانات مشابهة لـ NavigationPage ولكنها طريقة عرض ، فقط حتى نتمكن من إنجاز هذا النوع من التخطيط ، ولكن كان هناك الكثير من العمل / الشاق للقيام به.

يجب أن يكون من الممكن وضع المحتوى (بما في ذلك الصفحات) في أي مكان تريده داخل التطبيق.

هل يمكنك من فضلك أن تجعل حتى تتمكن من وضع الصفحات بشكل تعسفي في أي مكان تريده داخل التطبيق؟

أنا أشعر بالفضول إلى حد ما jsiemens نظرًا لأن هذا العرض من المحتمل ألا يبدو صحيحًا على الهاتف ، ولكنه يبدو رائعًا على سطح المكتب والكمبيوتر اللوحي. هل يمكنك التوسع في كيفية توقع نجاح ذلك. أخيرًا ، سأميل إلى القول إنك تجلب مفهوم المنطقة إلى نماذج من Wpf. رد فعلي غير العادي هو أنه بينما أحب هذا المفهوم ، فإننا نخاطر بجعل واجهة برمجة تطبيقات ملاحة معقدة بالفعل تتطلب درجة الدكتوراه أو على الأقل مستوى ذكاء عبقري والذي لن يكون أعظم شيء لاعتماده من قبل المستخدم.

dansiegel على الأقل شخصيًا ، ربما أستخدم VSM أو ما يعادله لنقل وضغط عرض التمرير في الأسفل عندما يكون أقل من عتبة إطار عرض معينة (مثل GMaps حاليًا). سيكون من المفيد معرفة كيفية عمل الملاحة وإدارة الدولة من أجل ذلك بالرغم من ذلك.

التنقل: أنا متأكد من أن هذه ليست مشكلة مستعصية إذا بدأت من منظور رحلة المستخدم ثم نظرت في كيفية توقع المستخدم أن تعمل. يجب أن يكون التنقل مستجيبًا لطبيعة ملء الشاشة للهاتف مقابل عرض أصغر على شاشة أكبر على سبيل المثال.

قد "يرى" المستخدم الجهاز اللوحي والعرض الأصغر كمعيار تنقل واحد. يمكن أن يكون هناك معلمان رئيسيان على شاشة صغيرة. يجب أن يكون التنقل ، بطريقة ما ، مستجيبًا.

كمطورين ، علينا بالتأكيد التعامل مع هذه الطبيعة المتجاوبة لأنها شيء سياقي. لا يمكننا الاعتماد على إطار العمل للتعامل مع ذلك من أجلنا ، لكن الإطار يحتاج إلى دعمه.

jsiemensdansiegel الطريق الأول التعامل مع هذا حاليا يستخدم ControlTemplate الصورة. أقوم بإنشاء محتوى من نوع "صفحتي" كـ ContentView s واستضافتهم بـ ContentPage (داخل NavigationPage ) يكون مناسبًا للنظام الأساسي. استخدام ControlTemplates يعني أنه يمكنني الحصول على عدة قيود ContentViews (عادةً في Grid حتى أتمكن من تراكب الأشياء) التي يتم تشغيلها / إيقاف تشغيلها بناءً على الخصائص القابلة للربط في ControlTemplate نفسها (يمكنك أيضًا استخدام DynamicResource s). تعمل النتيجة النهائية إلى حد ما مثل لوحات CSS على موقع ويب ، حيث يكون كل المحتوى في الصفحة ولكن لا يكون كل المحتوى مرئيًا طوال الوقت. ControlTemplate s سحرية لهذا وأريد الحفاظ على قدراتهم في Shell.

dansiegel أود ببساطة أن

jsiemens ، هذا جيد ، تعليقي يهدف فقط إلى تحفيز المزيد من المحادثات والتفكير النقدي لتحسين فكرتك. من بعض النواحي ، أود أن أقول تقريبًا نظرًا لمفهومك هنا ، أن كل صفحة يمكن أن تكون أساسًا متعددة الصفحات حيث يمكن إرفاق الصفحة بعنصر تحكم معين ويتم التعامل معها على أنها مجرد عرض آخر مقابل التنقل العادي.

dansiegel نعم ، أعتقد أن هذا ما أسعى إليه هو أن أتمكن من إضافة صفحة إلى أي مكان داخل التطبيق. من الغريب أن Xamarin Forms تفرض هذا القيد عندما لا تفعل الأنظمة الأساسية الأساسية (على سبيل المثال. iOS هو مجرد تسلسل هرمي لشجرة المشاهدات - يمكنك إضافة عرض NavigationController إلى أي مكان داخل التطبيق حرفيًا). أيضًا ، كان من المفترض أن يشير تعليقي إلى أنه ليس من الضروري أن تغطي مواصفات شل هذا - لا أعتقد أن التخطيط "سريع الاستجابة" يجب أن يكون مصدر قلق. أعتقد أنه طالما أنه من الممكن إنشاء التخطيط ، فيمكننا الاهتمام بتحميل الأصداف المشروط اعتمادًا على عامل الشكل ، وهذا جيد بما فيه الكفاية.

أفترض أنه ليس موضوعًا تمامًا لهذه المواصفات ، لكنني ذكرته هنا لأننا نتحدث عن كيفية إنشاء تخطيطات معقدة (على سبيل المثال. الأولوية الثالثة لـ MelbourneDeveloper - المرونة) ، وهذا بالتأكيد تخطيط يتصدر اهتم بي ولفريقي (نحن نبني تطبيق خرائط حيث نريد أن نكون قادرين على تعويم لوحات المحتوى أعلى الخريطة ، والتي يمكن أن تحتوي على محتوى "للصفحة فقط" مثل صفحات التنقل وعلامات التبويب).

لا أعرف كيف سيتم حل هذا باستخدام القشرة ، لكن رد فعلي الأولي على القشرة هو أنه لا يبدو أنه يفعل أي شيء لا يمكنني فعله بالفعل. أشعر عمومًا أن فريق Xamarin Forms يواصل إنشاء ميزات تتيح لي القيام بأشياء يمكنني فعلها بالفعل ، ولكن بطريقة مختلفة (على سبيل المثال ، CSS ، ومدير الحالة المرئية ، والآن مواصفات الرسم و Shell). لذلك هذا لا يجلب لي الكثير. أفضل أن يكون لدي ميزات جديدة تتيح لي القيام بأشياء لم أستطع القيام بها سابقًا (خارج عناصر التحكم و / أو أجهزة العرض المخصصة). إذا كانت shell هي الحل لإنجاز ذلك لأن بناء الجملة أكثر أناقة ، فأنا أؤيده جميعًا ، لكنني في النهاية أود أن يكون أكثر قوة وأكثر تعبيراً من التسلسل الهرمي الحالي للصفحة / العرض لأنه يجلب قيمة فعلاً.

هل يمكنك فصل إنشاء عرض أصلي في طريقة عرض xamarin إذا كان من الممكن عرض جميع العروض الفرعية داخل تخطيط دون استخدام عناصر واجهة مستخدم أصلية؟ نوع من نهج الرفرفة الهجين / xamarin التلقائي حيث يتم عرض مجموعات من طرق عرض XF على سطح واحد ويتم دمجها فقط في عرض أصلي واحد. قد يكون تجنب إنشاء / تخطيط عرض Android c # -> تكلفة java interop مفيدة.

في تقدم!!

jassmith بعد الانتهاء من شل ، سوف رسم تكون صالحة معا؟

هل ستدعم shell macos و wpf؟

juepiezhongren الأهداف الأولية هي iOS و Android. سيتم إعطاء الأولوية للمنصات الأخرى بعد ذلك.

الرسم ليس قيد التطوير حاليا. في المواصفات الحالية ، سيكون صالحًا مع شركة شل. تمامًا كما هو الحال اليوم ، يمكنك استخدام عناصر التحكم المستندة إلى SkiaSharp و Skia داخل Xamarin.Forms.

نحن نعمل على استراتيجيات محلية أخرى لدعم التصميم المتسق للمواد وأنماط التصميم الأخرى.

davidortinau هل تجعل الصدفة دعم RTL أفضل؟

أفضل بأي طريقة؟ ما الذي تفتقده من دعم RTL اليوم؟ يجب أن نتعامل معها في كل مكان.

لأكون صادقًا ، لم أقم بتطوير XF منذ فترة ، لكن معظم القيود معروفة: ألق نظرة على # 1222 و # 2448

ربما يمكن أن تساعد shell في هذه القيود العامة:

• يتم التحكم حاليًا في موقع زر NavigationPage وموقع عنصر شريط الأدوات وحركة الانتقال بواسطة الإعدادات المحلية للجهاز ، وليس إعداد FlowDirection.
• إعداد التطبيق العام لـ FlowDirection

وبعض القيود الأخرى الخاصة بالمنصة

أهم سمة من سمات Xamarin.Forms. كان يجب أن يتم بناؤه بهذا الشكل في المقام الأول.

بدون رسم ، لا يزال xf يفتقر إلى الكثير

تضمين التغريدة

فقط استخدم Skiasharp

mackayn استخدمته كثيرًا
https://github.com/xamarin/Xamarin.Forms/issues/1789
نظرة عالمية أمر لا بد منه

ذهب آدم إلى الرفرفة ، إنها حقًا علامة حزينة لـ xf ، حيث كان بإمكان xamarin في الأصل تحقيق سمعة أفضل بسهولة

يعتبر xamarin.native أكثر صلابة بالنسبة إلى xf ، مقارنة بأي حلول أخرى مشتركة بين الأنظمة الأساسية ، مهما كان رد الفعل الأصلي أو الرفرفة. بصفتي من محبي dotnet ، فإن الوضع الحالي لـ xf دائمًا ما يكون مخيبًا للآمال قليلاً بالنسبة لي.

تضمين التغريدة

هذه المناقشة لا طائل من ورائها ، إذا لم تفي باحتياجاتك ، استخدم Flutter ، فهي تتيح لنا تقديم التطبيقات عبر منصات متعددة (iOS و Android فقط مع Flutter وما إلى ذلك) ، ستجعل هذه التغييرات مظهرًا متسقًا وتشعر بمزيد من القابلية للتحقيق.

بسيطة صغيرة تشتكي ، فقط كثيرا. ما زال الصيحة لشل!

أوافق على أنه سيكون من الأجمل أن تكون Skia مخبوزة أكثر في Forms api (مثلما فعلت Telerik). أنا أوافق.

أنا سعيد لأنهم يستثمرون الجهد في Shell & CollectionView بالرغم من ذلك.

مرحبًا ، أرجوكم يقول الجميع ، كيف يمكنني استخدام هذا الخطأ في اليمين ، من اليمين إلى اليسار.

أهلا،

أحب الفكرة ، لكن لدي فقط بعض المدخلات الصغيرة.
أعتقد أنني تأخرت قليلاً ، لكن التسمية محيرة بعض الشيء ، على ما أعتقد.

1. العنصر والقسم والمحتوى كلها أسماء عامة حقًا. ليس من الواضح على الفور ما هي العلاقة بينهما. هل هو المحتوى => القسم => العنصر أو القسم => المحتوى => العنصر ، أو العنصر => القسم => المحتوى.
   لذلك يمكننا تحديد ماهية "الأشياء" المختلفة ، من خلال إيجاد اسم أكثر تحديدًا.

2. هذا يقودني إلى المدخلات التالية. لدينا شل كحاوية لجميع العناصر الداخلية. لذلك لا يمكننا استخدام الأسماء المباشرة مثل "عنصر" بدلاً من "ShellItem" بالداخل. يبدو لي بعض الشيء غير ضروري لاستدعاء كل "الأشياء" Shelltem ، ShellSection وما إلى ذلك ولكن طيب. هذا قابل للجدل.

أوتش

هل سيستمر إصداره في 2018؟

لدينا إصدار معاينة متاح الآن! ألق نظرة على https://blog.xamarin.com/connect-2018-xamarin-announcements/ للحصول على بعض العينات الرائعة.

هل نحتاج حقًا إلى Android 9؟ يبدو أن هذا نوع من التقييد.

يبدو كل شيء جيدًا ، ولكن يبدو أنه يعتمد فقط على تفاعل واجهة المستخدم.
أعتقد أنني سأكتشف عندما أحاول ذلك ، ولكن قلقي الأولي هو كيف يمكنني قيادة التنقل من منطق أو رمز العمل ، مثل الرسائل المستلمة من جهاز متصل بالبلوتوث مما يؤدي إلى تغيير الصفحة ، مع الحفاظ على فصل لائق للمخاوف؟

تضمين التغريدة

مرحبًا ، أرجوكم يقول الجميع ، كيف يمكنني استخدام هذا الخطأ في اليمين ، من اليمين إلى اليسار.

أثناء دعم RTL ، لا تزال القائمة المنبثقة تظهر على اليسار. هذا هو القيد الحالي.

هل من الممكن تخصيص واجهة tabbar السفلية؟

هل من الممكن إضافة عناصر تحكم إلى الغلاف لا يتم إعادة تحميلها عند التنقل داخل الصدفة؟ على سبيل المثال FAB ..

stfnilsson bottom tabbar UI قابلة للتخصيص عبر الأنماط ثم عارض مخصص. سنقدم أمثلة في المستقبل.

تم التخطيط لإضافة عناصر تحكم عالمية كما تصفها مثل FAB لـ MaterialShell. هل يمكنك تقديم سيناريوهات إضافية يمكن أن تستفيد من ذلك بالإضافة إلى بنك أبوظبي الأول؟

أولاً: لقد استخدمت قوقعتي الخاصة من قبل ، والآن يمكنني بسهولة استبدال قوقعتي بأصدافك وهو أفضل بكثير. لقد أعجبتنى حقا.

ربما تكون حالاتي طريقة مخصصة ولا تتعلق بالصدفة ولكن:

الحالة الأولى:
إذا كنت أرغب في إنشاء تطبيق بقائمة مخصصة للغاية ، زر قائمة واحد في كل ركن من أركان التطبيق ، كيف يمكنني إضافة الأزرار بحيث تكون جزءًا من الغلاف (مثل التراكب أو لوحة الإعلانات). لا أريد أن يتم عرضه في كل مرة أقوم فيها بالتنقل.

الحالة الثانية:
أرغب في استخدام الغلاف ولكني أرغب في تخصيص شريط التبويب السفلي بحيث يكون الزر الأوسط أعلى (يسمى الزر المرتفع الأوسط). هل يجب علي استخدام العارض وتخصيص عرض التنقل السفلي؟

هل تعتقد أنه يجب علي استخدام الصدفة في حالات خاصة مثل هذه؟

بالطبع أفكر في القيام بذلك على كل نظام أساسي ولكن يجب أن تبدو القوائم متشابهة على جميع الأنظمة الأساسية ، لذا فأنا أرغب في مشاركة الكود ..

ها هي ملاحظاتي. أقوم بهذا الاختبار ( 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>

كل شيء يعمل عندما نضغط على قائمة الهامبرغر. ومع ذلك ، إذا انتقلنا إلى قائمة Test واضغط على Home و Notifications ذهابًا وإيابًا واخترنا بين Recent أو Settings ، الصفحة سيفتح على التوالي. ولكن بعد ذلك ، عندما نضغط على قائمة الهامبرغر مرة أخرى ، يتعطل التطبيق.

كيف يمكننا استخدام GroupHeaderTemplate لإظهار عنوان لمجموعة من ShellContent في ShellItem؟

من الواضح للعديد من المستخدمين أن نماذج Xamarin لا يمكن صيانتها بحجمها وتعقيدها الحاليين ، لذا يجب أن يقلل أي شيء جديد التعقيد بدلاً من زيادته.

jassmith القصد هو أنك

إذا اكتملت شل ، فما الذي يمكن استهلاكه في المستقبل ، وعندما يتم ذلك ، يتم تقليل التعقيد الكلي لنماذج Xamarin؟ هل سيتم إهمال جميع الصفحات الأخرى باستثناء ContentPage؟

يجب أن تكون الإستراتيجية هي الحصول على أكبر قدر ممكن من الريبو. يعد استقرار قاعدة الريبو الأساسية وقابليتها للصيانة أهم شيء.

أيضًا إذا كان هناك سبب لعدم استدعاء Shell لـ ShellPage؟ فئات الصفحات الأخرى لها أسماء تنتهي بـ "الصفحة".

الإعلان الحالي لشركة شل (في https://blog.xamarin.com/xamarin-forms-4-0-preview/) ليس واعدًا.

1. طريقة مبسطة للتعبير عن المستوى العالي لبنية التطبيق الخاص بك

هذا يأخذ Xamarin إلى أبعد من هدفه الحقيقي. Xamarin ليست ضرورية لهندسة التطبيقات. يجب أن يكون هذا عن التخطيط فقط.

1. تسلسل هرمي لأنماط التنقل الشائعة لواجهة المستخدم التي تناسب الأنظمة الأساسية للجوّال المستهدفة

آمل أن يكون "mobile" خطأ مطبعيًا هنا لأن Xamarin.Forms يغطي أجهزة سطح المكتب أيضًا.

1. خدمة ملاحية قوية

Xamarin.Forms لا تحتاج إلى التنقل. إذا كان التنقل الحالي لا يعمل ، فيمكن فقط تقليل قيمته نظرًا لوجود العديد من الأساليب الجيدة للتنقل التي لا تتطلب أي شيء يتم تضمينه فيه.

مرحبًا charlesroddie ، شكرًا على ملاحظاتك.

يبدو أن شركة شل قد لا تكون مناسبة لك في هذا الوقت ، ولا بأس بذلك. لا تحتاج إلى استخدام شل إذا لم تقدم قيمة لتطبيقاتك. ومع ذلك ، فإن مواصفات شل مستنيرة بشكل كبير من خلال ملاحظات المطورين ، وخدمة مجتمع المطورين لدينا هي جوهر هدفنا.

في Xamarin.Forms اليوم ، تصف بالفعل بنية التطبيق الخاص بك ، والتسلسل الهرمي للمحتوى ، باستخدام TabbedPage ، و MasterDetailPage ، مع علامات التبويب وعناصر القائمة ، ومجموعات مختلفة. هذا ما أعنيه هنا بـ "العمارة". تبسط Shell هذه الأنماط وتستبدلها (إذا اخترت استخدام Shell).

"الجوال" ليس خطأ مطبعي ويتم استخدامه بشكل متعمد. تستهدف شركة شل نظامي iOS و Android. إذا كنت تستهدف سطح المكتب ، فلن تستخدم شل. لقد سمعت اهتمامًا من المساهمين حول إضافة دعم شل إلى الخلفيات الخلفية لسطح المكتب ، وستستقبل هذه العلاقات العامة بشكل جيد. أعتقد أن شل في وضع جيد للغاية لنقل التطبيقات إلى أي نظام أساسي ، وأن تكون مرنًا (مرنًا) للتكيف حتى مع التغييرات الجذرية في نمط واجهة المستخدم (من يدري ما هي الواجهات المستقبلية التي ستتبناها). اليوم أساس الاختبار هو iOS و Android.

عندما تحدثنا إلى المطورين حول شل ، فوجئت عندما علمت أن نظام الملاحة في شل كان على رأس قائمة الميزات التي يقدرونها. يعد التوجيه والارتباط العميق والقدرة على مقاطعة التنقل ووصف الحزمة الخلفية على الفور وتمرير البيانات والتحميل البطيء للصفحات سمات مقنعة للغاية للمطورين الذين يحلون المشكلات التي يواجهونها اليوم.

إذا كنت تستهدف سطح المكتب ، فلن تستخدم شل ... أعتقد أن شل في وضع جيد للغاية لنقل التطبيقات إلى أي نظام أساسي

أنا فقط لا أريد أن ينهار Xamarin تحت ثقله. حتى تصل شل إلى جميع الأنظمة الأساسية ، ستواجه مشكلة في الصيانة ، حيث إنها تعد إضافة وليست بديلاً لصفحات أخرى. لديك أيضًا مشكلة في المراسلة لمطوري سطح المكتب ، في وقت يتطلع فيه الكثيرون بوضوح إلى اعتماد إطار عمل عبر الأنظمة الأساسية.

يُظهر Xamarin الكثير من زحف الميزات ، مثل css. هذا يمكن أن يهدد المشروع بأكمله وآمل أن يفهم بعض صانعي القرار في المنظمة ذلك.

أنا فقط لا أريد أن ينهار Xamarin تحت ثقله. حتى تصل شل إلى جميع الأنظمة الأساسية ، ستواجه مشكلة في الصيانة ، حيث إنها تعد إضافة وليست بديلاً لصفحات أخرى. لديك أيضًا مشكلة في المراسلة لمطوري سطح المكتب ، في وقت يتطلع فيه الكثيرون بوضوح إلى اعتماد إطار عمل عبر الأنظمة الأساسية.

يُظهر Xamarin الكثير من زحف الميزات ، مثل css. هذا يمكن أن يهدد المشروع بأكمله وآمل أن يفهم بعض صانعي القرار في المنظمة ذلك.

أنا موافق. إذا كانت الميزة غير مدعومة على سطح المكتب (UWP) ، فلا فائدة لنا. أوافق أيضًا على CSS - يبدو أن هناك الكثير من التعقيد الإضافي وأعباء الصيانة لميزة لا تسمح لي بفعل أي شيء لم أستطع فعله من قبل. ما نحتاجه أكثر بكثير من أي شيء آخر هو مجرد المزيد من الضوابط - لجميع الأنظمة الأساسية ، والمزيد من القدرات لعناصر التحكم الحالية. لا تزال شل لديها نفس القيود التي تفرضها البنية التحتية للصفحة والتي تحتاج إلى اعتمادها بالكامل أو لا يمكنك استخدامها على الإطلاق ، ويمكن أن تعيش فقط في المستوى الجذر لتطبيقك. ليس هذا فقط ، ولكن لديك الآن طريقتان لفعل الشيء نفسه ، وهو أمر معقد ومربك. لذلك إذا كنت أرغب في الحصول على قائمة منبثقة دون استخدام shell ، فلا يمكنني فعل ذلك. وهي محدودة للغاية في مقدار عناصر التحكم التي يتم تعيين عناصر shell لها - علامات التبويب وصفحات التنقل والنشرات المنبثقة ليست كافية بالنسبة لنا. إذا كان بإمكان نماذج Xamarin تقديم مجموعة واسعة من عناصر التحكم التي يمتلكها إطار عمل مثل UWP ، والتي يتم عرضها كمجموعة من عناصر التحكم ، تمامًا كما هو الحال في UWP ، وبدون الانتفاخ غير المجدي (مثل css) ، فسأكون سعيدًا.

أعتقد أنكم تثيرون بعض النقاط الصحيحة ، ولكن كشخص يحتفظ بتطبيق UWP / iOS / Android وقد شعرت بخيبة أمل بعض الشيء عندما علمت أن شركة شل لا تدعم UWP ، مع وجود "ربما" فقط في المستقبل. ثم أدركت أنني أفتقد وجهة نظر شل. إنها طريقة سهلة رائعة لشخص ما لإنشاء تطبيق لمنصتين أساسيتين للهواتف المحمولة. بصفتي مطورًا للمؤسسة ... أحتاج إلى UWP ، لقد انتظرت حتى يتوفر دعم UWP حتى لأخذ XF في الاعتبار ... لكنني أظن أن الكثير من المطورين لا يحتاجون إليه ... أحتاج أيضًا إلى طريقة تنقل أكثر تعقيدًا ، وما إلى ذلك. تقدم شل.

لكنني أتذكر أيضًا قضاء الكثير من الوقت في محاولة البدء في التنقل والصفحات ... الأمر الذي قد يستغرق بعض الوقت لمعرفة ذلك. لكنني أيضًا أقوم بإنشاء مجموعة معقدة جدًا من تطبيقات الأعمال ، فهناك الكثير من التطبيقات البسيطة التي لا تحتاج فقط إلى هذا المستوى من التعقيد. يحتاج XF إلى التطور حتى يكتمل مقابل أشياء مثل Flutter ، إلخ. كما يحتاج أيضًا إلى الاستمرار في حث مطورين جدد على اعتماده. ويبدو لي أن استخدام النظام الأساسي سيساعد في تأمين الموارد اللازمة للحفاظ على النظام الأساسي.

لدي أيضًا مشروعان مستقبليان لا أحتاج فيهما إلى UWP وأتطلع إلى استخدام Shell عليها لأنني أعتقد أنها ستجعل إنتاجها أسرع بكثير بالنسبة لي.

لقد كنت أستخدم XF فقط منذ حوالي الإصدار 2.3 وبينما هناك بالتأكيد المزيد من العمل الذي يتعين القيام به ... استقر النظام الأساسي كما هو الآن بشكل كبير ... على الأقل بالنسبة لي ... لذلك أنا لست مهتمًا بذلك الصيانة الإضافية وتاريخيًا يبدو لي أن فريق XF يدرك تمامًا عبء الصيانة ... لذلك أنا على ثقة من أنهم سيطروا عليها.

شكرا على الإضافة الرائعة للمنصة!

ستؤدي إضافة طرق جديدة للقيام بالأشياء إلى إرباك المطورين الجدد حتى يتم إهمال الطرق القديمة وإزالة المستندات القديمة.

الرفرفة أبسط بكثير. لا توجد لغة ترميزية ، كل شيء في الكود. لن تتنافس Xamarin لتصبح أكثر تعقيدًا وعربات التي تجرها الدواب. سوف تنافس من خلال القيام بأكثر من Flutter (المزيد من المنصات) ، بنفس التركيز.

لقد وصلنا إلى النقطة التي نحتاج فيها إلى Xamarin.Core ، وليس بما في ذلك XAML أو CSS أو ارتباطات الممتلكات ، وليس بما في ذلك الصفحات أو القذائف خارج الفئات الأساسية ، مع التركيز على الأداء والاستقرار لهذا Core. إذا أراد بعض المطورين هذه الميزات على حساب قبول المعدل الحالي للأخطاء ، فيمكنهم استخدام Xamarin ، الإضافات حيث ستعيش كل هذه الأشياء.

ستؤدي إضافة طرق جديدة للقيام بالأشياء إلى إرباك المطورين الجدد حتى يتم إهمال الطرق القديمة وإزالة المستندات القديمة.

الرفرفة أبسط بكثير. لا توجد لغة ترميزية ، كل شيء في الكود. لن تتنافس Xamarin لتصبح أكثر تعقيدًا وعربات التي تجرها الدواب. سوف تنافس من خلال القيام بأكثر من Flutter (المزيد من المنصات) ، بنفس التركيز.

لقد وصلنا إلى النقطة التي نحتاج فيها إلى Xamarin.Core ، وليس بما في ذلك XAML أو CSS أو ارتباطات الممتلكات ، وليس بما في ذلك الصفحات أو القذائف خارج الفئات الأساسية ، مع التركيز على الأداء والاستقرار لهذا Core. إذا أراد بعض المطورين هذه الميزات على حساب قبول المعدل الحالي للأخطاء ، فيمكنهم استخدام Xamarin ، الإضافات حيث ستعيش كل هذه الأشياء.

charlesroddie لا شيء فعلوه أعلاه
إذا لم تكن واجهة المستخدم المشفرة ممكنة مع Xamarin ، فلن أستخدمها - توقف بالكامل!

Re Flutter بشكل عام - إنه لطيف جدًا ، ولكن المشكلة هي نظامي iOS و Android الوحيدان - وهذا لا يعمل بالنسبة لي إما لأنني بحاجة لاستهداف macOS و Windows 7 / 8.1 و Linux. لا شيء يتفوق على Xamarin. أشكال على هذا!

هل يمكنني تعيين عرض مخصص كصفحة رئيسية ، من المهم جدًا تضمينه ، فلن نفضل فقط عنصر القائمة أو الصفحات

دعم Xamarin Mac و UWP؟

كيف يمكنك ربط عملية الملاحة؟ أعتقد أنك على علم بذلك ولكن إذا كنت تأخذ Prism على سبيل المثال ، يتم إنشاء نماذج العرض بواسطة حاوية DI ويتم تعيينها تلقائيًا على أنها BindingContext للصفحة المطلوبة.

يمكنك أيضًا تنفيذ INavigatedAware لنموذج عرض والتعامل مع حالات استخدام محددة مثل تحميل البيانات ، وتمكين / تعطيل الخدمات ، وما إلى ذلك.

كنت أرغب في إضافة شيء مشابه لذلك كان تخميني الأول هو حدث شل OnNavigating و OnNavigated لكن Current و Target لا يكشفون عنصر ShellItem لذا فهو غير ممكن لتعيين BindingContext حسب اصطلاح أو أحداث نموذج عرض المشغل؟

أي اقتراحات لهذا؟

تحرير: تتبعها رقم 5166.

بالنسبة للرموز الموجودة في هذا الغلاف ، هل من الممكن استخدام "Icon Font" بدلاً من الصورة؟ من الصعب تغيير اللون أثناء وقت تشغيل الصورة ومن الصعب أيضًا إدارتها للحصول على درجات دقة مختلفة على نظام أساسي مختلف. هل يمكنني اقتراح إنشاء فئة رمز باستخدام خط التصميم متعدد الأبعاد الذي يتم عرضه باستخدام مكتبة SkiaSharp؟ الفصل سهل نسبيًا وسيجعل الكثير من الرموز جاهزة للاستخدام على الغلاف.

vincentwx أوافق. خطوط الرموز أسهل في الاستخدام وهي مألوفة أيضًا.

تضمين التغريدة أفعل هذا في تطبيق الآن:

<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>

لقد استخدمت هذا لإنشاء فئة ثابتة لجميع الصور الرمزية: https://andreinitescu.github.io/IconFont2Code/

هناك خطأ في لون iOS يحتاج إلى الإصلاح. # 5071

دعم Xamarin Mac و UWP؟

ليس في هذا الوقت mdonogma. نحن نجمع الاهتمام / الطلب لدعم منصات إضافية ، ولكن في هذا الوقت ليس على خريطة الطريق الخاصة بنا.

davidortinau شكرا على الكود والرابط.

في Android 8.0 ، لا يمكنني تمرير صفحة الويب في عنصر WebView الذي يتم استضافته في Shell Content. لكنها تعمل بشكل جيد بدون Xamarin Shell.

نموذج Xamarin 4.0.0.135214-pre4

هل هناك طريقة سهلة لتغيير FontFamily من علامات التبويب السفلية وعرض العنوان؟

varyamereon فعلت ذلك بالأمس. قم بتوسيع Shell لتتمكن من تعيين FontFamily.
سأقوم بنشر برنامج شل الموسع الخاص بي في GitHub قريبًا ولكن:

إنشاء غلاف مخصص:

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

ثم قم بإنشاء عارض مخصص لـ 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
            };
        }

ثم:

 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()
{
{

ثم لتعيين عائلة الخطوط: _ (لا تفعل ذلك كثيرًا) _

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

أي شخص قام بتمديد Shell بدعم نافذة منبثقة من الأسفل (الورقة السفلية)؟

لقد قمت بنقل الكثير من الكود من شيلتي القديمة إلى الجديدة (التكوين بالطبع) ، أحبها حقًا. حتى أنني أستخدمه لتطبيق سيتم إصداره لحث i May :-) (أقوم بتصحيح حتى كود Xamarin)

هل يوجد دعم لربط القائمة بقائمة Shell.MenuItems؟ أم يجب علي استخدام BindableLayout؟ أحيانًا أحتاج إلى تحميل قائمة من قاعدة البيانات واستخدامها كقوائم. لديهم نفس طريقة العرض ، لكنهم يقومون بتحميل بيانات مختلفة بناءً على القائمة المحددة.

هل هناك أي طريقة لتغيير OffscreenPageLimit في Android عند استخدام shell؟ هذا أمر مؤسف للغاية بالنسبة لتطبيقي ويمنعني من المضي قدمًا مع شل.

شكرا!

طلبان للميزة:

1. على مستوى الغلاف ، اضبط FontFamily لجميع عناوين الصفحات.
   على سبيل المثال

2. على مستوى الغلاف ، قم بتعيين صورة خلفية العنوان / التنقل لجميع عناوين الصفحات / أشرطة التنقل ، إلخ.
   على سبيل المثال

GroupBehavior لا يناسبني في pre4:

<ShellItem GroupBehavior="ShowTabs" FlyoutIcon="stuff.png" Title="Discussion">...
النتائج في:

xxx / Shell / Shell.xaml (14،14): خطأ: الموضع 108: 14. لم يتم العثور على خاصية أو خاصية قابلة للربط أو حدث لـ "GroupBehavior" أو نوع غير متطابق بين القيمة والممتلكات.

و GroupHeaderTemplate لا يبدو أنهما يفعلان شيئًا ، لكنك لست متأكدًا من كيفية استخدامه أو تمكينه.

أحاول إضافة / إزالة عناصر القائمة ، والتي تضيف العناصر بنجاح من خلال MenuItems.Add (عنصر) ، ولكن لا تظهر أي نتيجة عند عرض القائمة المنبثقة مرة أخرى. هل هذا هو النهج الصحيح للقيام بذلك؟

لا أرى أي ذكر للتلاعب في MenuItems ، لكن شل عديمة الفائدة إلى حد كبير بالنسبة لي (وأنا أفكر في الكثير من الآخرين ، بما في ذلك puppetSpace أعلاه) ما لم يكن من الممكن الحفاظ على هذه العناصر ديناميكيًا بناءً على منطق عملك.

أوافق مع dbwelch على أن القدرة على تغيير shell برمجيًا في ملف cs مهم جدًا. ليس فقط لعناصر القائمة ، ولكن أيضًا لـ ShellItems & ShellSections.

عندما أقوم بتشغيل Flyout وأضف عناصر القائمة ، أحصل على قائمة هامبرغر في Android ، وفي نظام iOS إذا نقرت في هذا المكان ، فإنها تعمل ، ولكن لا يوجد رمز. أيه أفكار؟

KyleTraynor هناك مشكلة مفتوحة في مكان ما لذلك. يجب عليك نسخ الصور 3bar.png و

الصور التي وجدتها في المصدر مرفقة:

melucas شكرا لك على المساعدة! كنت أذهب إلى الجنون في محاولة لإصلاح ذلك. يعمل بشكل رائع.

هل تعرف كيف يمكنني ضبط OffscreenPageLimit لنظام Android عند استخدام Shell؟

لدي صفحات علامة تبويب عليا تم إنشاؤها من خلال وجود 4 ShellContents داخل 1 ShellSection ، وهي تعمل بشكل رائع على نظام التشغيل iOS ، ولكن على نظام Android ، يتم إعادة تحميل الصفحات عند التبديل بينها وهو ما لا أريده. عادةً باستخدام صفحتي المبوبة ، يمكنني تعيين OffscreenPageLimit لإصلاح هذه المشكلة ، لكن لا يمكنني العثور على طريقة للقيام بذلك باستخدام Shell.

davidortinau هل يمكن أن يكون لدينا خيار تعيين عائلة الخطوط في عناوين الصفحات وعلامات التبويب السفلية

لذا ، نظرًا لأنه لم يكن هناك رد على رسالتي بشأن امتلاك القدرة على تغيير العناصر في flyout Shell ، فربما لا تكون هذه الوظيفة في النطاق ، أو ربما ، آمل أن يتم اعتبارها خطأ؟

لست متأكدًا من كيفية استخدام تطبيق جاد لشل بدون هذه الوظيفة. فقط التطبيقات البسيطة جدًا لا تتطلب القدرة على إضافة / تغيير / إزالة / تعطيل العناصر في قوائمها بناءً على إما أ) سياق المستخدم (أي مصدق / غير مصدق) ، أو ب) حالات مختلفة للتطبيق من شأنها تطلب ذلك.

مجرد فضول jassmith ، هل الأشخاص الذين أنشأوا المواصفات مدرجون في هذا المنتدى أم أن هذا فقط لتعليقات المطور؟

راجع للشغل ، بخلاف هذا العنصر الرئيسي ، لقد قمت بتطبيق Shell في الكود الخاص بي لتطبيق واحد وهو يعمل بشكل جيد جدًا ، شكرًا لك! ولكن ، للأسف ، سيتعين علينا سحبها وتنفيذ المنبثقة الخاصة بي إذا لم يكن لدى Shell هذه الوظيفة تعمل / يتم تنفيذها.

dbwelch ، عدة أشياء.
أنت تنشر على المواصفات ، لذلك من المحتمل ألا تحصل على رد كما كتبت عن فتح عدد جديد. أيضًا ، لم يعد Jason يعمل على النماذج ، لذا فإن استدعائه للخارج أمر لا طائل من ورائه.

خلاصة القول ، قم بتقديم مشكلة

dbwelchChaseFlorell فتحت قضية هنا: https://github.com/xamarin/Xamarin.Forms/issues/5428

davidortinau هل يمكن أن يكون لدينا خيار تعيين عائلة الخطوط في عناوين الصفحات وعلامات التبويب السفلية

jamiewest إرسال طلب ميزة! شكرا! 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

هل يمكن تنفيذ ميزة UseSwipeGesture؟
يبدو الآن أن فئة ShellItem لا تحتوي على خاصية ShellAppearance في أوبرا.
ولكن الآن في Android ، لا تشبه علامات تبويب Shell صفحة TabPage (يمكن لـ TabPage التمرير كإعداد افتراضي.)

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

jingliancui ، Brother Cui ، هل هناك أي qq أو WeChat؟

juepiezhongren مرحبًا ، يمكنك الانضمام إلى مجموعة qq هذه للدردشة معي 313308215

هل سنرى دعمًا مرئيًا وشلًا قادمًا لـ UWP عند RTM؟

أرحب بهذه الفكرة - بغض النظر عن أي شيء يجعلها أكثر صعوبة لأن العمل مع صفحات التنقل وصفحات التفاصيل الرئيسية وما إلى ذلك تبدو طريقة معقدة. ربما هذا لأنني أتيت من خلفية ويب (لم أعمل مع واجهات برمجة التطبيقات الأصلية كثيرًا). يتبادر إلى الذهن هنا تخصيص شريط التنقل وعناوين الصفحات وزر الرجوع وعناصر شريط الأدوات والرؤوس والتذييلات (ListView) وما إلى ذلك.

أفترض أن ما أطلبه هو أن الميزات الجديدة ، مثل * Shell ، يتم شحنها مع مراعاة التخصيص وقابلية التوسع. هناك عدد قليل جدًا من المواقف التي مررنا فيها حيث لم نكن بحاجة إلى إنشاء سلسلة من العارضين والسلوكيات والمحفزات وما إلى ذلك لأداء أشياء تبدو بسيطة.

مهما كان ما توصلتم إليه يا رفاق ، يرجى بذل كل ما في وسعكم لتسهيل الأمر علينا لجعل تطبيقات Xamarin الخاصة بنا تبدو جيدة مثل التطبيقات المحلية الأخرى! يبدو أن هذه الميزة ستمنحنا منصة إطلاق أفضل لتطبيقات XForms الحديثة المظهر!

هل هناك كود مصدر متاح لمعرفة كيفية عمل شل هذا ، بدلاً من الاضطرار إلى التخمين حول المواصفات؟ على سبيل المثال ، ما هو النمط المستخدم لتلوين رمز الهامبرغر ، إذا كان متاحًا. عذرًا ، جديد في C # / Xamarin ، ولكن إذا كان الكود قابلاً للعرض في مكان ما ، فسيساعد بشكل كبير.

dbwelch ، يمكنك تصفح الكود المصدري هنا على GitHub. اضغط على "T" واكتب Shell لمشاهدة الفئات المرتبطة. قد لا تكون هذه هي أفضل نقطة انطلاق ، ولكن إذا كنت جديدًا على C # / Xamarin. أوصي بمراجعة بعض عيناتي حتى نحصل على المزيد من الوثائق:

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

محرر المستندات: https://docs.microsoft.com/en-us/xamarin/xamarin-forms/app-fundamentals/shell؟
مقال MSDN: https://msdn.microsoft.com/en-us/magazine/mt848639
المدونة: https://blog.xamarin.com/xamarin-forms-4-0-preview/

@ davidortinau شكرًا ، لكنني اعتقدت أنه تم إصدار رمز متاح للتو ، أين رمز شل؟ لقد بحثت تحت الفروع مقابل 4.0 ، وشل ، وآخرين ، لكنها مختبئة عني! شكرا!

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

Shell.cs على سبيل المثال هنا

pauldipietro شكرا ، انظر الآن. davidortinau لقد قضيت وقتًا

تحديث: لقد وجدت المشكلة للتو ، وبالطبع ، هناك رمز مقزز موجود في FinishedLaunching لإضافة TintColor. DOH!

شكرا أيها السادة ، نقدر المساعدة!

لدي بعض العناصر التي تظهر في اللوحة المنبثقة وهو أمر جيد. ومع ذلك ، يوجد حاليًا بالفعل طريقة لإخفاء / عدم إظهار عنصر Shell (وليس محتوى العنصر). على سبيل المثال ، لدي ContentPage وأريد فقط التنقل داخل Shell.

<local:DetailPage />

يبدو أنه يقوم دائمًا بإضافة العنصر في لوحة / قائمة Flyout. وإذا لم يكن هناك عنوان ، فسيكون له مكدس فارغ / عنصر نائب للعنصر. لقد جربت طرقًا عديدة لإخفاء العنصر الذي لم يحالفه الحظ. ربما يمكن لشخص ما المساعدة أو أن الميزة لا تزال غير متوفرة حتى الآن.

مقدمة: أنا جهاز صراف آلي جديد. تحاول ألا تكون.

davidortinau لذلك ، كنت أحاول تعلم ميزة Shell هذه لإضافة التنقل ، وما إلى ذلك في أول مشروع Xamarin.Forms لشركتنا (woot!) وأنا عالق في محاولة معرفة ما إذا كان من الممكن اجتياز 1 أو المزيد من المعلمات من ShellItem إلى أجزاء أخرى من التطبيق عبر وظيفة التوجيه الجديدة. هل هذا شيء على الإطلاق؟ أو هل يجب أن نتمسك بالأمر باستخدام MenuItems ضمن مجموعة MenuItem بدلاً من ذلك؟ إذا كان يجب علينا استخدام MenuItem لتمرير 1 أو أكثر من القيم من مستوى Flyout ، فيبدو أنه لم يعد بإمكاننا هيكلة تطبيقنا باستخدام تسلسل Shell الهرمي نظرًا لأننا نستخدم MenuItems بدلاً من ذلك؟ ألا نفقد ذلك في استخدام MenuItems مع معلمات الأوامر؟

هل هناك أي شخص يمكنه الرد على هذا؟ إذا كان الأمر كذلك ، سأكون ممتنًا جدًا لذلك. أحب استخدام Shell بشكل أساسي ، ولكن لا يزال بإمكانك تمييز عنصر ShellItem الذي حدده المستخدم عند النقر فوق واحد لتمرير ذلك إلى صفحة ContentTemplate أو ما هو مناسب نظرًا لأن الكثير من عناصر ShellItems ستنتقل إلى صفحة وسيطة مماثلة لإنشاء OrderType واختيار قسم الطلبات المنسدلة أولاً قبل الانتقال إلى شاشة الطلب الرئيسية بالبيانات المناسبة للنوع والقسم المناسبين.

أيضًا ، أعتذر إذا كان هذا هو المكان الخطأ لذلك. إذا كان الأمر كذلك ، يرجى توجيهي إلى المكان الصحيح. شكرا!

تحديث:
ربما سأستخدم MenuItems في الوقت الحالي وأمرر معلمة الأمر إلى ShellViewModel للتنقل بالقيم الصحيحة للصفحة الهدف. الآن بعد أن فكرت في الأمر ، لن أحتاج حقًا إلى الانتقال إلى بنية مبوبة من عناصر MenuItems التي يتم دفعها إلى صفحة ContentTemplate.

كنت أتساءل أيضًا عما إذا كان بإمكاننا تحديد موقع MenuItems داخل Flyout بحيث لا تظهر كل عناصر ShellItems في الأعلى ؛ وإذا لم يكن علينا في يوم من الأيام تحديد عناصر MenuItems الخاصة بنا كجزء من مجموعة حتى يتمكنوا من الاختلاط مع ShellItems مثل:
MenuItem
ShellItem
ShellItem
MenuItem
ShellItem
MenuItem
...
هذا ، أو فقط اجعل ShellItems قادرًا على تمرير المعلمات في مرحلة ما إذا لم يتمكنوا من ذلك بالفعل.

أنا مع anthcool وأجد هذه ميزة مهمة للغاية. لم أتمكن من إيجاد طريقة للقيام بذلك واضطررت إلى التوقف عن استخدام شل. تحتاج فقط إلى أن تكون قادرًا على تمرير شيء ما إلى صفحة المحتوى لمعرفة ما تم النقر فوقه.

anthcool أحاول فقط المساعدة وإعطاء بعض الاقتراحات هنا كما فعلت في الوقت الحالي. قم بإنشاء فئة معلمات التنقل التي تحتوي على readonly Stack<NavigationParameter> كقائمة مكدس ، على سبيل المثال

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

معلمة التنقل هي:

public class NavigationParameter : NameValueCollection { }

يمكنك إضافة معلمات قبل الدفع عند التنقل ، على سبيل المثال:

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

مرة واحدة لك في صفحة أخرى، مجرد نظرة خاطفة أو البوب القيمة والتحقق من المفتاح.
شيء من هذا القبيل أعلاه. امل ان يساعد.

anthcool أحاول فقط المساعدة وإعطاء بعض الاقتراحات هنا كما فعلت في الوقت الحالي. قم بإنشاء فئة معلمات التنقل التي تحتوي على readonly Stack<NavigationParameter> كقائمة مكدس ، على سبيل المثال

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

معلمة التنقل هي:

public class NavigationParameter : NameValueCollection { }

يمكنك إضافة معلمات قبل الدفع عند التنقل ، على سبيل المثال:

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

مرة واحدة لك في صفحة أخرى، مجرد نظرة خاطفة أو البوب القيمة والتحقق من المفتاح.
شيء من هذا القبيل أعلاه. امل ان يساعد.

شكرا على فكرةrizamarhaban! حقا نقدر لكم الرنين في هذا. شكرا لك! سوف أتحقق من هذا هنا قريبا. مرة أخرى ، نقدر ذلك!

محبط للغاية عندما تعلم أن Shell و Visual لا يدعمان UWP.

هل هذه المواصفات فعلاً؟
لماذا نغلق هذا لمجرد وجود تطبيق Tizen الآن؟
كان لدي انطباع بأن وظيفة الملاحة لا تزال قيد المراجعة.

لا يزال لا يوجد دعم UWP. أكبر خيبة أمل شعرت بها من Xamarin.

weitzhandler يرجى Paul . [email protected] إذا كنت ترغب في مناقشة هذا و UWP بشكل عام. نحن لا نتجاهل النظام الأساسي بشكل نشط ، ولكن Android و iOS يتلقىان التنفيذ الأولي والتحقيقات في دعم Shell لـ UWP مستمرة بشكل نشط.

mrlacey Nah ، لم يتم الانتهاء من أي مكان قريبًا! إنها فقط تغلق بسبب القضايا ذات الصلة. 😄

بالنسبة لجميع أولئك الذين يطلبون دعم UWP ، فقد طعنت فيه: https://github.com/xamarin/Xamarin.Forms/pull/6015

هل هناك طريقة لتنفيذ قالب شريط التنقل على صفحة المحتوى؟
تحديد NavigationPage.TitleView لا ينطبق كما كان من قبل.
الريبو كمرجع:
https://github.com/InquisitorJax/Xamarin-Forms-Shell

تعديل:
يضرب مورفي مرة أخرى - فقط استخدم Shell.TitleView بدلاً من NavigationPage.TitleView :)

أهلا،
في مشروعي الجديد ، أستخدم Shell و CollectionView ، ولا بد لي من القول إن هذا رائع!
سؤال واحد عن شل

• هناك طريقة لإضافة عنصر سفلي ثابت (مثال الثعلب زر لتسجيل خروج المستخدم)

أرى أنه من الممكن إضافة رأس ثابت (FlyoutHeader و FlyoutHeaderBehavior) ولكن لا يمكنني العثور على أي معلومات حول التذييل السفلي
شكرا!

أهلا،
لدي سؤال آخر حول RegisterRoute.
تطبيقي كبير نوعًا ما ، ويحتوي على عدد كبير من الصفحات ، حوالي 30 ...
هل حقًا الطريقة الصحيحة لإضافة RegisterRoute لكل منهم؟
Routing.RegisterRoute("blabla", typeof(BlaBlaPage)); ... ...
أم الأفضل استخدام الطريقة القديمة؟
var blaPage = new BlaBlaPage (); await Navigation.PushAsync (blaPage);

matteopiccioni أوصي بالقيام بذلك على هذا

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

واستخدام
gotoasync("blabla")

أدرك الآن أنه يشعر بنفس الشعور ، ولكن مع نمو الميزات ، سيكون من الملائم أكثر تشغيل كل هذه الأشياء عبر نظام شل

هل حقًا الطريقة الصحيحة لإضافة RegisterRoute لكل منهم؟

إذا أصبحت هذه نقطة ألم ، فإننا نبحث في إضافة بعض الميزات التي ستؤدي فقط إلى فحص التجميع للصفحات أو ربما حتى بعض ميزات وقت التجميع التي ستنشئ هذه المسارات.

تكمن المشكلة الرئيسية هنا في أن أي نوع من التفكير سيؤدي إلى إبطاء تطبيقك ، لذا فإن القيام بذلك عند بدء التشغيل سيكلفك

@ PureWeen شكرا على الإجابة
يعد وقت بدء التشغيل البطيء أحد أكثر المشاكل المزعجة في xf (لنظام Android)
عند بدء التشغيل ، هل يمكنني إضافة المستوى الأول فقط من الصفحات (صفحات shellitems) إلى التوجيه وإضافة الصفحات الأخرى فقط بعد بدء تشغيل التطبيق (نوع من التحميل الكسول لـ RegisterRoute)؟

تضمين التغريدة

لذلك إذا قمت بذلك مرة واحدة فقط

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

لا بأس. كل ما كنت أتحدث عنه هو أنه إذا انتهى بنا المطاف ببناء شيء يجعله لا يضطر المستخدمون إلى القيام به ، فسنحتاج إلى موازنته بالأداء. في الوقت الحالي ، لا يقوم Routing.RegisterRoute("blabla", typeof(BlaBlaPage)); بأي انعكاس ، لذا فإن القيام بذلك مرة واحدة أمر جيد.

كل ما يفعله هو إضافة سلسلة والكتابة إلى القاموس

MustafaHosny اللهم امين يارب هل شاهدت تطبيق جهات اتصال Google الذي يستخدم Pie SDK على Google Pixel؟ أنا أحب UI / UX ، بدون شريط عنوان والهامبرغر مدمج في الجزء العلوي من التطبيق.

هل يمكن اعتبار هذا الاقتراح لشلك نظرًا لأنه نمط تستخدمه Google ، مع جهات الاتصال والخرائط ، وربما الآخرين؟

شكرا لك على وقتك واحترامك،

كارل

لاحظ أن جميع العينات التالية لا تستخدم نماذج ShellContent ، والتي تمت مناقشتها في مكان آخر في المواصفات. سيؤدي عدم استخدام ShellContents بشكل صحيح مع ContentTemplate إلى تحميل جميع الصفحات عند بدء التشغيل ، مما سيؤثر سلبًا على أداء بدء التشغيل. هذه العينات هي لأغراض التعلم فقط.
لحسن الحظ ، فإن استخدام ShellContents مع ContentTemplates عادة ما يكون أكثر إيجازًا من عدم استخدامها.
[...]
تتمثل المشكلة الرئيسية في استخدام Shell في السهولة التي يمكن للمستخدم من خلالها تحميل جميع الصفحات في بداية تشغيل التطبيق. يمكن أن يؤدي هذا التخصيص الكبير الذي تم تحميله من الأمام إلى أداء ضعيف جدًا لبدء التشغيل إذا كانت هناك حاجة إلى عدد كبير من صفحات المحتوى. من أجل إصلاح هذا القالب يجب أن تستخدم عندما يكون ذلك ممكنا.

بالنسبة لي ، يبدو أنه لا يجب عليك استخدام المحتوى مباشرة ولكن استخدام القوالب. هذا منطقي بالنسبة لي ، فلماذا دعم نهج المحتوى المباشر؟ (بصرف النظر عن البساطة ، إلا أنها تسمح للناس بإطلاق النار على أقدامهم). يبدو نوعًا أن القدرة على استخدام المحتوى المباشر هي ميزة "رائعة عند عمل عرض توضيحي - بخلاف ذلك فظيعة".

أهلا،
أنا جديدة هنا. لست متأكدًا مما إذا كان هذا هو المكان المناسب لطرح الأسئلة ، وإلا يرجى توجيهي إلى حيث أسأل:
حاولت أن أفعل شيئًا مشابهًا للعينة المحددة أعلاه:

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

لكنني حصلت على الأخطاء التالية:

خطأ XLS0413 لم يتم العثور على الخاصية "ItemsSource" في النوع "ShellItem".
خطأ XLS0415 لم يتم العثور على الخاصية القابلة للإرفاق "ItemTemplate" في النوع "ShellItem".

Elashi لذا هل تأمل في القيام بهذه الفكرة هنا
https://docs.microsoft.com/en-us/xamarin/xamarin-forms/user-interface/layouts/bindable-layouts

مع ShellItem؟

PureWeen كنت
هل تقترح أن هذه الفكرة لم تنفذ بعد؟
إذا لم يتم تنفيذه بعد ، فقد أكون مهتمًا بالعمل عليه.

لم يتم تنفيذه ، أتمنى أن يكون!

مرسل من الايفون الخاص بي

في 5 مايو 2019 ، الساعة 11:59 صباحًا ، كتب Elashi < [email protected] [email protected] > ما يلي:

PureWeen https://nam05.safelinks.protection.outlook.com/؟url=https٪3A٪2F٪2Fgithub.com٪2FPureWeen&data=02٪7C01٪7C٪7C5a4c31a04c6541d6080608d6d172b36a٪7C84df9aa7٪2Fgithub.com٪2FPureWeen&data=02٪7C01٪7C٪7C5a4c31a04c6541d6080608d6d172b36a٪3A٪2F٪2Fgithub.com٪2FPureWeen&data=02٪7C01٪7C٪7C5a4c31a04c6541d6080608d6d172b36a٪7C84df9aa7 ، ٪ 2BGt13FFjR5BCwdMg0UouarnTxI0٪ 2FawrXtVEURM٪ 3D & reserved = 0 كنت أتمنى استخدام هذه الفكرة :).
هل تقترح أن هذه الفكرة لم تنفذ بعد؟
إذا لم يتم تنفيذه بعد ، فقد أكون مهتمًا بالعمل عليه.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذه الرسالة الإلكترونية مباشرةً ، واعرضها على 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 & محفوظة = 0 ، أو كتم موضوع https://nam05.safelinks.protection.outlook.com/؟url=https٪3A٪2F٪ 2Fgithub.com٪ 2Fnotifications٪ 2Funsubscribe-المصادقة٪ 2FAABUHE2I4F33TX2SZJE2RVDPT377JANCNFSM4EZ4GB5Q والبيانات = 02٪ 7C01٪ 7C٪ 7C5a4c31a04c6541d6080608d6d172b36a٪ 7C84df9e7fe9f640afb435aaaaaaaaaaaa٪ 7C1٪ 7C0٪ 7C636926687892546103 وsdata = UXiXgRiTo4pAjJVraUqmJmYZibiWMdh9htX2SeFG4JM٪ 3D & محفوظة = 0 .

Elashi ليس الأمر كذلك ، لكني استطعت أن أرى أنها ميزة قوية حقًا لسيناريوهات MVVM

إذا كنت ترغب في العمل عليه ، فهل يمكنك إنشاء مشكلة تتعلق بأساسيات ما تفكر فيه؟

لذا من التجربة والخطأ ... على الرغم من أنه يحتوي على تعليقات حول الإيماءات في shell 3.2 و TheLittlePlayground الخاص به ، لا يمكنني جعل Gestures يعمل على ANDROID مع الحزمة المرئية.

هل أفتقد شيئًا ما في الملاحظات أن إيماءات Shell + تعمل فقط مع iPhone؟

davidortinau أعلم أن هذه مجرد بعض المواصفات ، وقد تم إغلاقها لفترة من الوقت ، لكنني كنت آمل أن تتمكن من توجيهي في الاتجاه الصحيح لأن المواصفات تشير إلى أن المهمة أدناه إما مكتملة أو في جدول الأعمال تطوير:

• أضف واجهة برمجة تطبيقات لعناصر "القائمة الفرعية" لنظام تحديد المواقع العالمي (GPS) الخاص بـ ShellContent -> الموسيقى -> فتح تطبيق الموسيقى

حاليًا نظرًا لأنني لا أستطيع تشغيل GroupHeaders ، فأنا أتطلع إلى إعادة صياغة قائمة FlyoutMenu الخاصة بي للفرز إلى 6 مجموعات رئيسية ، ثم تظهر قائمة فرعية مليئة بالعناصر Flyout التي تنقلني إلى التوجيه الذي حددته مسبقًا.

حالة الاستخدام الخاصة بي هي أن لدي أكثر من 50 خيارًا لعرضها ووضع ذلك في حالة التمرير ليس سهلًا على واجهة المستخدم ، ولكن كل خيار يتم عرضه هو شيء أحتاجه للسماح للمستخدمين بالوصول إليه بكفاءة دون الحاجة إلى التمرير بلا نهاية. يعتبر الفرز في مجموعات استنادًا إلى السمة الشاملة لكل خيار أكثر منطقية من وجهة نظر UI / UX.

هل يمكنك إلقاء بعض الضوء على موقف ذلك من حيث التطوير / الإنتاج؟ - أو وجهني في اتجاه قاعدة التعليمات البرمجية التي تنفذها حتى أتمكن من التعلم؟ (لقد كنت مع Xamarin لمدة شهر واحد فقط ، لذلك ما زلت جديدًا على بعض الموارد المتاحة).

تضمين التغريدة

لقد بحثت للتو في هذا الريبو على Google بشيء يمكن أن يعمل مع السيناريو الخاص بك على الأرجح. لن تكون شركة شل ، ولكن ربما يمكنك استخدامها في إعداد MasterDetailPage.

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

أيضًا ، قاموا فقط بنقل وتحديث الكثير من مواد الدورة التدريبية الخاصة بهم إلى MSFT Learn (التي أقوم بتشغيلها من خلال نفسي لسد الثغرات). هذا موجود هنا: https://docs.microsoft.com/en-us/learn/browse/؟

سأحاول أن أجري ما ورد أعلاه. حظا سعيدا ومرحبا بكم على متن!

مرحبًا يا رفاق ، أريد اختيار ملف أو صور من المعرض أو وحدة تخزين خارجية بتنسيق
أشكال xamarin الذين يختارون ملفه؟ الملف هو فقط امتداد .PDF. إلى
حدد كلا الملفين أستخدم زرًا واحدًا لذا يسعدني مساعدتي !!!

في الخميس ، 23 مايو 2019 ، الساعة 19:41 كتب Anthony Cool [email protected] :

TheBaileyBrew https://github.com/TheBaileyBrew

لقد بحثت في Google عن هذا الريبو بشيء يمكن أن يعمل مع السيناريو الخاص بك
على الأرجح. لن تكون شركة شل ، ولكن يمكنك استخدامها في صفحة MasterDetailPage
الإعداد ربما.

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

-
أنت تتلقى هذا لأنك مشترك في هذا الموضوع.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/xamarin/Xamarin.Forms/issues/2415؟email_source=notifications&email_token=AK7KSYK4N3XIVP3IHOBE2P3PW3CKJA5CNFSM4EZ4GB52YY3PNVWWK3TUL52HS4DFVREXG43VMissment
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AK7KSYI5XKMXD7FC7HZH45LPW3CKJANCNFSM4EZ4GB5Q
.

مرحبًا يا رفاق ، أرغب في إضافة علامات تبويب على أساس الشرط ، فكيف يمكنني إضافة علامات تبويب في Shell باستخدام C # وليس في Xaml وكذلك كيفية إضافة itms للقائمة.

تضمين التغريدة

هل هذا ما تبحث عنه؟
https://docs.microsoft.com/en-us/xamarin/xamarin-forms/app-fundamentals/shell/flyout#flyout -display-options

BeleShew سؤالك ربما يكون أكثر ملاءمة لتدفق التكديس أو تجاوزه على forums.xamarin.com

PWaliaDev يمكنك القيام بذلك من خلال مجموعات العناصر المختلفة التي تعد جزءًا من shell

Shell.Items.Add (عنصر ShellItem جديد ())
ShellItem () الجديد. Items.add (new ShellSection ())
ShellSection () جديد. Items.Add (new ShellContent ())

على الرغم من أنني أفترض أننا إذا أصلحنا هذه المشكلة
https://github.com/xamarin/Xamarin.Forms/issues/5428

التي تناسب السيناريو الخاص بك؟

PureWeen - لقد حصلت على خيارات العرض المحددة لكل رابط خاص بك ، ولكن ما أعاني منه هو أقرب إلى ما يتعامل معه BeleShew (إنشاء / إزالة عناصر منبثقة على أساس كل مستخدم)

إصلاح # 5428 يناسب ما أتطلع إلى تحقيقه.

يحتوي تطبيقي على مستخدمين لديهم العديد من الأدوار / الوصول ، وأحتاج إلى إظهار خيارات القائمة برمجيًا فقط لأولئك المستخدمين المصرح لهم (لا أريد أن يرى المستخدمون ما _ لا يمكنهم _ فعله ، فقط ما يمكنهم فعله.

على الرغم من أنني كنت ألعب مع هذا ، أحاول معرفة ما إذا كان من الممكن فحص خيارات القائمة الخاصة بي وإضافة بدلاً من ذلك ، قم بالإخفاء كما يفعل هذا الرمز (ولكن يجب أن أكرره مقابل كل مسار ممكن وخيار القائمة الذي قد يلتهم وقت التحميل:

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);
            }
        }

تعتبر شل رائعة من الناحية النظرية ولكن ليس من الناحية العملية بدون هذه الميزات التي يجب أن تتمتع بها.

1. إضافة / إزالة عناصر shell ديناميكيًا بناءً على دور المستخدم
2. سيناريو تسجيل الدخول / الخروج أو مسارين ملاحيين منفصلين بناءً على الظروف.
3. اختياريًا ، دعم أطر MVVM الأخرى مثل Prism

لا يمكن استخدام شل في التطبيقات الموجهة للأعمال حتى يتم توفير الميزة 1 و 2.

@ Im-PJ لماذا تعتقد أن 1 و 2 غير ممكنين؟ (متأكد من أنهم كذلك)

3 قيد التقدم ويتم تتبعها هنا .

هل يعرف أي شخص ما إذا كان من الممكن الحصول على حدث نقر من علامة تبويب App Shell؟
سؤال المنتدى ذي الصلة: https://forums.xamarin.com/discussion/159748/app-shell-pop-to-root-on-tab-tap

أتفق تمامًا مع @ Im-PJ ، ولا تفهم كيف لم يتم توفير هذه الميزات على وجه التحديد. إنه سبب رئيسي لأداة مثل شل. يمكن لأي شخص بناء قائمة الشرائح!

dotMorten ، ربما يمكنك القيام 1 أو 2 من خلال C # الشامل والقرصنة ، ولكن لا توجد أمثلة أو ذكر لربط / تعطيل / إخفاء / إضافة عناصر Shell في وقت التشغيل التي يمكنني العثور عليها. يبدو أن القدرات الديناميكية ستكون هدفًا رئيسيًا لهذه الأداة. يعد إنشاء تمثيل XML ، إلى جانب بعض ميزات المسار ، حدًا أدنى ، وهو ما يكفي لمنح الأشخاص التسويقيين ، ولكنه ليس كافيًا للاستخدام الفعلي في تطبيق جوال حقيقي وكامل الميزات.

@ Im-PJ

هل يمكنك التوسع قليلاً في كيفية اختلاف هذه الأشياء؟

إضافة / إزالة عناصر shell ديناميكيًا بناءً على دور المستخدم
سيناريو تسجيل الدخول / الخروج

يمكنك حاليًا إجراء سيناريو تسجيل الدخول / الخروج باستخدام TabBar أو إخفاء التنقل المنبثق إذا كنت في صفحة تسجيل دخول

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

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

إذا كنت في صفحة تسجيل الدخول ، فإن الطريقة الوحيدة للتنقل هي من خلال الكود.

يجري العمل هنا لفضح خاصية IsVisible القابلة للربط
https://github.com/xamarin/Xamarin.Forms/tree/shell_isvisible

إنها تحتاج فقط إلى القليل من التحسين قبل إنشاء العلاقات العامة

طريقان ملاحي منفصلان بناءً على الظروف.

هل يمكنك تقديم أمثلة لما تحاول القيام به وما لا يمكنك فعله حاليًا؟

أنا أستخدم Xamarin.Form Shell

نموذج الارتباط: https://docs.microsoft.com/en-us/xamarin/xamarin-forms/app-fundamentals/shell/flyout

ساعدني من فضلك. كيف تظهر شريط Tab في صفحة "حول"؟

أحتاج إلى صفحتين قذيفة في نفس الوقت.
واحد لقائمة flayout مع الصفحة الرئيسية والإعدادات وتسجيل الخروج وما إلى ذلك
واحد للصفحات المبوبة التي يجب دفعها من المنزل
في الوقت الحالي لا بد لي من استخدام "الطريقة القديمة"

أحتاج إلى صفحتين قذيفة في نفس الوقت.
واحد لقائمة flayout مع الصفحة الرئيسية والإعدادات وتسجيل الخروج وما إلى ذلك
واحد للصفحات المبوبة التي يجب دفعها من المنزل
في الوقت الحالي لا بد لي من استخدام "الطريقة القديمة"

إذا كنت تستخدم Tabbedpage ، فلا يمكن إظهار Flyout. أريد أن أظهر Flyout و Tabbar في هذا الوقت.

أضع جميع الصفحات في ملفبحيث تعرض الصفحات شريط Tab ، لكنني أريد أن يكون لدي فقط 4 عناصر في شريط التبويب (لا أريد إظهار علامة تبويب المزيد). كيف تفعل؟

<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>

أحتاج إلى صفحتين قذيفة في نفس الوقت.
واحد لقائمة flayout مع الصفحة الرئيسية والإعدادات وتسجيل الخروج وما إلى ذلك
واحد للصفحات المبوبة التي يجب دفعها من المنزل
في الوقت الحالي لا بد لي من استخدام "الطريقة القديمة"

إذا كنت تستخدم Tabbedpage ، فلا يمكن إظهار Flyout. أريد أن أظهر Flyout و Tabbar في هذا الوقت.

أضع جميع الصفحات في بحيث تعرض الصفحات شريط Tab ، لكنني أريد أن يكون لدي فقط 4 عناصر في شريط علامات التبويب (لا أريد إظهار المزيد من علامة التبويب). كيف تفعل؟

<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>

للأسف لا يمكنني استخدام شل
لا يزال لدي MasterDetailPage و TabbedPage في نفس التطبيق (في iOS لدي أعلى الصفحات المبوبة باستخدام Naxam.TopTabbedPage.Forms plugin)
كانت هذه تذكرتي القديمة