react native code push
9.0.0
تحذير
React Native CodePush لن يدعم الهندسة المعمارية الجديدة. من أجل استخدام هذا البرنامج المساعد على الإصدارات الأصلية React بدءًا من 0.76 ، ستحتاج إلى إلغاء الاشتراك من الهندسة المعمارية الجديدة.
ملاحظة: هذا README له صلة فقط بأحدث إصدار من البرنامج المساعد الخاص بنا. إذا كنت تستخدم إصدارًا قديمًا ، فيرجى التبديل إلى العلامة ذات الصلة على Github Repo لعرض المستندات لهذا الإصدار المحدد.
يوفر هذا البرنامج المساعد تكاملًا من جانب العميل لخدمة CodePush ، مما يتيح لك إضافة تجربة تحديث ديناميكية إلى تطبيقات (تطبيقات) React الأصلية بسهولة.
يتكون التطبيق الأصلي React من ملفات JavaScript وأي صور مصاحبة ، يتم تجميعها معًا بواسطة Bundler Metro وتوزيعها كجزء من ثنائي خاص من النظام الأساسي (أي ملف .ipa أو .apk ). بمجرد إصدار التطبيق ، يتطلب تحديث رمز JavaScript (على سبيل المثال إجراء إصلاحات الأخطاء ، إضافة ميزات جديدة) أو أصول الصور ، من إعادة ترجمة الثنائي وإعادة توزيعه ، والذي يتضمن بالطبع أي وقت مراجعة مرتبطًا بالمتجر (المتجر) أنت تنشر ل.
يساعد البرنامج المساعد CodePush في الحصول على تحسينات على المنتج أمام المستخدمين النهائيين على الفور ، من خلال الحفاظ على JavaScript والصور الخاصة بك متزامنة مع التحديثات التي تصدرها إلى خادم CodePush. وبهذه الطريقة ، يحصل تطبيقك على فوائد تجربة الهاتف المحمول غير المتصلة بالإنترنت ، بالإضافة إلى خفة التحديثات "الشبيهة بالويب" للتحديثات الجانبية بمجرد توفرها. إنه فوز!
من أجل التأكد من أن المستخدمين النهائيين لديك دائمًا إصدار وظيفي من التطبيق الخاص بك ، يحتفظ البرنامج المساعد CodePush بنسخة من التحديث السابق ، بحيث في حالة دفع تحديث عن طريق الخطأ ، يمكنه التراجع تلقائيًا. وبهذه الطريقة ، يمكنك أن تطمئن إلى أن خفة الحركة الجديدة الخاصة بك لن تؤدي إلى حظر المستخدمين قبل أن تتاح لك فرصة التراجع على الخادم. إنه مربح للجانبين!
ملاحظة: لا يمكن توزيع أي تغييرات منتج يلمس الكود الأصلي (على سبيل المثال تعديل ملف AppDelegate.m / MainActivity.java ، إضافة مكون إضافي جديد) عبر CodePush ، وبالتالي ، يجب تحديثه عبر المتجر (المتجر) المناسب.
نحن نبذل قصارى جهدنا للحفاظ على التوافق مع الإضافات الخاصة بنا مع الإصدارات السابقة من React Native ، ولكن نظرًا لطبيعة النظام الأساسي ، ووجود كسر التغييرات بين الإصدارات البرنامج المساعد لدعم الإصدار الدقيق من React Native الذي تستخدمه. يوضح الجدول التالي إصدارات Plugin CodePush تدعم رسميًا الإصدارات الأصلية React:
| رد فعل (الإصدار) الأصلي | دعم إصدار (إصدار) CodePush |
|---|---|
| <0.14 | غير مدعوم |
| v0.14 | v1.3 (قدم دعم Android) |
| v0.15-v0.18 | v1.4-v1.6 (تم تقديم دعم أصول iOS) |
| V0.19-V0.28 | v1.7-v1.17 (قدم دعم الأصول Android) |
| v0.29-v0.30 | v1.13-v1.17 (RN أعيد إعادة تمثيل رمز الاستضافة الأصلي) |
| V0.31-V0.33 | v1.14.6-v1.17 (RN refacted stisting code) |
| V0.34-V0.35 | v1.15-v1.17 (RN أعادت إعادة تمثيل رمز الاستضافة الأصلي) |
| v0.36-v0.39 | v1.16-v1.17 (RN refacted استئناف المعالج) |
| V0.40-V0.42 | v1.17 (RN refacted iOS Header Files) |
| V0.43-V0.44 | v2.0+ (RN refacted uimanager تبعيات) |
| v0.45 | v3.0+ (رمز مدير المثيل RN refacted) |
| v0.46 | v4.0+ (RN refacted JS Bundle Loader Code) |
| V0.46-V0.53 | v5.1+ (RN إزالة التسجيل غير المستخدمة من وحدات JS) |
| V0.54-V0.55 | V5.3+ (Android Gradle Plugin 3.x Integration) |
| V0.56-V0.58 | v5.4+ (RN ترقية الإصدارات لأدوات Android) |
| v0.59 | v5.6+ (RN refacted JS Bundle Loader Code) |
| V0.60-V0.61 | v6.0+ (تم ترحيل RN إلى التوليد التلقائي) |
| V0.62-V0.64 | V6.2+ (RN إزالة ليفليضل) |
| v0.65-v0.70 | v7.0+ (RN تحديث iPhone-target-version) |
| v0.71 | V8.0+ (تم نقل RN إلى مفاعل التصرف-plugin) |
ملاحظة: ستتوقف إصدارات react-native-code-push من V5.7.0 عن العمل في المستقبل القريب. يمكنك العثور على مزيد من المعلومات في وثائقنا.
نحن نعمل بجد للرد على إصدارات RN الجديدة ، لكنهم يكسروننا أحيانًا. سنقوم بتحديث هذا المخطط مع كل إصدار RN ، بحيث يمكن للمستخدمين التحقق لمعرفة ما هو دعمنا "الرسمي".
عند استخدام نظام React Native Assets (IE باستخدام require("./foo.png")
| عنصر | الدعامة (S) |
|---|---|
Image | source |
MapView.Marker(يتطلب Maps-maps-native >=O.3.2 ) | image |
ProgressViewIOS | progressImage ، trackImage |
TabBarIOS.Item | icon ، selectedIcon |
ToolbarAndroid(React Native 0.21.0+) | actions[].icon ، logo ، overflowIcon |
Video | source |
تمثل القائمة التالية مجموعة المكونات (والدعائم) التي لا تدعم حاليًا أصولها التي يتم تحديثها عبر CodePush ، نظرًا لاعتمادها على الصور ومقاطع الفيديو الثابتة (أي باستخدام { uri: "foo" } بناء الجملة):
| عنصر | الدعامة (S) |
|---|---|
SliderIOS | maximumTrackImage trackImage thumbImage minimumTrackImage |
Video | source |
مع إصدار مكونات أساسية جديدة ، والتي تدعم الأصول المرجعية ، سنقوم بتحديث هذه القائمة لضمان معرفة المستخدمين بالضبط التي يمكن أن يتوقعوا تحديثها باستخدام CodePush.
ملاحظة: يعمل CodePush فقط مع مكونات الفيديو عند استخدام require في الدعامة المصدر. على سبيل المثال:
< Video source = { require ( "./foo.mp4" ) } / > بمجرد اتباع إرشادات "بدء التشغيل" للأغراض العامة لإعداد حساب CodePush الخاص بك ، يمكنك بدء تشغيل CodePush-Foring الخاص بك React Native Asset عن طريق تشغيل الأمر التالي من داخل دليل جذر التطبيق الخاص بك:
npm install --save react-native-code-pushكما هو الحال مع جميع الإضافات الأصلية React الأخرى ، تختلف تجربة التكامل لنظام التشغيل iOS و Android ، لذا قم بإجراء خطوات الإعداد التالية اعتمادًا على النظام الأساسي (الأساسيات) التي تستهدفها. ملاحظة ، إذا كنت تستهدف كلا النظامين ، فمن المستحسن إنشاء تطبيقات CodePush منفصلة لكل منصة.
إذا كنت ترغب في معرفة كيفية دمج المشاريع الأخرى مع CodePush ، فيمكنك الاطلاع على تطبيقات المثال الممتازة التي يوفرها المجتمع. بالإضافة إلى ذلك ، إذا كنت ترغب في التعرف بسرعة على CodePush + React Native ، فيمكنك الاطلاع على مقاطع الفيديو الرائعة التي تبدأ من قبل Bilal Budhani و/أو Deepak Sisodiya.
ملاحظة: يفترض هذا الدليل أنك استخدمت أمر react-native init لتهيئة مشروع React Native الخاص بك. اعتبارًا من مارس 2017 ، يمكن أيضًا استخدام create-react-native-app لتهيئة مشروع React الأصلي. إذا كنت تستخدم هذا الأمر ، فيرجى تشغيل npm run eject في الدليل الرئيسي لمشروعك للحصول على مشروع يشبه إلى حد كبير ما الذي كان من شأنه أن ينشأ react-native init .
ثم تابع تثبيت الوحدة الأصلية
مع تنزيل المكون الإضافي CodePush وربطه ، وتطبيقك يسأل CodePush من أين تحصل على حزمة JS اليمنى ، والشيء الوحيد المتبقي هو إضافة الكود اللازم إلى تطبيقك للتحكم في السياسات التالية:
متى (وكم مرة) للتحقق من التحديث؟ (على سبيل المثال ، ابدأ التطبيق ، استجابةً للنقر فوق زر في صفحة الإعدادات ، بشكل دوري في بعض الفاصل الزمني الثابت)
عندما يتوفر تحديث ، كيفية تقديمه للمستخدم النهائي؟
أبسط طريقة للقيام بذلك هي "CodePush-emple" مكون الجذر الخاص بالتطبيق. للقيام بذلك ، يمكنك اختيار أحد الخيارين التاليين:
الخيار 1: لف مكون الجذر الخاص بك مع مكون codePush العالي:
لمكون الفصل
import codePush from "react-native-code-push" ;
class MyApp extends Component {
}
MyApp = codePush ( MyApp ) ;للمكون الوظيفي
import codePush from "react-native-code-push" ;
let MyApp : ( ) => React$Node = ( ) => {
}
MyApp = codePush ( MyApp ) ;الخيار 2: استخدم بناء جملة ديكور ES7:
ملاحظة: لم يتم دعم الديكورات بعد في تحديث اقتراح بابل 6.x. قد تحتاج إلى تمكينه عن طريق تثبيت واستخدام Babel-Presech-React-Itive-Lative-0.
لمكون الفصل
import codePush from "react-native-code-push" ;
@ codePush
class MyApp extends Component {
}للمكون الوظيفي
import codePush from "react-native-code-push" ;
const MyApp : ( ) => React$Node = ( ) => {
}
export default codePush ( MyApp ) ;افتراضيًا ، سيقوم CodePush بالتحقق من التحديثات على كل تطبيق. في حالة توفر تحديث ، سيتم تنزيله بصمت ، وتثبيته في المرة القادمة التي يتم فيها إعادة التطبيق (إما بشكل صريح من قبل المستخدم النهائي أو بواسطة نظام التشغيل) ، مما يضمن أقل تجربة غازية للمستخدمين النهائيين. إذا كان التحديث المتاح إلزاميًا ، فسيتم تثبيته على الفور ، مع التأكد من أن المستخدم النهائي يحصل عليه في أقرب وقت ممكن.
إذا كنت ترغب في اكتشاف تطبيقاتك بسرعة أكبر ، فيمكنك أيضًا اختيار المزامنة مع خادم CodePush في كل مرة يستأنف فيها التطبيق من الخلفية.
لمكون الفصل
let codePushOptions = { checkFrequency : codePush . CheckFrequency . ON_APP_RESUME } ;
class MyApp extends Component {
}
MyApp = codePush ( codePushOptions ) ( MyApp ) ;للمكون الوظيفي
let codePushOptions = { checkFrequency : codePush . CheckFrequency . ON_APP_RESUME } ;
let MyApp : ( ) => React$Node = ( ) => {
}
MyApp = codePush ( codePushOptions ) ( MyApp ) ; بدلاً من ذلك ، إذا كنت تريد تحكمًا دقيقًا في الحبيبات عند حدوث الشيك (مثل زر الضغط أو الفاصل الزمني للوقت) ، يمكنك الاتصال CodePush.sync() في أي وقت مع SyncOptions المطلوبة ، وإيقاف تشغيل Codepush التلقائي اختياريًا عن طريق تحديد أ checkFrequency اليدوي:
let codePushOptions = { checkFrequency : codePush . CheckFrequency . MANUAL } ;
class MyApp extends Component {
onButtonPress ( ) {
codePush . sync ( {
updateDialog : true ,
installMode : codePush . InstallMode . IMMEDIATE
} ) ;
}
render ( ) {
return (
< View >
< TouchableOpacity onPress = { this . onButtonPress } >
< Text > Check for updates < / Text >
< / TouchableOpacity >
< / View >
)
}
}
MyApp = codePush ( codePushOptions ) ( MyApp ) ; إذا كنت ترغب في عرض مربع حوار تأكيد تحديث ("تثبيت نشط") ، أو تكوين عند تثبيت تحديث متاح (مثل قوة إعادة تشغيل فورية) أو تخصيص تجربة التحديث بأي طريقة أخرى ، راجع مرجع codePush() API للحصول على معلومات حول كيفية تعديل هذا السلوك الافتراضي.
ملاحظة: إذا كنت تستخدم Saga Redux و Redux ، فيمكنك بدلاً من ذلك استخدام وحدة React-Native-Push-Saga ، والتي تتيح لك التخصيص عندما يتم استدعاء sync بطريقة ربما أبسط/أكثر تحديثًا.
لدى Android Google Play و iOS App Store إرشادات مقابلة لها قواعد يجب أن تكون على دراية بها قبل دمج حل CodePush داخل التطبيق الخاص بك.
تصف الفقرة الثالثة من موضوع تعاطي الجهاز وشبكة أن تحديث التعليمات البرمجية المصدر بأي طريقة أخرى غير آلية تحديث Google Play مقيد. لكن هذا التقييد لا ينطبق على تحديث حزم JavaScript.
لا ينطبق هذا التقييد على التعليمات البرمجية التي تعمل في جهاز افتراضي ولديها وصول محدود إلى واجهات برمجة تطبيقات Android (مثل JavaScript في WebView أو Browser).
هذا يسمح بالكامل CodePush لأنه يقوم بتحديث حزم JS فقط ولا يمكن تحديث جزء الرمز الأصلي.
الفقرة 3.3.2 ، منذ عودة اتفاقية ترخيص برنامج Apple Developer لعام 2015 ، سمحت بالكامل بإجراء التحديثات المطلقة لجافا سكريبت والأصول-وفي إصدارها الأخير (20170605) يمكن تنزيله هنا حتى هذا الحكم أوسع:
قد يتم تنزيل الرمز المفسر على تطبيق ما ولكن لفترة طويلة فقط مثل هذا الرمز: (أ) لا يغير الغرض الأساسي للتطبيق من خلال توفير الميزات أو الوظائف التي لا تتفق مع الغرض المقصود والمعلن عن التطبيق كما هو موضح في التطبيق لا يقوم المتجر ، (ب) بإنشاء متجر أو واجهة متجر للرمز أو التطبيقات الأخرى ، ولا يتجاوز (ج) التوقيع أو صندوق الرمل أو ميزات الأمان الأخرى لنظام التشغيل.
يتيح لك CodePush اتباع هذه القواعد في امتثال كامل طالما أن التحديث الذي تدفعه لا ينحرف بشكل كبير من منتجك من نية متجر التطبيقات الأصلية المعتمدة.
لمزيد من البقاء في الامتثال لإرشادات Apple ، نقترح أن التطبيقات الموزعة لمتجر التطبيقات لا تتيح خيار updateDialog عند الاتصال sync ، لأنه في إرشادات مراجعة متجر التطبيقات ، كتبت ذلك:
يجب ألا تجبر التطبيقات المستخدمين على تقييم التطبيق أو مراجعة التطبيق أو تنزيل التطبيقات الأخرى أو إجراءات أخرى مماثلة من أجل الوصول إلى الوظائف أو المحتوى أو استخدام التطبيق.
هذا ليس بالضرورة هو الحال بالنسبة لـ updateDialog ، لأنه لن يجبر المستخدم على تنزيل الإصدار الجديد ، ولكن على الأقل يجب أن تكون على دراية بهذا الحكم إذا قررت إظهاره.
بمجرد تكوين التطبيق الخاص بك وتوزيعه على المستخدمين ، وقمت بإجراء بعض التغييرات في JS أو Asset ، فقد حان الوقت لإصدارها. تتمثل الطريقة الموصى بها لإصدارها في استخدام الأمر release-react في CLI Center Center ، والذي سيحمل ملفات JavaScript وملفات الأصول وإصدار التحديث إلى خادم CodePush.
ملاحظة: قبل أن تتمكن من بدء إطلاق التحديثات ، يرجى تسجيل الدخول إلى مركز التطبيق عن طريق تشغيل أمر appcenter login .
في أبسط نموذجه ، يتطلب هذا الأمر فقط معلمة واحدة: اسم مالكك + "/" + اسم تطبيق.
appcenter codepush release-react -a < ownerName > / < appName >
appcenter codepush release-react -a < ownerName > /MyApp-iOS
appcenter codepush release-react -a < ownerName > /MyApp-Android يمكّن أمر release-react هذا سير العمل البسيط لأنه يوفر العديد من الإعدادات الافتراضية المعقولة (مثل إنشاء حزمة إصدار ، على افتراض أن ملف إدخال التطبيق الخاص بك على iOS هو إما index.ios.js أو index.js ). ومع ذلك ، يمكن تخصيص كل هذه التخلف عن السداد للسماح بالمرونة الإضافية عند الضرورة ، مما يجعلها مناسبة بشكل جيد لمعظم السيناريوهات.
# Release a mandatory update with a changelog
appcenter codepush release-react -a < ownerName > /MyApp-iOS -m --description " Modified the header color "
# Release an update for an app that uses a non-standard entry file name, and also capture
# the sourcemap file generated by react-native bundle
appcenter codepush release-react -a < ownerName > /MyApp-iOS --entry-file MyApp.js --sourcemap-output ../maps/MyApp.map
# Release a dev Android build to just 1/4 of your end users
appcenter codepush release-react -a < ownerName > /MyApp-Android --rollout 25 --development true
# Release an update that targets users running any 1.1.* binary, as opposed to
# limiting the update to exact version name in the build.gradle file
appcenter codepush release-react -a < ownerName > /MyApp-Android --target-binary-version " ~1.1.0 "
يدعم عميل CodePush التحديثات التفاضلية ، لذلك على الرغم من أنك ستصدر حزمة JS والأصول في كل تحديث ، فإن المستخدمين النهائيين لن يقوموا بتنزيل الملفات التي يحتاجونها إلا. تعالج الخدمة هذا تلقائيًا حتى تتمكن من التركيز على إنشاء تطبيقات رائعة ويمكننا القلق بشأن تحسين تنزيلات المستخدم النهائي.
لمزيد من التفاصيل حول كيفية عمل أمر release-react ، وكذلك المعلمات المختلفة التي يعرضها ، راجع مستندات CLI. بالإضافة إلى ذلك ، إذا كنت تفضل التعامل مع تشغيل أمر react-native bundle ، وبالتالي ، تريد حلًا أكثر مرونة من release-react ، راجع أمر release لمزيد من التفاصيل.
إذا واجهت أي مشكلات ، أو لديك أي أسئلة/تعليقات/تعليقات ، فيمكنك Ping لنا ضمن قناة #رمز Push على Reactiflux أو إرسال بريد إلكتروني إلينا و/أو التحقق من تفاصيل استكشاف الأخطاء وإصلاحها أدناه.
ملاحظة: يجب اختبار تحديثات CodePush في أوضاع غير وضع التصحيح. في وضع التصحيح ، يقوم React Native App دائمًا بتنزيل حزمة JS التي تم إنشاؤها بواسطة Packager ، لذلك لا تنطبق حزمة JS التي تم تنزيلها بواسطة CodePush.
في مستندات البدء الخاصة بنا ، أوضحنا كيفية تكوين المكون الإضافي CodePush باستخدام مفتاح نشر محدد. ومع ذلك ، من أجل اختبار إصداراتك بشكل فعال ، من الأهمية بمكان أن تستفيد من عمليات نشر Staging Production التي يتم إنشاؤها تلقائيًا عند إنشاء تطبيق CodePush الخاص بك لأول مرة (أو أي عمليات نشر مخصصة قد تكون قد قمت بإنشائها). وبهذه الطريقة ، لا تصدر أبدًا تحديثًا لمستخدميك النهائيين الذين لم تتمكن من التحقق من صحة نفسك.
ملاحظة: يمكن أن تساعد ميزة التراجع من جانب العميل في إلغاء حظر المستخدمين بعد تثبيت إصدار أدى إلى تعطل ، والتراجع من جانب الخادم (أي appcenter codepush rollback ) يسمح لك بمنع المستخدمين الإضافيين من تثبيت إصدار سيء بمجرد تحديده. ومع ذلك ، فمن الواضح أنه من الأفضل أن تتمكن من منع التحديث الخاطئ من إطلاقه على نطاق واسع في المقام الأول.
يتيح لك الاستفادة من عمليات نشر Staging Production تحقيق سير عمل مثل ما يلي (لا تتردد في التخصيص!):
حرر تحديث CodePush إلى نشر Staging الخاص بك باستخدام الأمر appcenter codepush release-react (أو appcenter codepush release إذا كنت بحاجة إلى مزيد من التحكم)
قم بتشغيل بناء التدريج/الإصدار التجريبي لتطبيقك ، ومزامنة التحديث من الخادم ، والتحقق من أنه يعمل كما هو متوقع
قم بترويج الإصدار الذي تم اختباره من Staging إلى Production باستخدام أمر appcenter codepush promote
قم بتشغيل بناء الإنتاج/الإصدار لتطبيقك ، وقم بمزامنة التحديث من الخادم والتحقق من أنه يعمل كما هو متوقع
ملاحظة: إذا كنت ترغب في اتباع نهج أكثر حذراً ، فيمكنك حتى اختيار إجراء "بدء تشغيل" كجزء من رقم 3 ، والذي يتيح لك التخفيف الأجهزة/الشروط الممكنة؟) من خلال جعل تحديث الإنتاج متاحًا فقط لنسبة مئوية من المستخدمين (على سبيل المثال appcenter codepush promote -a <ownerName>/<appName> -s Staging -d Production -r 20 ). بعد ذلك ، بعد انتظار فترة معقولة من الوقت لمعرفة ما إذا كانت أي تقارير تحطم أو ملاحظات العملاء تأتي ، يمكنك توسيعها إلى جمهورك بأكمله عن طريق تشغيل appcenter codepush patch -a <ownerName>/<appName> Production -r 100 .
ستلاحظ أن الخطوات المذكورة أعلاه تشير إلى "بناء التدريج" و "بناء الإنتاج" لتطبيقك. إذا كانت عملية الإنشاء الخاصة بك تنشئ بالفعل ثنائيات مميزة لكل "بيئة" ، فأنت لست بحاجة إلى قراءة أي شيء آخر ، لأن تبديل مفاتيح نشر CodePush يشبه تمامًا التعامل مع التكوين الخاص بالبيئة لأي خدمة أخرى يستخدمها تطبيقك (مثل Facebook). ومع ذلك ، إذا كنت تبحث عن أمثلة ( بما في ذلك المشاريع التجريبية ) حول كيفية إعداد عملية الإنشاء الخاصة بك لاستيعاب ذلك ، ثم الرجوع إلى الأقسام التالية ، اعتمادًا على النظام الأساسي (المنصات) التي يستهدفها تطبيقك:
يوضح القسم أعلاه كيف يمكنك الاستفادة من عمليات نشر CodePush المتعددة من أجل اختبار التحديثات الخاصة بك بشكل فعال قبل إطلاقها على نطاق واسع إلى المستخدمين النهائيين. ومع ذلك ، نظرًا لأن سير العمل هذا يضمن بشكل ثابت في مهمة النشر في الثنائي الفعلي ، فإن إنشاء التدريج أو الإنتاج لن يؤدي إلا إلى مزامنة التحديثات من هذا النشر. في كثير من الحالات ، يكون هذا يكفي ، نظرًا لأنك تريد فقط فريقك وعملائك وأصحاب المصلحة ، وما إلى ذلك أن يتزامن مع إصدارات ما قبل الإنتاج ، وبالتالي ، فهي تحتاج فقط إلى بناء يعرف كيفية المزامنة مع التدريج. ومع ذلك ، إذا كنت ترغب في أن تكون قادرًا على إجراء اختبارات A/B ، أو توفير الوصول المبكر لتطبيقك إلى مستخدمين معينين ، فقد يكون من المفيد جدًا أن تكون قادرًا على وضع مستخدمين (أو جماهير) ديناميكيًا في وقت التشغيل.
من أجل تحقيق هذا النوع من سير العمل ، كل ما عليك فعله هو تحديد مفتاح النشر الذي تريد أن يزامنه المستخدم الحالي عند استدعاء طريقة codePush . عند تحديد ذلك ، سيتغلب هذا المفتاح على "الافتراضي" الذي تم توفيره في ملفات Info.plist (iOS) أو MainActivity.java (Android). يتيح لك ذلك إنتاج بناء للتدريج أو الإنتاج ، وهو ما يمكن أيضًا "إعادة توجيهه" ديناميكيًا حسب الحاجة.
// Imagine that "userProfile" is a prop that this component received
// which includes the deployment key that the current user should use.
codePush . sync ( { deploymentKey : userProfile . CODEPUSH_KEY } ) ;مع هذا التغيير في مكانه ، أصبح الأمر مجرد مسألة اختيار كيفية تحديد تطبيقك لمفتاح النشر الصحيح للمستخدم الحالي. في الممارسة العملية ، عادة ما يكون هناك حلان لهذا:
فضح آلية مرئية للمستخدم لتغيير عمليات النشر في أي وقت. على سبيل المثال ، يمكن أن يكون لصفحة الإعدادات الخاصة بك تبديل لتمكين الوصول إلى "بيتا". يعمل هذا النموذج بشكل جيد إذا لم تكن مهتمًا بخصوصية تحديثات ما قبل الإنتاج ، ولديك مستخدمون للطاقة قد يرغبون في الاشتراك في التحديثات في وقت سابق (وربما عربات التي تجرها الدواب) في إرادتهم (نوع من قنوات الكروم ). ومع ذلك ، فإن هذا الحل يضع القرار في أيدي المستخدمين ، والذي لا يساعدك على إجراء اختبارات A/B بشفافية.
قم بتعليق الملف الشخصي من جانب الخادم للمستخدمين مع جزء إضافي من البيانات الوصفية التي تشير إلى النشر الذي يجب عليهم مزامنته. بشكل افتراضي ، يمكن للتطبيق الخاص بك فقط استخدام المفتاح المدمج الثنائي ، ولكن بعد مصادقة المستخدم ، يمكن أن يختار الخادم "إعادة توجيه" إلى نشر مختلف ، والذي يسمح لك بوضع بعض المستخدمين أو المجموعات بشكل متزايد في عمليات نشر مختلفة حسب الحاجة . يمكنك حتى اختيار تخزين استجابة الخادم في التخزين المحلي بحيث يصبح الافتراضي الجديد. إن كيفية تخزين المفتاح جنبًا إلى جنب مع ملفات تعريف المستخدم الخاصة بك تصل تمامًا إلى حل المصادقة الخاص بك (على سبيل المثال Auth0 ، Firebase ، API Custom DB + REST) ، ولكنه تافهة بشكل عام.
ملاحظة: إذا لزم الأمر ، يمكنك أيضًا تطبيق حل هجين سمح للمستخدمين النهائيين بالتبديل بين عمليات النشر المختلفة ، مع السماح أيضًا لخادمك بتجاوز هذا القرار. وبهذه الطريقة ، لديك تسلسل هرمي لـ "حل النشر" الذي يضمن أن تطبيقك لديه القدرة على تحديث نفسه خارج الصندوق ، يمكن للمستخدمين النهائيين أن يشعروا بالمكافأة من خلال الوصول المبكر إلى البتات ، ولكن لديك أيضًا القدرة على قم بتشغيل اختبارات A/B على المستخدمين حسب الحاجة.
نظرًا لأننا نوصي باستخدام نشر Staging لاختبار ما قبل الإصدار للتحديثات الخاصة بك (كما هو موضح في القسم السابق) ، فليس من المنطقي استخدامه لإجراء اختبارات A/B الخاصة بك ، بدلاً من السماح مبكرًا- الوصول (كما هو موضح في الخيار رقم 1 أعلاه). لذلك ، نوصي بالاستفادة الكاملة من عمليات نشر التطبيق المخصصة ، بحيث يمكنك تقسيم المستخدمين الخاص بك ، ومع ذلك ، فمن المنطقي لاحتياجاتك. على سبيل المثال ، يمكنك إنشاء عمليات نشر طويلة الأجل أو حتى لمرة واحدة ، وإصدار متغير من تطبيقك ، ثم ضع بعض المستخدمين فيه لمعرفة كيفية مشاركتهم.
// #1) Create your new deployment to hold releases of a specific app variant
appcenter codepush deployment add - a < ownerName > / <appName> test-variant-one
// #2) Target any new releases at that custom deployment
appcenter codepush release - react - a < ownerName > / <appName> -d test-variant-one ملاحظة: سيأخذ إجمالي عدد المستخدمين المذكور في "مقاييس تثبيت" النشر الخاصة بك في الاعتبار المستخدمين الذين "تحولوا" من نشر إلى آخر. على سبيل المثال ، إذا كان نشر Production الخاص بك يوضح حاليًا وجود مستخدم كامل واحد ، لكنك تبديل هذا المستخدم ديناميكيًا إلى Staging ، فإن نشر Production سيقوم بالإبلاغ عن إجمالي المستخدمين ، في حين أن Staging سيقوم بالإبلاغ عن 1 (المستخدم الذي تحول للتو). يتيح لك هذا السلوك تتبع اعتماد الإصدار بدقة ، حتى في حالة استخدام حل إعادة توجيه النشر على أساس وقت التشغيل.
قام مجتمع React Native بإنشاء بعض تطبيقات المصادر المفتوحة الرائعة التي يمكن أن تكون بمثابة أمثلة للمطورين الذين بدأوا. فيما يلي قائمة بتطبيقات OSS React الأصلية التي تستخدم أيضًا CodePush ، وبالتالي يمكن استخدامها لمعرفة كيفية استخدام الآخرين للخدمة:
بالإضافة إلى ذلك ، إذا كنت تتطلع إلى البدء في React Native + CodePush ، وتبحث عن مجموعة بداية رائعة ، فيجب عليك التحقق من ما يلي:
ملاحظة: إذا قمت بتطوير تطبيق React Native باستخدام CodePush ، فهذا هو أيضًا مفتوح المصدر ، فيرجى إخبارنا بذلك. نود إضافتها إلى هذه القائمة!
تتضمن طريقة sync الكثير من التسجيل التشخيصي خارج الصندوق ، لذلك إذا كنت تواجه مشكلة عند استخدامها ، فإن أفضل شيء لمحاولة أولاً هو فحص سجلات إخراج تطبيقك. سيخبرك هذا ما إذا تم تكوين التطبيق بشكل صحيح (مثل هل يمكن أن يجد المكون الإضافي مفتاح النشر الخاص بك؟) ، إذا كان التطبيق قادرًا على الوصول إلى الخادم ، إذا تم اكتشاف تحديث متاح ، إذا تم تنزيل/تثبيت التحديث بنجاح ، وما إلى ذلك ، نريد الاستمرار في تحسين التسجيل ليكون بديهية/شاملة قدر الإمكان ، لذا يرجى إعلامنا إذا وجدت أنه مربك أو في عداد المفقودين.
أبسط طريقة لعرض هذه السجلات هي إضافة العلم --debug لكل أمر. سيؤدي ذلك إلى إخراج دفق السجل الذي يتم ترشيحه إلى رسائل CodePush فقط. هذا يجعل من السهل تحديد المشكلات ، دون الحاجة إلى استخدام أداة خاصة من النظام الأساسي ، أو التجويف من خلال حجم كبير من السجلات.
بالإضافة إلى ذلك ، يمكنك أيضًا استخدام أي من الأدوات الخاصة بالنظام الأساسي لعرض سجلات CodePush ، إذا كنت أكثر راحة معها. بدء التشغيل البسيط لوحدة وحدة التحكم في Chrome DevTools ، وحدة التحكم Xcode (iOS) ، وحدة التحكم OS X (iOS) و/أو ADB Logcat (Android) ، وابحث عن الرسائل المسبقة بـ [CodePush] .
لاحظ أنه افتراضيًا ، يتم تعطيل السجلات الأصلية React على iOS في بنيات الإصدار ، لذلك إذا كنت ترغب في مشاهدتها في بناء الإصدار ، فأنت بحاجة إلى إجراء التغييرات التالية على ملف AppDelegate.m الخاص بك:
أضف بيان #import <React/RCTLog.h> . ل RN <v0.40 الاستخدام: #import "RCTLog.h"
أضف العبارة التالية إلى أعلى application:didFinishLaunchingWithOptions :
RCTSetLogThreshold (RCTLogLevelInfo);ستتمكن الآن من رؤية سجلات CodePush في وضع التصحيح أو الإصدار ، على كل من iOS أو Android. إذا لم يوفر فحص السجلات مؤشراً على المشكلة ، فيرجى الرجوع إلى المشكلات الشائعة التالية لأفكار حل إضافية:
| مشكلة / أعراض | حل ممكن |
|---|---|
| خطأ في التجميع | تحقق من أن إصدار React of React Native متوافق مع إصدار CodePush الذي تستخدمه. |
مهلة الشبكة / شنق عند الاتصال sync أو checkForUpdate في محاكاة iOS | حاول إعادة تعيين المحاكاة عن طريق تحديد Simulator -> Reset Content and Settings.. عنصر القائمة ، ثم إعادة تشغيل التطبيق الخاص بك. |
يستجيب الخادم مع 404 عند الاتصال sync أو checkForUpdate | تحقق من أن مفتاح النشر الذي أضفته إلى Info.plist (iOS) أو build.gradle (Android) أو أنك تمر sync / checkForUpdate ، في الواقع صحيح. يمكنك تشغيل appcenter codepush deployment list <ownerName>/<appName> --displayKeys لعرض المفاتيح الصحيحة لنشر التطبيقات الخاصة بك. |
| تحديث لم يتم اكتشافه | تحقق من أن إصدار تطبيق التشغيل الخاص بك (مثل 1.0.0 ) يطابق الإصدار الذي حددته عند إصدار التحديث إلى CodePush. بالإضافة إلى ذلك ، تأكد من إطلاق نفس النشر الذي تم تكوين تطبيقك للمزامنة. |
| لا يتم عرض التحديث بعد إعادة التشغيل | إذا كنت لا تتصل sync APP (كما هو الحال في componentDidMount من مكون الجذر الخاص بك) ، فأنت بحاجة إلى الاتصال بشكل صريح لـ notifyApplicationReady on App Start ، وإلا ، فإن المكون الإضافي سيعتقد أن التحديث الخاص بك قد فشل في التراجع عنه. |
| لقد أصدرت تحديثًا لنظام التشغيل iOS ، لكن تطبيق Android الخاص بي يعرض أيضًا تحديثًا ويكسره | تأكد من أن لديك مفاتيح نشر مختلفة لكل منصة لتلقي التحديثات بشكل صحيح |
| لقد أصدرت تحديثًا جديدًا ولكن التغييرات لا تنعكس | تأكد من قيامك بتشغيل التطبيق في أوضاع غير تصحيح. في وضع التصحيح ، يقوم React Native App دائمًا بتنزيل حزمة JS التي تم إنشاؤها بواسطة Packager ، لذلك لا تنطبق حزمة JS التي تم تنزيلها بواسطة CodePush. |
| لا توجد حزمة JS عند تشغيل تطبيقك ضد محاكاة iOS | بشكل افتراضي ، لا يقوم React Native بإنشاء حزمة JS عند الركض ضد المحاكاة. لذلك ، إذا كنت تستخدم [CodePush bundleURL] ، واستهداف محاكاة iOS ، فقد تحصل على نتيجة nil . سيتم إصلاح هذه المشكلة في RN 0.22.0 ، ولكن فقط لبناء الإصدار. يمكنك إلغاء حظر هذا السيناريو الآن عن طريق إجراء هذا التغيير محليًا. |
بالإضافة إلى القدرة على استخدام CodePush CLI لتحديثات الإصدار "يدويًا" ، نعتقد أنه من المهم إنشاء حل قابل للتكرار ومستدام لتقديم تحديثات إلى تطبيقك. وبهذه الطريقة ، الأمر بسيط بما يكفي لك و/أو فريقك لإنشاء والحفاظ على إيقاع أداء عمليات النشر الرشيقة. من أجل المساعدة في إعداد خط أنابيب الأقراص المضغوطة المستند إلى CodePush ، راجع التكاملات التالية مع خوادم CI المختلفة:
بالإضافة إلى ذلك ، إذا كنت ترغب في مزيد من التفاصيل حول شكل سير عمل CI/CD للهاتف المحمول الكامل ، والذي يتضمن CodePush ، تحقق من هذه المقالة الممتازة من قبل فريق Zeemee Engineering.
تشحن هذه الوحدة ملف *.d.ts كجزء من حزمة NPM الخاصة بها ، والتي تتيح لك ببساطة import ، وتلقي Intellisense في دعم المحررين (مثل Visual Studio Code) ، وكذلك التحقق من نوع الترجمة إذا كنت باستخدام TypeScript. بالنسبة للجزء الأكبر ، يجب أن يعمل هذا السلوك فقط خارج المربع ، ومع ذلك ، إذا قمت بتحديد es6 كقيمة لخيار برنامج التحويل target أو module في ملف tsconfig.json الخاص بك ، فما عليك سوى التأكد من تعيينك أيضًا خيار moduleResolution node . هذا يضمن أن برنامج التحويل البرمجي TypeScript سيبحث ضمن node_modules للحصول على تعريفات النوع للوحدات المستوردة. خلاف ذلك ، ستحصل على خطأ مثل ما يلي عند محاولة استيراد وحدة react-native-code-push : error TS2307: Cannot find module 'react-native-code-push'
اعتمد هذا المشروع رمز سلوك المصدر المفتوح Microsoft. لمزيد من المعلومات ، راجع مدونة الشهادة الأسئلة الشائعة أو الاتصال بـ [email protected] مع أي أسئلة أو تعليقات إضافية.
