أرى أن واجهات برمجة التطبيقات واسعة النطاق جدًا، ولكن قبل أن أتعمق في هذا الاتجاه، أردت أن أعرف ما إذا كان من الممكن بناء تطبيق Flutter مخصص بالكامل باستخدام واجهات برمجة التطبيقات التي يدعمها Discourse؟
نحن حاليًا على XenForo وسننتقل إلى Discourse أولاً ثم نبدأ في العمل على تجربة المستخدم المخصصة للتطبيق.
هل هناك أي شيء آخر يجب أن نكون حذرين منه؟
هل تنوي استخدام طريقة عرض الويب؟
إذا لم يكن الأمر كذلك:
مرحباً روبرت،
لا، لا أخطط لاستخدام طريقة عرض الويب. من شأن ذلك أن يقوض الغرض من تجربة مستخدم مخصصة.
تكرار العمل أمر مسلم به ومقبول.
ماذا تقصد بعدم التوافق مع المكون الخاص بالمظهر والنظام البيئي للإضافات؟ هل تقصد أن الإضافات لن تكشف عن واجهات برمجة التطبيقات وبالتالي لا يمكن استخدامها في التطبيق المخصص للجوال. المكون الخاص بالمظهر خاص بإطار عمل الواجهة الأمامية، لذا من المفهوم أنه لا يمكن استخدام مكونات Ember في Flutter.
لقد قرأت هذا الموضوع قبل نشر هذا هنا. انحدر هذا الموضوع إلى نقاش PWA مقابل التطبيقات الأصلية ولم يعد المنشئ الأصلي للموضوع أبدًا.
استعلامي ليس خاصًا بـ Flutter على أي حال على الرغم من أنني ذكرته في العنوان.
الاستعلام في الواقع هو، نظرًا لوجود قائمة واسعة من واجهات برمجة التطبيقات المكشوفة، هل من الممكن إنشاء واجهة أمامية مخصصة تعمل بكامل طاقتها باستخدام تلك الواجهات. أو هل هناك بعض الثغرات التي قد تمنعنا من القيام بذلك.
العناصر الأمامية لهذه (مكونات السمة هي عناصر أمامية 100٪) مكتوبة بلغة EmberJS وتستخدم واجهة برمجة تطبيقات Discourse JavaScript.
ستقطع نفسك تقريبًا بالتأكيد عن كل هذه التخصيصات.
لا، ولكنها عديمة الفائدة إلى حد كبير بدون تغييرات الواجهة الأمامية.
انظر منشوري:
(الموضوع مرتبط أعلاه)
بشكل أساسي، متعة كبيرة للمشروع أنا متأكد، لكنها لا معنى لها اقتصاديًا ولا تقنيًا.
إذا كنت ترغب في النشر على متاجر التطبيقات، فهناك خيار أفضل بكثير.
نعم، هذا ممكن تمامًا، حيث أن discourse هو مجرد تطبيق ember فوق واجهة برمجة تطبيقات rails.
أعتقد أنها فكرة سيئة للغاية، حيث ستكرر آلاف الساعات من العمل. ومع ذلك، كان لدي عميل فعل ذلك تمامًا وبدا سعيدًا به. لم أسمع منه منذ فترة طويلة؛ لا أعرف لماذا.
الشيء الجيد في النهج هو أنه في أي وقت يمكنك فقط اتخاذ قرار بالتبديل إلى الواجهة الأمامية لـ discourse. تعديل: أو، ربما، استخدام discourse بعد الترحيل ثم عدم جعل تطبيقك جيدًا بما يكفي لتبرير الانتقال إليه، أو السماح للمستخدمين باختيار الواجهة الأمامية التي يفضلونها.
شكرًا جاي، إجابتك هي حقًا ما كنت أبحث عنه. في الواقع، يمكنني استخدام الواجهة الأمامية للمناقشة لمستخدمي المتميزين وبناء تطبيق جوال بسيط لجذب المستخدمين العاديين الذين يرغبون في المشاركة دون الشعور بالإرهاق. أنت تعرف أولئك الذين يحبون استخدام Reddit و Facebook.
يا إلهي، لقد عدت إلى المناقشة بعد سنوات والتطور هنا مذهل للغاية. متحمس جدًا.
يضم مجتمعي 75 ألف عضو و 2.5 مليون مشاركة، لذا سيتطلب الأمر بعض العمل للترحيل. هذا هو هدفي الأول حاليًا.
لدينا بعض السمات التي يمكن اللعب بها والتي قد تكون أقل استهلاكًا للوقت من “بناء واجهة أمامية لـ Discourse باستخدام flutter من الصفر”
يمكنك تثبيت هذه السمات على موقعك ويمكن للمستخدمين تحديدها بأنفسهم.
أود أن يتم إثبات خطئي بمثال فعلي لواجهة أمامية مستقلة. أود أيضًا أن يتم تصحيحي إذا كان أي شيء أذكره هنا غير دقيق! 
فقط في فهمي، هناك بالفعل سوء تقدير كلما ظهر هذا الموضوع، بمعنى: لدى Discourse واجهة برمجة تطبيقات (API) وطبقة واجهة أمامية مستقلة، فلماذا لا تجرب واجهة أمامية مختلفة هناك؟
سوء التقدير الذي أراه هو أن:
شكرًا لك، هذا على الأرجح شيء كنت سأكتشفه لو تعمقت أكثر. إنه لأمر مؤسف إذن إذا تم تشغيل جميع الإحصائيات وحسابها في الواجهة الأمامية بدلاً من استخدام قوائم الانتظار في الواجهة الخلفية. لم تعد “headless” على الإطلاق.
شكراً ناتالي، لقد نظرت في السمات سابقاً وأود أن أقول إن FKB Pro أقرب إلى ما نريده.
انظر هذا المفهوم لواجهة المستخدم لتطبيق الهاتف المحمول.
هممم… لست متأكدًا من أننا نستطيع قول ذلك؟
يتم احتساب الإعجابات في الواجهة الخلفية، ويتم احتساب عدد المشاركات والمواضيع في الواجهة الخلفية…
أعتقد أن وقت القراءة يعتمد على كود الواجهة الأمامية، ولكن هذا ليس مفاجئًا…
نعم، سأغير إلى “تتبع القراءة”.. لكنها لا تزال وجهة نظري: العديد من الميزات المتقدمة تعتمد على تتبع القراءة.
يبدو لي وكأنه مجرد سمة.
لا تضيع أموالك على تطبيق أصلي بالكامل.
أتفق مع ذلك. بعض المكونات التي يمكنها بالفعل القيام بالعمل الشاق لهذا:
نعم، بناءً على الردود المفيدة هنا، سنحاول أولاً المضي قدمًا قدر الإمكان مع السمة نفسها. الأولوية الأولى هي الترحيل مع كل التخصيصات الموجودة لدينا والتي تشمل سوقًا مزدهرًا ونظام تقييم للتجارة.
حسنًا، استعلام آخر. هل يمكن للمستخدمين الاشتراك في فئات لرؤية الخيوط من تلك الفئات فقط في خلاصاتهم؟ هذا شيء كان لدي في ذهني مع واجهات برمجة التطبيقات.
هل هناك طريقة لعرض المحتوى الموصى به في الخلاصة بناءً على التسجيل والأهمية لمستخدم؟
أنصحك بفصل ذلك في موضوع آخر.
لاحظ أن في Discourse، الموضوع = Topic
كان هناك طلب ميزة لهذا:
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
