Xamarin.forms: ماذا عن الأشياء الموجودة في كل مكان لأشكال Xamarin؟

FWIWjuepiezhongren أنا أحقق في Ooui هنا:
https://github.com/praeclarum/Ooui

إذا كانت هناك طريقة لتجميعها باستخدام

لا تزال في حالة تجريبية قليلاً ، لكنها لفتت اهتمامي. 👍

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

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

لجميع المقاصد والأغراض ، HTML5 هي آلية العرض في كل مكان ، ولكنها متأصلة جدًا في JavaScript حيث تقدم TCO باهظًا عند إقرانها مع .NET. ما يقدمه Ooui هو احتمال استخدام HTML5 / CSS كآلية عرض ، مع الاستمرار في استخدام .NET حصريًا لبقية التطوير ، وبالتالي الاحتفاظ بالمعرفة ، والاستفادة من الاستثمارات الحالية ، وبالتالي تقليل تكاليف التطوير الإجمالية. بعد ذلك ، يُترك للمطورين قاعدة شفرة واحدة لكل من العرض التقديمي والبنية التحتية الداعمة له ، ويعملون عبر iOS و Droid و Windows و Web. شيء يطالب به العديد من مطوري .NET منذ عدة سنوات حتى الآن .

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

كان خيط صوت المستخدم عبارة عن دعوة لشيء مثل Xamarin.Forms. تم نشره في عام 2015 قبل أن تشتري Microsoft Xamarin. من متطلباته ، تم إصدار Xamarin.Forms على 1) Windows 10 4) Droid 5) iOS ، قيد المعاينة على 3) * nix (Unix / Linux) 6) Macintosh ، بدأ مع 2) نظام Windows القديم ، ولم يعد كذلك 7) HTML5 مختلف جدا. وفي الواقع ، تغطي أنظمة Windows 10 و Droid و iOS و Legacy windows و Mac 99.5٪ من أجهزة العميل. منذ Xamarin.Forms موجود ويقوم بكل هذا الآن ، ليست هناك حاجة لحل كبير آخر.

الأشياء الوحيدة المطلوبة هي:

• اجمع Xamarin.Forms مع WPF عن طريق تسريع Xamarin.WPF
• أعلن عن Xamarin.Forms: يبدو أنه لا يزال هناك بعض مطوري Net الذين لا يعرفون شيئًا عنها.

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

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

شكرًا لك على الوقت الذي قضيته في تقديم آرائك ،charlesroddie. أنا أقدرهم كثيرا.

ولا يفعل 7) HTML5 مختلف جدًا

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

ليست هناك حاجة لحل كبير آخر.

الفكرة هنا ليست حلًا كبيرًا آخر ، لكنها حل أبسط. إذا كنت تأخذ وقتًا في قراءة التعليقات الخاصة بـ UserVoice (كثيرًا ما تكون حية بالمناسبة 😄) ، فلا يوجد الكثير من المعجبين بـ Xamarin.Forms هناك. أنا شخصياً أؤيد المشروع (وجميع الأشياء Xamarin!) ، ولكن في نهاية اليوم ، فأنت تدعم عدد n من مجموعات العروض التقديمية ، لكل منها خصوصياتها واعتباراتها (والتي كما نعلم جميعًا أدت إلى جودة رديئة للغاية والتي أصبح الآن مجرد التعامل مع نفسه). بالإضافة إلى ذلك ، هناك العارضين المخصصين بالكامل والذي كان يمثل مشكلة في حالة احتياجك إلى عرض محدد لكل نظام أساسي. قارن ذلك مع النموذج حيث تقوم ببساطة بالحفاظ على تقنية عرض تقديمي واحد (HTML5) والأنظمة الأساسية ببساطة تعرض HTML5 التي كانت تدعمها وقادرة على القيام بذلك لسنوات عديدة حتى الآن. يتم تطبيق العرض الخاص بالمنصة ببساطة عن طريق تطبيق نمط معين.

أنا لا أقول إنها مثالية ، لكنها تبدو أخف بكثير ويمكن صيانتها على المدى الطويل - ناهيك عن CHEAPER ، LOL!

ومع ذلك ، ضع في اعتبارك أن مساحة تصميم HTML5 مليئة بالمواهب المخضرمة ، خاصةً فيما يتعلق بـ CSS. من منظور الأعمال ، يقلل هذا من التكلفة الإجمالية للملكية (TCO) لأنك لا تهتم فقط بتقديم تقنية عرض تقديمي واحد (بدلاً من n +) ، ولكن هناك الكثير من الموارد القادرة على العمل في هذا الفضاء لتوفير عمل عالي الجودة حوله. على سبيل المثال ، إذا كان لديك معدل دوران ، فسيكون من الأسهل العثور على مورد يعرف تقنية عرض واحدة (متخصصة - جودة أعلى) ، مقابل العثور على مورد يعرف n + (معمم - جودة أقل).

أعلم أنه من المتجذر في مجتمعنا التفكير في الويب على أنه "مختلف" ولكن يبدو أكثر فأكثر أن هذا "الاختلاف" قادر على تغيير كل شيء نعرفه عن العرض التقديمي في .NET space.
هذا هو انطباعي عما يحدث على الأقل. لكن من المعروف أنني مخطئ من وقت لآخر. 😉

ليس لدي أي خبرة في تكنولوجيا الويب وعندما قلت مختلفًا جدًا ، كنت أعني أن التكنولوجيا الحالية تبدو بعيدة جدًا عن سد الفجوة بين هياكل التطبيقات المحلية وتطبيقات الويب. Xamarin.Web سيكون فكرة جيدة ولكن يصعب تنفيذها ، على الرغم من أنه قد يكون هناك دليل على المفهوم قائم بالفعل على Ooui. في سياق Xamarin.Forms ، هذا يعني بالطبع لغة html أقل وليس أكثر.

هذا هو آها هنا ، في الواقع. لا أعتقد أن الأمر بهذه الصعوبة على الإطلاق ، مع الأخذ في الاعتبار. لا يدعم Ooui (حتى الآن) ربط البيانات ، أو أي نوع من تركيبات Xaml ، ولكن يجب أن تكون هذه سهلة التنفيذ بدرجة كافية. أيضًا ، من فضلك لا تفهموني خطأ هنا لأنني لست من محبي HTML على الإطلاق ، في الواقع Xaml هو مطلب مدرج في UserVoice المذكورة أعلاه. ولكن الآن بعد ما يقرب من 3 سنوات ، فأنا على استعداد للتنازل عن هذا إذا كان ذلك يعني قاعدة بيانات واحدة للوصول إلى السوق بنسبة 100٪. بالإضافة إلى ذلك ، لست متأكدًا مما إذا كنت قد رأيت ذلك ، لكن Ooui هو في الأساس نموذج مجمّع / محول حول عناصر HTML5. لذلك ، ستعمل مع كائنات .NET ولن تضطر إلى التعامل مع علامات div و yuck . هذا ما لفت اهتمامي هنا ، من بين أمور أخرى.

@ Mike-EEE أفالونيا هي تجربة لطيفة حقًا

أعتقد أن الشيء الأكثر إنتاجية لمطوري نماذج Xamarin هو إحياء https://github.com/chrfalch/NControl عن طريق نقله إلى SkiaSharp. سيسمح ذلك بضوابط إنشاء سهلة لا تتطلب سوى أنواعًا معينة من التفاعل ، وستتصرف هذه الضوابط بشكل متماثل عبر الأنظمة الأساسية ، وستدعم على الفور جميع الأنظمة الأساسية التي تدعمها SkiaSharp.

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

محرك الرفرفة هو c ++ و Dart - التي تكاد تكون مجموعة فرعية من c # - يجب أن تكون "قابلة للنقل" إلى C # و Xamarin.

أعتقد أن الطريقة الأكثر إنتاجية لركوب قطار التزلج هي جعل Xamarin يتبنى Flutter ويساعد Google في المضي قدمًا. يمكن أن تقدم Xamarin تكاملًا أفضل للنظام الأساسي.

نعم ، لن يكون مجهودًا في النماذج (على سبيل المثال ، يعد Redux خيارًا أكثر وضوحًا من MVVM) ، ولكنه سيكون رائعًا جدًا :)

تعال إلى مرض التصلب العصبي المتعدد. احتضان ومد كما كان بالأمس. عليك أن تفعل ذلك على أي حال إذا أصبحت الفوشيا شيئًا.

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

timahrentlov هل

juepiezhongren لم أجد مثل هذه المقارنة للرفرفة.

timahrentlov أعني مقارنة xamarin.forms مقابل رد فعل مواطن مع الأخذ بعين الاعتبار mvvm مقابل redux

@ Mike-EEE هل لاحظت العاصفة من Blazor و frank's ooui-wasm؟

juepiezhongren في الواقع ... بدأت الأمور تسخن! 🎉

@ Mike-EEE تفكر في ubis من أجل wasm ، skiasharp ليس خيارًا جيدًا.

samhouts ماذا يعني t-enhencement؟

بصراحة juepiezhongren ، أعتقد أن الخيار الحقيقي الوحيد على المدى الطويل هو HTML5 / CSS. لهذا السبب أنا مهتم بنهج WebSocket Bridge (Ooui). إنه خفيف الوزن وأقل حملًا من WASM. تمتص CSS ولكن مع القليل من الشحوم أعتقد أننا كمطورين يمكن أن نجعلها تعمل. 😉 على أي حال ، لدي شعور بأننا على بعد حوالي 12-18 شهرًا من شيء قابل للتطبيق حقًا ، وهو أمر رائع. Ooui و Blazor ليست سوى البداية / الرواد (درب Blazors؟ hah hah).

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

@ Mike-EEE نعم ، إنها CANVAS في html5 ، تمامًا مثل echarts.js التي ترعاها بايدو ، والتي تجعلها جيدة جدًا. لذلك ، يجب فصل محرك التصيير.

نقية HTML5 أسرع ،juepiezhongren. السيناريو الأكثر مثالية هو استخدام عناصر تحكم HTML5 DOM ، حيث يتم العرض بالفعل على لوحة NATIVE. 😉 بخلاف ذلك ، فأنت تقوم بالعرض على HTML5 Canvas وتقوم بتحديثه عبر JavaScript وهو slooooooow من خلال المقارنة وكثافة الموارد. بالطبع ، لا يزال من الممكن استخدام HTML5 Canvas لعناصر تحكم معقدة غير أصلية (مثل الرسوم البيانية ، إلخ) ، ولكن لا ينبغي استخدامها كسطح عرض ، IMO.

ما هو نقي HTML5؟ @ مايك- EEE شيء لا شبيبة؟

حسنًا ، juepiezhongren ... استخدام جميع عناصر التحكم "الأصلية" المخبوزة (يجب توخي الحذر عند استخدام هذه الكلمة ، LOL) في HTML5 بدلاً من إنشاء عناصر تحكم جديدة لعرضها عبر عنصر تحكم HTML5 canvas (شيء أنت سوف نرى في الوحدة أو JSIL ).

بالطبع ، هذا يعتمد على سياقك والتطبيق الذي تقوم ببنائه. في كل محادثتي ، أفترض / أفكر في العمل / LOB بشكل افتراضي ، لذلك يفضل استخدام HTML5 "الخالص". إذا كنت تقوم بتنفيذ سيناريوهات لعبة / رسومات مكثفة ، فإن WASM هو خيارك الأول ، متبوعًا بعنصر تحكم canvas .

أعتقد أنه من الأفضل ترك HTML5 في الخلف لصالح XF على SkiaSharp. إن برنامج ooui رائع ، لكنه سيعاني دائمًا من الاضطرار إلى تحويل عناصر تحكم XF إلى HTML. فقط اذهب مباشرة إلى القماش هو ما أقوله. قد تكون إمكانية الوصول / تحسين محركات البحث مشكلة الآن ولكن لا ترى لماذا لا يمكن التغلب على ذلك بنفس الطريقة التي يمكن الوصول بها إلى winforms التي تستخدم GDI.

صحيح yowl ... يعتمد على السيناريو ، حقًا. ستعمل تطبيقات LOB البسيطة بشكل جيد للغاية مع نهج Ooui. لاحظ أني أقول نهج (جسر WebSocket) وليس Ooui على وجه التحديد. Ooui بعيدة تمامًا عن كونها قوة عظمى شرعية.

SkiaSharp لا يعمل على الويب ، لذلك ستظل بحاجة إلى تطبيق آخر لتشغيله هناك. ما لم تستخدم WASM ، بالطبع. لكن هذا تنزيل أكبر. كل شيء يسير في HTML5 / web / lightweight هذه الأيام. التطبيقات التي يتم تحميلها بشكل أسرع وأكثر سرعة بسببها ستكون تلك التطبيقات التي تكتسب المستخدمين وبالتالي جذب السوق. نحن نشهد هذا مع PWAs وتقنية الويب ككل.

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

ومع ذلك ، أنا أتفق معك على أنه سيكون هناك في النهاية سيناريوهان هنا: HTML5 لغالبية جيدة من التطبيقات (التي تتطلب إمكانية الوصول / تحسين محركات البحث 😄) ، ثم WASM للتخصص / كثيف الرسومات / الألعاب / إلخ. إن عرض تقنية العرض المثالي يلبي احتياجات كلا المعسكرين بسلاسة حتى لا يضطر المطورون إلى معرفة الاختلافات (أي الصداع) أو التعامل معها (أي الصداع) لكليهما.

أنت تقول إن SkiaSharp لا يعمل على الويب وبقدر ما أعرف أنه لم يقم أحد ببنائه من أجل wasm ، لكن Skia تفعل ذلك لذا أتخيل أنه ممكن. أو قم ببناء XF بواجهة Skia الخلفية ، نفس الشيء. أنا متأكد من أن الأشخاص الأحاديين لديهم شيء ما في جعبتهم ، ابحث عن شيء ما في Build في مايو.

نعم ، لقد كنت أنتظر _years_ الآن // build لإظهار شيء مثير ،yowl. حتى الاتصال () ؛ تم تقليل الأحداث إلى التفاخر بشأن تشغيل .NET على الثلاجات والأجهزة الأخرى (قيمة منخفضة جدًا) بدلاً من تشغيلها في صفحة الويب (قيمة عالية للغاية).

أنا آخذ المزيد من نهج "سأصدق ذلك عندما أراه" هذه الأيام. 😉 بالنسبة لسيرك هذا العام ، لا أتوقع سماع أي شيء مهم بخلاف تطبيقات الويب التقدمية ، وكيف تمكنت MSFT من "دمجها" في نظامنا البيئي مع جعل العمل معها مكلفًا قدر الإمكان كمطوري .NET. هناك شريحة صغيرة من التفاؤل من أجلك. 🎉

ستعمل Skia + Canvas مع http://webassembly.org. ستحقق الرفرفة ذلك في المستقبل "أحضر واجهة المستخدم الخاصة بك". قد يكون هذا http://webassembly.org/demo/Tanks/ أيضًا تطبيق Skia للأعمال.

timahrentlov skia + قماش؟ تم تنزيل 10 ملايين ، إنه كبير حقًا.

أنا فقط أتساءل ، ماذا عن xamarin.flutter؟

أتفق مع juepiezhongren ، حجم skia كبير

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

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

يعد إصلاحها وإضافة ميزات جديدة معركة شاقة مستمرة ستزداد سوءًا مع إضافة المزيد من المنصات. Mac OS x، OOUI / Web، Tizen، أيا كان. سوف يطحن حتى يتوقف. أعني ، لقد حدث ذلك تقريبًا. إنه نهج DOA. وستعمل أدوات مثل الرفرفة في دوائر حول XF.

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

لا يهمني حقًا Flutter أو Tizen أو أي أشياء أخرى. كل ما يهم في تطوير الأجهزة المحمولة هو iOS و Android. ثم ربما UWP. لا أهتم كثيرًا بنظام التشغيل Mac OS X و WPF ، على الرغم مما يقوله الناس. إن محاولة توحيد الهاتف المحمول وسطح المكتب عندما لا تتمكن حتى من التعامل مع الهاتف المحمول (iOS و Android) أمر محزن.
Xamarin Forms هي حقًا أفضل مثال على Jack من جميع المهن ، سيد لا شيء. إنه مشروع OSS بدأ كمشروع عطلة نهاية الأسبوع. العمل المهم الوحيد هو تجميع XAML.
بخلاف ذلك ، ينتظر Xamarin إلى حد كبير المطورين في البرية لمواصلة العمل. لا يوجد حتى الآن التزام جاد بجعل الإطار كما ينبغي أن يكون حقًا.
مؤتمر Build قادم وسيعلنون بأجراس وصفارات مدى روعة نماذج Xamarin 3.0. في الواقع ، ستظل هناك نفس الأخطاء والقيود.

نحن بحاجة إلى كل من السكان الأصليين و ubi. xf جيد بما فيه الكفاية ، بسبب استخدام جميع واجهات برمجة التطبيقات الأصلية مع c #. يجب أن يكون ubis مهمًا أيضًا.

هل يمكن لأي شخص أن يعطي مثالاً على أي مشروع / إطار عمل / أداة أخرى بها العديد من الاتجاهات مثل نماذج Xamarin؟ ما أعنيه بـ "الاتجاهات" هو Android و iOS و UWP و Mac OS X و CSS و Flexbox و Tizen و WPF. هل فوت اي شيء؟ الويب / HTML؟ مجنون...
يبدو الأمر كما لو كان أحدهم يقول باستمرار "هل هناك أي شيء آخر يمكننا اللعب به اليوم"؟ يبدو الأمر كما لو أن شخصًا ما يقوم بالتجربة باستمرار. لا حرج في التجربة ، لكن من الغريب التحدث عن الأشياء التي تعمل عليها كما لو كانت صلبة ، في حين أنها كلها تجارب في الواقع.

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

يبدو أنه خلال العامين الماضيين لم يكن هناك أي بالغ في المنزل. من كان وراء عجلة القيادة ، يخطط للدورة؟ اي فصل؟

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

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

يمكن لمرض التصلب العصبي المتعدد أن يجعل الأمر أسهل على أنفسهم وأن يكونوا أشبه بالرفرفة. _XF يحتاج إلى إحضار واجهة المستخدم الخاصة به! _

في الوقت الحالي ، يبدو الجانب النبال مغرًا بالنسبة لي!

لم تكن Microsoft تهتم كثيرًا بنماذج Xamarin ... تستخدم Microsoft فقط شيء Xamarin للهاتف المحمول لمحاولة التبشير والحفاظ على مستوى .NET hype على قيد الحياة ... لا تزال Microsoft تعيش في الماضي ، في "المطورين والمطورين والمطورين "عصر الضجيج. وهذا ليس سيئًا ، لكن السيئ هو أن الأمر أكثر ضجيجًا من الجودة الآن.
الواقع هو أن معظم المطورين يستخدمون أجهزة MacBooks ولا يهتمون بـ Windows و .NET لفترة طويلة الآن. فشلت Microsoft في كل مكان تقريبًا في مساحة الأجهزة المحمولة والأجهزة. إنهم يكافحون من أجل الحفاظ على الضجيج على قيد الحياة ولكنه كان صعبًا جدًا. على مستوى الإدارة ، فشلت مايكروسوفت بشدة. لا تفهموني خطأ ، فهناك العديد من الأشخاص التقنيين الرائعين حقًا في Microsoft ، وأنا أتحدث عن الأشخاص ذوي المستوى المنخفض / التقنيين.

إذا بدأت MS فقط في استخدام XF لتطبيقاتها الخاصة ..

كيف يمكن أن؟ الأداء ليس حيث ينبغي أن يكون.

Reality is most of developers are on MacBooks هل لديك أي شيء يدعم ذلك؟

هل لديك أي شيء لتستعيده؟

لا ، ولكن إذا نظرت إلى أكثر التقنيات شيوعًا ، يمكنني أن أؤكد لك أن الغالبية العظمى من هؤلاء المطورين موجودون على أجهزة MacBook

opcodewriter ما

@ encrypt0r نعم ،

النظر في مقابل الشعبية ؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟

تأخرت Kinda في الحفلة هنا ، ولكن حتى Xamarin موجود على تقنية الويب الآن:
http://www.davidortinau.com/blog/styling_xamarin_forms_with_css

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

بعض المناقشات الإضافية حول هذا هنا:
https://twitter.com/migueldeicaza/status/972525236301238272

@ Mike-EEE ، هل شاهدت قضايا السحب والمادية؟

ليس لدي juepiezhongren ... هل هذا إشارة إلى HTML أو النماذج؟

@ مايك إي
https://github.com/xamarin/Xamarin.Forms/issues/2452
https://github.com/xamarin/Xamarin.Forms/issues/2415

هذا رائع

نعم ليس سيئًا juepiezhongren ولكن لا يستحق الوقت / المال / الجهد / الموارد إذا لم يكن موجودًا في كل مكان في المقام الأول. :)

لا تتعلق Material Shell بهذه المشكلة ، ولكن عناصر التحكم الأصلية لا تزال على غرار عناصر التحكم الحقيقية في كل مكان.

تضمين التغريدة
يعجبني هذا المفهوم ، ولكن ليس بالطريقة التي وضعتها به.

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

MisterJimson في الواقع الفكرة هي أن الغلاف المادي يجلب بطبيعته ضوابط في كل مكان

@ jassmith كيف بالضبط؟ تقديم عناصر تحكم أصلية خام أو تصميم؟ ستحتوي عناصر التحكم الأصلية على التصميم دائمًا على بعض التناقضات ، حتى لو كانت قليلة.

ويستندMisterJimson قذيفة على باسم Skia أو دائرة الرقابة الداخلية كوريدراو المعهد، وأعتقد
jassmith إذن ، سيكون هناك fluentShell أو cupertinoShell؟

MisterJimson asjuepiezhongren نعم الفكرة هي أنها ترسم بالكامل من الصفر. لن تضطر إلى الاعتماد على النظام الأساسي المستهدف ولكن يمكنك بالتأكيد أن تطلب منه ذلك. الهدف هو إحضار Material (مع MaterialShell على الأقل) في كل مكان.

تضمين التغريدة المشكلة الآن هي أن كل من FluentShell و CupertinoShell سيعتمدان بشكل كبير على Live blur. Android جميل وقد تمكنوا بطريقة ما من تجنب الحصول على عرض ضبابي مباشر فعال. جعل هذا من المادة الهدف الأول الطبيعي بينما نكتشف بالضبط ما يجب فعله حيال هذه المشكلة.

لكي نكون واضحين ، لا تقوم شل بالرسم ، كما تفعل MaterialShell.

هل رأيتم هذا يا رفاق - https://github.com/SteveSandersonMS/BlazorElectronExperiment.Sample ؟
فقط لسطح المكتب ، وليس منصات المحمول.

gulshan جانب الخادم أمر جيد

juepiezhongren على الأفكار
https://github.com/xamarin/Xamarin.Forms/issues/4435

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

PureWeen أنا لا

أو ، فقط اجعل عناصر التحكم الحالية مطبقة بالكامل ، فإن الكثير من الخصائص غير صالحة أثناء وضع الغلاف وصالحة أثناء وضع skia

لقد أحرزنا الكثير من التقدم في Visual في الأشهر القليلة الماضية. يسعدنا أن نحصل على تعليقاتك بشأنها. ندعوك لتجربة التحدي المرئي وإعلامنا بما إذا كان هذا يحل أي نقاط ألم دفعتك إلى تقديم هذا الاقتراح. شكرا! https://github.com/davidortinau/VisualChallenge

samhouts visual جيد ، لكننا نحتاج إلى رسم ، نحتاج إلى حل مثالي للبكسل

إذن ، أين يقع طلب التحسين هذا عند تعليقه مقابل المواصفات المرئية والرسم https://github.com/xamarin/Xamarin.Forms/issues/2452

ببساطة لأن عناصر تحكم xf الحالية تفتقر إلى خاصيتين كبيرتين للتخصيص الشخصي ، على سبيل المثال. فرشاة ، قالب تحكم ، إلخ.

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

https://github.com/xamarin/Xamarin.Forms/issues/5005

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

لقد أحرزنا الكثير من التقدم في Visual في الأشهر القليلة الماضية.

من جانبنا ، يعتبر Windows وسطح المكتب أولًا. لا يدعم المرئي حتى UWP ، ولن يجربه حتى.

أعتقد أنه يمكننا إغلاق هذا الآن لأننا نحرز تقدمًا في # 2452. شكرا!