Flutter: دفع التعليمات البرمجية / تحديث ساخن / تحديثات خارج النطاق

ccfloitschG

انظر أيضا
https://groups.google.com/forum/#!msg/flutter -dev / YwzItp1pxJo / 7bFGDLvxBAAJ
سأكون متحمس للغاية بشأن هذا.

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

استخدم حالات

• الأخطاء الحرجة ، خاصة على نظام iOS ، خاصة بالنسبة لكبار الشخصيات أو المواقف العاجلة والحساسة للوقت و / أو الأعمال الحرجة و / أو المستخدمين الذين لا يمكنهم استخدام التطبيق على الإطلاق لسبب ما.
• اختبار أكثر ديناميكية للميزات من عمليات الطرح المرحلية
• ستكون هذه لمسة رائعة عند التحضير لفوشيا و / أو أجهزة Chromebook. يمكن أن تكون هناك سيناريوهات يكون فيها الرفرفة "تنافس" مع تطبيقات الويب ليس فقط حلول pwas / Kotlin / Swift / React / Xamarin / حلول أخرى هجينة

في المعركة الملحمية التي تدور حول Flutter vs React Native ، يعد دفع الشفرة أحد أدوات الجحيم (:
بصفتي مطورًا لـ RN ، لا يمكنني التأكيد بما فيه الكفاية على أهمية هذه الميزة. سوف يمر الكثير من Flutter لمجرد عدم وجود دفعات ساخنة. بمجرد أن تعتاد على إصلاح الخلل بسرعة ودفع ميزات جديدة ، لا يمكنك العودة.

التحويل البرمجي إلى مسار جافا سكريبت سيقلل من مزايا السهام ، أليس كذلك؟
لقد اكتشفت أن بعض التطبيقات الأصلية كانت قادرة على إعادة تحميل الكود باستخدام Rollout.io ولكن تم حظره بواسطة Apple: https://news.ycombinator.com/item؟
بالنظر إلى هذا النمط ، يبدو أن الرفرفة لن تحتوي على ميزة دفع رمز سلس مثل ما نراه عند التفاعل الأصلي.
أرغب في الحصول على مزيد من الأفكار حول إمكانيات هذه الميزة من المشرفين الأساسيين (:

التحويل البرمجي إلى مسار جافا سكريبت سيقلل من مزايا السهام ، أليس كذلك؟

ما هي المزايا التي تتحدث عنها؟

هناك حاجة ماسة Codepush. أحب أن أرى إمكانية إصدار الترقية عبر الهواء على Flutter.

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

يمكن لميزة codepush دفع الإصلاحات الحاسمة للمستخدمين على الفور بدلاً من انتظار الترقية ؛ لسبب ما ، يبدو أن المستخدمين بطيئون في الترقية أحيانًا :(

لا يوجد دعم دفع رمز ساخن هو NO GO :-(

يبدو أن JavascriptCore قد لا يكون مطلوبًا بعد الآن للتعليمة البرمجية المفسرة: https://www.theregister.co.uk/2017/06/07/apple_relaxes_developer_rules/؟page=2

إذا كان نظام IOS البيئي يمثل عائقًا ، فلماذا لا يتم تطبيقه على نظام Android فقط في الوقت الحالي؟ شيء أفضل من لا شيء وهو نقطة البداية.

نقدر كثيرا لفريق تنفيذ هذه الميزة في أسرع وقت ممكن.

لقد قمنا ببناء بعض النماذج الأولية هنا ، ولكن ليس لدينا أي شيء لمشاركته في الوقت الحالي. للقيام بذلك بشكل جيد سيتطلب بعض العمل في سلسلة أدوات مترجم Dart. أتوقع أن تمر عدة أشهر قبل أن يكون لدينا الكثير لنشاركه هنا. يركز الفريق حاليًا على التثبيت لـ 1.0.

كل ما قيل ، نسمعك. :) من الواضح أن هذه ميزة يقدرها الكثير من الناس ونحن مهتمون بتوفير وظائف مثل هذه في النهاية.

يمكن أن يكون دعم "Code Push" لـ Flutter هو المسمار الأخير في التابوت فيما يتعلق بـ React Native.

مع كل حبي لـ RN ومجتمع RN ، لكونها مغير اللعبة ، فهي لا تضاهي Flutter.
Flutter يثبتها في أي جانب (الأدوات ، الأداء ، اللغة ...).

بعد 1.0 زيارة وينمو المجتمع أكثر قليلاً + دعم Code Push = لا يمكنني رؤية أي سبب لبدء مشروع محمول جديد مع أي شيء آخر Flutter.

أي تقدم في برنامج "Code Push" ؟؟

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

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

مسؤوليات إضافية: تنزيل الأصول ، والتحقق من التوقيعات وما لا. تحديث محركات flutter / dart / skia وما لا.

يبدو لي أنه ينتهك إرشادات iOS ، لكنني حقًا لست معجبًا بأي شيء مفسر على أي حال ، أو iOS بشكل عام. وأنا أفضل استخدامه في Android بدلاً من عدم امتلاكه على الإطلاق ، لمجرد أنه رائع.

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

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

أي تحديثات؟
(أراهن أن الميزة قد اكتملت بالفعل وستأتي كمفاجأة عندما تصل 1.0)
😁

حتى التصويت

هناك سبب واحد فقط يمنعنا من استخدام Flutter: دفع الكود

إذا كنتم لا تستطيعون دعم Code Push ، فهل هناك طريقة لإنشاء محلل من بعض القواميس (مثل json و xml ...) إلى Flutter Widget؟ هل هذا مستحيل أم فكرة جيدة؟

هذا يبدو واعدا بعض الشيء تهيئة Firebase عن بُعد للأداة إذا لزم الأمر.
على الرغم من أن جعل الشركات لديها فكرة عما تريده يساعد أيضًا :)

في الجمعة ، 12 أكتوبر ، 2018 ، 3:45 صباحًا Hưng Lương Đỗ Minh [email protected]
كتب:

إذا كنتم لا تستطيعون دعم Code Push ، فهل هناك طريقة لعمل محلل لـ
توليد من بعض القواميس (مثل json ، xml ...) إلى Flutter Widget؟ يكون
هذا مستحيل أم فكرة جيدة؟

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/flutter/flutter/issues/14330#issuecomment-429251785 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AC4TYe9qDMi4bt2U5qyyAnJisN3ys_Z5ks5ukFavgaJpZM4RxUZi
.

أعتقد أنه يمكن تنزيل واجهة المستخدم / العرض المكتوبة بلغة Dart على الأقل عبر الشبكة من الخادم.
للإلهام ، انظر كيف يقوم إطار عمل Qt Quick بذلك.

QtDD12 - تقديم تطبيقات QML عبر الشبكة - جيريمي لين:

• فيديو
• الشرائح

نتوقع أن يتم تضمينه في الإصدار 1.0 القادم!

سيستخدم العديد من عملائنا تطبيق Flutter على جهاز كشك خلف جدران حماية صارمة تمنع آليات تحديث تطبيقات Google Store. لن يقوم هؤلاء العملاء بإدراج متجر Play في القائمة البيضاء. سيكون لدينا في النهاية 100 جهاز من الأجهزة مع تطبيق Flutter ، وسيكون وجود طريقة لدفع التحديثات إلى التطبيق مع الالتزام بقيود جدار حماية العميل أمرًا مذهلاً!

eseidelGoogle - لقد مضى وقت

هل مازلتم تعملون على هذا؟ كيف تسير الامور؟

يستمر التقدم. لا توجد تحديثات للمشاركة في هذا الوقت.

لقد توصلنا إلى ثلاثة مصطلحات واضحة لما كان الناس يلجونه إلى هذا الخطأ في وقت سابق اليوم:

• "التصحيح الديناميكي": القدرة على تحديث كود Dart لتطبيق ما في الحقل عن طريق تنزيل تصحيح (من نوع ما) وتقديمه إلى Dart VM. قد يتطلب ذلك إعادة تحميل التطبيق حتى يتم تفعيله.
• "تحميل الامتداد الديناميكي": القدرة على تنزيل بعض رموز Dart التي لم تكن مكتوبة عند نشر التطبيق لأول مرة ، مما يضيف ميزة جديدة إلى التطبيق. يمكن القيام بذلك بسرعة. قد يتطلب الأمر أن يكون التطبيق الأساسي أكبر نظرًا لأننا لا نستطيع أن نعرف مسبقًا ما هو مطلوب لكل امتداد مستقبلي.
• "تسليم التطبيق المعياري": القدرة على تجميع تطبيق واحد في عدة أرشيفات منفصلة عند تجميعها ، وتنزيلها بشكل مستقل حسب الحاجة.

ربما ينبغي علينا تقسيم هذه المشكلة إلى ثلاثة أخطاء يمكننا تتبعها بشكل منفصل.

هل هذا ممكن حقًا لنظام iOS؟ بصرف النظر عن إمكانية حظر Apple لهذا تمامًا كما فعلت مع rollout.io ، يجب تشغيل جافا سكريبت بدون أي نوع من JIT (عدم الكتابة إلى الصفحات القابلة للتنفيذ على iOS). كما أن خصائص GC المختلفة لنواة جافا سكريبت أثناء إنشاء Flutter لأطنان من الأشياء قصيرة العمر قد لا تبشر بالخير.

ما لا تسمح به Apple حاليًا (أو في المستقبل) منفصل تمامًا عن التطبيقات الفنية. يعمل Flutter في العديد من الأماكن بخلاف iOS. من الواضح أننا نرغب دائمًا في تصميم تقنيات يمكنها العمل على نظام iOS (كما أعتقد أن العديد من حلول "دفع الكود" الممكنة يمكن أن تفعل ذلك) ، لكن iOS ليس الاعتبار الوحيد. امل ان يساعد؟

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

هناك سبب واحد فقط يمنعنا من استخدام Flutter: دفع الكود

أود ترك ملاحظاتي فقط لإظهار اهتمامي بهذا الموضوع.
تطور شركتي تطبيقًا متعدد العملاء يعمل بنظام Android فقط لإدارة فرق الصيانة. في عام 2018 ، أصدرنا ما يقرب من 100 تحديث ، ولم يطلب أي منها إصدارًا جديدًا من خلال Google Play نظرًا لأن معظمها عبارة عن تعديلات صغيرة وتخصيصات يحتاجها كل عميل ، ولا يمكن التنبؤ بها مسبقًا.
ستكون إعادة كتابة هذا التطبيق في Flutter بمثابة حلم ، ولكن بغض النظر عن تكاليف إعادة الكتابة ، فإن إضاعة المال في انتظار الإصلاح أو التخصيصات التي سيتم نشرها من خلال GPlay سيكون بمثابة كابوس.

نأمل أن نحقق في أقرب وقت ممكن

نقطة أخرى: إذا قدم فريق Flutter حل الإصلاح السريع رسميًا ، أعتقد أن Apple قد ترفض جميع التطبيقات التي أنشأها Flutter في وقت ما ، لأن الإصلاح السريع يكسر إرشادات مراجعة AppStore بالتأكيد ، يمكن للمطورين تجاوز مراجعة AppStore وتعديلهم التطبيق ، فهو غير آمن للمستخدمين.

ترفض Apple حاليًا جميع التطبيقات المزودة بـ JsPatch ، والتي كانت أكثر حلول الإصلاح السريع شيوعًا في الصين. تم إنشاء JsPatch أعلى وقت تشغيل JsCore و OC.

أرغب في إنشاء تطبيقات Flutter بدون وظيفة الإصلاح السريع ، بدلاً من التطبيقات التي قد ترفضها Apple في المستقبل.

MaxZeng جميل أن أعرف عن JsPatch. ولكن في الوقت الحالي ، يبدو أن الترقيع الساخن مسموح به. هناك العديد من تطبيقات React Native في متجر Apple وكلها تستخدم الترقيع السريع عبر CodePush.

إذا كان يدعم iOS / android فقط مثل هذا المثال:
يطلب MyFlutterApplication الإذن / يريد تحديث تطبيقك
سجلات التغيير: إضافة البسيسات والكلاب (v1.0)
سماح | لا تسمح

بعد مراجعة المبادئ التوجيهية لكلا الطرفين.

MaxZeng جميل أن أعرف عن JsPatch. ولكن في الوقت الحالي ، يبدو أن الترقيع الساخن مسموح به. هناك العديد من تطبيقات React Native في متجر Apple وكلها تستخدم الترقيع السريع عبر CodePush.

نعم ، يُعد ReactNative استثناءً من دفع التعليمات البرمجية في الوقت الحالي ، لكن هذا لا يعني أن Apple تدعمه رسميًا. تم رفض تطبيق شركتنا من قبل AppStore أكثر من 3 مرات مؤخرًا بسبب إطار عمل RN ، وعلينا إعادة كتابة هذه الوظائف بواسطة OC / H5 ، إنه كابوس للمطورين.

رد فعل الأصلية لا تزال الإطار آمنه لشركة آبل، لأنه يتم تقديمها على رأس UIKit أخيرا، ولكن الرفرفة مختلفة تماما:
1 ، أولاً ، يكسر النظم الإيكولوجية لمطوري Apple ، ويتجاوز إطار عمل UIKit ، وهو خارج سيطرة Apple ، على سبيل المثال ، سيكون هناك المزيد والمزيد من تطبيقات نمط MD في AppStore ، وقد يكون هذا مخالفًا لإرشادات واجهة الإنسان الخاصة بشركة Apple. آبل شركة مشهورة بسبب تصميمها الرائع.
2 、 ثانيًا ، إذا تم دعم إعادة التحميل السريع بواسطة Flutter رسميًا ، فقد تستخدم Apple هذا السبب لرفض Flutter Apps مباشرةً.

من وجهة نظري ، يجب أن يتبع Flutter إرشادات مراجعة AppStore بدلاً من كسرها ، وهذا أمر مهم لإطار عمل للجوّال عبر الأنظمة الأساسية ، ولا يجب كسر النظام البيئي لشركة Apple لأننا نستطيع القيام بذلك. إذا رفضت Apple Flutter ، فستختفي الميزة الرئيسية لـ Flutter.

إن CodePush ليس أسلوبًا صعبًا أو غامضًا ، ويمكن لشركة Apple تنفيذه بسهولة (خاصة استنادًا إلى OC) ، والسبب الوحيد الذي يمنع Apple من السماح به هو أنه غير آمن للمستخدمين النهائيين ، وهذا يضر AppStore / Google Play تمامًا. إنها كارثة إذا تمكنت العديد من التطبيقات من تغيير وظائفها في أي وقت وفي أي مكان ، ومن الصعب تتبع هذه الإجراءات الضارة والحد منها بعد السماح للتطبيق بالنشر.

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

MaxZeng جميل أن أعرف عن JsPatch. ولكن في الوقت الحالي ، يبدو أن الترقيع الساخن مسموح به. هناك العديد من تطبيقات React Native في متجر Apple وكلها تستخدم الترقيع السريع عبر CodePush.

نعم ، يُعد ReactNative استثناءً من دفع التعليمات البرمجية في الوقت الحالي ، لكن هذا لا يعني أن Apple تدعمه رسميًا. تم رفض تطبيق شركتنا من قبل AppStore أكثر من 3 مرات مؤخرًا بسبب إطار عمل RN ، وعلينا إعادة كتابة هذه الوظائف بواسطة OC / H5 ، إنه كابوس للمطورين.

لا يزال React Native إطار عمل _SAFE_ لشركة Apple ، لأنه يتم عرضه أعلى UIKit أخيرًا ، لكن Flutter مختلف تمامًا:
1 ، أولاً ، يكسر النظم الإيكولوجية لمطوري Apple ، ويتجاوز إطار عمل UIKit ، وهو خارج سيطرة Apple ، على سبيل المثال ، سيكون هناك المزيد والمزيد من تطبيقات نمط MD في AppStore ، وقد يكون هذا مخالفًا لإرشادات واجهة الإنسان الخاصة بشركة Apple. آبل شركة مشهورة بسبب تصميمها الرائع.
2 、 ثانيًا ، إذا تم دعم إعادة التحميل السريع بواسطة Flutter رسميًا ، فقد تستخدم Apple هذا السبب لرفض Flutter Apps مباشرةً.

من وجهة نظري ، يجب أن يتبع Flutter إرشادات مراجعة AppStore بدلاً من كسرها ، وهذا أمر مهم لإطار عمل للجوّال عبر الأنظمة الأساسية ، ولا يجب كسر النظام البيئي لشركة Apple لأننا نستطيع القيام بذلك. إذا رفضت Apple Flutter ، فستختفي الميزة الرئيسية لـ Flutter.

إن CodePush ليس أسلوبًا صعبًا أو غامضًا ، ويمكن لشركة Apple تنفيذه بسهولة (خاصة استنادًا إلى OC) ، والسبب الوحيد الذي يمنع Apple من السماح به هو أنه غير آمن للمستخدمين النهائيين ، وهذا يضر AppStore / Google Play تمامًا. إنها كارثة إذا تمكنت العديد من التطبيقات من تغيير وظائفها في أي وقت وفي أي مكان ، ومن الصعب تتبع هذه الإجراءات الضارة والحد منها بعد السماح للتطبيق بالنشر.

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

نقطة مثيرة للاهتمام للغاية وتبدو معقولة من بعض النواحي ، ولكن بها أيضًا بعض الأخطاء.

1. كما يدعم Flutter Apple's Cupertino ، ليس العضو
2. قد تعرف الوحدة في منطقة الألعاب ، يعمل نظام عرض Flutter بشكل مشابه في بعض النواحي.
3. في الواقع وفي الوقت الحالي ، يمكن أن يؤدي استخدام الويب (JS) إلى تنفيذ CodePush وتجاوز مراجعة AppStore لتعديل تطبيقهم. فلماذا ترفض Flutter (dart) وتترك JS.

فلماذا ترفض Flutter (dart) وتترك JS.

يعمل JS في صندوق رمل وبالتالي فهو آمن. (مثل كل صفحة ويب محملة في Safari)

يجمع Dart إلى رمز ثنائي ولا يقيده مثل هذا الصندوق الرمل.

أنا مطور أندرويد لسنوات عديدة. أعتقد أن دفع الكود ليس مهمًا جدًا.
إذا لم يكن لديك Code Push ، فلا يمكنك تطوير؟ إذا كان الأمر كذلك ، فهذا أحمق للغاية.
Flutter هو إطار عمل للجوال ، لذا يجب أولاً معرفة المزيد من المعرفة بتطوير الأجهزة المحمولة.
بدون دفع التعليمات البرمجية ، يمكنك استخدام التحديث الكامل.
كما يقول الإعلان: اعبر الجسر عندما يأتي المرء إليه.
بصفتي مطورًا ، أعتقد أنه من المهم استخدام طرق مختلفة لحل نفس المشكلة.

Flutter ليس React Native ، لا يمكنك استخدام التجربة لـ React Native (أو إطار عمل آخر) للنظر إلى Flutter ، إنها أشياء مختلفة.

MaxZeng ربما يمكن

بدون التحديث الساخن مثل RN ، لن ننتقل إلى Flutter! يجب أن تجعل الأطر حياة المطور أسهل !!

الزهور التي انتظرتها قد ولت.

MaxZeng ربما يمكن

1 、 في الواقع ، سيؤدي ذلك إلى إتلاف الأنظمة البيئية لمتجر Google Play أيضًا ، وسيجعل فريق Android من الصعب التحكم في سلوكيات التطبيق.
2 、 CodePush ليس ضروريًا لمعظم التطبيقات ， سيتم استخدام هذه التقنية بشكل ضار من قبل بعض المطورين.
3 、 قد يتسبب ذلك في حدوث "Man In The Middle Attack" كبير إذا لم يقم المطورون بتشفير التصحيحات بشكل صحيح - قد يقوم المتسللون الخبيثون بتعديل التعليمات البرمجية المدفوعة لاختطاف تطبيقات Flutter.

أريد فقط أن أقول ， الإصلاح العاجل هو ميزة استيراد لمعظم الشركات الصينية. أكثر من 70٪ من أجهزة Android الصينية لا تدعم Google Play

@ act64 تحقق من https://github.com/flutter/flutter/wiki/Roadmap

@ act64 تحقق من https://github.com/flutter/flutter/wiki/Roadmap

نصت خارطة الطريق على إصلاح عاجل لنظام Android ، ونأمل أن يتم دعم نظام iOS قريبًا.

taibaiyinxing لا يستطيع

taibaiyinxing لا يستطيع

zoechi نحن نستخدم تطبيق المؤسسة ولا نحتاج إلى تحميله على متجر التطبيقات.

التصحيح الديناميكي على Android ، مما يسمح بنشر تحديثات التعليمات البرمجية في تطبيقات Flutter التي تعمل على Android مباشرة من الخوادم.
🎉

https://github.com/flutter/flutter/wiki/Roadmap

يبدو أنه لا توجد خطة لدعم CODE PUSH على IOS في هذا العام.

https://github.com/flutter/flutter/wiki/Roadmap

"لا ينبغي النظر إلى القائمة الواردة هنا على أنها شاملة ولا تعد بمثابة وعد بأننا سنكمل كل هذا العمل". :)

لا يزال عمل دفع الشفرة في الأيام الأولى نسبيًا للاختبار. ما هي المنصات التي سننشرها / لن ننشرها في عام 2019 لم يتم تحديدها بعد. إنه فبراير فقط بعد كل شيء. 10 أشهر وقت طويل!

يركز المهندسون حاليًا على بناء التكنولوجيا الأساسية لدعم 3 حالات استخدام @ Hixie الموضحة في: https://github.com/flutter/flutter/issues/14330#issuecomment -442274897
أتوقع أننا سنبدأ في إجراء بعض الاختبارات المحدودة لواحدة على الأقل من حالات الاستخدام هذه في الأشهر المقبلة.

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

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

كنقطة جانبية ، يمكن أن يكون الحل المحتمل إذا وفرت المتاجر مسارًا للتحديثات الفورية للمطورين "الموثوق بهم" (مثل خدمة التتبع السريع). يمكن أن تقوم Google و Apple بعد ذلك بإجراء تدقيق في الوقت الفعلي (آليًا ، ... كما هو الحال مع AI ؟؟ ... مع التراجع التلقائي بأثر رجعي حسب الضرورة) للتطبيق. لكن هذا يبدو غير مرجح لمجموعة من الأسباب التقنية وغيرها. يمتلك كلا المتجرين بالطبع مسارًا سريعًا لمختبري الإصدارات التجريبية.

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

للحصول على مثال لأداة تقوم بهذا النوع من الأتمتة لـ Flutter ، انظر:
https://github.com/mmcc007/fledge
للسجل ، يتضمن وثائق للعديد من خطوات الإعداد لمرة واحدة التي لا يمكن أتمتتها بسهولة:
https://mmcc007.github.io/fledge/

charliezzo باستخدام هذه الأداة ، أو أدوات مثلها ، يمكن تسليم تطبيق Flutter (والتحديثات ، وما إلى ذلك)

كما أن لديها سير عمل لأتمتة التسليم إلى المستخدمين النهائيين عبر المتاجر (ساعات + لـ Google ، أيام + لـ Apple).

@ mmcc007
اوه شكرا لك. لكنني أقول إنني لا أريد دفع تطبيقي إلى متجر Google play ومتجر التطبيقات.
أحتاج إلى بيع تطبيقي بطريقة أخرى.
ولست بحاجة إلى google play ومتجر التطبيقات لتحديث تطبيقي.
أريد فقط تحديث تطبيقي بنفسه عندما يقوم المستخدمون بتثبيته وبدء تشغيله.
و flutter عبارة عن إطار 60 إطارًا في الثانية أو إطار عمل أعلى ، ويمكنه إنشاء لعبة عبر الإنترنت ، ولا نريد الحصول على القليل من التصحيح من متجر Google play ومتجر التطبيقات.
أنت تعلم أن كل رقعة في وقت قصير من خلال google play ومتجر التطبيقات بطيئة وصعبة.
في الحقيقة أنت تعلم أننا لا نستطيع استخدام google play في الصين. ومتجر التطبيقات بطيء جدًا.
هناك الكثير من متاجر التطبيقات مثل google play في china. ليس لدينا وقت لدفع التحديث إلى كل متجر تطبيقات.

يجب أن يكون Code Push ميزة أساسية في Flutter. ضعها على القمة.

يمكننا القيام بذلك عن طريق استبدال جميع الملفات الموجودة في app_flutters على Android

مرحبًا ، هل يمكنك أن تعطيني بريدك الإلكتروني لمزيد من المناقشة ， وجد فريقنا أيضًا هذا الحل ， ولكن لا يمكن أن يعمل إلا عندما يجب إيقاف التطبيق وإعادة تشغيل app。tksLNeway

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

يرجى المشاركة مع مقتطف موجز أو منشور مدونة أو التعليق هنا أو cc

LNewayKinsomyJS يمكن إما منكم إعطاء مزيد من التفاصيل الرجاء؟
شكرا

taibaiyinxing لا يستطيع

zoechi هل تقول أنت و / أو فريق Flutter لديهما تحليل يخلص إلى أن تقنية codepush الممكنة بواسطة Flutter تختلف اختلافًا جوهريًا عن تقنية React-native وهي محظورة - وبالتالي ، بسبب Apple ، قد لا تأتي أبدًا إلى iPhone؟

إذا تمت إضافة هذه الميزة ، فهل ستدعم الإصدار التجريبي 1.0.0؟

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

بالنسبة لما يستحق ، من تجربتي مع Ionic ، أعتقد أن "دفع الكود" مبالغ فيه ، وآمل ألا يقضي فريق Flutter الكثير من الوقت في العمل عليه بينما لا يزال هناك الكثير من الميزات الأساسية الأخرى المفقودة.

عندما قمت بتطوير UAVForecast ، استخدمت Ionic ، التي جذبتها ميزة "النشر الأيوني" التي عرضت تحديث محتويات التطبيق بالكامل عن بُعد. في ذلك الوقت (كان هذا في عام 2014) ، كانت أوقات مراجعة متجر التطبيقات من Apple في حدود أسبوعين. كنت أرغب في التكرار بسرعة ، والتحرك بسرعة ، وكسر الأشياء ، كما يقولون.

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

بعد حوالي عام من إطلاق الإصدار الأول ، تحسنت أوقات مراجعة متجر التطبيقات بشكل ملحوظ. اليوم ، لم يستغرق الأمر سوى أيام قليلة ، وبالطبع على متجر Google Play Store يمكن أن يستغرق الأمر بضع ساعات. نظرًا لجميع المشكلات التي واجهتها ، قررت إزالة وظيفة "النشر الأيوني" من تطبيقي ، ومع وجود عدة ملايين تنزيلات ورائي الآن ، لم أنظر إلى الوراء.

بينما أحب Ionic وأقدر حقًا كل ما قام به مطورها ، Drifty (شكرًا لك!) ، أجادل أن Drifty ارتكب خطأ استثمار الكثير من الوقت في ميزات لامعة مثل دفع الكود الذي يجذب المستخدمين ، ولم يكن هناك وقت كافٍ للحصول عليه صواميل ومسامير الإطار الصحيحة لتجنب المشكلات التي تؤدي في النهاية إلى إبعادهم. الآن في نسخته الرابعة ، تمت إعادة كتابة Ionic عدة مرات بطرق غير متوافقة مع الإصدارات السابقة لدرجة أنني توقفت عن محاولة مواكبة ذلك - لا يزال الإصدار الأخير يحتوي على العديد من المشكلات الخطيرة التي تمنعني من الترقية ، وأنا الآن أعيد كتابة تطبيقي بالكامل في رفرفة.

كانت التجربة حتى الآن ممتازة ، ولدي الكثير من المرح ، ولكن لا تزال هناك بعض الثغرات والإغفالات الرئيسية في Flutter ، خاصة في المكونات الإضافية. على سبيل المثال: لا يوجد تكامل لحقل النص مع الملء التلقائي لكلمة المرور ، والمكوِّن الإضافي لخرائط Google عبارة عن أجزاء مجردة (وهناك أخطاء في عرض إطار العمل ذات الصلة) ، ولا يدعم WebView الأصلي file: // URLs لتحميل الأصول ، ولا يدعم شريط علامات التبويب دعم الشفافية أو الخلفيات المتدرجة ، وخلايا الجدول لا تدعم colspan ، و ThemeData ليست قابلة للتوسيع باستخدام ألوان خاصة بالتطبيق لاستخدامها مع الرسوم المتحركة ، وتفتقر مكتبة DateTime الوحيدة المدركة تمامًا للمنطقة الزمنية إلى العديد من الميزات المهمة للمنطقة الزمنية واللحظة ، وهناك العديد من الأساليب لإدارة الحالة محيرة للقادمين الجدد ، يجب عليك "الرفرفة النظيفة" بشكل متكرر لتجنب الاستثناءات الغريبة ، وغالبًا ما لا تعمل المقايضة السريعة كما ينبغي ، ويمكنني الاستمرار ...

سأصنف _ كل _ من هذه العناصر على أنها أكثر أهمية من "دفع الكود" ، خاصةً إذا كانت تخاطر برفض Apple تطبيقات Flutter ، إذا تطلب الأمر تغييرات كبيرة في إطار عمل المترجم الذي قد يجعل التحسينات التي تعمل على تحسين أداء التطبيق أكثر صعوبة في النهاية (سأحتاج إلى تحسين الأداء بنسبة 5٪ مقارنة بـ "دفع التعليمات البرمجية" في أي يوم) ، أو يستغرق وقتًا بعيدًا عن إكمال ميزة إطار العمل.

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

matthewlloyd الكثير من النقاط العظيمة!

إذا كنتم لا تستطيعون دعم Code Push ، فهل هناك طريقة لإنشاء محلل من بعض القواميس (مثل json و xml ...) إلى Flutter Widget؟ هل هذا مستحيل أم فكرة جيدة؟

- هل لدى أحد رأي في هذا؟
https://pub.dartlang.org/packages/dynamic_widget
يبدو واعدًا ، على الرغم من أنه لا يعالج مخاوف "الخطأ الحرج".

هذا هو الجزء المجنون هو أن دفع الشفرة هو العامل الرئيسي في الغرفة ، وهذا بعمق مسألة تجارية / عملية وأخرى تقنية ، ويميل أحد الجانبين إلى تجاهل الآخر ...

لا يوجد تكامل لحقل النص مع الملء التلقائي لكلمة المرور ، والمكوِّن الإضافي لخرائط Google مجرد (وهناك أخطاء في عرض إطار العمل ذات الصلة) ، ولا يدعم WebView الأصلي الملف: // URLs لتحميل الأصول ، ولا يدعم شريط علامات التبويب الشفافية أو خلفيات متدرجة ، وخلايا الجدول لا تدعم colspan ، و ThemeData ليست قابلة للتوسيع باستخدام ألوان خاصة بالتطبيق لاستخدامها مع الرسوم المتحركة ، وتفتقر مكتبة DateTime الوحيدة المدركة تمامًا للمنطقة الزمنية إلى العديد من الميزات المهمة للمنطقة الزمنية واللحظة ، وهناك العديد من الأساليب لقول الإدارة إنها مربكة للقادمين الجدد ، عليك أن "ترفرف تمامًا" بشكل متكرر لتجنب الاستثناءات الغريبة ، فعادة ما لا تعمل المقايضة السريعة كما ينبغي ، ويمكنني الاستمرار ...

نأمل أن كل هؤلاء لديهم بالفعل مشكلة جيثب: د

كان هذا سابقًا في خارطة الطريق لعام 2019. بعد التحقيق في هذا الأمر بمزيد من التفصيل ، قررنا عدم المضي قدمًا في هذا العمل في الوقت الحالي.

كانت هناك عدة عوامل دفعتنا إلى هذا القرار:

• للامتثال لفهمنا لسياسات المتجر على Android و iOS ، سيقتصر أي حل على كود JIT على Android والتعليمات البرمجية المفسرة على iOS. لسنا واثقين من أن خصائص أداء مثل هذا الحل على iOS ستصل إلى الجودة التي نطلبها من منتجنا. (بعبارة أخرى ، "سيكون بطيئًا جدًا").

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

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

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

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

شكرًا لك على توصيل منطق الفريق بشفافية.

eseidelGoogle هل

هذا محبط للغاية.

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

React Native + تعمل خدمة دفع الكود وأثبتت نفسها في العالم الحقيقي. إنها معركة تم اختبارها. يبدو أنه لا توجد مشكلة في متاجر التطبيقات فيما يتعلق بالتحديثات غير المباشرة. يبدو أن الجميع "بخير" معها. لذلك أعتقد أن حل Flutter يمكن السماح به أيضًا.

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

خطوة جيدة! أنا أفضل إنفاق الجهد الهندسي على تحسين Flutter بدلاً من إضافة ميزة دفع التعليمات البرمجية التي يمكن أن تزيد من تعقيد النظام البيئي وتضر به

لدي حاليًا أول تطبيق لي على الإطلاق ، تم تطويره في Flutter ، في الاختبار التجريبي المفتوح ولقد قمت بدفع حوالي 10 حزم تطبيقات مع الإصلاحات. ولكن يجب أن يكون في الغالب خاليًا من الأخطاء عند إطلاقه للإنتاج.

لذلك لا أعرف ما إذا كنت سأحتاج إلى هذه الميزة في أي وقت ، لكنني وجدت حزمة الحانة هذه OTA Update التي يبدو أنها تعمل بشكل جيد عند درجة 89 ، والتي تم إسقاطها فقط من خلال شعبيتها. هل هذه الحزمة آمنة؟ يبدو أنه يتم تنزيل APK من عنوان URL ويفك ضغطه محليًا ويؤدي إلى تثبيت نية APK على Android.

يمكن لأولئك الذين يحتاجون تمامًا إلى هذه الميزة تجربة هذه الحزمة.

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

كان لديّ جهاز ذاكرة وصول عشوائي بسعة 2 غيغابايت عندما بدأت ، محاولًا تطوير تطبيق Android كما كنت أرغب دائمًا ولكن جهازي لم يكن على مستوى المهمة. لقد جربت PhoneGap ، و Cordova ، وبعض إطارات عمل Intel ، و React-Native ، ولم يبدأ تشغيل أي منها. كان Flutter هو الوحيد الذي بدأت به بالفعل ومع واجهة مستخدمه الجميلة وأدوات التطوير ، فإنه يتقدم بأميال على معاصريه حتى بدون هذه الميزة.

أي تحديث؟

لن يكون سير عمل إصدار التطبيق هو نفسه أبدًا بعد أن أفسدتنا طريقة رد الفعل الأصلي باستخدام Code Push. عار حقيقي لأن Flutter لن تدعمه. يتشكل Flutter بشكل جيد وقد يكون منافسًا لـ React Native إذا اختاروا دعم هذه الميزة. واحسرتاه...

Hixie حسنًا ، لذا فإن التغيير الهندسي / الفني الأساسي له العديد من الجوانب السلبية في الوقت الحالي - وهذا أمر منطقي بالنسبة لي.

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

على سبيل المثال

• تهيئة Firebase في الوقت الفعلي
• خادم baased json-> عناصر واجهة المستخدم (على سبيل المثال https://github.com/dengyin2000/dynamic_widget/blob/master/WIDGETS.md أو simlar ، لا أؤيد المكون الإضافي الدقيق حتى الآن ولكن الفكرة)
• أو ربما شيء آخر ، ربما وظائف السحابة للمستخدمين المتقدمين ...
• من الواضح أنني لا أقترح عليك بذل مجهود هندسي لحالة استخدام "كبيرة" ، ولكن نوعًا من بديل hello-world-code-push-push الذي يلبي معظم الحاجة دون "دعنا نصلح / نغير كل شيء" اكتب العمارة.

فرضيتي هي أنه "يمكننا" تلبية 70-90٪ من الاهتمام بـ codepush بدون تغيير معماري أساسي للرفرفة ؛ ما رأي أي شخص في هذا؟

قد يؤدي نهج Code-as-ui الخاص بـ Flutter إلى تسهيل هذا الأمر أكثر مما قد يفعله مطورو Android ....

لقد رأيت شخصيًا شركتين على الأقل اختارتا اللاعبين الآخرين على الرفرفة لهذا السبب فقط ، وتحدث العديد من الشركات الأخرى بالمثل.

ربما يمكن أن تستمر المحادثة
"المستخدم: هل تتخطى دعم codepush"
"فريق Flutter: نعم ، في الوقت الحالي ، لهذه الأسباب (كما فعلت) ولكن بالإضافة إلى ذلك ، يمكنك تجربة" أ "أو" ب "لبعض حالات الاستخدام"

آسف للتعليق الطويل

neiljaywarner ربما تستحق LUA أن تبحث عنها - لقد قمت بإثبات المفهوم العام الماضي حيث يمكن استخدام نصوص LUA لإنشاء / تعديل وظائف تطبيق Flutter.

neiljaywarner ، أؤيد جميعًا هذا النوع من النهج ، لكن هذا مصدر قلق متعامد مما يغطيه هذا الخطأ.

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

شكرا لتوصيل عقلانية الفريق بشفافية.

أنا موافق

تعني وظيفة دفع التعليمات البرمجية المزيد من التطبيقات ، والمزيد من العملاء ، والمزيد من المطورين ، والمزيد من الاختبارات ، والمزيد من إصلاح الأخطاء ، ومشاكل أقل

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

maplerichie ، موافق ، السبب الذي يجعلني أحب الرفرفة هو تجربة المطور والأداء والنظام الأساسي المشترك لجميع الأجهزة. لا أمانع إذا لم يتم تنفيذ دفع الكود (ربما) ، فهذا من أجل سمعة وشعبية النظام البيئي. الآن أعرف لماذا يبدو دفع الكود بطيئًا جدًا عند استخدام تطبيقات Windows (بدء التشغيل البطيء ، وتأخير الإدخال ، وتأخر الرسوم المتحركة) هنا

نحن بحاجة شديدة لهذه الوظيفة
بحاجة إلى تحديث ساخن

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

yaronlevi أنا "شركة ناشئة صغيرة" ، حتى أقل من اثنين من المطورين الذين يعملون على تطبيق جوال ، أنا فقط ، وأنا أوصل إلى الإنتاج بدورات إصدار سريعة. مع Google Play Store الذي يقدم تحديثات لا تستغرق سوى بضع ساعات ، ومراجعة Apple App Store للتحديثات دائمًا تقريبًا أقل من 24 ساعة في تجربتي هذه الأيام ، أنا بالتأكيد لا أحتاج إلى دفع الكود. إذا كان Flutter مزودًا بدفع الكود ، فسأقوم بخطوات فعالة للتأكد من تعطيله في تطبيقي.

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

حسنًا ، شكرًا على أي حال.
أعتقد أننا بحاجة إلى معرفة ذلك بأنفسنا.

حقا مخيب للآمال :)

سيتم قريبًا دمج Flutter for web SDK مع Mobile SDK. الحل البديل هو استخدام WebView للجوال لتحميل كود الرفرفة. 😁

matthewlloyd مرحبًا

ربما تساعد
https://github.com/dengyin2000/dynamic_widget
https://github.com/neohelden/Flutter-AdaptiveCards

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

يستخدم MXFlutter JavaScript لتنفيذ إمكانات عرض Flutter ، ويدعم بناء جملة Flutter ، ويدعم دفع الكود والتحديث السريع.
https://github.com/TGIF-iMatrix/MXFlutter

@ TGIF-iMatrix هل تعرف ما إذا كان هذا الحل يتوافق مع سياسة توزيع المتجر؟

تضمين التغريدة
إنه آمن لأنه توزيع js-> محلل أصلي-> طريقة إنشاء عناصر واجهة المستخدم.

سننظر في استخدام flutter إذا كان يدعم دفع الكود

@ TGIF-iMatrix من المحتمل جدًا ألا توافق Apple على ذلك ، حيث تم إلغاء إعفاء تحديثات Javascript Core من اتفاقيات متجر التطبيقات ، وتم تحذير / رفض العديد من مستخدمي CodePush بسبب هذه الميزة.

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

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

هل جرب أي شخص tinker-lib مع flutter وهو من tencent github repo وأي نجاح في ذلك إذا كان أي شخص مهتم يمكنني التعاون معك ، فقد حاولت دفع التحديث ولكن هناك حاجة إلى تعديلات صغيرة لتحميل رمز جديد يجب القيام به في رفرفة. ملف قطعة أثرية جرة

نأمل في الحصول على حل في أقرب وقت ممكن

فيما يتعلق بالآثار المترتبة على أداء تنفيذ دفع الكود ، هل سيكون تجميع كود Dart إلى WebAssembly أي مساعدة؟ قد يسمح هذا بتنفيذ تجميع JIT في iOS داخل صندوق حماية JavaScript.

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

التحديث الساخن مهم جدًا بالنسبة لنا ، إذا دعم الرفرفة التحديث الساخن ، فسنستخدم الرفرفة للتعويض عن التفاعل الأصلي.

لقد خططت لأفضل طريقة ممكنة لدفع الكود ولكن نظرًا لضيق الوقت ، لا يمكنني بدء هذا المشروع إلا من نوفمبر الأسبوع الماضي أو من ديسمبر ، لا أقوم بتعديل أي كود محرك أو رمز إطار أو أي كود جافا مثل tinker lib حتى لا ينتهك أي مصطلحات متجر ، تطبيق الإخراج هو أيضًا aot ، لذا لا يوجد تراجع في الأداء ، أحاول أن أجعله سهل التنفيذ بحيث يمكن لأي شخص إضافة تطبيقه ، بناءً على بحثي حول فريق flutter الأساسي للشفرة ، أصبح من المستحيل عمداً جعل الكود يدفع i جربت جميع الإمكانيات مع التنفيذ الحالي وخلصت إلى أن الطرق الممكنة فقط إما أن تقوم بإجراء تعديلات على المحرك أو إعداد حل دون تعديل المحرك ، فأنا أختار الخيار الثاني وخططت لجميع المتطلبات اللازمة للمشروع. آمل أن ينجح المشروع. في هذه الأثناء ، إذا أعاد فريق flutter التأكيد على المشكلة ، فنحن جميعًا سعداء بالتنفيذ الداخلي.

ستكون هناك حاجة دائمًا إلى التحديث الساخن

هذه وظيفة أساسية لا غنى عنها

لقد خططت لأفضل طريقة ممكنة لدفع الكود ولكن نظرًا لضيق الوقت ، لا يمكنني بدء هذا المشروع إلا من نوفمبر الأسبوع الماضي أو من ديسمبر ، لا أقوم بتعديل أي كود محرك أو رمز إطار أو أي كود جافا مثل tinker lib حتى لا ينتهك أي مصطلحات متجر ، تطبيق الإخراج هو أيضًا aot ، لذا لا يوجد تراجع في الأداء ، أحاول أن أجعله سهل التنفيذ بحيث يمكن لأي شخص إضافة تطبيقه ، بناءً على بحثي حول فريق flutter الأساسي للشفرة ، أصبح من المستحيل عمداً جعل الكود يدفع i جربت جميع الإمكانيات مع التنفيذ الحالي وخلصت إلى أن الطرق الممكنة فقط إما أن تقوم بإجراء تعديلات على المحرك أو إعداد حل دون تعديل المحرك ، فأنا أختار الخيار الثاني وخططت لجميع المتطلبات اللازمة للمشروع. آمل أن ينجح المشروع. في هذه الأثناء ، إذا أعاد فريق flutter التأكيد على المشكلة ، فنحن جميعًا سعداء بالتنفيذ الداخلي.

لقد خططت لأفضل طريقة ممكنة لدفع الكود ولكن نظرًا لضيق الوقت ، لا يمكنني بدء هذا المشروع إلا من نوفمبر الأسبوع الماضي أو من ديسمبر ، لا أقوم بتعديل أي كود محرك أو رمز إطار أو أي كود جافا مثل tinker lib حتى لا ينتهك أي مصطلحات متجر ، تطبيق الإخراج هو أيضًا aot ، لذا لا يوجد تراجع في الأداء ، أحاول أن أجعله سهل التنفيذ بحيث يمكن لأي شخص إضافة تطبيقه ، بناءً على بحثي حول فريق flutter الأساسي للشفرة ، أصبح من المستحيل عمداً جعل الكود يدفع i جربت جميع الإمكانيات مع التنفيذ الحالي وخلصت إلى أن الطرق الممكنة فقط إما أن تقوم بإجراء تعديلات على المحرك أو إعداد حل دون تعديل المحرك ، فأنا أختار الخيار الثاني وخططت لجميع المتطلبات اللازمة للمشروع. آمل أن ينجح المشروع. في هذه الأثناء ، إذا أعاد فريق flutter التأكيد على المشكلة ، فنحن جميعًا سعداء بالتنفيذ الداخلي.

مرحبًاcanewsin
حاولت أيضًا أن أفعل الشيء نفسه من خلال عدم تعديل محرك الرفرفة. اكتشفت أنه في وضع AOT ، يبحث المحرك عن ملفات .so في مسار المكتبة الأصلي لنظام Android ، مع تعديل / إضافة ملف هناك بعد تقييد تجميع التطبيق بواسطة JVM. ومن ثم لا يمكن إضافة الملفات التي تم تنزيلها عبر الهواء إلى مسار lib الأصلي.

في انتظار المزيد من الأفكار منك. 😀

لا أعتقد أن هناك حاجة لتحديث كل من كود dart والكود الأصلي.
فقط دارت كود جيد

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

NEELANSHSETHI هل يمكنك نشر الخطة هنا؟ يمكننا البدء في تنفيذه

almeynman يرجى

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

هذا هو السبب الرئيسي لعدم انتقالنا من رد الفعل الأصلي إلى الرفرفة. :(

😔

تتفوق ReactNative على Flutter بسبب هذه الميزة ولدي الكثير من المشاريع حيث تم فك تشفير اختيار البيئة (RN أو Flutter) مقارنةً بميزة كود الدفع! في انتظار الخبر: /

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

eseidelGoogle
قضية أعمال:
لدينا تطبيق لتتبع الحافلات على الأجهزة اللوحية ولكن يتم تحديث العميل مرة واحدة في الشهر لأن الجهاز اللوحي يستخدم بيانات الإنترنت وليس wifi
باستخدام Code Push ، سنتمكن من التحديث دون استهلاك الكثير من بيانات العميل

كان لدينا تطبيق كوردوفا مع دعم دفع الكود. عندما يتعلق الأمر بتحديث التطبيق عن طريق الخطأ ، اعتقدنا أن flutter ستضيف دعم دفع الكود "على أي حال" لذلك قمنا بتطوير تطبيقنا باستخدام flutter. لكن الحياة بدون دفع التعليمات البرمجية كانت مروعة تمامًا بالنسبة لنا في العام الماضي. لذلك نحن أخيرًا (ولحسن الحظ) في عملية (إعادة) إعادة كتابة التطبيق في رد فعل أصلي لاستعادة دعم الكود الخاص بنا.

Code Push ، لهذا السبب أتعلم React-Native الآن.

إذا كنت مهتمًا بتنفيذي
اتبع تقرير التقدم هنا
https://github.com/canewsin/flutter-code-push-timeline
يرجى قراءة جميع تعليقاتي أعلاه قبل المتابعة.

Code Push ، لهذا السبب سأظل مع React-Native.

من فضلك لا تنشر مشاركات غير بناءة ، +1 ، "نحتاج إلى هذا" ، "نحن نستخدم X بدلاً من ذلك" ، إلخ ، لأنها ليست بناءة ولا تساهم في المناقشة.

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

أريد أيضًا تذكير جميع المشتركين هنا بأن github يحتوي على زر unsubscribe في الجزء العلوي الأيمن من الموضوع.

أيضًا ، يعطي فريق Flutter الأولوية للمشكلات بناءً على عدد الإبهامات ، لذا فإن رفع هذا العداد يمكن أن يكون أمرًا كبيرًا. هذا والنقر على "اشتراك" يكفي.

يسير مشروع Code push الذي تناولته جيدًا ولكني أريد بعض الأمثلة على متطلبات دفع الكود ، لذلك إذا اكتمل دفع الكود ، فكيف تستخدمه ، فقم بنشر متطلباتك الفريدة كقضية جديدة في هذا الريبو https://github.com/ canewsin / flutter code-push-timeline بحيث يكون التطوير على المسار الصحيح.
القيود التي وجدتها حتى الآن هي:
لا يمكننا الوصول إلى النظام الأساسي الأصلي ولكن يمكن القيام بذلك عبر وظيفة ffi.
يعمل كود codepush في وضع الحماية لبعض المخاوف الأمنية ، لذلك لا يمكن إلحاق أي ضرر بالجهاز.

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

مثير جدا!
مرحبا ، هل لديك أي أمثلة حتى الآن؟ وكيف تتعامل مع قسم iOS؟ منذ أبل صارمة للغاية في هذا المجال. شكرا

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

مثير جدا!
مرحبا ، هل لديك أي أمثلة حتى الآن؟ وكيف تتعامل مع قسم iOS؟ منذ أبل صارمة للغاية في هذا المجال. شكرا

تعمل حاليًا مع جانب android ، على الرغم من أن جانب ios غبي ، على غرار إصدار sandboxed لتطبيقات js التفاعلية ، سيتم تشغيل الكود في وضع الحماية دون الوصول إلى منصة apis للنظام الأساسي ، لذلك قد لا تكون المشكلة عندما يكون جاهزًا لجانب iOS.

مرحبًاeseidelGoogle
أي تحديثات؟ الجدول الزمني؟

مرحبًاeseidelGoogle
أي تحديثات؟ إنه ديسمبر ، ميزة سيتم إطلاقها في عام 2019؟

سألت موضوع AMA حول هذه المسألة. قد تحتوي على معلومات مفيدة.
https://www.reddit.com/r/FlutterDev/comments/d51o4w/were_the_flutter_team_at_google_ask_us_anything/f0ium5w؟utm_source=share&utm_medium=web2x

Hixie قرأت مقالتك على Reddit
https://www.reddit.com/r/FlutterDev/comments/d51o4w/were_the_flutter_team_at_google_ask_us_anything/f0ium5w/؟utm_source=share&utm_medium=web2

أتساءل هل ستكون تحديثات تطبيق Flutter صغيرة الحجم إذا قمت بنشرها كـ abb "Android App Bundle" في Google Play أم أنها للرمز الأصلي فقط؟

هذه ميزة مهمة لبناء المؤسسات (التطبيقات التي يتم توزيعها خارج المتاجر ، على سبيل المثال من خلال بوابات الويب)

إنها ميزة مطلوبة للغاية. لماذا لا نحصل عليها رسميا؟ ما الذي يمنعها من إعطاء هذه الميزة؟

هل هذه خارطة طريق 2020؟

لا

2020 ولا تزال تنتظر

يرجى قراءة هذا قبل النشر أدناه.

إليك ملخص قصير إذا كنت لا تريد التمرير لأعلى لفهم:

كما تمت الإشارة في هذا التعليق ، فإن التحديات الثلاثة الكبرى هي:

• ما دفع
• هل هي آمنة للمستخدمين
• من حيث يتم دفعها

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

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

يتم تجميع Flutter ، على الأقل في وضع الإصدار ، وحتى لو لم تكن كذلك ، فهي ليست جافا سكريبت ، وبالتالي ، لا يمكن تفسيرها على iOS دون كسر شرط "no JIT" ، أو أن تكون بطيئة للغاية.

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

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

يمكن أن يكون لديك أفضل النوايا في العالم ، وسيكون هناك دائمًا من يساندك معهم.

في الوقت الحالي ، على نظام Android ، إذا كنت لا تستخدم متجر Play للتوزيع ، فيمكنك فقط إنشاء برنامج تنزيل يجلب ملف apk ويطلب من المستخدم تثبيته. على نظام iOS ، حسنًا ، لا يمكنك التحميل الجانبي بشكل فعال دون الكثير من الألم ، ولا تهتم أجهزة JB'd بقيود متجر التطبيقات.

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

الآن ، إذا كنت تريد أن يلقي الفريق نظرة ، فانتقل إلى المنشور

إذا كان تعليقك يقع في القائمة أدناه ، يرجى إعادة النظر في نشره.

• السؤال عن وقت / ما إذا كان موجودًا في خارطة الطريق
• "ليس هناك" (وأشكال مختلفة ، مثل التعليق السابق لهذا التعليق)
• "نحن نستخدم إطار العمل X لأنه لا يوجد دفع برمجي"
• "يعد Framework X أفضل لأن دفع التعليمات البرمجية"
• "نحن بحاجة إلى دفع التعليمات البرمجية"
• "تحديثات؟"
• إن الحجج الخاصة بالتعليمات البرمجية تدفع
  
  
  
  • تطبيقات المؤسسة / Sideloaded
  
  
  • الترقيع في حالات الطوارئ
  
  
  • إضافة الميزات
  
  
• الحجج ضد الكود تدفع
  
  
  
  • أصبحت مدد مراجعة متجر التطبيقات / play أقصر الآن
  
  
  • متجر اللعب / التطبيقات يحظرها
  
  
  • لا تحتاجها
  
  

هذه المشكلة مشحونة بالفعل بتعليقات كافية كما هي ، لذا يُرجى عدم إضافة تعليقات لا تضيف شيئًا إلى المحادثة. إذا كان لدى الفريق ما يقوله ، فسيقومون بنشره هنا ، حيث أن هذا المنشور يضم ما يقرب من 100 مشارك في الوقت الحالي ، وأكثر من 500 إبهام ، فلا يمكن تجاهله.

لأكون صادقًا ، لا أعتقد أن هذا يجب أن يكون مصدر قلقك. سوف يستخدم المطور الميزة على مسؤوليته الخاصة. إذا قررت Apple فجأة حظر جميع التطبيقات التي تستخدم دفع الكود ، فسيتعين على تطبيقك استخدام طريقة مختلفة. لكن هذا لا يحدث لجافا سكريبت. لم يحدث لسنوات ، فلماذا حدث لـ Flutter؟ لا يمكنهم حتى التحقق من ذلك. يطلب الناس هذه الميزة لأنها مفيدة. يمكنك كتابة وحدات صغيرة وتحديثها ديناميكيًا. إنها لعبة تغيير. يمكنك إصلاح الخلل في وحدة على الطاير. بالإضافة إلى ذلك ، لا تستطيع Apple التحقق حقًا مما يفعله التطبيق ، فهو لا يمتلك الموارد. سيكون من المستحيل ، أتمنى أن تدرك ذلك. بالإضافة إلى ما هو الهدف؟ يمكنني كتابة رمز غامض وإدخال باب خلفي في أحد التطبيقات ، يتم تشغيله عندما أقدم JSON معينًا كنتيجة لاستدعاء REST. كيف ستتمكن Apple من التحقق من ذلك؟ لا تستطيع. لا يوجد شيء يمكن أن تفعله Apple أو Android لوقف ذلك. يحتاج الناس إلى هذه الميزة ، ويجب عليك تنفيذها. ما نفعله به ، إنه عملنا وليس عملك. قلت بنفسك ، هذه الميزة بها أكثر من 500 إبهام وأكثر من 100 مشارك. ربما حان الوقت لتنفيذه حسب طلب المجتمع.

dedalozzo حجج جديدة عظيمة!

أنا لست جزءًا من فريق flutter ، لذا من فضلك لا تستهدفني من أجل طلب التنفيذ.

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

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

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

بالإضافة إلى ذلك ، كما هو مذكور أعلاه ، يتيح لك التوزيع خارج متجر Play دفع ملفات APK المحدثة.

أنا آسف ، اعتقدت أنك أحد أعضاء فريق Flutter.

ما قلته في تعليقك الأخير صحيح. في واقع الأمر ، يبدو أن Apple و Google تتسامح مع دفع الكود ، حتى لو كان حدًا ومخالفًا للقواعد.

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

الكثير من العمل قيد التقدم ، ولكنه يتيح دفع الكود https://github.com/chgibb/hydro-sdk

chgibb Hold on ... تتيح دفع الكود ولكن أيضًا تغير كل شيء من Dart إلى Typescript؟

هل هناك طريقة للفصل بين هذين الأمرين؟ للحصول على codepush أثناء كتابة Dart كالمعتاد؟

SpajicM الذي يعمل فقط _لأنه لا يستخدم Dart ، بدلاً من ذلك ، ربما يستخدم محرك JS ، مثل JavascriptCore ، المملوك لشركة Apple ، ويبدو أنهما ينظران إلى الاتجاه الآخر عند استخدامه مع دفع الكود.

خدش ذلك ، فهو يستخدم Lua bytecode ، والذي يتعارض مع سياسة المتجر في كل شكل أو شكل.

miyoyo لماذا هذا بالتحديد ضد سياسة المتجر؟
SpajicM إنها مضافة بحتة. يمكن تضمين أجزاء الكتابة المطبوعة في تطبيق Dart أكبر. صغيرة مثل أجزاء نصية واحدة أو شاشات كاملة.

تحظر سياسة المتجر دفع أي نوع من التعليمات البرمجية المجمعة ، والتي يبدو أن ملفات .hc منها ، نظرًا لأنها مجمعة lua bytecode (ربما مع الامتدادات ، لم يتم التحقق منها).

حالة الاستخدام المحددة لدفع رمز _ مجمع_ إلى التطبيقات تتعارض صراحةً مع سياسة متجر Play ، والعنصر "عدم توفير رمز مصدر" الذي _ يمكنك _ تمرير جافا سكريبت فيه لأنه ، في CodePush ، لن يتم تطبيقه ، مما يخالف إرشادات Apple .

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

كيف تعمل كل هذه الألعاب المحمولة مع تحديثات اللعبة؟ هل يقومون فقط بدفع / تنزيل الأصول؟

miyoyo من https://play.google.com/about/privacy-security-deception/malicious-behavior/
...This restriction does not apply to code that runs in a virtual machine and has limited access to Android APIs...
ملفات Hydro-SDK .hc هي رمز Lua 5.2 نقي بدون امتدادات أو ميزات خاصة. يتم تشغيلها في مترجم بدون وظيفة للطفرات الذاتية أو إنشاء الكود. لا شيء من dart:io مكشوف لهم. على الرغم من ذلك ، لا يوجد ما يمنع المضمن من تعريض فئة dart:io File أو كشف PlatformChannel s على سبيل المثال.

يعتبر قسم التفاح 2.5.2 أكثر غموضًا قليلاً فيما يتعلق بمعنى كلمة "تنفيذ" ، وكذلك في تغيير الميزات أو الوظائف.

https://developer.apple.com/app-store/review/guidelines/#2.5.2

...
2.5.2 Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install, or execute code which introduces or changes features or functionality of the app, 
...

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

تستخدم تحديثات ألعاب kuhnroyal Mobile إما Dynamic Asset Delivery للأشياء غير القابلة للتنفيذ ، وعادة ما يتم تتبعها سريعًا لأنها تتطلب قدرًا أقل من التحقق ، وملفات توسيع APK التي تتيح لك إجراء ترقيات جزئية ، ولكنها لا تزال تخضع لدورات تحديث المتجر العادية ، وتحديثات APK المنتظمة .

تحدث مع العميل: ضع عنوانًا مفاده أن هذا لم يعد يمثل أولوية بالنسبة لهم.

يمكنك استخدام Localizely للحصول على تحديثات عبر الهواء للنصوص / الترجمات: https://localizely.com/flutter-over-the-air

من أجل الرفرفة ، قم ببناء هذه الميزة أو قم بإرشادنا حول كيفية بنائها. اشكرك .

أيها الناس _please_ ، هذه هي المرة الثالثة التي يتم فيها نشر هذا ، ولكن _لا ترسل تعليقات إلا إذا كان لديك بالفعل شيء تضيفه_ .

استشر هذا المنشور لمزيد من التفاصيل ولإبداء الإعجاب بالمنشور الأول.

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

في غضون ذلك ، أي بديل لدفع التعليمات البرمجية؟

في غضون ذلك ، أي بديل لدفع التعليمات البرمجية؟

بناء على خبرتي ، لا يوجد بديل

samerdernaikamfenej في حين ليس تماما إنتاج جاهزة، وقد بدأ هذا المشروع مع دفع الكود كما هدف واضح https://github.com/chgibb/hydro-sdk

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

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

هذا ليس صحيحا. يرجى التحقق مرة أخرى وعدم نشر معلومات خاطئة!

تنص المادة 3.3.2 من اتفاقية ترخيص مطور Apple على ما يلي:

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

إنها تسمح على وجه التحديد بتنزيل التعليمات البرمجية المفسرة مثل JS طالما أنك لا تغير الغرض الأساسي من التطبيق. لقد كان الأمر على هذا النحو لأكثر من 5 سنوات حتى الآن ولم أسمع أبدًا عن أي شخص يتعرض للنزوع من استخدام برنامج codepush بطريقة عادية ومسؤولة.

قم بإلقاء نظرة على قسم AppCenter حول التوافق مع إرشادات البرمجة والتخزين. يتم استخدام برنامج ترميز AppCenter (المدعوم من Microsoft) بواسطة عدد كبير من التطبيقات التي لا تحتوي على مشاكل امتثال المتجر. https://github.com/microsoft/react-native-code-push#store -guideline-الامتثال

إن أكبر مانع لـ codepush الذي أراه هو أنه قد لا يستحق مقايضة الأداء بإجبارك على استخدام compile-to-js أو تفسير Dart على iOS بدلاً من المترجم مسبقًا. نظرًا لأن Flutter يستهدف المتصفح ، إلا أنني أظن أن أداء التحويل البرمجي إلى js سيكون جيدًا بدرجة كافية ، ولكن ربما لا يزال غير مقبول في أداء فريق Flutter.

ربما يأتي حل طرف ثالث (مثل AppCenter لـ React Native) وسد هذه الفجوة. CodePush مفيد للغاية!

حسنًا ، يكشف بحث Google السريع عن العديد من الأمثلة لرفض Apple للتطبيقات التي تتضمن إمكانية دفع الكود ، انظر على سبيل المثال

https://github.com/microsoft/react-native-code-push/issues/1297

نظرًا لأن أوقات مراجعة App Store تُقاس الآن دائمًا تقريبًا بالساعات وليس بالأيام ، فأنا لا أفهم لماذا قد يخاطر أي شخص. إذا تم دمج دفع الكود في محرك Flutter ، فقد تقرر Apple حظر جميع تطبيقات Flutter.

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

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

عند الحديث شخصيًا ، فإن شغفي بدفع الكود يتمحور حول تولي مسؤولية سلسلة التوريد الخاصة بتسليم التحديث كما هي. ناهيك عن العقبات الكبيرة التي تنطوي عليها محاولة أتمتة العملية الحالية في إعداد قرص مضغوط متماسك نظرًا للحالة المؤسفة لأدوات CLI xcode .

أعتقد أن أقل من 24 ساعة في الغالبية العظمى من الحالات كافية للجميع تقريبًا. إذا كنت بحاجة إلى الحصول على تحديث من خلال عملية مراجعة Apple بسرعة أكبر من ذلك ، على سبيل المثال لإصلاح خطأ عاجل ، يمكنك طلب مراجعة عاجلة. لقد فعلت ذلك في إحدى المرات ، واكتملت مراجعة التطبيق حرفيًا بعد 10 دقائق من تقديم الطلب.

إن الحصول على ملكية سلسلة التوريد الخاصة بالتسليم هو أمر يفعله المرء على حسابه ...

إرشادات متجر تطبيقات Apple ، القسم 2.5.2 (https://developer.apple.com/app-store/review/guidelines/#software-requirements):

"2.5.2 يجب أن تكون التطبيقات محتواة ذاتيًا في حزمها ، ولا يجوز لها قراءة البيانات أو كتابتها خارج منطقة الحاوية المخصصة ، ولا يجوز لها تنزيل أو تثبيت أو تنفيذ التعليمات البرمجية التي تقدم ميزات أو وظائف التطبيق أو

متطلبات برنامج مطور Apple ، القسم 3.3.2:

3.3.2 باستثناء ما هو مبين في الفقرة التالية ، لا يجوز للتطبيق تنزيل أو تثبيت رمز قابل للتنفيذ.

AndrewMorsillo @ بغض النظر عن كل إرشادات وبغض النظر عن مقدار المعلومات المقدمة ، فإن أفضل ما يمكننا الحصول عليه هو "ربما يكون مسموحًا لسنا متأكدين من أنها ليست جريمة يمكن حظرها في الواقع ، فقد نكون غير متأكدين" .

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

بقدر ما أستطيع أن أقول ، فإن تداول كل ذلك لتجاوز دورة المراجعة لمدة 24 ساعة وكتابة الاختبارات لا يستحق كل هذا العناء. (كان بإمكاني أن أفهم أنه كان أسبوعًا ، وهذا عادةً ما يكون فقط من جانب iOS ، وهو فعليًا أكبر نقطة خلاف هنا)

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

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

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

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

في يوم الجمعة ، 7 أغسطس 2020 الساعة 07:38 ، كتب SpajicM [email protected] :

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

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

miyoyo https://github.com/miyoyo لا أعرف لماذا تشعر
بحاجة إلى الرد على كل تعليق أو فكرة يتم تقديمها هنا.
الناس يريدون هذا. أنتم يا رفاق طلبتم من الناس التصويت لصالح القضية ، وقد صوتنا لصالحها
على طول الطريق إلى القمة. لن يتم حل هذا إلا إذا كان شخص ما
يفكر فيه بنشاط ويدفعه.

-
أنت تتلقى هذا لأنك مشترك في هذا الموضوع.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/flutter/flutter/issues/14330#issuecomment-670242698 ،
أو إلغاء الاشتراك
https://github.com/notifications/unsubscribe-auth/ADS5AJFUU2V6MHQIP7AMZKLR7M5HPANCNFSM4EOFIZRA
.

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

ربما تكون أسوأ طريقة لتجربة المستخدم ...: /

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

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

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

UX-wise ، أليست هذه طريقة سيئة للتعامل مع التحديثات؟ إذا قام شخص ما بتعطيل التحديثات التلقائية يدويًا ، فلماذا يتجاوز Flutter ذلك؟ إنه أمر قابل للنقاش إذا كان يجب أن يتمتع أي تطبيق بهذه القوة ، ولكن بالتأكيد ليس الإطار بأكمله.

أعتقد أن مركزية عملية التحديث من خلال متاجر التطبيقات أفضل لتجربة المستخدم نظرًا لأنها تستطيع إدارة جميع التحديثات من خلال المتجر. UX على حساب وقت المطور هو نوع من جوهر تطوير التطبيق. وإذا كنت بحاجة إلى إصلاح فوري (على سبيل المثال ، لثغرة أمنية) ، يمكنك الحصول على تحديث عاجل ، أو رفض السماح للمستخدم باستخدام التطبيق حتى يتم تحديثه. بالطبع هذا الأخير ليس خيارًا رائعًا ، والأول مزعج ، لكن ذلك لأن Apple و Google يضعان المستخدمين في المرتبة الأولى ، ولا علاقة لهما بـ Flutter نفسها.

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

عند الحديث شخصيًا ، فإن شغفي بدفع الكود يتمحور حول تولي مسؤولية سلسلة التوريد الخاصة بتسليم التحديث كما هي.

هذا نوع من المشكلة في هذا الموضوع - محاولة القيام بما تحذر منه Apple و Google بشدة ليست فكرة جيدة إذا كنت ستستخدم متاجر التطبيقات الخاصة بهم. كما قال miyoyo ، إنها منطقة رمادية في أحسن الأحوال ، وهي غير مناسبة تمامًا للإطار الذي تستخدمه Google والشركات / الأفراد الآخرون.

أخيرًا https://github.com/flutter/code-push

إنه فعليًا https://github.com/microsoft/react-native-code-push

حسنًا ، لا يزال Flutter غير قادر على تحديث الكود الخاص بك ، ولكن في الواقع تحدث هذا الرابط عن الصور وذكرني أن Firebase Remote Config يعد شيئًا. الجانب السلبي هو أنك تحتاج إلى استباق أجزاء التعليمات البرمجية التي قد تحتاج إلى تغيير وتوقع تلك التغييرات في تطبيقك ، ولكن بمجرد القيام بذلك ، يجب أن يكون سريعًا جدًا في طرح تغييرات جديدة بدون متجر التطبيقات (على غرار ما يفعله React Native Code Push مع صوره)

ardyfeb يقوم أشخاص مثلك بإعطاء المجتمع

هناك ؛ طريقة أخرى لحل ذلك
بدون استخدام flutter web

هناك ؛ طريقة أخرى لحل هذا. لقد رأيت الكثير من التطبيقات تفعل ذلك. إذا كان التطبيق قديمًا ، فانتقل إلى رسالة منبثقة ، إما أن تقوم بإغلاقه أو تحديث التطبيق. هذا كل شيء.
...
يوم الجمعة ، 7 أغسطس 2020 الساعة 07:38 ، SpajicM @ . * > كتب: الأمر لا يتعلق فقط بعملية المراجعة ، إنه يتعلق أيضًا بالمستخدمين الذين يتعثرون في الإصدارات القديمة من التطبيق لأنهم ربما أوقفوا التحديث التلقائي. بالتأكيد ، يمكنك تنفيذ الحد الأدنى من الإصدار للتحقق بنفسك ، ولكن بعد ذلك يجب أن يذهبوا مرة أخرى من خلال متجر Play ويكون الناس كسالى للأسف. باستخدام دفع الكود ، يمكنه فقط تحديث التطبيق بسرعة في كل تشغيل (آمل) والسماح للمستخدم بالدخول بسلاسة أكبر. miyoyo https://github.com/miyoyo لا أعرف لماذا تشعر بالحاجة إلى الرد على كل تعليق أو فكرة يتم تقديمها هنا. الناس يريدون هذا. طلبتم يا رفاق من الناس التصويت لصالح هذه القضية ، وقمنا بالتصويت حتى القمة. لن يتم حل هذا أبدًا ما لم يفكر شخص ما به بنشاط ويدفعه. - أنت تتلقى هذا لأنك مشترك في هذا الموضوع. قم بالرد على هذه الرسالة الإلكترونية مباشرةً ، أو اعرضها على GitHub < # 14330 (تعليق) > ، أو قم بإلغاء الاشتراك https://github.com/notifications/unsubscribe-auth/ADS5AJFUU2V6MHQIP7AMZKLR7M5HPANCNFSM4EOFIZRA .

هذا يبدو رائعًا ... إذا كنت تبني تطبيقات مصرفية.

إذا احتاج شخص ما إلى تحديثات عبر الهواء لترجمات التطبيق فقط ، فإليك نموذج لتطبيق Flutter: https://github.com/localizely/flutter-ota-sample-app

يبدو أن إرشادات شركة آبل مختلفة عما كانت عليه من قبل؟

هذا لا يزال هو نفسه

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

ومع ذلك ، لا يمكنني العثور على أي إشارات أخرى إلى التعليمات البرمجية المفسرة أو القابلة للتنفيذ.

هل من الممكن أن التفاصيل المتعلقة بنظام Apple البيئي من المنشور الأصلي لم تعد صحيحة بالنظر إلى أنها لم تعد تقول شيئًا محددًا عن اللغات المترجمة أو المترجمة؟