نماذج Xamarin و MVVMCross و SkiaSharp: الثالوث المقدس لتطوير التطبيقات عبر الأنظمة الأساسية
نشرت: 2022-03-11تحدث عن وضع توقعات عالية. الثالوث المقدس ، لا أقل!
الحقيقة هي أن تطوير تطبيقات الأجهزة المحمولة يكون مكلفًا عندما تستهدف منصات متعددة ، لأنه لا يوجد رمز مشترك. تطلب منك Apple البرمجة في Objective-C أو Swift ، ويطلب منك Android الترميز في Java ، ويتطلب WinPhone التطوير في .NET ، غالبًا C #. أضف إلى ذلك العدد الكبير من المكتبات التي توفرها كل منصة للتعامل مع الخرائط أو الرسم أو الصور أو نظام تحديد المواقع العالمي (GPS) - يلزم قدر هائل من الوقت والمعرفة لإنشاء تطبيق جوال واحد.
وغني عن القول ، أن معظم الشركات الناشئة لا تستطيع تحمل نفقاتها ثلاث مرات ، وحتى الشركات القائمة يمكن أن تجد صعوبة في تبرير سعر الدخول إلى مساحة الهاتف المحمول.
في هذه المقالة ، ستتعلم كيف يمكن أن تكون نماذج Xamarin ، بالاقتران مع MVVMCross و SkiaSharp ، طريقة قابلة للتطبيق لبناء تطبيقات جوال عبر الأنظمة الأساسية دون المساومة على الألفة والأداء والتفرد. ستراجع المقالة هذه التقنيات الثلاث وكيف يمكنها تقليل تكلفة التطوير من خلال السماح بإعادة استخدام الرمز الأقصى عبر منصات متنقلة متعددة.
مشكلة مهمة
تعد مسألة تطوير تطبيقات الأجهزة المحمولة عبر الأنظمة الأساسية أمرًا حقيقيًا ، وعلى هذا النحو ، ظهرت العديد من الحلول المختلفة على مر السنين لتقليل تكاليف التطوير من خلال مشاركة الكود بين الأنظمة الأساسية. في صناعة ألعاب الفيديو ، على سبيل المثال ، توفر جميع محركات الألعاب الرئيسية حلاً متعدد المنصات ، مع استهداف Unreal و Unity للهواتف المحمولة والأجهزة اللوحية.
على صعيد التطبيقات ، كانت هناك محاولات متعددة لقيادة هذا السوق عبر الأنظمة الأساسية على مر السنين. فشل الكثير منهم وفقدوا في الهاوية ، لكن اثنين منهم ما زالوا على قيد الحياة بعد عدة سنوات. من بينها Xamarin ، الحل الوحيد من خلال .NET الذي يقدم الدعم لجميع المنصات المحمولة الثلاثة.
مواطن أم لا ، لقد جئت إلى هنا
إذن هناك حرب تدور بين الحلول المختلفة ومن يقول الحرب تعني الدعاية!
يتم خوض الحرب في الغالب على جبهة N الكبيرة: أن تكون مواطنًا! يجب أن تكون حذرًا من الكلمة لأنه ليس لها معنى واضح. إنها الكلمة الأكثر استخدامًا في عالم تطوير الأجهزة المحمولة في الوقت الحاضر وهي عصرية جدًا. الحقيقة هي أنه لا أحد يوافق على ما تعنيه بالفعل.
عند تحديد إطار عمل عبر الأنظمة الأساسية ، فإن جميع الخيارات "الأصلية" ليست متساوية ، لذا احترس ، فقد تقارن التفاح بالبرتقال. بالنسبة للبعض ، يتعلق الأمر بلغة البرمجة ، وبالنسبة للآخرين يتعلق الأمر بالقدرة على استخدام ميزات الأجهزة ، يعتقد البعض الآخر أن الأمر يتعلق باستخدام واجهات برمجة التطبيقات / واجهة المستخدم للنظام الأساسي ، وغالبًا ما يتعلق الأمر فقط بعدم كونه تطبيق ويب.
هناك حجج في كل جانب من النقاش ولن أتعمق أكثر لأنه عديم الفائدة. لماذا هو عديم الفائدة؟ حسنًا ، دعني أخبرك بحقيقة يصعب تقبلها: المستخدمون النهائيون لديك لا يهتمون!
نعم ، لقد قرأت هذا بشكل صحيح ، فقط المبرمجون لديك هم من يهتمون. لن يختار المستخدم النهائي تطبيقك أبدًا بسبب التكنولوجيا الأساسية: سيختار التطبيق الخاص بك لأنه يجيب على مشكلته ويعطي تجربة جيدة.
لذا بدلاً من الخلاف حول معنى الكلمة ، دعنا نلقي نظرة على كيفية قيام Xamarin بتوفير طريقة فعالة لمنح المستخدمين ما يهتمون به.
الآب والابن والروح القدس
قبل المضي قدمًا ، دعنا نوضح فقط العناصر الثلاثة التي تشكل حلنا لمشكلة التطوير عبر الأنظمة الأساسية.
الأب: زامارين
كما ذكرنا سابقًا ، Xamarin هو حل .NET لتطوير تطبيقات الأجهزة المحمولة وسطح المكتب. تم شراؤها من قبل Microsoft في عام 2016 ولكن يعود تاريخها إلى حوالي أربع سنوات مع مشروع Mono. في الوقت الحاضر ، يتميز بثلاثة حلول: Xamarin.iOS و Xamarin و Android و Xamarin.Mac. الأنظمة الأساسية الأخرى تتعامل بالفعل مع تطبيقات .NET افتراضيًا ، كونها حلول Microsoft. باختصار ، يوفر Xamarin رابطًا مباشرًا إلى واجهات برمجة تطبيقات النظام الأساسي في .NET. لذلك ، يمكنك استخدام الميزات الأصلية من تطبيق .NET. هناك أيضًا وحدة امتداد لـ Xamarin تسمى Forms والتي توفر طبقة تجريد لواجهة المستخدم.
الابن: SkiaSharp
SkiaSharp هو برنامج التفاف .NET على مكتبة رسومات Google Skia المتجهية. Skia هو محرك العرض الأصلي لـ Android و Chrome و ChromeOS و Firefox. باستخدام SkiaSharp ، يمكنك استخدام المكتبة في تطبيق .NET لجعلها مشتركة بين الأنظمة الأساسية. هذا يعني أن الظل الأنيق الذي يقول مصممك "سيجعل تطبيقك أفضل كثيرًا" يمكن ترميزه مرة واحدة فقط بدلاً من تكراره لكل نظام أساسي مستهدف. أنا شخصياً أعتقد أن أفضل ميزة لها هي القدرة على تقديم رسومات SVG بطريقة تمكّنك من منع تكرار عوامل الشكل المختلفة مع الاحتفاظ بعرض واضح ومثالي للبيكسل.
الروح القدس: MVVMCross
للحفاظ على كل شيء منفصلاً جيدًا ومترابطًا بشكل غير محكم ، سيعتمد حلنا المقدس على MVVMCross. يطبق إطار العمل هذا البنية التحتية MVVM (Model-View-ViewModel) بحيث يمكن الاحتفاظ بكل شيء بشكل مستقل. يتم تقسيم التطبيقات بشكل عام إلى ثلاثة أجزاء دون الحاجة إلى التقنية العالية:
- النموذج: تمثيل ذاكرة لبياناتنا
- العرض: واجهة المستخدم الخاصة بنا ، والتي تعرض البيانات والإجراءات للمستخدمين
- The ViewModel: الطبقة التي تربط نموذجنا برؤيتنا والعكس صحيح
في هندسة البرمجيات ، نسعى دائمًا إلى إبقاء العرض منفصلاً عن ViewModel بحيث يمكن إعادة استخدام منطق التطبيق (في ViewModel) حتى إذا قمنا بتغيير التمثيل المرئي. يساعدنا MVVMCross على تحقيق ذلك فقط من خلال معالجة روابط البيانات وتوفير أنماط وأدوات لتجريد النظام الأساسي.
ما يهتم به المستخدمون النهائيون
فقط للتلخيص ، هناك أشياء مختلفة تميز التطبيقات الناجحة عن التطبيقات السيئة. تطبيق ناجح:
- يحل مشكلة الحياة الحقيقية
- يقدم تجربة ممتعة
من الواضح أن النقطة رقم 1 لا علاقة لها بالإطار الذي تختاره. لذلك دعونا نركز على النقطة رقم 2. هناك ثلاثة جوانب رئيسية تساهم في متعة تطبيقك:
- معرفة
- أداء
- التفرد
معرفة
تتعلق الألفة بسهولة الاستخدام وإيجاد طريقك بسرعة من خلال التطبيق.
بمعنى آخر ، يتعلق الأمر باستخدام نماذج واجهة المستخدم المختلفة للنظام الأساسي بطريقة متماسكة على مستوى النظام. على سبيل المثال ، تساهم الأشياء البسيطة مثل مواضع الأزرار أو إجراءات سياق القائمة أو التنقل في معرفة تطبيقك.
الألفة هي نقطة الضعف الرئيسية لتطبيقات الويب أو الأطر القائمة على واجهة الويب. من ناحية أخرى ، توفر Xamarin Forms تعيينات عبر الأنظمة الأساسية لعناصر واجهة المستخدم التي يوفرها البائع.
لذلك يحصل المستخدمون لديك على تجربة تتوافق مع الشكل العام للمنصة وشعورها ، لذا سيشعرون بالراحة في تطبيقك بشكل حدسي.
أداء
بصراحة ، ذكر كلمة "أصلي" في الدعاية التسويقية الخاصة بك لا يعني شيئًا. خذ Jasonette كمثال "أصلي عبر HTTP". يتم تخزين واجهة المستخدم على خادم ويب ... مرحبًا بالرحلات ذهابًا وإيابًا وحالات التباطؤ ، لذلك نرى أنه لا يمكن بالضرورة افتراض أن المحتوى الأصلي يعني أداءً أفضل!
لذلك مع خروج هذه الأسطورة عن الطريق ، عند النظر إلى معايير الحياة الواقعية ، يظهر Xamarin باعتباره الحل الأكثر تقريبًا فيما يتعلق بالأداء. توفر نماذج Xamarin ، التي لا تتطلب المزيد من مفاتيح تبديل السياق ، أداءً مشابهًا لتطبيقات اللغة الأصلية.
استنتاجي هو أن خيارات التنفيذ الخاصة بك هي ما يمكن أن يبطئ تطبيقك بدلاً من Xamarin مقابل اللغة الأم. هناك خيارات أخرى في وضع غير موات بشكل واضح فيما يتعلق بالأداء.
التفرد
تعد إمكانية قيام المصممين لديك بإنشاء تطبيق فريد من نوعه أمرًا مهمًا جدًا أيضًا إذا كنت ترغب في تقديم أفضل تجربة مستخدم ممكنة وتمييز تطبيقك.
في كثير من الأحيان ، يعني التفرد إنشاء عناصر تحكم أو رسوم متحركة أو إيماءات ذات مظهر مخصص. عندما لا يكون متاحًا بسهولة في Xamarin ، يمكنك استخدام SkiaSharp (غلاف حول مكتبة عرض رسومات متجهية Skia من Google) والاستفادة من مفهوم العارض المخصص لنماذج Xamarin للاقتراب من الأجهزة حسب الضرورة ، أثناء الترميز دائمًا في واحد اللغة ، وهو شيء لا تستطيع الحلول الأخرى تقديمه.
ما تهتم به كعمل تجاري
في هذه المرحلة ، من المرجح أنك تعتقد أن اختيار إطار العمل هو أيضًا قرار تجاري. بصرف النظر عن العوامل خارج نطاق هذه المقالة ، مثل توافر الموارد البشرية ، فإن Xamarin لديها الكثير لتقدمه ، خاصةً عند اقترانها بـ MVVMCross. سأشرح بالتفصيل أربعة جوانب سترغب في أخذها في الاعتبار في قرارك:
- تكاليف السعر والتطوير
- إعادة استخدام الكود
- توافر المكونات
- الدعم والمجتمع
السعر وتكاليف التطوير
دعنا نخرج هذا من الطريق. منذ وقت سابق من هذا العام ، Xamarin مجاني للعاملين لحسابهم الخاص والشركات الصغيرة مثل الشركات الناشئة (مع Visual Studio Community Edition). بالنسبة للمؤسسات الكبيرة ، تأتي "بحرية" مع ترخيص Visual Studio قد يكون لديك بالفعل. Xamarin Forms و MVVMCross و SkiaSharp كلها أيضًا مجانية ومفتوحة المصدر لتتصدرها!
كما ذكرت سابقًا ، يتيح لك الانتقال إلى مسار .Net مع Xamarin تطوير تطبيقاتك بلغة واحدة من البداية إلى النهاية. تتطلب معظم الحلول الأخرى من المبرمجين معرفة لغات مختلفة. في حالة كوردوفا ، على سبيل المثال ، يجب أن تتقن ليس فقط HTML و Javascript و CSS ، ولكن أيضًا ربما Objective-C و / أو Java و / أو C # إذا كنت بحاجة إلى الوصول إلى واجهات برمجة تطبيقات البائع التي لا تحتوي على مكون إضافي متاح .
يؤدي تنوع اللغات المستخدمة إلى مزيد من مفاتيح التبديل والمزيد من الأدوات لإتقانها مما يؤدي إلى تقليل الكفاءة. Xamarin ، من ناحية أخرى ، هو حل شامل: من Visual Studio يمكنك إنشاء ونشر وتصحيح الأخطاء على جميع الأنظمة الأساسية.
على الرغم من أنه لا يرتبط مباشرة بـ Xamarin ، فإنك تحصل أيضًا على الكثير من الميزات في C # التي تسرع التطوير باختيار حل .Net. أي أنك تستفيد من الميزات الرائعة في C # 4.5+ مثل سهولة تعدد مؤشرات الترابط مع عدم المزامنة / الانتظار والإغلاق والانعكاس ، والتي ثبت أنها تعمل على تحسين الكفاءة.
إعادة استخدام الكود
من المحتمل أنك فكرت في إعادة استخدام الكود وعلى الأرجح أنك تعتبر جميع الحلول مكافئة إلى حد ما في هذا الصدد. آسف لقول صديقي ، لكنك مخطئ!
ربما تساءل المبرمجون منكم عن سبب اقتراح استخدام MVVMC عبر طبقة MVVM المضمنة في النماذج؟ حسنًا ، إليك شيء يجب مراعاته: هل تقوم حقًا ببناء تطبيقات الجوال فقط؟
من خلال عزل منطق التطبيق الخاص بك مع MVVMCross واستخدام انعكاس التحكم الذي يوفره ، يمكنك إعادة استخدام الحد الأقصى من التعليمات البرمجية على الهاتف المحمول ، ولكن أيضًا على نظامي التشغيل Windows و Mac (لأن Xamarin.Mac هو صديقك).
لن يوفر لك المال فحسب ، بل يطرح أيضًا ممارسات هندسية جيدة ستقلل من تكاليف صيانة الكود.
توافر المكون
ربما لست مثلي ، لكني أكره إعادة اختراع العجلة. لذلك ، يعد الوصول إلى المكونات الحالية التي يمكنك دمجها بسهولة في تطبيقك أمرًا ضروريًا لتسريع وقتك في السوق وغالبًا ما يؤدي ذلك إلى خفض التكاليف في نفس الوقت.
يوفر لك اختيار Xamarin و MVVMCross خيارين لاختيار المكونات الحالية من. أولاً ، يتوفر المزيد والمزيد من المكونات لـ Xamarin مع أو بدون النماذج. يحتوي Xamarin على متجر مكون مدمج داخل Visual Studio حيث يمكنك العثور على حلول مختلفة لمشاكل التطبيقات الشائعة وتبيع الشركات الأخرى مباشرة ، لذا تأكد من البحث قبل البدء في كتابة المكونات الخاصة بك (أو فكر في بيعها بمجرد إنشائها).
ثانيًا ، ستحتاج إلى البحث في حزم Nuget لأن هناك احتمالية أن يكون أحدهم قد كتب بالفعل رمزًا للقيام بما تحتاجه. من بين هذه الحزم ، ستجد قائمة مناسبة من المكونات الإضافية MVVMCross عبر الأنظمة الأساسية والتي ستحل المشكلات الشائعة مثل البريد الإلكتروني أو نظام تحديد المواقع العالمي (GPS) أو الترجمة.
إذا كنت خبيرًا بالفعل في C # ، فمن المحتمل أن يكون لديك المكونات المفضلة لديك. بالطبع ، لا تريد السماح لهم بالرحيل ، فهم يشعرون براحة تامة. كن مطمئنًا ، يمكنك إنشاء روابط C # للمكونات الحالية ثم استخدامها كما لو كنا مجمعين مع Xamarin ، حتى في النماذج مع القليل من المساعدة من العارضين المخصصين.
عند الحديث عن ذلك ، قد ترغب في إلقاء نظرة على مستودع جيثب لربط Xamarin قبل إنشاء المستودع الخاص بك.
الدعم والمجتمع
أخيرًا ، يعد الوصول إلى الدعم والأمثلة عاملاً مهمًا للغاية في اختيار إطار العمل. كان Xamarin موجودًا منذ فترة ، لذا فإن حجم المجتمع جيد جدًا اليوم.
عادةً ما يؤدي البحث عن معلومات على Google إلى ظهور عدد لا بأس به من الإجابات (نصيحة: جرب أيضًا عمليات البحث عن monotouch و monodroid ، أسلاف Xamarin) ويقدم Xamarin الكثير من الأمثلة والوثائق الرائعة على موقعه على الويب.
علاوة على ذلك ، نظرًا لأن Xamarin هو حقًا مجرد ارتباط عبر واجهات برمجة تطبيقات البائع ، فإن وثائق Apple و Google ذات صلة دائمًا وستجيب على العديد من أسئلتك. يمكنك بعد ذلك إنشاء خدمة MVVMCross الخاصة بك لتجريد واجهات برمجة التطبيقات الخاصة بالمورد داخل الكود المشترك الخاص بك.
بالنسبة لمستقبل Xamarin ، مع استحواذ Microsoft عليه في مارس الماضي ، أراهن أنه لن يتم المضي قدمًا في أي مكان باستثناء المستقبل. منذ هذا البيع ، والانتقال المطابق إلى نموذج مجاني ، نما المجتمع فقط ، وتحسن الدعم ، واستمر المنتج في التحسن ربما حتى بوتيرة أسرع!
يبدو المستقبل مشرقًا بالنسبة لـ Xamarin.
لنستعد للحركة!
أنا مدرك لحقيقة أنني قد أفتح علبة من الديدان بهذه المقالة. الآن لا تفهموني بشكل خاطئ ، هناك خيارات أخرى تستحق النظر فيها وأنا أدعوك للقيام بذلك ، لأن مخاوفي قد لا تكون هي نفسها مخاوفك.
ضع في اعتبارك أنه إذا كان لديك جدول زمني مدته ستة أسابيع وبعد أربعة أشهر لا يزال لديك تطبيق غير جاهز ، فلن تربح. سيترك ذلك شهرين ونصف الشهر والكثير من المال لتدريب شخص ما في المنزل أو لتوظيف شخص مطلع. قد يكون الإصرار على إنشاء تطبيق "أصلي" في تلك المرحلة ضارًا جدًا بمصير مشروعك.
توفر Xamarin وهذه التقنيات المصاحبة ما يهتم به المستخدمون بالضبط وما تحتاجه. آمل أن تساعدك هذه المقالة في اتخاذ قرار مستنير بشأن إطار العمل الذي قد تختاره لتطبيقك المحمول التالي.