سؤال

لدي تطبيق J2ME يعمل على هاتفي المحمول (العميل)،

أرغب في فتح اتصال HTTP مع الخادم واستمر في الاقتراع للحصول على معلومات محدثة على الخادم.

سيؤدي كل استطلاع بإجراءات إلى استخدام بايت GPRS وستحول مكلفا على المدى الطويل، حيث تعتمد فاتورة GPRS على الحزم المرسلة واستلمتها. هل هناك طريقة فعالة للبيت للاستيقاظ باستخدام بروتوكول HTTP؟

لقد سمعت أيضا عن الاقتراع الطويل، لكنني لست متأكدا من كيفية عملها وكيف سيكون فعالا.

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

هل كانت مفيدة؟

المحلول

إذا كنت تريد حل هذه المشكلة باستخدام HTTP فقط، الاقتراع الطويل سيكون أفضل طريقة. إنه سهل إلى حد ما. تحتاج أولا إلى إعداد عنوان URL على جانب الخادم للإعلام (على سبيل المثال http://example.com/notify)، وتحديد بروتوكول الإعلام. يمكن أن يكون البروتوكول ببساطة مثل بعض خطوط النصوص وكل سطر هو حدث. علي سبيل المثال،

  MSG user1
  PHOTO user2 album1
  EMAIL user1
  HEARTBEAT 300

مؤشر ترابط الاقتراع على الهاتف يعمل مثل هذا،

  1. قم بإجراء اتصال HTTP لإعلام عنوان URL. في J2ME، يمكنك استخدام HttpConnection GCF.
  2. سيتم حظر الخادم إذا لم يكن هناك أحداث لدفعه.
  3. إذا استجاب الخادم، احصل على كل سطر وتفرخ مؤشر ترابط جديد لإخطار التطبيق والاسترجاع إلى # 1.
  4. إذا أغلق الاتصال لأي سبب من الأسباب، والنوم لفترة من الوقت والعودة إلى الخطوة 1.

يجب أن تولي اهتماما باتباع تفاصيل التنفيذ،

  1. ضبط مهلة HTTP على كل من العميل والخادم. كلما طالت المهلة، والأكثر كفاءة. اتصال مهلة سيؤدي إلى إعادة الاتصال.
  2. تمكين HTTP Keepalive على كل من الهاتف والخادم. مصافحة TCP في اتجاهات TCP مكلفة في مصطلح GPRS، لذا حاول تجنب ذلك.
  3. كشف الاتصالات التي لا معنى لها. في البيئات المتنقلة، من السهل جدا الحصول على اتصالات HTTP التي لا معنى لها (تم تخفيض الاتصال، لكن خيط الاقتراع لا يزال ينتظر). يمكنك استخدام دقات القلب لاسترداد. قل معدل دقات القلب هو 5 دقائق. يجب أن يرسل الخادم إشعارا في كل 5 دقائق. إذا لم يكن هناك بيانات لدفع، فقط أرسل نبضات. على الهاتف، يجب أن يحاول مؤشر ترابط الاقتراع إغلاق اتصال الاقتراع وإعادة فتحه إذا لم يتم استلام أي شيء لمدة 5 دقائق.
  4. معالجة أخطاء الاتصال بعناية. الاستطلاع الطويل لا يعمل بشكل جيد عندما يكون هناك مشاكل في الاتصال. إذا لم تتم التعامل معها بشكل صحيح، فقد تكون قاطع الصفقة. على سبيل المثال، يمكنك إضاعة الكثير من الحزم على الخطوة 4 إذا كان النوم ليس طويلا بما فيه الكفاية. إذا كان ذلك ممكنا، تحقق من توفر GPRS على الهاتف ووضع مؤشر ترابط الاقتراع عند تعليقه عند عدم توفر GPRS لحفظ البطارية.
  5. قد تكون تكلفة الخادم مرتفعة للغاية إذا لم تنفذ بشكل صحيح. على سبيل المثال، إذا كنت تستخدم جافا Servlet، فسيكون لدى كل تطبيق قيد التشغيل اتصال استطلاع واحد على الأقل وموضوعه. اعتمادا على عدد المستخدمين، يمكن أن يقتل هذا Tomcat بسرعة :) تحتاج إلى استخدام تقنيات فعالة من الموارد، مثل Apache Mina.

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

نصائح أخرى

لا أعرف بالضبط ما تقصده "الاقتراع"، هل تعني شيئا مثل IMAP idle.ب يبقى اتصال مفتوحا ولا يوجد في النفقات العامة لبناء الاتصال نفسه مرارا وتكرارا. كما هو مذكور، هناك حل آخر ممكن هو رأس رئيس طلب HTTP (نسيت ذلك، شكرا!).

انظر إلى هذا الدورة التعليمية للحصول على اتصالات HTTP الأساسية في J2ME.

دفع البيانات إلى تطبيق / جهاز دون دعم دعم (مثل BlackBerry) غير ممكن.

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

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

أفضل طريقة للقيام بذلك هي استخدام اتصال مأخذ التوصيل. العديد من التطبيقات مثل gmail استخدامها.

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top