بناء تطبيق واحد لعدة أجهزة محمولة

Question

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

على وجه الخصوص، هل من الممكن استخدام تطبيق BREW واحد لدقة شاشات متعددة؟

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

Answer 1

نعم، من الممكن، لقد تمكنا من القيام بذلك في مكان عملي السابق.لكن المطلوب صعب رغم ذلك:

1. قم بالتجميع للحصول على إصدار BREW للقاسم المشترك الأدنى.الإصدار 1.1 هو الأساس لجميع الهواتف الحالية المتوفرة.
2. يجب أن يكون الكود الخاص بك قادرًا على التعامل مع العديد من الحلول.تعتبر طرق اكتشاف عرض الشاشة وارتفاعها دقيقة لجميع الهواتف في تجربتي.
3. يجب تحميل جميع مواردك على جميع الأجهزة.قد يتطلب ذلك إنشاء أداة تحميل الصور المخصصة الخاصة بك للتغلب على مشكلات معينة في الجهاز.بالنسبة للصوت، أعلم أن نوع MIDI البسيط 0 يعمل على الجميع ولكن QCP يجب أن يعمل أيضًا (ليس لدي خبرة في ذلك بنفسي).
4. استخدم الخطوط النقطية.هناك العديد من مشكلات الجهاز المتعلقة بالخطوط مما يجعل استخدام خطوط النظام أمرًا جديرًا بالاهتمام.
5. صمم بنية التعليمات البرمجية الخاصة بك كآلة ذات حالة محدودة.لا أستطيع التأكيد على هذا بما فيه الكفاية - افعل هذا ولن تتحقق الكثير من المشاكل أبدًا.
6. احصل على حلول بديلة لكل مشكلة في الجهاز.هذا هو الجزء الصعب!هذا ممكن، لكن حفرة الأرانب هذه عميقة بشكل لا يصدق...

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

Answer 2

لقد كتبت تحويل J2ME إلى Brew الذي يتم استخدامه في Javaground.من الممكن تمامًا كتابة دقة متعددة ورمز ثنائي واحد.لدينا قاعدة بيانات لأخطاء الجهاز حتى تتمكن من اكتشاف الجهاز عبر معرف النظام الأساسي ثم إنشاء سلسلة من العلامات التي تحدد الأخطاء التي تم وضع علامة عليها.على سبيل المثال، تحتوي معظم هواتف Motorola Brew (إن لم يكن كلها) على خطأ حيث لا تؤدي المكالمة الواردة إلى مقاطعة التطبيق حتى ترد على المكالمة، لذلك أستخدم TAPI لمراقبة مكالمة واردة وإنشاء حدث إخفاء (نظرًا لأننا محاكاة Java، على الرغم من أن الكود الذي تم إنشاؤه هو C++ خالص).أقوم ببعض عمليات التحقق في وقت التشغيل لإصدار Brew، وأقوم بتعطيل واجهات برمجة تطبيقات معينة إذا كان Brew 2 بدلاً من Brew 3.

تعد الألعاب ثلاثية الأبعاد أسهل في جعل الدقة مستقلة نظرًا لأنك تقوم بتوسيع نطاق البرنامج.

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

المشكلة في البنية الشاملة تمامًا هي أن هناك اختلافًا كبيرًا في القدرة، لذلك قد يكون من المفيد الحصول على عدد قليل من الإصدارات، فالأجهزة القديمة تحتوي فقط على أقل من 1 ميجابايت من الكومة (وحجم شاشة صغير)، ومن ثم تحصل على الكثير مع 6 ميجابايت + (176 × 204 إلى أكبر).

مع Brew، لديك مجموعة متسقة إلى حد ما من القيم الأساسية (على عكس Java)، على الرغم من أن بعض الأجهزة الجديدة عبارة عن شاشة تعمل باللمس (ويتعين عليك التعامل مع إدخال المؤشر) وشاشات دوارة.

هناك أيضًا بعض هواتف Nokia القديمة التي تستخدم وضع endian الكبير مما يعني أن الملفات ليست مثل ملفات التعديل العادية (إلا إذا كنت تريد كتابة بعض رؤوس بادئات لغة التجميع الرائعة التي تقوم بفك تشفير الملف)

Answer 3

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

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