Xamarin.forms: Uwp Xamarin. الأشكال. شل

تم إنشاؤها على ١٧ مارس ٢٠١٩  ·  61تعليقات  ·  مصدر: xamarin/Xamarin.Forms

Uwp Xamarin.Forms.Shell لا يعمل بشكل صحيح في uwp ، بنفس الطريقة التي يعمل بها على android و ios

التعليق الأكثر فائدة

عادةً ما أستخدم iOS و Android لمستخدمي هاتفي و UWP لمستخدمي الكمبيوتر اللوحي وسطح المكتب. لذا فإن الحصول على دعم UWP سيكون مهمًا جدًا للحفاظ على تفاعل مستخدمي Windows.

ال 61 كومينتر

يتوفر دعم Shell فقط لنظامي التشغيل Android و iOS في الوقت الحالي. نعمل باستمرار على تقييم التعليقات المتعلقة بدعم UWP المستقبلي المحتمل وسنوفر المزيد من المعلومات في المستقبل عندما تصبح متاحة.

عادةً ما أستخدم iOS و Android لمستخدمي هاتفي و UWP لمستخدمي الكمبيوتر اللوحي وسطح المكتب. لذا فإن الحصول على دعم UWP سيكون مهمًا جدًا للحفاظ على تفاعل مستخدمي Windows.

ماذا؟؟ تتخلى MS بالفعل عن منصتها الخاصة. من المحزن سماع ذلك!

ليس هناك أي رؤية حول موعد تقديم دعم UWP؟ أو هل تم اتخاذ القرار بالفعل؟

دعم شل لـ UWP - من فضلك!

أود أيضًا أن أرى دعم UWP لشركة Shell.

بالنسبة لشركتي ، يعد UWP مهمًا للغاية لأن عملائنا يستخدمون Windows Tablets مع بعض هواتف Android لإنجاز عملهم. لن نتمكن من الترحيل إلى Shell إذا كان دعم UWP مفقودًا.

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

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

سأصوت أيضًا على القدرة على استخدام UWP مع شل.

UWP من فضلك ... أو على الأقل بعض نكهة Microsoft UX API التي يمكننا الاعتماد عليها لبضع سنوات. هذا النهج المتمثل في "سنخبرك إذا كان من الممكن أن ندعمه لاحقًا" هو مجرد أسلوب دنيء.

لذا ، نعم ، UWP أو أيًا كان سوف يدعمها ولكن الأهم من ذلك: التزامنا عندما نعرف ما إذا كان أو متى.

لا يمكن الانتقال إلى شل بدون هذا اليقين.

ليس فقط UWP ولكن أيضًا MacOS من فضلك.

لا أعرف ما إذا كنت قد أدركت أن UWP ليس فقط نظامًا أساسيًا لا يزال يستخدم على نطاق واسع من قبل المطورين ، ولكنه أيضًا أسرع طريقة لتشغيل تطبيقات XF المستندة إلى Android و iOS وتشغيلها. لأنه - بالمقارنة - المحاكيات المقدمة لكل من عالم Android و Mac بطيئة للغاية وعرضة للمشاكل ودعنا لا نتحدث عن تجربة الشهادة الرهيبة أو لا نزال مجبرًا على امتلاك جهاز Mac حقيقي ، أليس كذلك؟ لذلك على الرغم من أنه لا يمكن أن يحل محل التطوير على الشيء الحقيقي بعد كل شيء ، فإن تطبيق UWP يزيد من إنتاجية المطورين من خلال تقديم طريقة سريعة وسهلة وشاملة لإنجاز ... الأشياء ... وبعد ذلك: افعل ما يلزم لتنشيط تطبيقك وتشغيله على نظامي iOS و Android أيضًا.

لذا هل يمكنك إضافة دعم shell لـ UWP؟

أتفق مع Mephisztoe ، إنها حقًا أداة إنتاجية رائعة ، وبالطبع فإن خيار جعل التطبيق متاحًا لنظام التشغيل Windows يعد إضافة رائعة أيضًا :)

من فضلك لا تحيل Xamarin.Forms إلى منصات المحمول فقط. أود أن أرى دعمًا مستمرًا لـ UWP على وجه الخصوص ، ولكن أيضًا WPF و GTK #.

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

سيكون للمنصات المختلفة دائمًا أولويات مختلفة. بعد كل شيء ، قلت "جميع المنصات الثلاثة" ، وليس "جميع المنصات السبع".

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

Xamarin. الأشكال
يعرض Xamarin.Forms مجموعة أدوات واجهة مستخدم كاملة عبر الأنظمة الأساسية لمطوري .NET. أنشئ تطبيقات Android و iOS و Universal Windows Platform أصلية بالكامل باستخدام C # في Visual Studio.

وفي التمهيدي تقول:

توفر Xamarin.Forms طريقة لإنشاء تطبيقات أصلية بسرعة لأنظمة iOS و Android و Windows و macOS ، تمامًا في C #.

هذا لا يعني أنه لا يدعم أيضًا GTK و WPF و Tizen.

أوافق على أن هذه الأنظمة الأساسية ربما تكون أقل أهمية من UWP ، ولكن هناك الكثير من الأشخاص الذين يعتقدون أن UWP أقل أهمية من iOS و Android.

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

لمعلوماتك، إلا إذا أنا قراءة ملاحظات الإصدار بشكل غير صحيح، يبدو أن هناك ShellRenderer التنفيذ لتايزن في المعاينة 4.1. لم يذكر UWP.

إذا استغرق طلب السحب من

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

سنستخدم أيضًا الغلاف بمجرد توفره على UWP. لدينا نفس المشكلة المذكورة أعلاه. لدينا مزيج من الأجهزة اللوحية والهواتف وأجهزة الكمبيوتر المحمولة التي تعمل بنظام Android و Windows. ونعتقد أيضًا أن أفضل بيئة تطوير هي UWP

هذه المشكلة هي أحد الأسباب الرئيسية للتخلي عن XF. لعملائنا ، سطح المكتب والجوال لهما نفس الأولوية.

ماذا يمكنني أن أقول إن لم يقال بالفعل ..

حتى تتعامل معها!
دعم UWP ليس اختياريًا لـ Microsoft - هل تحتاج حقًا إلى إخبارك بذلك؟

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

كما نتعامل مع هذا على أنه اختبار لالتزام MS Xamarin تجاه المطورين. هل هناك أي شخص في جانب التصلب العصبي المتعدد مستعد للوزن؟

نأسف للجميع ، سوف نخفف من الأفكار الأخرى ... لكنني كنت مندهشًا تمامًا لاكتشاف عدم وجود دعم UWP - لم يخطر ببالي مطلقًا أن UWP لن يكون نظامًا أساسيًا مضمّنًا من get-go. ريك.

من: Jeremy [email protected]
تاريخ الإرسال: 16 آب (أغسطس) 2019 الساعة 2:28 مساءً
إلى: xamarin / Xamarin.Forms [email protected]
نسخة إلى: Rick Piovesan [email protected] ؛ أذكر [email protected]
الموضوع: Re: [xamarin / Xamarin.Forms] Uwp Xamarin.Forms.Shell (# 5593)

papiermache https://github.com/papiermache يرجى ملاحظة أن مدونة قواعد السلوك تنطبق على جميع الاتصالات والقضايا والتعليقات على هذا المشروع

-
أنت تتلقى هذا لأنه تم ذكرك.
الرد على هذا البريد الإلكتروني مباشرة، مشاهدته على جيثب https://github.com/xamarin/Xamarin.Forms/issues/5593؟email_source=notifications&email_token=ABJC5GJKYHEGIOR3P2UIKX3QE4EVLA5CNFSM4G7ANE7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4PT3PQ#issuecomment-522141118 ، أو كتم موضوع https://github.com/ الإخطارات / unsubscribe-auth / ABJC5GKCHSPBRJ5JNNEVD5LQE4EVLANCNFSM4G7ANE7A .

مرحبًا dotMorten ، هل يمكنك تقديم أي تحديث؟ هل ما زلت تخطط لمحاولة تشغيل UPW + Shell؟ افهم أن هذا عمل لطف ومجتمع :) أتساءل فقط لأن جهودك تبدو أقرب إلى تشغيل Shell + UWP. لا يزال محيرًا تمامًا لما يبدو أنه محور Microsoft بعيدًا عن دعم Windows مع Xamarin. ممتن لكل الخير الآخر ، لكن لا يزال محتارًا ومحبطًا.

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

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

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

شكرا

متفق عليه ، أريد فقط معرفة ما إذا كان XF لن يشمل دعم Windows. إذا لم يكن كذلك ، فأنا أريد أيضًا أن أعرف لماذا لا؟ هل يعرفون ما هي حزمة Windows UX "التالية" التي ستكون بخلاف UWP ولا يريدون إضاعة الدورات؟ هل ستكون بعض عناصر Blazor / HTML هي القطعة التالية؟ إذا كان الأمر كذلك ، فقط أخبرني (لنا) حتى أتمكن من الانتقال ... ربما لإلغاء النظام الأساسي؟


من: Scott Kuhl [email protected]
تاريخ الإرسال: الخميس ، 22 أغسطس 2019 ، الساعة 1:21:22 مساءً
إلى: xamarin / Xamarin.Forms [email protected]
نسخة إلى: David Gerding [email protected] ؛ التعليق [email protected]
الموضوع: Re: [xamarin / Xamarin.Forms] Uwp Xamarin.Forms.Shell (# 5593)

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

pauldipietro https://github.com/pauldipietro هل يمكننا الحصول على تحديث حول هذا؟ يبدو لي أنني أرسل إشارة إلى أن دعم UWP لم يعد يمثل أولوية لفريق XF. إذا كان هذا صحيحًا ، فيرجى إخبارنا حتى نتمكن من وضع خطط حول ذلك.

شكرا

-
أنت تتلقى هذا لأنك علقت.
الرد على هذا البريد الإلكتروني مباشرة، مشاهدته على جيثب https://github.com/xamarin/Xamarin.Forms/issues/5593؟email_source=notifications&email_token=AAD7YD4EYE5XBBSXIR6MGV3QF3KKFA5CNFSM4G7ANE7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD456VUI#issuecomment-524020433 ، أو كتم موضوع https://github.com/ الإخطارات / إلغاء الاشتراك - المصادقة / AAD7YD42CJSV4KS5ZFWWJU3QF3KKFANCNFSM4G7ANE7A .

بصراحة تامة ، يبدو لي أن أفضل رهان هو استبدال XF بـ Uno Platform ...

أوضح Xamarin أن هدفه هو في الغالب الأجهزة المحمولة (الهواتف والأجهزة اللوحية والساعات) ، وليس أجهزة سطح المكتب أو أجهزة الكمبيوتر المحمولة.

ليس لديهم مصلحة في دعم وصيانة UWP بأنفسهم ، لذلك ليس من الجيد بالنسبة لي أن أوصي زبائني.

أريد توضيح حاجتي: لست بحاجة إلى _UWP_ لنماذج Xamarin. أحتاج إلى _ بعض Windows target_ لأشكال Xamarin. يبدو UWP وكأنه المرشح الأكثر قابلية للتطبيق. إذا كان عليّ أن أخمن أن Microsoft ستنتقل في النهاية إلى عميل HTML و Blazor لأجهزة الكمبيوتر المكتبية وتنتقل إليها لأنها قد تمنحهم أوسع وصول لـ UX في عالم ما بعد Windows. قد يتلاءم ذلك أيضًا بشكل أفضل مع مسار shell القابل للتكوين (وليس مسار xf). في حالة عدم وجود أي خارطة طريق متماسكة لجانب Windows من UX ، لا يمكنني تخيل ما قد يخططون له أيضًا.

ولكن لكي نكون واضحين ، فإن إسقاط دعم Windows لـ Xamarin دون الإعلان بأحرف كبيرة كبيرة ، "نحن لا ولن نفعل WINDOWS" ، هو ، على الأقل ، أمر غير لائق حقًا. يرن من "مايكروسوفت القديمة".

davidortinau وآخرون: من فضلك افعل شيئًا أكثر من الإشارة إلى الموتى الفعلي الآن (راجع أحدث منشورdotMorten ) "دعم المجتمع لـ XF Shell + Windows".

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

العديد من الأشياء التي قد تحتاج إلى تغيير وتتطلب شراء أوسع من فريق XF

أعلم أن أحد هذه الأمور له علاقة بـ WinUI الذي نأمل أن نجتذب إليه كتبعية مع هذا العلاقات العامة
https://github.com/xamarin/Xamarin.Forms/pull/7214

تحافظ العلاقات العامة على توافق 16299 ومن خلال اختباراتي تعمل بشكل رائع عندما يتم تضمينها مع كتلة صلبة ولا تتطلب من المستخدم تثبيت WinUI. ما زلت بحاجة للحصول على 16299 نسجًا في جهاز VM للتأكد ولكني ما زلت متفائلًا. أعلم أن @ dotMorten قد أعربت عن بعض المخاوف بشأن سحب WinUI ، لذا إذا تجاهلت تلك تمامًا ، فيرجى إبلاغي بذلك :-)

ها هي تلك الكتلة المعدنية.

Xamarin.Forms.4.3.0.1853.zip

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

المسار الذي أراه لهذا حاليًا هو

  • تم دمج # 7214 حتى نعتني بتبعية WinUI
  • احصل على إعادة تأسيس UWP Shell PR (لقد حددنا هذا لعدو سريع في المستقبل ، لذا سنفعل ذلك إما بعد ذلك أو إذا هزمنا شخص آخر)
  • لقد عمل مورتن بالفعل مع Gastropods ، لذلك نريد فقط اختباره ببضع عينات أخرى (بشكل أساسي Xaminals) ، بمجرد أن يعمل ذلك ونقوم بإجراء أي تغييرات مطلوبة في تنظيف الكود ، سنقوم بدمج

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

@ بيور وين ،
يمكنني تشغيل App132.zip باستخدام Xamarin Nuget الذي قدمته. يبدو أن التطبيق يعمل بشكل جيد ... على افتراض أنه من المفترض أن يضيف عناصر ذات طابع زمني للتحكم في القائمة. يضيف كل من الزر الموجود في الجزء العلوي وسلوك Pull to Refresh عناصر.

لست متأكدًا مما أبحث عنه ولكني أقدر جهودك وسأحاول تقديم المساعدة قدر المستطاع.

ديف جي

PureWeen @ رائع أن ترى أنك تمضي قدمًا مع WinUI. كان الاعتماد على WinUI يخلق سلوكيات متقطعة بالنسبة لي ، حيث كان WinUI يضيف تبعية لم تتم إضافتها بشكل مؤقت. هذا قابل للإصلاح إذا كنت تستخدم VS2019 ، لكنني لست متأكدًا مما إذا كان WinUI قد استفاد من هذه الميزة حتى الآن (وسيظل يؤثر على مستخدمي VS2017 ، ولكن على الأقل لديه حل بديل).
بالإضافة إلى ذلك ، كانت هناك أخطاء في WinUI تسببت في الكثير من المتاعب بالنسبة لي ، لكنني لاحظت مؤخرًا أنه تم إصلاح بعض الأخطاء التي قمت بتسجيلها ، لذلك كل هذا مشجع. اتصل بي بمجرد دخول 7214 ، وسأحاول أن أبدأ هذا الجهد.
كما أحب المساعدة في إعادة التأسيس. في المرة الأخيرة التي قمت فيها بذلك ، أفسدت تمامًا هذه العلاقات العامة :-)

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

لقد اختبرت التطبيق الذي أدرجته أعلاه في VS 2017 وعمل معي لذلك أعتقد أننا على ما يرام في هذا المجال

لست متأكدًا مما أبحث عنه ولكني أقدر جهودك وسأحاول تقديم المساعدة قدر المستطاع.

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

مجرد محاولة التحقق من أن إضافة تبعية WINUI لن تسبب أي صداع :-)

لقد اختبرت التطبيق الذي أدرجته أعلاه في VS 2017

بدون إضافة WinUI إلى رئيس المشروع؟ هذه هي المشكلة التي وجدتها: إذا قام الأشخاص بالترقية إلى إصدار من XF يعتمد على WinUI ، فلن يعمل بدون إضافة تبعية يدويًا إلى WinUI. IMHO هذا تغيير جذري. يمكن لـ WinUI تغيير الحزمة الخاصة بهم بحيث تعمل بشكل ضمني ، ولكنها تتطلب VS2019 لأنها تعتمد على ميزة NuGet 5.0 (و afaik لم يجروا هذا التغيير لذا لن يعمل في أي منهما الآن).

إليك المشكلة التي قمت بتسجيل الدخول إليها في WinUI: https://github.com/microsoft/microsoft-ui-xaml/issues/596#issuecomment -524187369

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

مجرد إضافة ذلك عندما اختبرت app123 كان مع VS2019.

بدون إضافة WinUI إلى رئيس المشروع؟

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

لا أفهم حقًا كيف يعمل ذلك. هناك نمط يجب إضافته وحزمة إطار عمل appx إضافية يجب تثبيتها مع الحزمة ، ويتم كل ذلك بواسطة .targets. هل حزمة إطار العمل مثبتة بالفعل على جهازك؟

مجلة Visual Studio Magazine غطت للتو هذه القضية على وجه الخصوص. مايكروسوفت ، حان الوقت لرد رسمي.

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

dotMorten أنا في الخارج لبضعة أيام ولكن

يعمل هذا الهدف بشكل عابر عندما اختبرت على VS 2017
https://github.com/microsoft/microsoft-ui-xaml/blob/8f8cd0fe32754cfcd83dafb2fc8539703b6aec26/build/NuSpecs/MUXControls-Nuget-Common.targets#L6

إليك nuget محدث يتيح لك تجاوز الإعداد في مشروع النماذج المحلي
Xamarin.Forms.4.3.0.1853.zip

<SkipMicrosoftUIXamlCheckTargetPlatformVersion>false</SkipMicrosoftUIXamlCheckTargetPlatformVersion>

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

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

PureWeen هذا هو الشيء الذي يجب أن يعمل دون إضافة هذه الأسطر بشكل صريح (حيث يتعين على جميع المستخدمين تحديث رؤوس مشاريعهم أيضًا):
image

أعتقد أنك تقول أنه يعمل ، ولكن فقط تأكد من أننا على نفس الصفحة.

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

إعادة: الحاجة إلى هدف سطح مكتب / كمبيوتر محمول / جهاز لوحي لأشكال Xamarin

بالنسبة لأولئك منا الذين يقومون ببناء تطبيقات الهاتف المحمول في بيئات الشركات ، فإن القدرة على إنتاج سطح مكتب / كمبيوتر محمول قابل للتنفيذ "للعمل على حد سواء" من نفس قاعدة التعليمات البرمجية الأساسية مثل قاعدة Android / iOS أمر ضروري. لا يلزم أن يكون Windows فقط (سيكون الهدف المستند إلى المستعرض مثل HTML / JS جيدًا بنفس الدرجة) ولكن الغالبية العظمى من مستخدمينا لديهم سطح مكتب / كمبيوتر محمول يعمل بنظام Windows + هاتف iPhone / Android ، لذا فإن ملف Windows القابل للتنفيذ هو جيد بالنسبة للجزء الأكبر.

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

تعمل نماذج Xamarin بشكل جيد مع هذه السيناريوهات ، ونود حقًا استخدام Shell و CollectionView ، لكنها تمثل برامج رفوف لنا حتى يمكن استخدامها لإنتاج عمل سطح مكتب / كمبيوتر محمول على حد سواء ...

dotMorten لذا فإن السبب في أنني لا أرى الاستثناء هو أن لديّ WinUI كاعتماد على الكتلة ، لذا إذا قمت بتثبيت XF على رأس UWP ، فإن WinUI يأتي أثناء الرحلة ويطبق أهدافه.

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

لقد تحدثنا عن هذا قليلاً في هذه المسألة
https://github.com/xamarin/Xamarin.Forms/issues/4126

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

تضمين التغريدة يسعدنا أن نرى نفس الشيء بعد ذلك. بعض الأشياء التي يجب مراعاتها في مناقشاتك:

  • إذا تم دمج العلاقات العامة الخاصة بي في WinUI ، فسيؤثر ذلك فقط على مستخدمي VS2017 (والذي قد يصبح غريبًا إذا استخدم الفريق كليهما ويؤثر فقط على بعض المستخدمين).
  • يمكنك اكتشاف هذا أثناء Init () وإلقاء خطأ يخبر المستخدمين بالضبط بما يجب عليهم فعله حتى لا يكون الألم سيئًا للغاية.
  • كنت أتلاعب بفكرة أن XF لديه ملف أهداف يضيف التبعية إلى مشروع الإحالة إذا لم يكن موجودًا بالفعل ، ولكن يمكنه
    خلق تجربة تطوير غريبة.
  • ستستخدم جميع مشاريع UWP دائمًا هذه التبعية بمجرد فصل WinUI عن النظام الأساسي (ولكن بحلول ذلك الوقت ، من المحتمل أن يكون VS2017 خارج الدعم على أي حال).

    • ستتمكن من دعم الإصدارات الأقل من Win10 مع هذا التغيير ، مما يؤدي إلى إنشاء قيمة مضافة يمكن أن تبررها.

    • لن يلاحظ أحد لأنه وفقًا لفريقك ، لا أحد يستخدم UWP حقًا على أي حال 😜 j / k

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

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

إليكم طعم Xaminals الذي يعمل على UWP مع السيرة الذاتية و Shell !!!

image

عمل عظيم!

بعمل رائع. سنقوم بتضمينها في إطار عملنا لبناء تطبيقات على مستوى المؤسسة بمجرد ظهورها

عمل رائع ، سأحاول في إصدار مستقبلي من تطبيقي ؛)

نعم ، Xamarin فعل ذلك! قرأت رجلاً يقول إننا ننتقل إلى أونو. رقم!!!! لقد كان Xamarin رائعًا بالنسبة لنا ووفر لنا الكثير من الوقت لنتعلم كيف تتعلم Swift + java. دعونا نتحلى بالصبر مع الفريق وندعمهم

مغلق بـ # 6015

عمل رائع ، شكرًا لكل فريق <3 ، سأديره 💃

عمل رائع ، شكرا جزيلا!

حسنًا ، حدث شيء غريب ، لقد قمت بترقية مشروعي لاستخدام 4.3.0.947036 ، والآن يفشل المشروع عند استدعاء النماذج.
"تعذر العثور على نوع وقت تشغيل Windows" Microsoft.UI.Xaml.Controls.XamlControlsResources

الغريب جدًا هو مقدار الكود الموجود الآن في XamlTypeInfo.g.cs ، في الإصدار السابق من Xamarin ، كان لدينا 13 إدخالًا فقط ، والآن لدينا أكثر من 43 إدخالًا. لا تساعد. أيه أفكار

@ abrantie1z - (على الرغم من أنها خارج الموضوع ، أعتقد أنني سأذكر) لم يعد من الضروري أن تكون نماذج Uno و Xamarin خيارًا حصريًا للطرفين - راجع https://platform.uno/xamarin-forms/ و https: / /visualstudiomagazine.com/articles/2019/09/19/uno-platform-2.aspx تحذير: لم أستخدم Uno ، لذلك ليس لدي أي فكرة عن مدى قوة هذا الدعم. ولكن أي شيء يثير اهتمام المزيد من الأشخاص بـ XF في المتصفحات يعد أمرًا جيدًا.

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات