الفرق بين المراجعتين ل"Cordova/next steps"

من موسوعة حسوب
اذهب إلى التنقل اذهب إلى البحث
(أنشأ الصفحة ب'<noinclude>{{DISPLAYTITLE: موضوعات متقدمة عن كوردوفا}}</noinclude> تصنيف: Cordova بالنسبة للمطورين الذين لديهم...')
 
 
(11 مراجعة متوسطة بواسطة مستخدمين اثنين آخرين غير معروضة)
سطر 1: سطر 1:
−
<noinclude>{{DISPLAYTITLE: موضوعات متقدمة عن كوردوفا}}</noinclude>
+
بعد أن تفهم كيفية استخدام [[Cordova/cli|واجهة سطر الأوامر]] الخاصة بكوردوفا، وكيفية الاستفادة من [[Cordova/plugins|الإضافات]]، فهناك بعض الأشياء التي قد ترغب في تعلمها لإنشاء تطبيقات أفضل وأكثر فاعلية. تشرح هذه الصفحة بعض النصائح حول عدة مواضيع تتعلق بأفضل الممارسات المُتعارف عليها بين المطورين، وطرق الاختبار والترقية، ومواضيع أخرى. على أي حال، أنت لست ملزمًا بتطبيقها بل يمكن اعتبارها كنقطة انطلاقتك كمطور نحو مرحلة أكثر تقدمًا.
−
[[تصنيف: Cordova]]
 
−
بالنسبة للمطورين الذين لديهم يفهمون كيفية استخدام [[Cordova/cli|واجهة سطر الأوامر]] الخاصة بكوردوفا وكيفية الاستفادة من الإضافات، فهناك بعض الأشياء التي قد ترغب في تعلمها لأجل إنشاء تطبيقات أفضل وأكثر فاعلية. تقدم الوثيقة التالية نصائح حول عدة مواضيع تتعلق بأفضل الممارسات، وطرق الاختبار والترقية، ومواضيع أخرى، ولكنها غير ملزمة ملزمة. يمكن اعتبارها نقطة انطلاق كمطور نحو مرحلة أكثر تقدمًا. أيضا، إن كنت ترى شيئا يمكن تحسينه، يرجى [http://cordova.apache.org/contribute/ contribute]!
 
  
−
يحتوي هذا الدليل على المواضيع التالية:  
+
{{DISPLAYTITLE:الخطوات التالية في كوردوفا}}{{DISPLAYTITLE:الخطوات التالية في كوردوفا}}
−
*أفضل الممارسات
+
[[تصنيف: Cordova]]
−
* معالجة الترقيات
+
==أفضل ممارسات التطوير في كوردوفا==
−
* اختبار تطبيقات كوردوفا
+
===التطبيقات أحادية الصفحة (SPA) هي صديقك المفضل===
−
* تصحيح تطبيقات كوردوفا  
+
من المهم أن تُصمّم تطبيقات كوردوفا وفق مقاربة التطبيقات أحادية الصفحة (SPA، اختصار للعبارة Single Page Application). هذه التطبيقات من جانب العميل (client-side application) تُشغّل عبر طلبية (request) واحدة من صفحة إلكترونية، إذ يحمِّل المستخدم في البداية مجموعة أولية من الموارد (ملفات [[HTML]] و [[CSS]] و [[JavaScript|JavaScript]])، أمَّا التحديثات الأخرى (إظهار عارض [view] جديد، وتحميل البيانات...) فتُجرَى عبر طلبات XHR.
−
*واجهة المستخدم  
 
−
*إعتبارات خاصة
 
−
*المواكبة
 
−
*الحصول على المساعدة
 
  
 +
تُستخدم مقاربة SPA عادةً لإنشاء التطبيقات المعقدة من جانب العميل. GMail هو أحد المثلة الرائعة على ذلك. فبعد تحميل GMail، كل الوظائف التي تُقدم للمستخدم (استعراض البريد، التحرير، والتنظيم...) تتم من خلال تحديث الدوم (DOM) بدلًا من مغادرة الصفحة الحالية لتحميل صفحة جديدة.
  
−
== اعتمد على التطبيقات أحادية الصفحة (SPA) ==
+
يمكن أن تساعدك مقاربة SPA على تنظيم تطبيقك بطريقة أكثر كفاءة، ولكن لها أيضًا بعض الفوائد الخاصة لتطبيقات كوردوفا. فمثلًا، تطبيقات كوردوفا تنتظر إطلاق الحدث <code>[https://cordova.apache.org/docs/en/latest/cordova/events/events.html#deviceready deviceready]</code> قبل استخدام أية إضافة. لذلك إن لم تستخدم SPA، وقام المستخدم بالنقر للانتقال من صفحة إلى أخرى، فسيتعين عليك الانتظار حتى يُفعّل الحدث<code>[https://cordova.apache.org/docs/en/latest/cordova/events/events.html#deviceready deviceready]</code> مرة أخرى قبل أن تستطيع استخدام الإضافات.
  
−
أولا وقبل كل شيء - يجب أن تُصمّم تطبيقات كوردوفا خاصتك وفق مقاربة التطبيقات أحادية الصفحة (SPA). وهي تطبيقات من جانب العميل (client-side application) تُشغّل من طلبية (request) واحدة من صفحة إلكترونية. يحمِّل المستخدم مجموعة أولية من الموارد (ملفاتHTML و CSS و و[[JavaScript|[[Java|جافا]]اسكريبت]]) ويجراء مزيدًا من التحديثات (إظهار معرض [view] جديد، وتحميل البيانات...) عبر أجاكس (AJAX). تُستخدم مقاربة SPA عادةً لإنشاء تطبيقات معقدة من جانب العميل. GMail هو أحد المثلة الرائعة على ذلك. بعد تحميل GMail، فإنّ استعراض البريد، والتحرير والتنظيم كلها تتم من خلال تحديث الدوم (DOM) بدلاً من مغادرة الصفحة الحالية لتحميل صفحة جديدة تمامًا.  
+
حتى لو لم تكن تستخدم كوردوفا، فإنشاء تطبيق هاتفي بدون استخدام المقاربة أحادية الصفحة سيضر بأداء تطبيقك. ذلك لأن التنقل بين الصفحات يتطلب إعادة تحميل النصوص البرمجية والأصول (assets) وغير ذلك. وحتى في حال تخزين تلك الأصول مؤقتًا، فهذا لن يحل كل المشكلات المتعلقة بالأداء.
  
−
يمكن أن تساعدك مقاربة SPA على تنظيم تطبيقك بطريقة أكثر كفاءة، ولكن لها أيضًا بعض الفوائد لتطبيقات كوردوفا. يجب أن ينتظر تطبيق كوردوفا إطلاق الحدث [../../cordova/events/events.html#deviceready deviceready] قبل استخدام أي إضافات. إن لم تستخدم SPA، وقام المستخدم بالنقر للانتقال من صفحة إلى أخرى، فسيتعين عليك الانتظار حتى يتم يُفعّل الحدث [../../cordova/events/events.html#deviceready deviceready] مرة أخرى قبل استخدام الإضافات.  
+
إليك بعض الأمثلة عن مكتبات SPA التي يمكنك استخدامها في تطبيقات كوردوفا:
 +
*[http://angularjs.org/ AngularJS]
 +
*[http://emberjs.com/ EmberJS]
 +
*[http://backbonejs.org/ Backbone]
 +
*[http://www.telerik.com/kendo-ui Kendo UI]
 +
*[http://facebook.github.io/react/ ReactJS]
 +
*[http://www.sencha.com/products/touch/ Sencha Touch]
 +
*[https://vuejs.org/ Vue]
 +
*[https://onsen.io/ Onsen UI]
 +
وغيرها كثير.
 +
===اعتبارات متعلقة بالأداء===
 +
في هذا القسم، سنتكلم عن بعض الأساليب المُتبعة لتحسين أداء تطبيقاتك:
 +
====النقر مقابل اللمس (Click versus Touch)====
 +
الكثير من الأجهزة تفرض تاخيرُا على النقرات يقارب 300 ميلي ثانية للتمييز بين الحدث <code>touch</code> والحدث <code>hold</code>. وهذا قد يبطئ تطبيقك ويجعله غير متجاوب. تجنب هذا التأخير  هو أحد أفضل أساليب تحسين الأداء. لمعرفة المزيد عن مشكلة التأخير، راجع [https://developers.google.com/web/updates/2013/12/300ms-tap-delay-gone-away هذا المقال] على مدونة جوجل.
  
−
حتى لو لم تكن تستخدم كوردوفا، فإنشاء تطبيق هاتفي بدون استخدام المقاربة أحادية الصفحة سيضر بأداء تطبيقك. وذلك لأن التنقل بين الصفحات سيتطلب إعادة تحميل النصوص البرمجية والأصول (assets) وغير ذلك. وحتى في حال تخزين تلك الأصول مؤقتًا، فستظل هناك بعض المشكلات المتعلقة بالأداء.  
+
لم تعد معظم إصدارات Android تفرض هذا التأخير، لكن منصة iOS لا تزال تفعل ذلك افتراضيا. في منصة iOS، يمكنك التخلص من هذا التأخير عبر استخدام [https://github.com/apache/cordova-plugin-wkwebview-engine WkWebView] بدلاً من <code>UIWebView</code> الافتراضي. وفي Android و iOS، يجب عليك التأكد من أن يكون للوسم الوصفي [[Cordova/webviews|للعارض]]<nowiki/>على الأقل <code>width=device-width</code>، وإلا فسيظل التأخير  باقيا. إذا كنت بحاجة إلى دعم أجهزة قديمة (Android 4.4 أو iOS 8) ، فيمكنك استخدام  [https://github.com/ftlabs/fastclick FastClick]، أو استخدام <code>touchstart</code> و <code>touchend</code> بدلاً من <code>click</code>.
  
−
إليك بعض الأمثلة عن مكتبات SPA التي يمكنك استخدامها في تطبيقات كوردوفا:
 
−
[http://angularjs.org AngularJS]
 
−
[http://emberjs.com EmberJS]
 
−
[http://backbonejs.org Backbone]
 
−
[http://www.telerik.com/kendo-ui Kendo UI]
 
−
[http://monaca.mobi/en/ Monaca]
 
−
[http://facebook.github.io/react/ ReactJS]
 
−
[http://www.sencha.com/products/touch/ Sencha Touch]
 
−
[http://jquerymobile.com jQuery Mobile]
 
  
−
وغيرها كثير.  
+
====تحويلات CSS مقابل التعديل على DOM====
 +
استخدام تحويلات CSS المُسرّعة (accelerated CSS transitions) للأجهزة أفضل بكثير من استخدام [[JavaScript|JavaScript]] لإنشاء الرسوميات (animations). انظر في قائمة الموارد في نهاية هذا القسم للاطلاع على أمثلة.
 +
====بطء الشبكة (Networks Suck)====
 +
قد لا تكون الشبكات سيئة دائمًا، ولكن زمن الانتظار في شبكات الجوّال، مهما كانت جيدة، أسوأ بكثير مما تعتقد. فتطبيق على سطح المكتب يعمل على إفراغ 500 صف من بيانات JSON كل 30 ثانية، سيكون بطيئا جدًّا على جهاز الجوّال، كما سيستنزف البطارية. ضع في اعتبارك أنَّ لتطبيقات كوردوفا عدة طرق لحفظ البيانات في التطبيق (مثل [[Cordova/storage#.D8.A7.D9.84.D8.AA.D8.AE.D8.B2.D9.8A.D9.86 .D8.A7.D9.84.D9.85.D8.AD.D9.84.D9.8A .28LocalStorage.29|التخزين المحلي]] والواجهة البرمجية [[Cordova/storage#FileSystem API|FileSystem]]). استخدم ذاكرة التخزين المؤقت لحفظ البيانات محليًّا، ولكن انتبه لكمية البيانات التي ترسلها ذهابًا وإيابًا. خصوصًا إن كان تطبيقك متصلًا بشبكة جوال محلية.
  
−
== 2) اعتبارات متعلقة بالأداء ==  
+
إليك المصادر والمراجع التالية التي يمكن أن تستفيد منها في هذا الخصوص:
 +
*[http://coenraets.org/blog/2013/10/top-10-performance-techniques-for-phonegap-and-hybrid-apps-slides-available/ "أفضل عشرة نصائح بخصوص الأداء في PhoneGap  والتطبيقات الهجينة"]
 +
*[https://channel9.msdn.com/Events/Build/2013/4-313 "تطبيقات ومواقع سريعة بلغة جافاسريبت"]
 +
===رصد انقطاع الاتصال (Offline) والتعامل معه===
 +
قد لا يكون تطبيقك على شبكة بطيئة وحسب، بل من الممكن أن يكون منقطعًا بالكامل عنها. يجب أن يتعامل تطبيقك مع هذا الوضع بطريقة ذكية وصحيحة. أو قد يعتقد الناس أن تطبيقك معطل. نظرًا لسهولة التعامل مع هذا الأمر (كوردوفا توفر أحداثًا ترصد حالة الاتصال [online] أو انقطاع الاتصال [offline] بشبكة الإنترنت)، فلا يوجد أي سبب على الإطلاق لئلًا يتجاوب تطبيقك بالشكل الصحيح مع حالات انقطاع الاتصال. تأكد من اختبار تطبيقك (راجع قسم الاختبار أدناه) وتأكد من اختبار كيفية تعامله مع الحالات التي يبدء فيها من حالة ثم ينتقل إلى أخرى.
  
−
في هذه الفقرة سنتكلم عن بعض الأساليب المفيدة في تحسين أداء تطبيقاتك:
+
لاحظ أن الحدثين <code>online</code> و <code>offline</code>، وكذلك الواجهة البرمجية للاتصال بالشبكة (Network Connection API) ليست مثالية. لذلك قد تحتاج إلى استخدام طلبية XHR للتحقق مما إن كان الجهاز متصلًا أو منقطعًا عن الإنترنت.
  
−
'''Click versus Touch''' - أكبر وأبسط خطأ يمكن أن تفعله هو استخدام أحداث النقر (click events). في حين أن هذا الأمر يعمل بشكل جيد على الهواتف، فإن معظم الأجهزة تفرض تاخيرُا على النقرات بـ 300 ميليثانية (300ms) للتمييز بين الحدث touch والحدث hold. استخدام <code>touchstart</code>، أو <code>touchend</code>، سيؤدي إلى تحسن كبير - قد لا تبدوا 300 ميليثانية بالشيء الخطير، ولكن يمكن أن تؤدي إلى تحديثات كثيرة في واجهة المستخدم (UI). يجب أيضًا مراعاة حقيقة أن الأحداث "touch" غير مدعومة في المتصفحات التي لا تدعم متصفحات webkit، راجع الصفحة [http://caniuse.com/#search=touch CanIUse]. لتجاوز هذه القيود، يمكنك استخدام بعض المكتبات مثل HandJS و Fastclick.  
+
حاول إضافة الدعم للمسائل المتعلق بالشبكة. فمتجر Apple (وربما متاجر أخرى) سيرفض التطبيقات التي لا تعالج بشكل صحيح حالات الاتصال/الانقطاع عن الشبكة. لمزيد من المناقشات حول هذا الموضوع، راجع صفحة [http://blogs.telerik.com/appbuilder/posts/13-04-23/is-this-thing-on-%28part-1%29 "هل هذا الشيء متصل؟"]
 +
==إدارة الترقيات==
 +
===ترقية مشاريع كوردوفا===
 +
لا يوجد أمر خاص بترقية مشاريع كوردوفا. بدلاً من ذلك ، أزل المنصة من مشروعك، ثمّ أعد إضافتها للترقية إلى أحدث إصدار:<syntaxhighlight lang="console">cordova platform rm android
 +
cordova platform add android
 +
</syntaxhighlight>من الضروري أن تنتبه إلى ما تم تغييره في الإصدار المحدث، لأن التحديث قد يكسر شيفرتك البرمجية. أفضل مكان للعثور على هذه المعلومات سيكون في ملاحظات الإصدار المنشورة في المستودعات وعلى مدونة كوردوفا. سيكون عليك اختبار تطبيقك للتحقق من أنه يعمل بشكل صحيح بعد إجراء التحديث.
  
−
'''CSS Transitions versus DOM Manipulation''' - استخدام تحويلات CSS المُسرّعة للأجهزة (hardware accelerated CSS transitions) أفضل بشكل كبير من استخدام [[JavaScript|[[Java|جافا]]اسكريبت]] لإنشاء الرسوميات (animations). انظر في قائمة الموارد في نهاية هذا القسم لتحصل على أمثلة.  
+
'''ملاحظة''': قد لا تتوافق بعض الإضافات مع الإصدار الجديد من كوردوفا. في هذه الحالة حاول البحث عن إضافةٍ بديلةٍ تؤدي العمل الذي تحتاجه، وإلا فربما عليك تأخير ترقية المشروع. أو يمكنك تعديل الإضافة بحيث تعمل ضمن الإصدار الجديد، وتنشرها لمساعدة المطورين الآخرين.
 +
===ترقية الإضافات===
 +
لا توجد حاليًا آلية لترقية الإضافات المُعدّلة عبر أمرٍ واحد. بدلًا من ذلك، أزل الإضافة ثم أضفها مجددًا إلى مشروعك، وسيُثبّت الإصدار الجديد:<syntaxhighlight lang="console">cordova plugin rm some-plugin
 +
cordova plugin add some-plugin</syntaxhighlight>ارجع إلى صفحة [[Cordova/platform plugin versioning ref|إدارة إصدارات المنصات والإضافات]] لمزيد من التفاصيل.
  
−
'''Networks Suck''' - الشبكات ليست سيئة دائمًا، ولكن زمن الانتظار الخاص بشبكات الجوّال، مهما كانت جيدة، أسوأ بكثير مما تعتقد. فتطبيق على سطح المكتب يعمل على إفراغ 500 صف من بيانات JSON، كل 30 ثانية، سيكون بطيئا على جهاز الجوّال، كما سيستنزف البطارية. ضع في اعتبارك أن لتطبيقات كوردوفا عدة طرق لحفظ البيانات في التطبيق (مثل التخزين المحلي [LocalStorage] ونظام الملفات [file system]). استخدم ذاكرة التخزين المؤقت لحفظ البيانات محليا، ولكن انتبه لكمية البيانات التي ترسلها ذهابا وإيابا. خصوصًا إن كان تطبيقك متصلًا بشبكة خلوية.  
+
تأكد من مراجعة توثيق الإضافة المحدّثة، حيث قد تحتاج إلى تعديل شيفرتك لتعمل مع الإصدار الجديد. تأكد أيضًا من أن الإصدار الجديد من الإضافة يعمل دون مشاكل مع إصدار مشروع كوردوفا خاصتك.
  
−
'''Additional Performance Articles and Resources'''
+
اختبر تطبيقاتك على الدوام للتأكد من أن تثبيت الإضافة الجديدة لم يؤدي إلى كسر أو تعطيل شيء ما.
−
[http://sintaxi.com/you-half-assed-it "You half assed it"]
 
−
[http://coenraets.org/blog/2013/10/top-10-performance-techniques-for-phonegap-and-hybrid-apps-slides-available/ "Top Ten Performance Tips for PhoneGap and Hybrid Apps"]
 
−
[https://channel9.msdn.com/Events/Build/2013/4-313 "Fast Apps and Sites with JavaScript"]
 
  
−
== 3) رصد انقطاع الاتصال (Offline) والتعامل معه ==  
+
إن كان مشروعك يحتوي على الكثير من الإضافات التي تحتاج إلى التحديث، فيمكنك ربح الوقت بإنشاء نص برمجي shell أو رُقعة (batch script) تضيف وتزيل الإضافات عبر أمرِ واحدِ.
 +
==اختبار تطبيقات كوردوفا==
 +
يعد اختبار تطبيقاتك أمرًا بالغ الأهمية. يستخدم فريق كوردوفا أداة [https://jasmine.github.io/ Jasmine]، ولكن يمكنك استخدام ما يناسبك من الحلول.
  
−
قد لا يكون تطبيقك على شبكة بطيئة وحسب، بل من الممكن أن يكون منقطعًا بالكامل عن الشبكة. يجب أن يتعامل طلبك مع هذا الوضع بطريقة ذكية وصحيحة. أو قد يعتقد الناس أن تطبيقك معطل. نظرًا لسهولة التعامل مع هذا (كوردوفا توفر أحداثًا ترصد حالة الاتصال [online] أو انقطاع الاتصال [offline] بشبكة الإنترنت)، لذلك لا يوجد أي سبب على الإطلاق لئلًا يتجاوب تطبيقك بالشكل الصحيح عند انقطاع الاتصال. تأكد من اختبار (راجع قسم الاختبار أدناه) تطبيقك وتأكد من اختبار كيفية يتعامل تطبيقك مع الحالات التي يبدء فيها من حالة ثم ينتقل إلى أخرى.  
+
===الاختبار على المحاكيات مقابل الاختبار على جهاز حقيقي===
 +
من الشائع استخدام متصفحات سطح المكتب ومحاكيات برمجية (simulators) أو محاكيات عتادية (emulators) عند تطوير تطبيقات كوردوفا. لكنّ ذلك لا يُعفيك من ضرورة اختبار تطبيقك على أكبر عدد ممكن من الأجهزة الفعلية:
 +
*المُحاكيات البرمجية تبقى مجرد محاكيات. على سبيل المثال، قد يعمل تطبيقك في محاكي iOS بدون مشاكل، ولكنه قد يفشل على جهاز حقيقي (خاصة في ظروف معينة، مثل حالة انحسار الذاكرة). أو قد يفشل تطبيقك في المحاكي بينما يعمل بشكل جيد على جهاز حقيقي.
 +
*المحاكيات العتادية مجرد محاكيات أيضًا. لن تعطيك فكرة دقيقة عن أداء تطبيقك على جهاز فعلي. على سبيل المثال، قد تعرض بعض المحاكيات العتادية تطبيقك بطريقة مشوّهة، في حين أن الجهاز الحقيقي سيعرضه بشكل طبيعي. (إذا واجهت هذه المشكلة، قم بتعطيل المضيف GPU في المحاكي.)
 +
*المحاكيات البرمجية أسرع بشكل عام من الجهاز الحقيقي. على خلاف المحاكيات العتادية التي تكون أبطأ بشكل عام. لا تحكم على أداء تطبيقك من أدائه على المُحاكي البرمجي أو العتادي، ولكن احكم على أداء تطبيقك من خلال تشغيله على مجموعة من الأجهزة الحقيقية.
 +
*من المستحيل تكوين فكرة دقيقة عن كيفية استجابة تطبيقك للّمس من خلال استخدام المُحاكيات. لذلك، من الضروري أن تُشغّل التطبيق على جهاز حقيقي، فهي الطريقة الوحيدة المضمونة لتكتشف المشاكل المتعلقة بأحجام عناصر واجهة المستخدم، والاستجابة، وما إلى ذلك.
 +
*يأمل المطورون أن يكونوا قادرين على الاكتفاء باختبار تطبيقاتهم على جهاز واحد فقط لكل منصة، لكن من الأفضل اختبار العديد من الأجهزة بمُختَلَف المنصات التي تدعمها. على سبيل المثال، ما قد ينجح على هاتف أندرويد معيّن قد يفشل على جهاز أندرويد آخر. وما قد يعمل على آخر إصدار من iOS قد يفشل على إصدار أقدم.
 +
بالطبع، من المستحيل اختبار كل الأجهزة الموجودة في السوق. لهذا قد يكون من الحكمة توظيف عدة أشخاص يملكون أجهزة مختلفة للاختبار. على الرغم من أنهم لن يكشفوا كل المشاكل الممكنة، إلا أنهم على الأرجح سيكتشفون ثغرات ومشاكل لن يكون بمقدورك إيجادها وحدَك.
 +
==تنقيح تطبيقات كوردوفا==
 +
في أغلب الأحوال، التنقيح (debugging) في كوردوفا واضح ومباشر.
 +
===تنقيح تطبيقات iOS===
 +
====Xcode====
 +
يمكنك استخدام بيئة التطوير Xcode لتصحيح الجانب الأصلي (native side) من تطبيقات كوردوفا في منصة iOS. تأكد من إظهار منطقة التصحيح ‎(<code>View -> Debug Area</code>)‎. بمجرد تشغيل التطبيق على الجهاز (أو المُحاكي)، فيمكنك مطالعة مُخرجات السجل (log output) في منطقة التصحيح. فهو المكان الذي ستُطبع فيه الأخطاء والتنبيهات. يمكنك أيضًا وضع نقاط توقف (breakpoints) داخل الشيفرات المصدرية. هذا سيسمح لك بالمرور عبر الشيفرة البرمجية سطرًا سطرًا، واستعراض حالة المتغيرات في كل خطوة. إذ يتم إظهار حالة المتغيرات في منطقة التصحيح عند كل نقطة توقف.
  
−
لاحظ أن الحدثين online و offline، وكذلك الواجهة البرمجية للاتصال بالشبكة (Network Connection API) ليست مثالية. قد تحتاج إلى استخدام طلبية XHR للتحقق مما إن كان الجهاز متصلًا أو منقطعًا عن الإنترنت. حاول أيضًا إضافة بعض أشكال الدعم للمسائل المتعلق بالشبكة - في الواقع، متجر Apple (وربما متاجر أخرى) سيرفض التطبيقات التي لا تعالج بشكل صحيح حالات الاتصال/الانقطاع عن الشبكة. لمزيد من المناقشات حول هذا الموضوع، راجع صفحة [http://blogs.telerik.com/appbuilder/posts/13-04-23/is-this-thing-on-%28part-1%29 "Is This Thing On?"]  
+
بمجرد تشغيل تطبيقك على الجهاز، يمكنك إظهار مفتش Safari (كما هو موضح أدناه) لتصحيح [[Cordova/webviews|العارض]] وملفات [[JavaScript|JavaScript]] الخاصة بالتطبيق. لمزيد من التفاصيل، راجع صفحة التنقيح في [https://developer.apple.com/support/debugging/ Apple Support].
 +
====التنقيح عند بعد عبر مفتش Safari====
 +
باستخدام مفتش Safari ‏(Safari's web inspector‏)‏، يمكنك تصحيح أخطاء [[Cordova/webviews|العارض]] و ملفات [[JavaScript|JavaScript]] الخاصة بتطبيقك. هذه الأداة تعمل فقط على منصات macOS.
  
 +
يُستخدم متصفح Safari للاتصال بالجهاز (أو المحاكي)، إذ يربط بين أدوات المطورين الخاصة بالمتصفح وبين تطبيق كوردوفا. هكذا يمكنك الاستفادة من الخدمات التي تقدمها أدوات التطوير ، مثل فحص ومعالجة  DOM، وتصحيح أخطاء [[JavaScript|JavaScript]]، وفحص الشبكة، ووحدة التحكم والمزيد.
  
−
== ترقية مشاريع كوردوفا ==
+
مثل بيئة التطوير Xcode، يُمكِّنك مفتش Safari من تعيين نقاط توقف في شيفرة [[JavaScript|JavaScript]]، وعرض حالة المتغيرات عند تلك النقاط. يمكنك الاطلاع على الأخطاء والتنبيهات والرسائل المطبوعة على وحدة التحكم. ويمكنك أيضًا تشغيل أوامر [[JavaScript|JavaScript]] مباشرة من وحدة التحكم أثناء تشغيل التطبيق.
  
−
إن أنشأت مشروعك الحالي باستخدام كوردوفا ‎3.x‎، فيمكنك ترقية المشروع من خلال تنفيذ الأمر التالي:
+
لتبدأ الفحص، عليك تمكينه أولاً على الجهاز من <code>Settings > Safari > Advanced > Web Inspector</code>. أما على على سطح المكتب ، قم بتمكين أدوات المطور من <code>Safari > Preferences > Advanced > Show Develop menu</code> في شريط القائمة. ستتمكن عقب ذلك من اختيار الجهاز المتصل والتطبيق الذي تريد فحصه من القائمة <code>Develop</code>.
−
<syntaxhighlight lang="console">cordova platform update platform-name ios, android, etc.‎</syntaxhighlight>  
+
===التنقيح عن بعد عبر Chrome===
 +
مثل Safari، يعمل Chrome مع أندرويد فقط، ولكن يمكن استخدامه من أي منصة مكتبية. بمجرد ربط الاتصال، ستحصل على نفس أدوات المطورين (Chrome Dev) المُستخدمة مع تطبيقات سطح المكتب لأجل استخدامها مع تطبيقات الجوال. والأفضل من ذلك، أن أدوات Chrome Dev تعطيك خيار المرآة، والذي يعرض تطبيقك على محاكي هاتفي. ولكنه أكثر من مجرد معرِض، إذ يمكنك التمرير (scroll) والنقر في أدوات التطوير، وسترى التحديثات على جهاز الهاتف. 
  
−
أما إن كنت قد أنشأت مشروعك الحالي باستخدام إصدار سابق لكوردوفا 3.x، فمن الأفضل إنشاء مشروع جديد بالإصدار كوردوفا 3.x، ثم نسخ الشيفرة البرمجية لمشروعك الحالي وأصولِه إلى المشروع الجديد. عبر الخطوات التالية:  
+
لتبدأ الفحص، عليك فتح العنوان <code>chrome://inspect</code> في Chrome على سطح المكتب. سترى قائمة بالأجهزة المتصلة والتطبيقات التي يمكنك فحصها. لكن من الضروري إعداد جهازك لأجل التنقيح عبر USB وإلا فلن تعمل هذه الطريقة. يمكن الاطلاع على مزيد من التفاصيل حول التصحيح عن بُعد عبر Chrome من [https://developers.google.com/chrome/mobile/docs/debugging هنا].  
−
* أنشئ مشروعًا جديدًا باستخدام كوردوفا ‎3.x
 
−
* انسخ المجلد www من مشروعك القديم نحو المشروع الجديد
 
−
* انسخ إعدادات المشروع القديم إلى المشروع الجديد
 
−
* أضف كل الإضافات المستخدمة في المشروع القديم إلى المشروع الجديد
 
−
* قم ببناء مشروعك
 
−
* اختبر، واختبر، واختبر!
 
  
−
بغض النظر عن الإصدار السابق للمشروع، فمن الضروري أن تنتبه إلى ما تم تغييره في الإصدار المحدث، لأن التحديث قد يكسر شيفرتك البرمجية. أفضل مكان للعثور على هذه المعلومات سيكون في ملاحظات الإصدار المنشورة في المستودعات وعلى مدونة كوردوفا. سيكون عليك اختبار تطبيقك للتحقق من أنه يعمل بشكل صحيح بعد إجراء التحديث.  
+
إن كان بإمكانك رؤية جهازك في قسم فحص الأجهزة (inspect devices section)، ولكن لم تستطع مشاهدة [[Cordova/webviews|عارض]] كوردوفا، فقد تحتاج إلى إضافة <code>android:debuggable="true"‎</code> إلى العقدة <code><application></code> في الملف <code>AndroidManifest.xml</code>.
  
−
ملاحظة: قد لا تتوافق بعض الإضافات مع الإصدار الجديد من كوردوفا. إذا لم تكن الإضافة متوافقةً مع إصدار كوردوفا الجديد، فربما تعثر على إضافةٍ بديلةٍ تؤدي العمل الذي تحتاجه، وإلا فربما عليك تأخير ترقية المشروع. أو يمكنك تعديل الإضافة بحيث تعمل ضمن الإصدار الجديد، وتساعد المطورين الآخرين.  
+
من الممكن استخدام أدوات Chrome Dev لفحص تطبيقات iOS، من خلال خادم WebKit وسيط (WebKit proxy)‏، يمكنك زيارة صفحته على مستودع  git من [https://github.com/google/ios-webkit-debug-proxy/ هنا].
 +
===خيارات أخرى===
 +
لمزيد من الأمثلة والشروحات حول نصائح التصحيح أعلاه، انتقل إلى [http://developer.telerik.com/featured/a-concise-guide-to-remote-debugging-on-ios-android-and-windows-phone/ هذا الرابط].
 +
==واجهة المستخدم==
 +
ليس من السهل على المطورين بناء تطبيقات جميلة وأنيقة بكوردوفا. العديد من الناس يختارون استخدام بيئة عمل لواجهة المستخدمين (UI framework) لتسهيل ذلك. فيما يلي قائمة مختصرة بالخيارات الممكنة:
 +
*[http://ionicframework.com/ ionic] - يملك هذا الإطار المُتميّز واجهة سطر أوامر خاصة به لمعالجة إنشاء المشاريع.
 +
*[http://goratchet.com/ Ratchet] - مُطوّر من قبل نفس الأشخاص الذين طوروا Bootstrap.
 +
*[http://www.telerik.com/kendo-ui Kendo UI] - واجهة مستخدم وإطار تطبيقات مفتوح المصدر من [https://www.telerik.com/ Telerik].
 +
*[https://onsen.io/ Onsen UI] - واجهة مستخدم مفتوحة المصدر للمواقع وتطبيقات كوردوفا.
  
−
== ترقية الإضافات ==
+
*[http://topcoat.io/ Topcoat]
 +
*[http://facebook.github.io/react/ ReactJS]
 +
عند بناء واجهة المستخدم، من المهم التفكير في جميع المنصات التي تستهدفها، وفي توقعات المستخدمين على كل منصة. على سبيل المثال، تطبيقات أندرويد التي تعتمد واجهة مستخدم على محاكي عتادي لأنماط المنصة iOS قد لا تتناسب مع مستخدمي أندرويد.
  
−
لا توجد حاليًا آلية لترقية الإضافات التي تم تغييرها باستخدام أمر واحد. بدلاً من ذلك، أزل الإضافة وأعد إضافتها إلى مشروعك، وسيُثبّت الإصدار الجديد:  
+
تفرض مخازن التطبيقات (application stores) في بعض الأحيان نمطًا معينًا لواجهة المستخدم. لهذا السبب، من المهم أن تحترم خصوصيات كل منصة، وأن تكون على دراية بمختلف إرشادات واجهات المستخدمين لتلك المنصات، والتي يمكنك الاطلاع عليها من الروابط التالية:
−
<syntaxhighlight lang="console">cordova plugin rm "some-plugin"
+
*[https://developer.apple.com/library/ios/documentation/userexperience/conceptual/MobileHIG/index.html iOS]
−
cordova plugin add "some-plugin"‎</syntaxhighlight>
+
*[http://developer.android.com/design/index.html Android]
 +
*[https://dev.windows.com/en-us/design Windows Phone]
 +
== اعتبارات خاصة ==
 +
على الرغم من أن كوردوفا تسهّل عملية التطوير العابر للمنصات، فلا تتوقع أبدًا أن تعزِلك بشكل كامل عن المنصة الأصلية. لذلك يجب أن تكون على وعي بالقيود الموجودة.
  
−
ارجع إلى صفحة [../../platform_plugin_versioning_ref/index.html Manage versions and platforms] لمزيد من التفاصيل.  
+
=== الملاحظات الخاصة بالمنصات ===
 +
أثناء قراءة التوثيق، ابحث عن الأقسام التي تحدد سلوكيات أو متطلبات خاصة بمنصات معينة. إن وجدتها، فستكون ذلك في قسم بعنوان "ملاحظة خاصة بأندرويد" أو "ملاحظة خاصة بمنصة iOS "، اقرأ تلك الملاحظات بحرص، وتذكرها أثناء عملك مع كوردوفا.
 +
===تحميل المحتوى عن بعد===
 +
استدعاء دوال [[JavaScript|JavaScript]] (في كوردوفا) من صفحة HTML محملة عن بُعد (أي صفحة HTML غير مُخزّنة محليًا على الجهاز) ليس مدعومًا. هذا لأنَّ كوردوفا لم تُصمّم لأجل ذلك، كما لم يقم مجتمع كوردوفا باختبار هذا الإعداد. وفي حين أن هذا الأمر قد يعمل في بعض الظروف، إلا أنه غير موصى به وغير مدعوم. لأنه يطرح عدة تحديات، مثل الحفاظ على التزامن بين الأجزاء المكتوبة بلغة [[JavaScript|JavaScript]] والأجزاء الأصلية من كوردوفا (نظرًا لأنها موصولة بواجهات برمجية خاصة قابلة للتغيير)، إضافة إلى موثوقية المحتويات البعيدة (remote content) التي تستدعي دوال محلية أصلية (native local functions)، وكذلك احتمال الرفض من متجر التطبيقات.
  
−
تأكد من مراجعة توثيق الإضافة المحدّثة، حيث قد تحتاج إلى تعديل شيفرتك لتعمل مع الإصدار الجديد. تأكد أيضًا من أن الإصدار الجديد من الإضافة يعمل دون مشاكل مع إصدار مشروع كوردوفا خاصتك.  
+
عرض محتويات HTML المُحمّلة عن بعد في [[Cordova/webviews|العارض]] يجب أن يحدث باستخدام <code>InAppBrowser</code>. فقد صُمِّم <code>InAppBrowser</code> بحيث يمنع شيفرات [[JavaScript|JavaScript]] المُنفّدة في المحتويات الخارجية من الوصول إلى الواجهة البرمجية لتطبيقات [[JavaScript|جافاسكريبت]]-كوردوفا للأسباب المذكورة أعلاه.
  
−
اختبر تطبيقاتك على الدوام للتأكد من أن تثبيت الإضافة الجديدة لم يؤدي إلى كسر أو تعطيل شيء ما.  
+
يرجى الرجوع إلى [[Cordova/security|صفحة الأمن في كوردوفا]].
  
−
إن كان مشروعك يحتوي على الكثير من الإضافات التي تحتاج إلى تحديثها، فيمكنك ربح الوقت بإنشاء نص برمجي shell أو رُقعة (batch script) تضيف وتزيل الإضافات عبر أمرِ واحدِ فقط.  
+
== الاستمرار قُدمًا ==
 +
فيما يلي بعض الطرق التي ستساعدك على مواكبة مستجدات كوردوفا وهي:
 +
*اشترك في [http://cordova.apache.org/#news مدونة كوردوفا].
 +
*اشترك في [http://cordova.apache.org/#mailing-list البريد الإلكتروني للمطورين]. لكن تذكر أنه ليس مجموعة دعم، ولكنه مكان مُخصص لمناقشة كل ما يتعلق بتطوير كوردوفا.
  
 +
== الحصول على المساعدة ==
 +
الروابط التالية هي أفضل الأماكن التي يمكن أن تحصل منها على المساعدة حول كل ما يتعلق بكوردوفا:
 +
*[http://slack.cordova.io/ Slack]: يعد هذا أحد أفضل الأمكنة للحصول على مساعدة من مجتمع كوردوفا، وتحصل على أجوبة لتساؤلاتك.
 +
*[http://stackoverflow.com/questions/tagged/cordova StackOverflow]: باستخدام الوسم <code>Cordova</code>، يمكنك استعراض وتصفح جميع الأسئلة المتعلقة بكوردوفا. لاحظ أن الموقع StackOverflow يحوّل تلقائيًا الوسم"<code>Phonegap</code>" إلى الوسم "<code>Cordova</code>"، وبذلك ستتمكن من الوصول إلى الأسئلة القديمة أيضًا.
 +
*[https://groups.google.com/forum/#!forum/phonegap PhoneGap Google Group]: هذه كانت صفحة منتدى الدعم القديم لمّا كانت كوردوفا تحمل الاسم PhoneGap صحيح أنه لا يزال هناك الكثير من مستخدمي كوردوفا الذين يترددون على هذه المجموعة، إلا أنّ مجتمع كوردوفا قد أعرب عن اهتمامه بالتركيز بشكل أكبر على استخدام [http://stackoverflow.com/questions/tagged/cordova StackOverflow] للحصول على الدعم.
 +
*[http://phonegap.meetup.com/ الملتقيات]: للأسف لا توجد ملتقيات محلية لكوردوفا أو PhoneGap في عالمنا العربي. لكن مع تزايد شعبية هذه المنصة نأمل أن نرى ذلك قريبًا، إلى ذلك الحين، سيكون عليك أن تكتفي بالمنتديات والمواقع المذكورة في الأعلى.
 +
*[https://academy.hsoub.com/questions/c3-programming/ قسم الأسئلة في أكاديمية حسوب]: إن أشكل عليك شيء فاطرح أسئلتك هنا لتحصل على مساعدة مباشرة من المستقلين والمبرمجين على الأكاديمية.
  
−
يعد اختبار تطبيقاتك أمرًا بالغ الأهمية. يستخدم فريق كوردوفا أداة Jasmine، ولكن يمكنك استخدام ما يناسبك من حلول الاختبار.
+
== انظر أيضًا ==
 +
* [[Cordova/webviews|تضمين كوردوفا في تطبيق أصيل]]
 +
* [[Cordova/platform plugin versioning ref|إدارة إصدارات المنصات والإضافات]]
  
−
== الاختبار على محاكي والاختبار على جهاز حقيقي ==
 
−
 
−
من الشائع استخدام متصفحات سطح المكتب ومحاكيات الأجهزة عند تطوير تطبيقات كوردوفا. ومع ذلك، فمن المهم أن تختبر تطبيقك على أكبر عدد ممكن من الأجهزة الفعلية:
 
−
* فالمحاكيات تبقى مجرد محاكيات. على سبيل المثال، قد يعمل تطبيقك في محاكي iOS بدون مشاكل، ولكنه قد يفشل على جهاز حقيقي (خاصة في ظروف معينة، مثل حالة انحسار الذاكرة). أو قد يفشل تطبيقك في المحاكي بينما يعمل بشكل جيد على جهاز حقيقي.
 
−
* المحاكيات هي مجرد محاكيات. لا تمثل مدى جودة تشغيل تطبيقك على جهاز فعلي. على سبيل المثال، قد تعرض بعض المحاكيات تطبيقك بطريقة مشوهة، في حين أن الجهاز الحقيقي سيعرضه بشكل طبيعي. (إذا واجهت هذه المشكلة، قم بتعطيل المضيف GPU في المحاكي.)
 
−
* المحاكيات (Simulators) أسرع بشكل عام من الجهاز المادي. على خلا المشاكلات (Emulators) التي تكون أبطأ بشكل عام. لا تحكم على أداء تطبيقك من أدائه على المُحاكي أو المُشاكل. ولكن احكم على أداء تطبيقك من خلال تشغيله على مجموعة من الأجهزة الحقيقية.
 
−
* من المستحيل الحصول على فكرة جيدة عن كيفية استجابة تطبيقك للّمس عن طريق استخدام المُحاكيات أو المُشاكلات. بدلاً من ذلك، تشغيل التطبيق على جهاز حقيقي سيكشف عن المشكلات المتعلقة بأحجام عناصر واجهة المستخدم، والاستجابة، وما إلى ذلك.
 
−
* على الرغم من أنه سيكون من الجيد أن تكون قادراً على الاختبار على جهاز واحد فقط لكل منصة، فمن الأفضل اختبار العديد من الأجهزة بمُختَلَف المنصات التي تدعمها. على سبيل المثال، ما قد ينجح على هاتف أندرويد معيّن قد يفشل على جهاز أندرويد آخر. وما قد يعمل على جهاز iOS 7 قد يفشل على جهاز iOS 6.
 
−
 
−
بالطبع، من المستحيل اختبار كل الأجهزة الموجودة في السوق. لهذا السبب، قد يكون من الحكمة توظيف عدة أشخاص يملكون أجهزة مختلفة للاختبار. على الرغم من أنهم لن يكشفوا كل المشاكل الممكنة، إلا أنهم على الأرجح سيكتشفون ثغرات ومشاكل لن يكون بمقدورك إيجادها لوحدك.
 
−
 
−
نصيحة: على أجهزة Android Nexus، يمكن تثبيت عدة إصدارات مختلفة من أندرويد بسهولة على الجهاز. ستتيح لك هذه العملية البسيطة اختبار تطبيقك بسهولة على مستويات مختلفة من أندرويد باستخدام جهاز واحد، وستعفيك من شراء عدد كبير من الأجهزة الضمان أو اختراق (jailbreak) جهازك. للمزيد من التفاصيل ارجع إلى الصفحة [https://developers.google.com/android/nexus/images#instructions Google Android factory images and instructions].
 
−
 
−
 
−
يتطلب التصحيح في (Debugging) كوردوفا بعض الإعدادات. فعلى عكس تطبيقات سطح المكتب، لا يمكنك ببساطة فتح أدوات المطورين على جهازك المحمول وبدء التصحيح، لحسن الحظ هناك بعض البدائل الممتازة.
 
−
 
−
== تصحيح تطبيقات iOS ==
 
−
=== Xcode ===
 
−
 
−
يمكنك عبر Xcode تصحيح الجانب الأصلي (native side) لمنصة iOS من تطبيقات كوردوفا. تحقق من أنّ إظهار منطقة التصحيح ‎(View -> Debug Area)‎. بمجرد تشغيل التطبيق على الجهاز (أو المُحاكي)، فيمكنك مطالعة مُخرجات السجل (log output) في منطقة التصحيح. فذلك هو المكان الذي ستُطبع فيه الأخطاء والتنبيهات. يمكنك أيضًا وضع نقاط توقف (breakpoints) داخل الملفات المصدرية. هذا سيسمح لك بالمرور عبر الشيفرة البرمجية سطرًا سطرًا، واستعراض حالة المتغيرات في كل خطوة. يتم إظهار حالة المتغيرات في منطقة التصحيح عند كل نقطة توقف. بمجرد تشغيل تطبيقك على الجهاز، يمكنك إظهار مفتش Safari - ‏Safari's web inspector‏ - (كما هو موضح أدناه) لتصحيح [[Cordova/webviews|المعرض]] وملفات [[JavaScript|[[Java|جافا]]اسكريبت]] الخاصة بالتطبيق. لمزيد من التفاصيل، راجع توثيق [https://developer.apple.com/support/debugging/ Apple Support].
 
−
=== التصحيح عند بًُعد عبر مفتش سافاري ===
 
−
 
−
باستخدام مفتش Safari ‏(Safari's web inspector‏)‏، يمكنك تصحيح طريقة [[Cordova/webviews|المعرض]] و ملفات [[JavaScript|[[Java|جافا]]اسكريبت]] الخاصة بتطبيقك. هذه الأداة تعمل فقط على منصات OSX، ابتداءً من iOS 6. إذ يستخدم متصفح Safari للاتصال بجهازك (أو المحاكي) وسيقوم بين أدوات المطورين الخاصة بالمتصفح وبين تطبيق كوردوفا. هكذا يمكنك الاستفادة من أدوات التطوير - فحص/ومعالجة الدوم DOM، تصحيح أخطاء [[JavaScript|[[Java|جافا]]اسكريبت]]، فحص الشبكة، وحدة التحكم والمزيد. مثل Xcode، يُمكِّنك مفتش Safari من تعيين نقاط توقف في شيفرة [[JavaScript|[[Java|جافا]]اسكريبت]]، وعرض حالة المتغيرات عند تلك النقاط. يمكنك الاطلاع على الأخطاء والتنبيهات والرسائل المطبوعة على وحدة التحكم. يمكنك أيضًا تشغيل أوامر [[JavaScript|[[Java|جافا]]اسكريبت]] مباشرة من وحدة التحكم أثناء تشغيل التطبيق. لمزيد من التفاصيل حول كيفية إعداد مفتش Safari وما يمكنك فعله به، راجع الصفحتين [http://moduscreate.com/enable-remote-web-inspector-in-ios-6/ Enabling Remote Web Inspector in iOS 6] و [https://developer.apple.com/library/safari/documentation/AppleApplications/Conceptual/Safari_Developer_Guide/Introduction/Introduction.html Safari Web Inspector Guide].
 
−
 
−
== التصحيح عن بعد عبر كروم ==
 
−
 
−
مثل Safari، يعمل كروم مع أندرويد فقط، ولكن يمكن استخدامه من أي منصة مكتبية. فهو يتطلب على الأقل الإصدار Android 4.4 (KitKat)‎، والمستوى 19 من واجهة برمجة التطبيقات (API)، و Chrome 30+‎ (على سطح المكتب). بمجرد ربط الاتصال، ستحصل على نفس أدوات المطورين (Chrome Dev) لأجل تطبيقات الجوال كما تفعل مع تطبيقات سطح المكتب. والأفضل من ذلك، أن أدوات Chrome Dev تعطيك خيار المرآة، والذي يعرض تطبيقك على محاكي جهاز هاتفي. ولكنه أكثر من مجرد عرض - إذ يمكنك التمرير والنقر من أدوات التطوير، وسترى التحديثات على جهاز الهاتف. يمكن الاطلاع على مزيد من التفاصيل حول التصحيح عن بُعد عبر Chrome من هنا: [https://developers.google.com/chrome/mobile/docs/debugging https://developers.google.com/chrome/mobile/docs/debugging]
 
−
 
−
إن كان بإمكانك رؤية جهازك في قسم فحص الأجهزة (inspect devices section)، ولكن لم تستطتع مشاهدة [[Cordova/webviews|معرض]] كوردوفا، فقد تحتاج إلى إضافة <code>android:debuggable="true"</code> في العقدة <code><application></code> في الملف <code>AndroidManifest.xml</code>.
 
−
 
−
من الممكن استخدام أدوات Chrome Dev لفحص تطبيقات iOS، من خلال خادم WebKit وسيط (WebKit proxy)‏: [https://github.com/google/ios-webkit-debug-proxy/ https://github.com/google/ios-webkit-debug-proxy/]
 
−
 
−
== Ripple ==
 
−
 
−
Ripple هو مُشاكل (emulator) لمشاريع كوردوفا يعمل على سطح المكتب. حيث يتيح لك تشغيل تطبيق كوردوفا على سطح المكتب، وإنشاء (اختلاق) العديد من ميزات كوردوفا. على سبيل المثال، يتيح لك محاكاة مقياس التسارع (accelerometer) لاختبار أحداث الاهتزاز (shake events). حيث يقوم بتزييف الواجهة البرمجية للكاميرا من خلال السماح لك بتحديد صورة من القرص الصلب. يساعدك Ripple على التركيز أكثر على شيفرتك البرمجية بدلاً من القلق بشأن إضافات كوردوفا. يمكنك معرفة المزيد عن Ripple من هنا: [http://ripple.incubator.apache.org/ http://ripple.incubator.apache.org/]
 
−
 
−
== Weinre ==
 
−
 
−
ينشئ Weinre خادمًا محليًا يمكنه استضافة عميل تصحيح (debug client) يعمل عن بًعد لاستخدامه مع تطبيقات كوردوفا. بعد تثبيته وتشغيله، يمكنك نسخ سطر من الشيفرة البرمجية إلى تطبيق كوردوفا ثم إعادة تشغيله. يمكنك بعد ذلك فتح لوحة أدوات التطوير على سطح المكتب لبدء العمل على التطبيق. قد لا يبدو Weinre بنفس أناقة مُصحِّحَي Chrome و Safari Remote، ولكنه يتميز بالقدرة على العمل مع مجموعة أكبر بكثير من أنظمة التشغيل والمنصات. يمكن الاطلاع على مزيد من المعلومات هنا: [http://people.apache.org/%7Epmuellr/weinre/docs/latest/ http://people.apache.org/~pmuellr/weinre/docs/latest/]
 
−
 
−
== خيارات أخرى ==
 
−
* لمزيد من الأمثلة والشروحات حول نصائح التصحيح أعلاه، راجع الصفحة: [http://developer.telerik.com/featured/a-concise-guide-to-remote-debugging-on-ios-android-and-windows-phone/ http://developer.telerik.com/featured/a-concise-guide-to-remote-debugging-on-ios-android-and-windows-phone/]
 
−
 
−
 
−
ليس من السهل بناء تطبيقات جميلة وأنيقة بكوردوفا، خاصة على المطورين. العديد من الناس يختارون استخدام إطار لواجهة المستخدمين (UI framework) لتسهيل ذلك. فيما يلي قائمة مختصرة بالخيارات الممكنة:
 
−
* [http://jquerymobile.com jQuery Mobile] - يعمل jQuery Mobile تلقائيًا على تحسين تخطيطك (layout) ليمنحك أداءً أفضل على الهاتف. كما أنه يتولى إنشاء تطبيقات الصفحة الأحادية (SPA) تلقائيا.
 
−
* [http://ionicframework.com/ ionic] - يملك هذا الإطار المُتميّز واجهة سطر أوامر خاصة به لمعالجة إنشاء المشاريع.
 
−
* [http://goratchet.com/ Ratchet] - مُطوّر من قبل نفس الأشخاص الذين طوروا Bootstrap.
 
−
* [http://www.telerik.com/kendo-ui Kendo UI] - واجهة مستخدم وإطار تطبيقات مفتوح المصدر من Telerik.
 
−
[http://topcoat.io Topcoat]
 
−
[http://facebook.github.io/react/ ReactJS]
 
−
 
−
عند بناء واجهة المستخدم، من المهم التفكير في جميع المنصات التي تستهدفها، وفي توقعات المستخدمين على كل منصة. على سبيل المثال، تطبيقات أندرويد التي تعتمد واجهة مستخدم على شاكلة نمط المنصة iOS، قد لا تتناسب مع مستخدمي أندرويد. يتم فرض نمط واجهة المستخدم في بعض الأحيان من قبل مخازن التطبيقات (application stores). ولهذا السبب، من المهم أن تحترم خصوصيات كل منصة، وأن تكون على دراية بمختلف إرشادات واجهات المستخدمين لتلك المنصات:
 
−
[https://developer.apple.com/library/ios/documentation/userexperience/conceptual/MobileHIG/index.html iOS]
 
−
[http://developer.android.com/design/index.html Android]
 
−
[https://dev.windows.com/en-us/design Windows Phone]
 
−
 
−
== مقالات ومصادر إضافية عن واجهة المستخدم ==
 
−
 
−
على الرغم من أن معايير المتصفحات أصبحت أكثر وأكثر اتساقا، فلا نزال مضطرين أحيانًا للتعامل مع بعض المعايير المخصوصة بكل متصفح على حدة (عبر البادئات المُزعجة webkit- و ‎-ms.) المقالة التالية مهمة لمن يريد تطوير واجهة مستخدمين لتطبيقات عابرة للمنصات (cross browser): [http://blogs.windows.com/windows_phone/b/wpdev/archive/2012/11/15/adapting-your-webkit-optimized-site-for-internet-explorer-10.aspx http://blogs.windows.com/windows_phone/b/wpdev/archive/2012/11/15/adapting-your-webkit-optimized-site-for-internet-explorer-10.aspx]
 
−
 
−
 
−
على الرغم من أن كوردوفا تسهّل عملية التطوير العابر للمنصات، فلا تتوقع أبدًا أن تعزلك بشكل كامل عن المنصة الأصلية. لذلك يجب أن تكون على وعي بالقيود الموجودة.
 
−
 
−
== تحميل المحتوى عن بُعد ==
 
−
 
−
استدعاء دوال [[JavaScript|[[Java|جافا]]اسكريبت]] (في كوردوفا) من صفحة HTML محملة عن بُعد (أي صفحة HTML غير مُخزّنة محليًا على الجهاز) ليس مدعومًا. هذا لأن كوردوفا لم تُصمّم لأجل ذلك، ولم يقم مجتمع كوردوفا باختبار هذا الإعداد. في حين أنه قد يعمل في بعض الظروف، إلا أنه غير موصى به وغير مدعوم. هناك تحديات من هذه السياسة، وهو الحفاظ على التزامن بين إصداري الأجزاء المكتوبة بلغة [[JavaScript|[[Java|جافا]]اسكريبت]] والأجزاء الأصلية من كوردوفا (نظرًا لأنها موصولة بواجهات برمجيي خاصة قابلة للتغيير)، إضافة إلى موثوقية المحتويات البعيدة التي تستدعي دوال محلية أصلية (native local functions)، وكذلك احتمال الرفض من متجر التطبيقات.
 
−
 
−
عرض محتويات HTML المُحمّلة عن بعد في [[Cordova/webviews|معرض]] يجب أن يحدث باستخدام InAppBrowser. صُمِّم InAppBrowser بحيث يمنع شيفرات [[JavaScript|[[Java|جافا]]اسكريبت]] المُنفّدة في تلك المحتويات الخارية من الوصول إلى الواجهة البرمجية لتطبيقات [[JavaScript|[[Java|جافا]]اسكريبت]]-كوردوفا للأسباب المذكورة أعلاه. يرجى الرجوع إلى الدليل [../appdev/security/index.html Security Guide].
 
−
 
−
 
−
فيما يلي بعض الطرق لمواكبة مستجدات كوردوفا.
 
−
* اشترك في [http://cordova.apache.org/#news Cordova blog].
 
−
* اشترك في [http://cordova.apache.org/#mailing-list developer list]. ملاحظة - هذه ليست مجموعة دعم! ولكنه المكان الذي تتم فيه مناقشة كل ما يتعلق بتطوير كوردوفا.
 
−
 
−
 
−
الروابط التالية هي أفضل الأماكن التي يمكن أن تحصل منها على المساعدة حول كل ما يتعلق بكوردوفا:
 
−
* StackOverflow: [http://stackoverflow.com/questions/tagged/cordova http://stackoverflow.com/questions/tagged/cordova] باستخدام الوسم Cordova، يمكنك استعراض وتصفح جميع الأسئلة المتعلقة بكوردوفا. لاحظ أن StackOverflow يحوّل تلقائيًا الوسم"Phonegap" إلى الوسم "Cordova"، وبذلك ستتمكن من الوصول إلى الأسئلة القديمة أيضًا
 
−
* PhoneGap Google Group: [https://groups.google.com/forum/#!forum/phonegap https://groups.google.com/forum/#!forum/phonegap] مجموعة جوجل هذه كانت منتدى الدعم القديم لمّا كانت كوردوفا لا تزال تسمى PhoneGap صحيح أنه لا يزال هناك الكثير من مستخدمي كوردوفا الذين يترددون على هذه المجموعة، إلا أنّ مجتمع كوردوفا قد أعرب عن اهتمامه بالتركيز بشكل أكبر على استخدام StackOverflow للحصول على الدعم
 
−
* الملتقيات: [http://phonegap.meetup.com http://phonegap.meetup.com] - حاول العثور على مجموعات الملتقيات المحلية لكوردوفا أو PhoneGap.
 
 
==مصادر==
 
==مصادر==
−
*[https://cordova.apache.org/docs/en/latest/guide/next/index.html صفحة Best Practices Cordova app development في توثيق كوردوفا الرسمي.]
+
*[https://cordova.apache.org/docs/en/latest/guide/next/index.html صفحة Next Steps في توثيق كوردوفا الرسمي.]

المراجعة الحالية بتاريخ 10:26، 4 ديسمبر 2020

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

أفضل ممارسات التطوير في كوردوفا

التطبيقات أحادية الصفحة (SPA) هي صديقك المفضل

من المهم أن تُصمّم تطبيقات كوردوفا وفق مقاربة التطبيقات أحادية الصفحة (SPA، اختصار للعبارة Single Page Application). هذه التطبيقات من جانب العميل (client-side application) تُشغّل عبر طلبية (request) واحدة من صفحة إلكترونية، إذ يحمِّل المستخدم في البداية مجموعة أولية من الموارد (ملفات HTML و CSS و JavaScript)، أمَّا التحديثات الأخرى (إظهار عارض [view] جديد، وتحميل البيانات...) فتُجرَى عبر طلبات XHR.

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

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

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

إليك بعض الأمثلة عن مكتبات SPA التي يمكنك استخدامها في تطبيقات كوردوفا:

وغيرها كثير.

اعتبارات متعلقة بالأداء

في هذا القسم، سنتكلم عن بعض الأساليب المُتبعة لتحسين أداء تطبيقاتك:

النقر مقابل اللمس (Click versus Touch)

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

لم تعد معظم إصدارات Android تفرض هذا التأخير، لكن منصة iOS لا تزال تفعل ذلك افتراضيا. في منصة iOS، يمكنك التخلص من هذا التأخير عبر استخدام WkWebView بدلاً من UIWebView الافتراضي. وفي Android و iOS، يجب عليك التأكد من أن يكون للوسم الوصفي للعارضعلى الأقل width=device-width، وإلا فسيظل التأخير باقيا. إذا كنت بحاجة إلى دعم أجهزة قديمة (Android 4.4 أو iOS 8) ، فيمكنك استخدام FastClick، أو استخدام touchstart و touchend بدلاً من click.


تحويلات CSS مقابل التعديل على DOM

استخدام تحويلات CSS المُسرّعة (accelerated CSS transitions) للأجهزة أفضل بكثير من استخدام JavaScript لإنشاء الرسوميات (animations). انظر في قائمة الموارد في نهاية هذا القسم للاطلاع على أمثلة.

بطء الشبكة (Networks Suck)

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

إليك المصادر والمراجع التالية التي يمكن أن تستفيد منها في هذا الخصوص:

رصد انقطاع الاتصال (Offline) والتعامل معه

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

لاحظ أن الحدثين online و offline، وكذلك الواجهة البرمجية للاتصال بالشبكة (Network Connection API) ليست مثالية. لذلك قد تحتاج إلى استخدام طلبية XHR للتحقق مما إن كان الجهاز متصلًا أو منقطعًا عن الإنترنت.

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

إدارة الترقيات

ترقية مشاريع كوردوفا

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

cordova platform rm android
cordova platform add android

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

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

ترقية الإضافات

لا توجد حاليًا آلية لترقية الإضافات المُعدّلة عبر أمرٍ واحد. بدلًا من ذلك، أزل الإضافة ثم أضفها مجددًا إلى مشروعك، وسيُثبّت الإصدار الجديد:

cordova plugin rm some-plugin
cordova plugin add some-plugin

ارجع إلى صفحة إدارة إصدارات المنصات والإضافات لمزيد من التفاصيل.

تأكد من مراجعة توثيق الإضافة المحدّثة، حيث قد تحتاج إلى تعديل شيفرتك لتعمل مع الإصدار الجديد. تأكد أيضًا من أن الإصدار الجديد من الإضافة يعمل دون مشاكل مع إصدار مشروع كوردوفا خاصتك.

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

إن كان مشروعك يحتوي على الكثير من الإضافات التي تحتاج إلى التحديث، فيمكنك ربح الوقت بإنشاء نص برمجي shell أو رُقعة (batch script) تضيف وتزيل الإضافات عبر أمرِ واحدِ.

اختبار تطبيقات كوردوفا

يعد اختبار تطبيقاتك أمرًا بالغ الأهمية. يستخدم فريق كوردوفا أداة Jasmine، ولكن يمكنك استخدام ما يناسبك من الحلول.

الاختبار على المحاكيات مقابل الاختبار على جهاز حقيقي

من الشائع استخدام متصفحات سطح المكتب ومحاكيات برمجية (simulators) أو محاكيات عتادية (emulators) عند تطوير تطبيقات كوردوفا. لكنّ ذلك لا يُعفيك من ضرورة اختبار تطبيقك على أكبر عدد ممكن من الأجهزة الفعلية:

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

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

تنقيح تطبيقات كوردوفا

في أغلب الأحوال، التنقيح (debugging) في كوردوفا واضح ومباشر.

تنقيح تطبيقات iOS

Xcode

يمكنك استخدام بيئة التطوير Xcode لتصحيح الجانب الأصلي (native side) من تطبيقات كوردوفا في منصة iOS. تأكد من إظهار منطقة التصحيح ‎(View -> Debug Area)‎. بمجرد تشغيل التطبيق على الجهاز (أو المُحاكي)، فيمكنك مطالعة مُخرجات السجل (log output) في منطقة التصحيح. فهو المكان الذي ستُطبع فيه الأخطاء والتنبيهات. يمكنك أيضًا وضع نقاط توقف (breakpoints) داخل الشيفرات المصدرية. هذا سيسمح لك بالمرور عبر الشيفرة البرمجية سطرًا سطرًا، واستعراض حالة المتغيرات في كل خطوة. إذ يتم إظهار حالة المتغيرات في منطقة التصحيح عند كل نقطة توقف.

بمجرد تشغيل تطبيقك على الجهاز، يمكنك إظهار مفتش Safari (كما هو موضح أدناه) لتصحيح العارض وملفات JavaScript الخاصة بالتطبيق. لمزيد من التفاصيل، راجع صفحة التنقيح في Apple Support.

التنقيح عند بعد عبر مفتش Safari

باستخدام مفتش Safari ‏(Safari's web inspector‏)‏، يمكنك تصحيح أخطاء العارض و ملفات JavaScript الخاصة بتطبيقك. هذه الأداة تعمل فقط على منصات macOS.

يُستخدم متصفح Safari للاتصال بالجهاز (أو المحاكي)، إذ يربط بين أدوات المطورين الخاصة بالمتصفح وبين تطبيق كوردوفا. هكذا يمكنك الاستفادة من الخدمات التي تقدمها أدوات التطوير ، مثل فحص ومعالجة DOM، وتصحيح أخطاء JavaScript، وفحص الشبكة، ووحدة التحكم والمزيد.

مثل بيئة التطوير Xcode، يُمكِّنك مفتش Safari من تعيين نقاط توقف في شيفرة JavaScript، وعرض حالة المتغيرات عند تلك النقاط. يمكنك الاطلاع على الأخطاء والتنبيهات والرسائل المطبوعة على وحدة التحكم. ويمكنك أيضًا تشغيل أوامر JavaScript مباشرة من وحدة التحكم أثناء تشغيل التطبيق.

لتبدأ الفحص، عليك تمكينه أولاً على الجهاز من Settings > Safari > Advanced > Web Inspector. أما على على سطح المكتب ، قم بتمكين أدوات المطور من Safari > Preferences > Advanced > Show Develop menu في شريط القائمة. ستتمكن عقب ذلك من اختيار الجهاز المتصل والتطبيق الذي تريد فحصه من القائمة Develop.

التنقيح عن بعد عبر Chrome

مثل Safari، يعمل Chrome مع أندرويد فقط، ولكن يمكن استخدامه من أي منصة مكتبية. بمجرد ربط الاتصال، ستحصل على نفس أدوات المطورين (Chrome Dev) المُستخدمة مع تطبيقات سطح المكتب لأجل استخدامها مع تطبيقات الجوال. والأفضل من ذلك، أن أدوات Chrome Dev تعطيك خيار المرآة، والذي يعرض تطبيقك على محاكي هاتفي. ولكنه أكثر من مجرد معرِض، إذ يمكنك التمرير (scroll) والنقر في أدوات التطوير، وسترى التحديثات على جهاز الهاتف.

لتبدأ الفحص، عليك فتح العنوان chrome://inspect في Chrome على سطح المكتب. سترى قائمة بالأجهزة المتصلة والتطبيقات التي يمكنك فحصها. لكن من الضروري إعداد جهازك لأجل التنقيح عبر USB وإلا فلن تعمل هذه الطريقة. يمكن الاطلاع على مزيد من التفاصيل حول التصحيح عن بُعد عبر Chrome من هنا.

إن كان بإمكانك رؤية جهازك في قسم فحص الأجهزة (inspect devices section)، ولكن لم تستطع مشاهدة عارض كوردوفا، فقد تحتاج إلى إضافة android:debuggable="true"‎ إلى العقدة <application> في الملف AndroidManifest.xml.

من الممكن استخدام أدوات Chrome Dev لفحص تطبيقات iOS، من خلال خادم WebKit وسيط (WebKit proxy)‏، يمكنك زيارة صفحته على مستودع git من هنا.

خيارات أخرى

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

واجهة المستخدم

ليس من السهل على المطورين بناء تطبيقات جميلة وأنيقة بكوردوفا. العديد من الناس يختارون استخدام بيئة عمل لواجهة المستخدمين (UI framework) لتسهيل ذلك. فيما يلي قائمة مختصرة بالخيارات الممكنة:

  • ionic - يملك هذا الإطار المُتميّز واجهة سطر أوامر خاصة به لمعالجة إنشاء المشاريع.
  • Ratchet - مُطوّر من قبل نفس الأشخاص الذين طوروا Bootstrap.
  • Kendo UI - واجهة مستخدم وإطار تطبيقات مفتوح المصدر من Telerik.
  • Onsen UI - واجهة مستخدم مفتوحة المصدر للمواقع وتطبيقات كوردوفا.

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

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

اعتبارات خاصة

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

الملاحظات الخاصة بالمنصات

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

تحميل المحتوى عن بعد

استدعاء دوال JavaScript (في كوردوفا) من صفحة HTML محملة عن بُعد (أي صفحة HTML غير مُخزّنة محليًا على الجهاز) ليس مدعومًا. هذا لأنَّ كوردوفا لم تُصمّم لأجل ذلك، كما لم يقم مجتمع كوردوفا باختبار هذا الإعداد. وفي حين أن هذا الأمر قد يعمل في بعض الظروف، إلا أنه غير موصى به وغير مدعوم. لأنه يطرح عدة تحديات، مثل الحفاظ على التزامن بين الأجزاء المكتوبة بلغة JavaScript والأجزاء الأصلية من كوردوفا (نظرًا لأنها موصولة بواجهات برمجية خاصة قابلة للتغيير)، إضافة إلى موثوقية المحتويات البعيدة (remote content) التي تستدعي دوال محلية أصلية (native local functions)، وكذلك احتمال الرفض من متجر التطبيقات.

عرض محتويات HTML المُحمّلة عن بعد في العارض يجب أن يحدث باستخدام InAppBrowser. فقد صُمِّم InAppBrowser بحيث يمنع شيفرات JavaScript المُنفّدة في المحتويات الخارجية من الوصول إلى الواجهة البرمجية لتطبيقات جافاسكريبت-كوردوفا للأسباب المذكورة أعلاه.

يرجى الرجوع إلى صفحة الأمن في كوردوفا.

الاستمرار قُدمًا

فيما يلي بعض الطرق التي ستساعدك على مواكبة مستجدات كوردوفا وهي:

الحصول على المساعدة

الروابط التالية هي أفضل الأماكن التي يمكن أن تحصل منها على المساعدة حول كل ما يتعلق بكوردوفا:

  • Slack: يعد هذا أحد أفضل الأمكنة للحصول على مساعدة من مجتمع كوردوفا، وتحصل على أجوبة لتساؤلاتك.
  • StackOverflow: باستخدام الوسم Cordova، يمكنك استعراض وتصفح جميع الأسئلة المتعلقة بكوردوفا. لاحظ أن الموقع StackOverflow يحوّل تلقائيًا الوسم"Phonegap" إلى الوسم "Cordova"، وبذلك ستتمكن من الوصول إلى الأسئلة القديمة أيضًا.
  • PhoneGap Google Group: هذه كانت صفحة منتدى الدعم القديم لمّا كانت كوردوفا تحمل الاسم PhoneGap صحيح أنه لا يزال هناك الكثير من مستخدمي كوردوفا الذين يترددون على هذه المجموعة، إلا أنّ مجتمع كوردوفا قد أعرب عن اهتمامه بالتركيز بشكل أكبر على استخدام StackOverflow للحصول على الدعم.
  • الملتقيات: للأسف لا توجد ملتقيات محلية لكوردوفا أو PhoneGap في عالمنا العربي. لكن مع تزايد شعبية هذه المنصة نأمل أن نرى ذلك قريبًا، إلى ذلك الحين، سيكون عليك أن تكتفي بالمنتديات والمواقع المذكورة في الأعلى.
  • قسم الأسئلة في أكاديمية حسوب: إن أشكل عليك شيء فاطرح أسئلتك هنا لتحصل على مساعدة مباشرة من المستقلين والمبرمجين على الأكاديمية.

انظر أيضًا

مصادر

مجلوبة من "https://wiki.hsoub.com/index.php?title=Cordova/next_steps&oldid=29951"