تُبلغ مستخدمة أن Trailhead يرفض “8,4” مسافةً على هاتفها الألماني. تصلح أداة التحليل في خمس دقائق. ودون أي شيء آخر، يعني إيصال هذا الإصلاح إليها build جديدًا، وإرسالًا، ومراجعة، ثم انتظار أن تحدّث تطبيقها. يختصر EAS Update ذلك إلى أمر واحد: ينشر كود JavaScript وassets جديدة، وتنزّلها نسخ Trailhead المثبّتة في المرة التالية التي تبدأ فيها.
\nيحتوي build الإصدار على شيئين: التطبيق الأصلي (كود Swift وKotlin وC++ المترجَم، بما في ذلك كل وحدة أصلية)، وحزمة JavaScript مضمّنة. والتحديث يستبدل الجزء الثاني فقط. حين يبدأ التطبيق، يتحقّق expo-updates من الخادم بحثًا عن حزمة أحدث لقناته وإصدار وقت التشغيل الخاص به. وافتراضيًا، يبدأ فورًا بالكود الذي لديه أصلًا، وينزّل التحديث الجديد في الخلفية، ويستخدمه في التشغيل التالي. لا ينتظر بدء التشغيل الشبكةَ أبدًا، وهذا مهم لتطبيق يُفتح عند بداية درب وفيه خطّ إشارة واحد.
اضبطه مرة واحدة، ثم اصنع builds جديدة لتتضمّن إعدادات التحديث:
\neas update:configureهذا يضيف رابط التحديث وruntimeVersion إلى إعدادات تطبيقك. ثم أعطِ كل build profile قناة (channel) في eas.json:
{\n \"build\": {\n \"preview\": { \"distribution\": \"internal\", \"channel\": \"preview\" },\n \"production\": { \"autoIncrement\": true, \"channel\": \"production\" }\n }\n}ونشر تحديث أمر واحد:
\neas update --channel production --message \"Accept comma decimals in distance\"تلتقطه الـ production builds في تشغيلها التالي. انشر على preview أولًا، وتحقّق منه على builds المختبِرين، ثم انشر الكود نفسه على production.
يصل باستخدام eas update | \nيحتاج إلى build جديد وإصدار في المتجر | \n
|---|---|
| الـ components والشاشات والتنسيقات والمنطق | \nإضافة وحدة أصلية أو ترقيتها | \n
| الصور والخطوط المضمّنة مع JavaScript | \nأوصاف الأذونات وغيرها من الإعدادات الأصلية | \n
| إصلاح الأخطاء وتعديل النصوص | \nأيقونة التطبيق وشاشة البداية ومعرّف الحزمة | \n
| شاشات جديدة مبنية من وحدات أصلية موجودة | \nترقيات Expo SDK | \n
هذا هو التمييز بين JavaScript والكود الأصلي من الدرس الثاني في الدورة، وقد صارت له عواقب الآن. إن مسّ تغيير ما الكود الأصلي أو الإعدادات الأصلية، فلا يستطيع التحديث إيصاله.
\nتخيّل أن Trailhead 1.1 يضيف expo-camera. كود JavaScript الخاص به يستورد وحدة أصلية لا تحتويها builds الإصدار 1.0. لو تلقّى مستخدمو 1.0 ذلك التحديث، لانهار التطبيق حين يلمس الكاميرا. يمنع إصدار وقت التشغيل (runtime version) ذلك: كل build وكل تحديث يحمل واحدًا، ولا ينطبق التحديث إلا على الـ builds التي لها إصدار وقت التشغيل نفسه.
{\n \"expo\": {\n \"version\": \"1.1.0\",\n \"runtimeVersion\": { \"policy\": \"appVersion\" }\n }\n}مع سياسة appVersion، يكون إصدار وقت التشغيل هو version الخاص بتطبيقك، فترفع version كلما تغيّر الكود الأصلي، فتتوقّف builds الإصدارين 1.0 و1.1 عن مشاركة التحديثات. أما سياسة fingerprint فتحسب hash للأجزاء الأصلية من مشروعك بدلًا من ذلك، فيتغيّر إصدار وقت التشغيل تلقائيًا حين يتغيّر الكود الأصلي. كلتاهما تعمل؛ اختر واحدة وافهمها.
تصل التحديثات إلى مستخدمين كثيرين بسرعة، وهذا سلاح ذو حدّين. إن أساء أحدها التصرّف، فتراجع:
\neas update:rollbackيرشدك خطوة بخطوة لإعادة فرع القناة إلى تحديث سابق أو إلى الكود المضمّن في الـ build. ويحصل المستخدمون على التراجع في تشغيلهم التالي، بالطريقة نفسها التي حصلوا بها على التحديث. ولهذا يستحق كل تحديث العناية نفسها التي يستحقها الإصدار: شغّل اختباراتك، وانشر على preview، وافتحه على هاتف حقيقي، ثم انشر على production. يسمح المتجران بتحديث JavaScript بهذه الطريقة لإصلاح الأخطاء والتحسينات؛ أما استخدامه لتغيير ما يفعله التطبيق جوهريًا دون مراجعة فمخالف لقواعدهما.
هذا إيقاع يناسب فريقًا صغيرًا:
\neas update إلى preview، وتحقّق، ثم إلى production. في اليوم نفسه.version، ثم production build، ثم TestFlight والمسار الداخلي، ثم المراجعة، ثم الإطلاق. بتخطيط مسبق، كل بضعة أسابيع.eas update:rollback جاهزًا.بدأت بـ Text واحد في مشروع Expo. أما Trailhead الآن ففيه قوائم تبقى سريعة، وtabs وstacks مع params مضبوطة الأنواع، ونموذج يتعامل مع لوحة المفاتيح، وبيانات في SQLite وtoken في التخزين الآمن، وتتبّع GPS، وصور، وتذكيرات، واختبارات، وbuilds للمتاجر، وطريقة لإصلاح الأخطاء في عصر اليوم نفسه. والأهم أنك تعرف أين يختلف React Native عن الويب ولماذا: native views، وthreads اثنان، ولا cascade، وأذونات يمكن رفضها، ونوعان من التغييرات، JavaScript وأصلي.
خطوات تالية جيدة: أضف Reanimated وreact-native-gesture-handler لتفاعلات أغنى، وTanStack Query لبيانات الخادم، وMaestro لبضعة اختبارات end-to-end. ثم أطلق شيئًا صغيرًا لمستخدمين حقيقيين وتعلّم مما يفعلونه به.
\n","toc":[{"id":"sec-1","text":"كيف يصل التحديث إلى الهاتف","level":2},{"id":"sec-2","text":"ما يمكن أن يصل عبر الهواء وما لا يمكن","level":2},{"id":"sec-3","text":"إصدارات وقت التشغيل تُبقي التحديثات متوافقة","level":2},{"id":"sec-4","text":"حين يسوء تحديث","level":2},{"id":"sec-5","text":"روتين إصدار يصمد","level":2},{"id":"sec-6","text":"أين وصلت الآن","level":2}],"takeaways":["يستبدل EAS Update حزمة JavaScript والملفات المرافقة (assets) في الـ builds المثبّتة، دون ملف تطبيق جديد ودون مراجعة المتجر.","تغييرات JavaScript والـ assets وحدها يمكن أن تصل عبر الهواء؛ أما الوحدات الأصلية الجديدة ونصوص الأذونات والأيقونات وترقيات الـ SDK فتحتاج إلى build جديد.","قناة الـ build (channel) تحدّد أي التحديثات يتلقّاها، وإصدار وقت التشغيل (runtime version) يحدّد أي التحديثات متوافقة مع كوده الأصلي.","افتراضيًا، يُنزَّل التحديث في الخلفية ويُطبَّق عند التشغيل التالي.","حين يسيء تحديث التصرّف، يعيدeas update:rollback المستخدمين إلى تحديث سابق أو إلى الكود المضمّن في الـ build الخاص بهم."],"further":[{"title":"EAS Update introduction","url":"https://docs.expo.dev/eas-update/introduction/"},{"title":"How EAS Update works","url":"https://docs.expo.dev/eas-update/how-it-works/"},{"title":"Runtime versions and updates","url":"https://docs.expo.dev/eas-update/runtime-versions/"},{"title":"Rollbacks","url":"https://docs.expo.dev/eas-update/rollbacks/"}],"quiz":[{"q":"أيّ تغيير في Trailhead يمكن أن يصل إلى المستخدمين باستخدام eas update وحده؟
expo-camera لمسح رموز QR على علامات الدروب.","why":"الوحدة الأصلية الجديدة يجب أن تُترجَم داخل الملف التنفيذي، فتحتاج إلى build جديد وإصدار في المتجر."},{"text":"إصلاح خطأ الفاصلة في parseDistanceKm وإعادة صياغة رسالة خطأ.","why":"صحيح. كلاهما تغيير في JavaScript، وهذا بالضبط ما يستبدله التحديث."},{"text":"تغيير وصف إذن الموقع في app.json.","why":"أوصاف الاستخدام تُترجَم إلى الإعدادات الأصلية؛ ولا تتغيّر إلا مع build جديد."},{"text":"الترقية إلى إصدار Expo SDK التالي.","why":"ترقية الـ SDK تغيّر الكود الأصلي وإصدار وقت التشغيل، فتحتاج دائمًا إلى builds جديدة."}],"answer":1},{"q":"نشرت تحديثًا على قناة production. فتح مستخدم Trailhead بعد ساعة. مع الإعدادات الافتراضية، متى يرى الإصلاح؟
","options":[{"text":"فورًا؛ يتوقّف التطبيق عند شاشة البداية حتى يُنزَّل التحديث.","why":"افتراضيًا، يبدأ التطبيق بالكود الذي لديه أصلًا، فلا تؤخّر الشبكة البطيئة بدء التشغيل أبدًا."},{"text":"فقط بعد أن يعيد تثبيت التطبيق من المتجر.","why":"التحديثات تُثبَّت دون المتجر. وهذا هو جوهر EAS Update."},{"text":"في التشغيل الذي يلي هذا التشغيل؛ يُنزَّل التحديث في الخلفية أثناء هذه الجلسة.","why":"صحيح. يتحقّق التطبيق عند التشغيل، وينزّل في الخلفية، ويطبّق التحديث في المرة التالية التي يبدأ فيها."}],"answer":2},{"q":"مستخدمو Trailhead 1.0 (المبني قبل إضافة expo-camera) و1.1 (المبني بعدها) يستخدمون قناة production. نشرت تحديث JavaScript يستورد expo-camera. ما الذي يحمي مستخدمي 1.0 من الانهيار؟
appVersion أو fingerprint، تنتج التغييرات الأصلية إصدار وقت تشغيل جديدًا، ولا تصل التحديثات إلا إلى الـ builds المتوافقة."},{"text":"لا شيء؛ يجب أن تنشر تحديثات منفصلة يدويًا وتأمل أن يحصل عليها المستخدمون الصحيحون.","why":"إصدارات وقت التشغيل موجودة بالضبط حتى لا تضطر إلى الاعتماد على الأمل."},{"text":"يثبّت EAS Update الوحدة الأصلية الناقصة مع كود JavaScript.","why":"لا تستطيع التحديثات إضافة كود أصلي. ولهذا تهمّ فحوص التوافق."}],"answer":0}],"exercise":{"kind":"choice","multiple":true,"options":["copy-fix","reducer-bug","new-screen","add-sdk-module","icon","permission-text","new-image"],"correct":["copy-fix","reducer-bug","new-screen","new-image"],"title":"تحديث أم build جديد؟","prompt":"Trailhead 1.2 منشور مع ضبط runtimeVersion على سياسة appVersion. قائمة الفريق لهذا الأسبوع أدناه. اختر كل تغيير تستطيع إيصاله إلى مستخدمي 1.2 الحاليين باستخدام eas update وحده، دون build جديد ودون مراجعة المتجر.
النصوص، والمنطق، والشاشات الجديدة المبنية من وحدات موجودة أصلًا في الملف التنفيذي، والصور المضمّنة مع JavaScript، كلها جزء من حزمة التحديث، فتصل باستخدام eas update. أما وحدة أصلية جديدة مثل expo-haptics فيجب أن تُترجَم داخل التطبيق؛ وأيقونة التطبيق وأوصاف الأذونات تعيش في الإعدادات الأصلية التي يقرؤها نظام التشغيل من الملف التنفيذي المثبّت. هذه الثلاثة تحتاج إلى version جديد، وproduction build، وإصدار في المتجر.
hikesReducer بحيث يعيد تعديلُ تاريخ رحلة ترتيبَ القائمة.","why":"تحديث. منطق JavaScript خالص، وهو الإصلاح المثالي عبر الهواء."},"new-screen":{"text":"أضف شاشة إحصاءات سنوية مبنية فقط من View وText وFlatList.","why":"تحديث. الشاشات الجديدة لا بأس بها ما دامت كل وحدة أصلية تستخدمها موجودة أصلًا في الـ build."},"add-sdk-module":{"text":"أضف expo-haptics ليهتزّ زرّ Save اهتزازًا خفيفًا.","why":"build جديد. الوحدة الأصلية غير الموجودة في الملف التنفيذي المثبّت لا يمكن أن تصل في تحديث."},"icon":{"text":"استبدل أيقونة التطبيق بالشعار الجديد.","why":"build جديد. أيقونة الشاشة الرئيسية جزء من حزمة التطبيق المثبّتة، لا من حزمة JavaScript."},"permission-text":{"text":"وضّح وصف إذن الموقع في خيارات الـ plugin الخاص بـ expo-location.","why":"build جديد. خيارات الـ config plugins تُكتب في الإعدادات الأصلية حين يُبنى التطبيق."},"new-image":{"text":"استبدل رسم حالة الفراغ بصورة PNG جديدة مستوردة عبر require().","why":"تحديث. الصور المضمّنة عبر مُجمِّع JavaScript هي assets تتضمّنها التحديثات."}}},"words":719,"readMinutes":4}