[Python] تطبيق قائم على المتصفح أو تطبيق واجهة المستخدم الرسومية المستقلة؟


Answers

دعونا نتظاهر للحظة أن جهود التطوير / النشر / الصيانة / التكلفة متساوية وننظر إليها من منظور مستخدم التطبيق:

أي واجهة المستخدم هو المستخدم سيجد أكثر فائدة؟

من ناحية

  • سهولة الاستعمال
  • إستجابة
  • أنماط ملاحية / استخدام مألوفة
  • معظم مثل الأدوات / التطبيقات الأخرى المستخدمة على النظام الأساسي (أي ، أصلية)

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

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

من منظور التنمية

  • لا يوجد مستعرضان متاحان اليوم مماثلا بالضبط .
  • حتى مع واجهات Ajax و javascript والديناميكية والمتجاوبة ليست سهلة لتنفيذ / تصحيح.

هناك العديد والعديد من تطبيقات واجهة المستخدم الرسومية المستقلة التي هي مجرد رهيبة ، لا جدال. تطوير / نشر وصيانة واجهة المستخدم الرسومية متعددة المنصات غير تافهة.

تطوير واجهات مستخدم جيدة أمر صعب.

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

لا أعتقد أن معظم المستخدمين سيستخدمون واجهة ويب إذا ما أعطوا بديلاً.

IMNSHO

Question

أنا متأكد من أن هذا قد تم طرحه من قبل ، لكني لا أستطيع العثور عليه.

ما هي فوائد / حدود استخدام واجهة مستعرضة لتطبيق قائم بذاته مقابل استخدام إطار واجهة المستخدم الرسومية العادي؟

أعمل على تنفيذ برنامج بايثون حاليًا مع wxPython for the GUI. التطبيق هو ببساطة نماذج دخول المستخدم ومربعات الحوار. أنا أفكر في الانتقال إلى PyQt بسبب الأدوات التي تحتوي عليها (للتوسعة المستقبلية) ، ثم أدركت أنني ربما أستخدم متصفحًا للقيام بالكثير من نفس الأشياء.

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

تعديل للتوضيح ، اعتبارًا من الآن ، سيكون التطبيق مستندًا إلى المتصفح ، وليس مستندًا إلى الويب. سيتم تخزين كافة المعلومات محليًا على جهاز الكمبيوتر العميل؛ لا يلزم إجراء أية مكالمات من الخادم ولن يكون هناك حاجة إلى الوصول إلى الإنترنت (قد يأتي لاحقًا). سيكون مجرد واجهة المستخدم الرسومية المتصفح بدلا من واجهة المستخدم الرسومية wxPython / PyQt. نأمل أن يكون له معنى.




فوائد واجهة المستعرض:

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

فوائد الواجهة القائمة على واجهة المستخدم الرسومية:

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



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

هناك عمليات سحب لكونك تطبيق ويب ، مثل ..

إنها صفحة ويب. هناك أشياء لا يمكنك القيام بها (بسهولة)

لا يمكنك بسهولة تعيين مفتاح ctrl + j للقيام بشيء ما. على سبيل المثال: يحاول جدول بيانات Google تعيين اختصارات لوحة المفاتيح ويعمل معظم الوقت ، وأحيانًا تتولى معالجة المستعرضات الافتراضية للاختزال مهامه.

لا يمكنك إنشاء تنبيهات الهدير (إطار عمل إشعارات OS X). لا يمكنك الوصول إلى نظام الملفات. من الصعب السماح بالوصول في وضع عدم الاتصال.

جافا سكريبت هي وحدة المعالجة المركزية الثقيلة جدا.

حاول تغيير حجم مستند جدول بيانات Google ، أو تحميل صفحة على Digg (موقع جافا سكريبت ثقيل للغاية) - سيكون استخدام وحدة المعالجة المركزية (CPU) بنسبة 100٪ لفترة من الوقت .. والقيام بنفس الشيء في تطبيق سطح مكتب أصلي هو أمر بسيط

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

يجب أن تكون متاحة لخادم الويب في جميع الأوقات ، إلى الأبد

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

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

"إنها صفحة ويب" : من السهل إنشاء نماذج ومربعات حوار في HTML و javascript (أو حتى استخدام البرمجة النصية من جانب الخادم ، على سبيل المثال <?php if($_POST["email"] ==""){echo("Are you sure you want to continue?); ?> )

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

"الترقيات القسرية" : أتصور أن هذا قد يكون مرغوبًا ، حيث لا تريد أن يقوم المستخدمون بإدخال البيانات بالطريقة القديمة.

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

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




حلّي هو هذا

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

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

في كل قرار هو حقا لك! نظرًا لأن مطور جافا باستخدام جافا سكريبت و Swing يمكن أن يحل مشكلتي مع هذه المشكلة.




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




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

أنا مستعد تماما لها...




Links