واجهات برمجة تطبيقات Android 4.0

مستوى واجهة برمجة التطبيقات: 14

Android 4.0 (ICE_CREAM_SANDWICH) هو إصدار رئيسي لنظام التشغيل يضيف مجموعة متنوعة من الميزات الجديدة للمستخدمين ومطوّري التطبيقات. إلى جانب كل الميزات وواجهات برمجة التطبيقات الجديدة التي تمت مناقشتها أدناه، يُعد Android 4.0 إصدارًا مهمًا لنظام التشغيل الأساسي لأنّه يوفّر المجموعة الشاملة من واجهات برمجة التطبيقات والمظاهر المجسمّة من الإصدار Android 3.x إلى الشاشات الأصغر حجمًا. بصفتك مطور تطبيقات، لديك الآن نظام أساسي واحد وإطار عمل واجهة برمجة تطبيقات موحّد يمكّنك من تطوير تطبيقك ونشره باستخدام حزمة APK واحدة توفّر تجربة مستخدم محسّنة للهواتف والأجهزة اللوحية وغيرها، وذلك عند تشغيل الإصدار نفسه من Android، الإصدار Android 4.0 (المستوى 14 من واجهة برمجة التطبيقات) أو الإصدارات الأحدث.

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

نظرة عامة على واجهة برمجة التطبيقات

تقدِّم الأقسام أدناه نظرة عامة فنية على واجهات برمجة التطبيقات الجديدة في نظام التشغيل Android 4.0.

واجهات برمجة التطبيقات الاجتماعية في مقدّم جهات الاتصال

تم توسيع واجهات برمجة تطبيقات جهات الاتصال التي حدّدها مزوّد خدمة ContactsContract لتتيح ميزات جديدة موجَّهة للشبكات الاجتماعية، مثل ملف شخصي لمالك الجهاز وإمكانية دعوة المستخدمين لجهات اتصال فردية إلى الشبكات الاجتماعية المثبَّتة على الجهاز.

الملف الشخصي للمستخدِم

يتضمّن Android الآن ملفًا شخصيًا يمثّل مالك الجهاز، على النحو المحدّد في جدول ContactsContract.Profile. يمكن للتطبيقات الاجتماعية التي تحتفظ بهوية المستخدم المساهمة في بيانات الملف الشخصي للمستخدم من خلال إنشاء إدخال ContactsContract.RawContacts جديد ضمن ContactsContract.Profile. وهذا يعني أنّ جهات الاتصال الأولية التي تمثّل مستخدم الجهاز لا تنتمي إلى الجدول التقليدي لجهات الاتصال الأولية المحدّدة في ContactsContract.RawContacts معرّف الموارد المنتظم (URI)، وبدلاً من ذلك، عليك إضافة جهة اتصال أوّلية للملف الشخصي في الجدول على CONTENT_RAW_CONTACTS_URI. بعد ذلك، يتم تجميع جهات الاتصال الأولية في هذا الجدول في ملف شخصي واحد مرئي للمستخدم ويحمل اسم "أنا".

تتطلب إضافة جهة اتصال أولية جديدة للملف الشخصي الحصول على إذن android.Manifest.permission#WRITE_PROFILE. وبالمثل، للقراءة من جدول الملف الشخصي، يجب عليك طلب الإذن android.Manifest.permission#READ_PROFILE. ومع ذلك، من المفترض ألّا تحتاج معظم التطبيقات إلى قراءة الملف الشخصي للمستخدم، حتى عند المساهمة بالبيانات في الملف الشخصي. قراءة الملف الشخصي للمستخدم هي إذن حساس، ويجب أن تتوقع أن يكون المستخدمون تشكك في التطبيقات التي تطلب ذلك.

دعوة Intent

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

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

صور كبيرة الحجم

يوفّر Android الآن إمكانية التقاط صور عالية الدقة لجهات الاتصال. عند إدخال صورة في أحد سجلات جهات الاتصال، يعالجها النظام يمكنك إضافة صورة كبيرة إلى جهة اتصال عن طريق وضع صورة كبيرة في عمود PHOTO المعتاد من صف البيانات، وعندئذٍ سيعالجها النظام في الصورة المصغّرة المناسبة ويعرض سجلات الصور.

ملاحظات حول استخدام جهات الاتصال

تتيح لك واجهات برمجة التطبيقات ContactsContract.DataUsageFeedback الجديدة المساعدة في تتبُّع معدّل استخدام المستخدم لطرق معيّنة للتواصل مع المستخدمين، مثل معدّل استخدام المستخدم لكل رقم هاتف أو عنوان بريد إلكتروني. تساعد هذه المعلومات في تحسين ترتيب كل طريقة اتصال مرتبطة بكل شخص، وتقديم اقتراحات أفضل للاتصال بكل شخص.

موفّر التقويم

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

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

يحدّد CalendarContract نموذج بيانات التقاويم والمعلومات المتعلقة بالأحداث في "موفّر التقويم". يتم تخزين جميع بيانات تقويم المستخدم في عدد من الجداول التي تحدّدها فئات فرعية مختلفة من CalendarContract:

  • يحتوي الجدول CalendarContract.Calendars على المعلومات الخاصة بالتقويم. يحتوي كل صف في هذا الجدول على تفاصيل تقويم واحد، مثل الاسم واللون ومعلومات المزامنة وما إلى ذلك.
  • يحتوي الجدول CalendarContract.Events على معلومات خاصة بالأحداث. ويحتوي كل صف في هذا الجدول على معلومات عن حدث واحد، مثل عنوان الحدث وموقعه الجغرافي ووقت البدء ووقت الانتهاء وغير ذلك. يمكن أن يقع الحدث مرة واحدة أو يتكرر عدة مرات. يتم تخزين الضيوف والتذكيرات والخصائص الموسّعة في جداول منفصلة واستخدام _ID الخاص بالحدث لربطهم بالحدث.
  • يحتوي الجدول CalendarContract.Instances على وقت البدء والانتهاء لحالات تكرار الحدث. يمثّل كل صف في هذا الجدول موضع ورود واحد. بالنسبة إلى الأحداث لمرة واحدة، هناك تعيين واحد لواحد للمثيلات بالأحداث. بالنسبة إلى الأحداث المتكررة، يتم إنشاء صفوف متعددة تلقائيًا للتوافق مع التكرارات المتعددة لهذا الحدث.
  • يحتوي جدول CalendarContract.Attendees على معلومات الضيف أو الضيف في الفعالية. ويمثل كل صف ضيفًا واحدًا في الحدث. وهي تحدد نوع الضيف الذي يحضره الشخص ورد الشخص على الحدث.
  • يحتوي الجدول CalendarContract.Reminders على بيانات التنبيهات/الإشعارات. يمثل كل صف تنبيهًا واحدًا لحدث. يمكن أن يتضمن الحدث تذكيرات متعددة. ويتم تحديد عدد التذكيرات لكل حدث في MAX_REMINDERS، والذي يتم ضبطه من خلال محوِّل المزامنة الذي يملك التقويم المعني. يتم تحديد التذكيرات بعدد الدقائق قبل تحديد موعد الحدث، مع تحديد طريقة المنبّه مثل استخدام التنبيه أو البريد الإلكتروني أو رسالة SMS لتذكير المستخدم.
  • يحتوي الجدول CalendarContract.ExtendedProperties على حقول بيانات مبهمة يستخدمها محوّل المزامنة. لا يتخذ المزوّد أي إجراء بشأن العناصر في هذا الجدول باستثناء حذفها عند حذف الأحداث ذات الصلة بها.

للوصول إلى بيانات تقويم مستخدم من خلال موفّر التقويم، يجب أن يطلب تطبيقك إذن READ_CALENDAR (للإذن بالوصول للقراءة) وWRITE_CALENDAR (للإذن بالتعديل).

الغرض من الحدث

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

موفِّر البريد الصوتي

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

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

تحدِّد الفئة VoicemailContract موفّر المحتوى لمقدّم خدمة البريد الصوتي. توفِّر الفئتان الفرعيتان VoicemailContract.Voicemails وVoicemailContract.Status جداول يمكن للتطبيقات من خلالها إدراج بيانات البريد الصوتي لتخزينها على الجهاز. للاطّلاع على مثال عن تطبيق مزوِّد خدمة البريد الصوتي، يُرجى الاطّلاع على العرض التوضيحي لموفِّر خدمة البريد الصوتي.

وسائط متعددة

يضيف Android 4.0 العديد من واجهات برمجة التطبيقات الجديدة للتطبيقات التي تتفاعل مع الوسائط مثل الصور والفيديوهات والموسيقى.

تأثيرات الوسائط

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

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

  1. يجب ربطها بصورة زخرفة GL_TEXTURE_2D
  2. يجب أن تحتوي الملفات على مستوى mipmap واحد على الأقل.

يحدّد الكائن Effect تأثير وسائط واحدًا يمكنك تطبيقه على إطار صورة. الخطوات الأساسية لإنشاء Effect هي:

  1. عليك استدعاء EffectContext.createWithCurrentGlContext() من سياق OpenGL ES 2.0.
  2. استخدِم دالة EffectContext المعروضة لاستدعاء EffectContext.getFactory()، والتي تعرض مثيل EffectFactory.
  3. يمكنك استدعاء createEffect()، مع تمريره باسم مؤثّر من @link android.media.effect.Effect}، مثل EFFECT_FISHEYE أو EFFECT_VIGNETTE.

يمكنك تعديل معلَمات التأثير عن طريق استدعاء setParameter() وتمرير اسم مَعلمة وقيمة مَعلمة. يقبل كل نوع من التأثيرات معلمات مختلفة، يتم توثيقها باسم التأثير. على سبيل المثال، تحتوي السمة EFFECT_FISHEYE على معلَمة واحدة للتشويه scale.

لتطبيق أي تأثير على زخرفة، استدعِ apply() على Effect واعرض زخرفة الإدخال، وعرضه وارتفاعه، والهيئة الناتجة. يجب ربط زخرفة الإدخال بصورة زخرفة GL_TEXTURE_2D (يتم ذلك عادةً من خلال استدعاء الدالة glTexImage2D()). يمكنك تقديم مستويات متعددة من mipmap. إذا لم يتم ربط زخرفة الإخراج بصورة زخرفة، سيتم ربطها تلقائيًا بالتأثير كـ GL_TEXTURE_2D وبمستوى mipmap واحد (0)، سيكون له نفس حجم الإدخال.

نضمن توافق جميع التأثيرات المدرَجة في "EffectFactory". يُرجى العِلم أنّ بعض التأثيرات الإضافية المتاحة من المكتبات الخارجية لا تتوافق مع جميع الأجهزة، لذا عليك أولاً التحقّق مما إذا كان التأثير المطلوب من المكتبة الخارجية متوافقًا مع التطبيق عن طريق استدعاء isEffectSupported().

عميل جهاز التحكّم عن بُعد

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

لتفعيل برامج التحكم عن بُعد لمشغّل الوسائط، يمكنك إنشاء مثيل RemoteControlClient باستخدام الدالة الإنشائية، وتمريره PendingIntent الذي يبث ACTION_MEDIA_BUTTON. يجب أن يعلن الغرض أيضًا عن مكوِّن BroadcastReceiver الصريح في تطبيقك والذي يعالج حدث ACTION_MEDIA_BUTTON.

للإشارة إلى إدخالات التحكّم في الوسائط التي يمكن للمشغّل استخدامها، يجب استدعاء setTransportControlFlags() على RemoteControlClient، وتمرير مجموعة من علامات FLAG_KEY_MEDIA_*، مثل FLAG_KEY_MEDIA_PREVIOUS وFLAG_KEY_MEDIA_NEXT.

يجب بعد ذلك تسجيل RemoteControlClient من خلال تمريره إلى MediaManager.registerRemoteControlClient(). بعد التسجيل، سيتلقّى جهاز استقبال البث الذي أشرت إليه عند إنشاء مثيل RemoteControlClient أحداث ACTION_MEDIA_BUTTON عند الضغط على زر من وحدة التحكّم عن بُعد. يتضمن الغرض الذي تتلقّاه KeyEvent لمفتاح الوسائط الذي تم الضغط عليه، والذي يمكنك استرداده من الغرض باستخدام getParcelableExtra(Intent.EXTRA_KEY_EVENT).

لعرض معلومات على وحدة التحكّم عن بُعد عن الوسائط قيد التشغيل، يمكنك الاتصال بجهة الاتصال editMetaData() وإضافة بيانات وصفية إلى الصفحة RemoteControlClient.MetadataEditor التي تم إرجاعها. ويمكنك توفير صورة نقطية لأعمال فنية وسائط ومعلومات رقمية مثل الوقت المنقضي والمعلومات النصية مثل عنوان المقطع الصوتي. للحصول على معلومات عن المفاتيح المتاحة، يُرجى الاطّلاع على علامات METADATA_KEY_* في MediaMetadataRetriever.

للاطّلاع على نموذج لعملية التنفيذ، راجع مشغِّل الموسيقى العشوائي الذي يوفّر منطق التوافق بحيث يفعّل برنامج التحكّم عن بُعد على الأجهزة التي تعمل بالإصدار 4.0 من نظام التشغيل Android مع الاستمرار في إتاحة الأجهزة مع العودة إلى الإصدار 2.1 من نظام التشغيل Android.

مشغّل الوسائط

  • يتطلب بث الوسائط على الإنترنت من MediaPlayer الآن الحصول على إذن INTERNET. إذا كنت تستخدم MediaPlayer لتشغيل محتوى من الإنترنت، احرص على إضافة إذن INTERNET إلى ملف البيان وإلا لن تعمل الوسائط التي سيتم تشغيلها بدءًا من الإصدار Android 4.0.
  • تسمح لك السمة setSurface() بتحديد Surface للعمل في مستودع الفيديو.
  • يتيح لك setDataSource() إرسال عناوين HTTP إضافية مع طلبك، ما قد يكون مفيدًا للبث المباشر عبر بروتوكول HTTP(S)
  • يحترم البث المباشر عبر بروتوكول HTTP(S) الآن ملفات تعريف ارتباط HTTP في جميع الطلبات.

أنواع الوسائط

يدعم Android 4.0 ما يلي:

  • الإصدار الثالث من بروتوكول البث المباشر عبر HTTP/HTTPS
  • ترميز الصوت AAC الأولي من ADTS
  • صور WebP
  • فيديو Matroska

لمزيد من المعلومات، يُرجى الاطّلاع على تنسيقات الوسائط المتوافقة.

الكاميرا

تتضمن فئة Camera الآن واجهات برمجة تطبيقات لرصد الوجوه والتحكم في مناطق التركيز وقياس الأداء.

التعرّف على الوجه

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

لاكتشاف الوجوه في تطبيق الكاميرا، يجب تسجيل Camera.FaceDetectionListener من خلال الاتصال بـ setFaceDetectionListener(). يمكنك بعد ذلك بدء سطح الكاميرا وبدء رصد الوجوه عن طريق الاتصال بـ startFaceDetection().

عندما يرصد النظام وجهًا أو أكثر في مشهد الكاميرا، يطلب استدعاء onFaceDetection() عند تنفيذ Camera.FaceDetectionListener، بما في ذلك مصفوفة من Camera.Face عناصر.

يوفّر مثيل الفئة Camera.Face معلومات مختلفة حول الوجه الذي تم رصده، بما في ذلك:

  • Rect يحدّد حدود الوجه بالنسبة إلى مجال الرؤية الحالي للكاميرا
  • عدد صحيح بين 1 و100 يشير إلى مدى ثقة النظام في أن الكائن هو وجه بشري
  • معرّف فريد يتيح لك تتبُّع عدة وجوه
  • العديد من عناصر Point التي تشير إلى موضع العينَين والفم

ملاحظة:قد لا تكون ميزة "التعرّف على الوجه" متوافقة مع بعض الأجهزة، لذا يجب التحقّق من خلال الاتصال بـ getMaxNumDetectedFaces() والتأكد من أنّ القيمة المعروضة أكبر من صفر. بالإضافة إلى ذلك، قد لا تتيح بعض الأجهزة التعرّف على العينَين والفم، وفي هذه الحالة، ستكون هذه الحقول في الكائن Camera.Face فارغة.

مناطق التركيز وقياس الأداء

يمكن لتطبيقات الكاميرا الآن التحكم في المناطق التي تستخدمها الكاميرا للتركيز ولقياس توازن اللون الأبيض والتعرّض التلقائي للضوء. تستخدم كلتا الميزتَين الفئة Camera.Area الجديدة لتحديد منطقة العرض الحالية للكاميرا التي يجب التركيز عليها أو قياسها. من خلال مثال الفئة Camera.Area، يتم تحديد حدود المنطقة باستخدام Rect ووزن المنطقة، ما يمثّل مستوى أهمية هذه المنطقة مقارنةً بالمناطق الأخرى في الاعتبار باستخدام عدد صحيح.

قبل ضبط منطقة التركيز أو منطقة قياس حصة القراءة، يجب أولاً الاتصال بـ "getMaxNumFocusAreas()" أو "getMaxNumMeteringAreas()"، على التوالي. وإذا كان ناتج هذه القيمة صفرًا، فهذا يعني أنّ الجهاز لا يتيح الميزة المقابلة.

لتحديد مناطق التركيز أو قياس حصة القراءة المجانية التي تريد استخدامها، ما عليك سوى الاتصال بـ setFocusAreas() أو setMeteringAreas(). ويأخذ كل عنصر List من Camera.Area عنصر يشير إلى المناطق التي يجب التركيز عليها أو قياس حصة القراءة المجانية. على سبيل المثال، يمكنك تنفيذ ميزة تسمح للمستخدم بضبط منطقة التركيز من خلال لمس منطقة من المعاينة، والتي تترجمها بعد ذلك إلى عنصر Camera.Area وتطلب من الكاميرا التركيز على تلك المنطقة من المشهد. وسيتم تحديث التركيز أو التعرض للضوء في هذه المنطقة باستمرار مع تغير المشهد في المنطقة.

تركيز تلقائي مستمر للصور

يمكنك الآن تفعيل التركيز التلقائي المستمر (CAF) عند التقاط الصور. لتفعيل CAF في تطبيق الكاميرا، عليك تمرير FOCUS_MODE_CONTINUOUS_PICTURE إلى setFocusMode(). عندما تكون مستعدًا لالتقاط صورة، اتصل بـ autoFocus(). ستتلقّى "Camera.AutoFocusCallback" معاودة الاتصال على الفور للإشارة إلى ما إذا كان قد تم توفير التركيز. لاستئناف CAF بعد تلقّي معاودة الاتصال، عليك الاتصال برقم cancelAutoFocus().

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

ميزات الكاميرا الأخرى

  • أثناء تسجيل الفيديو، يمكنك الآن الاتصال برقم takePicture() لحفظ صورة بدون مقاطعة جلسة الفيديو. وقبل إجراء ذلك، عليك الاتصال بـ isVideoSnapshotSupported() للتأكّد من أنّ الأجهزة تتوافق مع هذه الميزة.
  • يمكنك الآن قفل التعرض التلقائي وموازنة اللون الأبيض باستخدام setAutoExposureLock() وsetAutoWhiteBalanceLock() لمنع تغيير هذه الخصائص.
  • يمكنك الآن الاتصال بـ setDisplayOrientation() أثناء تشغيل معاينة الكاميرا. في السابق، كان بإمكانك استدعاء هذا فقط قبل بدء المعاينة، ولكن يمكنك الآن تغيير الاتجاه في أي وقت.

أهداف بث الكاميرا

  • Camera.ACTION_NEW_PICTURE: تشير هذه الرسالة إلى أنّ المستخدم قد التقط صورة جديدة. يستدعي تطبيق الكاميرا المُدمَج عملية البث هذه بعد التقاط صورة، ويجب أيضًا أن تبث تطبيقات الكاميرا التابعة لجهة خارجية هذا الغرض بعد التقاط صورة.
  • Camera.ACTION_NEW_VIDEO: تشير هذه الرسالة إلى أنّ المستخدم قد التقط فيديو جديدًا. يستدعي تطبيق الكاميرا المُدمَج عملية البث هذه بعد تسجيل الفيديو، ويجب أيضًا أن تبث تطبيقات الكاميرا التابعة لجهة خارجية هذا الغرض بعد التقاط فيديو.

شعاع Android (NDEF Push مع NFC)

شعاع Android هي ميزة جديدة من ميزات NFC تتيح لك إرسال رسائل NDEF من جهاز إلى آخر (عملية تُعرف أيضًا باسم "NDEF Push"). تبدأ عملية نقل البيانات عندما يكون جهازان يعملان بنظام التشغيل Android ويتوافقان مع ميزة "شعاع Android" بالقرب من الجهازَين (حوالي 4 سم)، وعادة ما يتلامس الجهازان مع ظهرَيهما. قد تحتوي البيانات داخل رسالة NDEF على أي بيانات تريد مشاركتها بين الأجهزة. على سبيل المثال، يشارك تطبيق الأشخاص جهات الاتصال، ويشارك YouTube الفيديوهات، ويشارك المتصفّح عناوين URL باستخدام شعاع Android.

لنقل البيانات بين الأجهزة باستخدام ميزة "شعاع Android"، يجب إنشاء NdefMessage يحتوي على المعلومات التي تريد مشاركتها عندما يكون نشاطك في المقدّمة. يجب بعد ذلك تمرير NdefMessage إلى النظام بإحدى الطريقتَين التاليتَين:

  • حدِّد NdefMessage واحد لدفعه أثناء النشاط:

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

  • حدِّد NdefMessage المطلوب إرساله في وقت بدء شعاع Android:

    نفِّذ NfcAdapter.CreateNdefMessageCallback، حيث يؤدي تنفيذ الطريقة createNdefMessage() إلى عرض NdefMessage الذي تريد إرساله. بعد ذلك، عليك تمرير عملية تنفيذ NfcAdapter.CreateNdefMessageCallback إلى setNdefPushMessageCallback().

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

إذا أردت تشغيل رمز معيَّن بعد أن يُسلّم النظام رسالة NDEF بنجاح إلى الجهاز الآخر، يمكنك استخدام العلامة NfcAdapter.OnNdefPushCompleteCallback وضبطها باستخدام setNdefPushCompleteCallback(). سيتصل النظام بعد ذلك بـ onNdefPushComplete() عند تسليم الرسالة.

يرسل النظام على الجهاز المستلِم رسائل NDEF Push بطريقة مشابهة لعلامات NFC العادية. يستدعي النظام غرضًا من خلال الإجراء ACTION_NDEF_DISCOVERED لبدء نشاط، وذلك من خلال ضبط عنوان URL أو نوع MIME وفقًا لأول NdefRecord في NdefMessage. بالنسبة إلى النشاط الذي تريد الردّ عليه، يمكنك توضيح فلاتر الأهداف لعناوين URL أو أنواع MIME التي يهتم بها تطبيقك. لمزيد من المعلومات حول ميزة "إرسال العلامات"، اطّلِع على دليل المطوِّر حول الاتصال القصير المدى (NFC).

إذا كنت تريد أن يتضمن NdefMessage عنوان URI، يمكنك الآن استخدام الطريقة المناسبة createUri لإنشاء NdefRecord جديد استنادًا إلى سلسلة أو كائن Uri. إذا كان معرّف الموارد المنتظم (URI) هو تنسيق خاص تريد أن يتلقّاه تطبيقك أيضًا أثناء حدث شعاع Android، عليك إنشاء فلتر أهداف لنشاطك باستخدام نظام معرِّف الموارد المنتظم (URI) نفسه من أجل تلقّي رسالة NDEF الواردة.

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

إذا كان تطبيقك لا يستخدم واجهات برمجة تطبيقات NFC لتنفيذ المراسلة الفورية من خلال NDEF، سيتّبع Android سلوكًا تلقائيًا: عندما يكون تطبيقك في المقدّمة على أحد الأجهزة ويتم استدعاء شعاع Android مع جهاز آخر يعمل بنظام التشغيل Android، سيتلقَّى الجهاز الآخر رسالة NDEF تتضمّن سجلّ تطبيق Android يحدِّد تطبيقك. إذا كان التطبيق المُستلِم مثبّتًا على الجهاز، يشغِّله النظام، وإذا لم يكن مثبّتًا، يفتح Google Play وينقل المستخدم إلى تطبيقك لتثبيته.

يمكنك قراءة مزيد من المعلومات حول ميزة "شعاع Android" وميزات NFC الأخرى في دليل المطوِّر حول أساسيات NFC. للحصول على بعض أمثلة الرموز باستخدام شعاع Android، شاهد العرض التوضيحي لميزة شعاع Android.

اتصال Wi-Fi P2P

يتيح Android الآن الاتصالات من نظير إلى نظير (P2P) عبر شبكة Wi-Fi بين الأجهزة التي تعمل بنظام التشغيل Android وأنواع الأجهزة الأخرى (وفقًا لبرنامج اعتماد Wi-Fi DirectTM) التابع لتحالف Wi-Fi Alliance بدون نقطة اتصال أو اتصال بالإنترنت. يوفّر إطار عمل Android مجموعة من واجهات برمجة التطبيقات Wi-Fi P2P التي تسمح لك باكتشاف الأجهزة الأخرى والاتصال بها عندما يتيح كل جهاز استخدام اتصال Wi-Fi P2P، ثم التواصل عبر اتصال سريع على مسافات أطول بكثير من اتصال البلوتوث.

تحتوي الحزمة الجديدة android.net.wifi.p2p على جميع واجهات برمجة التطبيقات لإجراء الاتصالات من نظير إلى نظير باستخدام Wi-Fi. الصف الأساسي الذي عليك العمل معه هو WifiP2pManager، ويمكنك الحصول عليه من خلال طلب الرقم getSystemService(WIFI_P2P_SERVICE). يتضمّن WifiP2pManager واجهات برمجة تطبيقات تتيح لك ما يلي:

  • عليك إعداد تطبيقك لاتصالات P2P من خلال الاتصال بـ initialize().
  • استكشاف الأجهزة المجاورة من خلال الاتصال برقم discoverPeers()
  • يمكنك بدء اتصال من نظير لنظير (P2P) من خلال الاتصال بـ connect().
  • والمزيد

يلزم كذلك استخدام عدة واجهات وفئات أخرى، مثل:

  • تتيح لك واجهة WifiP2pManager.ActionListener تلقّي طلبات معاودة الاتصال عندما تنجح عملية، مثل اكتشاف التطبيقات المشابهة أو الاتصال بهم، في حال نجاحها أو تعذُّر إكمالها.
  • تتيح لك واجهة WifiP2pManager.PeerListListener بتلقي معلومات حول التطبيقات المشابهة التي تم اكتشافها. يوفر معاودة الاتصال WifiP2pDeviceList التي يمكنك من خلالها استرداد كائن WifiP2pDevice لكل جهاز ضمن النطاق والحصول على معلومات، مثل اسم الجهاز والعنوان ونوع الجهاز وإعدادات WPS المتوافقة مع الجهاز والمزيد.
  • تسمح لك واجهة WifiP2pManager.GroupInfoListener بتلقّي معلومات حول مجموعة P2P. يوفّر رد الاتصال عنصر WifiP2pGroup الذي يوفّر معلومات المجموعة، مثل المالك واسم الشبكة وعبارة المرور.
  • تتيح لك واجهة WifiP2pManager.ConnectionInfoListener تلقّي معلومات حول الاتصال الحالي. توفّر معاودة الاتصال عنصر WifiP2pInfo يحتوي على معلومات، مثلاً ما إذا تم إنشاء المجموعة ومالك المجموعة.

لاستخدام واجهات برمجة التطبيقات Wi-Fi P2P، يجب أن يطلب تطبيقك أذونات المستخدم التالية:

  • ACCESS_WIFI_STATE
  • CHANGE_WIFI_STATE
  • INTERNET (على الرغم من أن تطبيقك لا يتصل بالإنترنت من الناحية الفنية إلا أنّ الاتصال بنظراء اتصال Wi-Fi من نظير لنظير (P2P) باستخدام مقابس جافا العادية يتطلب إذنًا بالإنترنت).

يبث نظام Android أيضًا العديد من الإجراءات المختلفة أثناء أحداث معينة عبر شبكة Wi-Fi من نظير لنظير (P2P):

يمكنك الاطّلاع على مستندات WifiP2pManager للحصول على مزيد من المعلومات. اطلع أيضًا على نموذج تطبيق Wi-Fi P2P التجريبي.

أجهزة Bluetooth Health

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

على غرار سماعات الرأس العادية وأجهزة الملف الشخصي لـ A2DP، عليك استدعاء getProfileProxy() باستخدام نوع الملف الشخصي BluetoothProfile.ServiceListener ونوع الملف الشخصي HEALTH لإنشاء اتصال بكائن الخادم الوكيل للملف الشخصي.

بعد الحصول على الخادم الوكيل لملف Health الشخصي (كائن BluetoothHealth)، يتضمن الاتصال بالأجهزة الصحية المقترنة والتواصل معها فئات البلوتوث الجديدة التالية:

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

لمزيد من المعلومات حول استخدام الملف الشخصي لتطبيق Bluetooth Health، يمكنك الاطّلاع على مستندات BluetoothHealth.

تسهيل الاستخدام

يحسّن Android 4.0 إمكانية الوصول للمستخدمين ذوي العجز البصري من خلال وضع "الاستكشاف باللمس" الجديد وواجهات برمجة التطبيقات الموسّعة التي تتيح لك توفير المزيد من المعلومات حول محتوى العرض أو تطوير خدمات متقدّمة لتسهيل الاستخدام.

وضع الاستكشاف باللمس

يمكن للمستخدمين المصابين بفقدان البصر الآن استكشاف الشاشة عن طريق لمس وسحب إصبع على الشاشة لسماع الأوصاف الصوتية للمحتوى. وبما أنّ وضع "الاستكشاف باللمس" يعمل كمؤشر افتراضي، فإنّه يسمح لقارئي الشاشة بتحديد النص الوصفي بالطريقة نفسها التي تتّبعها برامج قراءة الشاشة عندما يتنقّل المستخدم باستخدام لوحة التحكّم أو كرة التعقب، وذلك من خلال قراءة المعلومات المقدَّمة من android:contentDescription وsetContentDescription() عند إجراء محاكاة لحدث "التمرير". هذا تذكير بضرورة تقديم نص وصفي لطرق العرض في تطبيقك، خاصةً ImageButton وEditText وImageView والتطبيقات المصغّرة الأخرى التي قد لا تحتوي بشكل طبيعي على نص وصفي.

تسهيل استخدام المشاهدات

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

تجدر الإشارة أولاً إلى أنّ سلوك طريقة sendAccessibilityEvent() قد تغيّر في الإصدار Android 4.0. كما هو الحال في الإصدار السابق من Android، عندما يفعِّل المستخدم خدمات تسهيل الاستخدام على الجهاز وحدث إدخال مثل النقر أو التمرير، يتم إرسال إشعار إلى شاشة العرض المعنيّة عن طريق الاتصال بالرقم sendAccessibilityEvent(). في السابق، كان تنفيذ sendAccessibilityEvent() يؤدي إلى ضبط AccessibilityEvent وإرساله إلى AccessibilityManager. يتضمن السلوك الجديد بعض أساليب معاودة الاتصال الإضافية التي تسمح للعرض والعناصر الرئيسية بإضافة المزيد من المعلومات السياقية إلى الحدث:

  1. عند طلب البيانات، يتم تأجيل الإجراءين sendAccessibilityEvent() وsendAccessibilityEventUnchecked() إلى onInitializeAccessibilityEvent().

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

  2. بعد الانتهاء من الإعداد، إذا كان الحدث من بين أنواع متعدّدة يجب تعبئتها بمعلومات نصية، سيتلقّى العرض بعد ذلك استدعاءً إلى dispatchPopulateAccessibilityEvent()، ما يؤدي إلى تأجيل الزحف إلى استدعاء onPopulateAccessibilityEvent().

    في عمليات التنفيذ المخصّصة للسمة View، يجب عادةً تنفيذ الإجراء onPopulateAccessibilityEvent() لإضافة محتوى نصي إضافي إلى AccessibilityEvent في حال كان نص android:contentDescription غير متوفّر أو غير كافٍ. لإضافة المزيد من الوصف النصي إلى AccessibilityEvent، يمكنك الاتصال بـ getText().add().

  3. في هذه المرحلة، تمرّر علامة View الحدث إلى أعلى التسلسل الهرمي لطريقة العرض من خلال استدعاء requestSendAccessibilityEvent() في العرض الرئيسي. بعد ذلك، يمكن لكل طريقة عرض رئيسية زيادة معلومات تسهيل الاستخدام من خلال إضافة السمة AccessibilityRecord حتى تصل في النهاية إلى العرض الجذر، ما يؤدي إلى إرسال الحدث إلى AccessibilityManager باستخدام sendAccessibilityEvent().

بالإضافة إلى الطرق الجديدة المذكورة أعلاه والتي تكون مفيدة عند توسيع الفئة View، يمكنك أيضًا اعتراض عمليات استدعاء الأحداث هذه على أي View من خلال توسيع نطاق AccessibilityDelegate وإعداده في العرض باستخدام setAccessibilityDelegate(). عند إجراء ذلك، تعمل كل طريقة من طرق تسهيل الاستخدام في طريقة العرض على تأجيل المكالمة إلى الطريقة المناسبة في المفوَّض. على سبيل المثال، عندما تتلقى المشاهدة استدعاء إلى onPopulateAccessibilityEvent()، يتم تمريرها إلى الطريقة نفسها في View.AccessibilityDelegate. يتم إعطاء أي طرق لا يتعامل معها المفوّض مباشرةً إلى طريقة عرض السلوك الافتراضي. ويتيح لك هذا الإجراء تجاهل الطرق اللازمة فقط لأي طريقة عرض محدّدة بدون توسيع فئة View.

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

خدمات إمكانية الدخول

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

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

  1. بعد تلقّي AccessibilityEvent من أحد التطبيقات، يمكنك استدعاء AccessibilityEvent.getRecord() لاسترداد AccessibilityRecord محدّد (قد تكون هناك عدة سجلّات مرفقة بالحدث).
  2. من AccessibilityEvent أو AccessibilityRecord فردي، يمكنك استدعاء getSource() لاسترداد كائن AccessibilityNodeInfo.

    تمثّل السمة AccessibilityNodeInfo عقدة واحدة من محتوى النافذة بتنسيق يسمح لك بالاستعلام عن معلومات تسهيل الاستخدام حول تلك العقدة. يصف الكائن AccessibilityNodeInfo الذي يتم عرضه من AccessibilityEvent مصدر الحدث، في حين يصف المصدر من AccessibilityRecord المصدر السابق لمصدر الحدث.

  3. باستخدام AccessibilityNodeInfo، يمكنك طلب معلومات عنه، واستدعاء getParent() أو getChild() لاجتياز العرض الهرمي، وإضافة طرق عرض فرعية إلى العقدة.

لكي ينشر تطبيقك نفسه على النظام كخدمة لتسهيل الاستخدام، يجب أن يعلن عن ملف إعداد XML يتوافق مع AccessibilityServiceInfo. لمزيد من المعلومات حول إنشاء خدمة لتسهيل الاستخدام، يمكنك الاطّلاع على AccessibilityService وSERVICE_META_DATA للحصول على معلومات حول ضبط XML.

واجهات برمجة التطبيقات الأخرى لإمكانية الوصول

إذا كنت مهتمًا بحالة إمكانية الوصول للجهاز، يتضمّن AccessibilityManager بعض واجهات برمجة التطبيقات الجديدة، مثل:

خدمات المدقق الإملائي

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

يجب أن تعلن التطبيقات التي تستخدم خدمة المدقق الإملائي عن إذن BIND_TEXT_SERVICE على النحو الذي تتطلبه الخدمة. يجب أن تذكر الخدمة أيضًا فلتر الأهداف مع تحديد <action android:name="android.service.textservice.SpellCheckerService" /> باعتباره الإجراء المطلوب وأن تتضمّن عنصر <meta-data> يوضّح معلومات الإعداد للمدقق الإملائي.

يمكنك الاطّلاع على نموذج من تطبيق خدمة المدقق الإملائي ونموذج تطبيق عميل المدقق الإملائي للحصول على مثال عن الرمز البرمجي.

محركات تحويل النص إلى كلام

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

استخدام محركات تحويل النص إلى كلام

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

يمكنك أيضًا طلب البحث عن محركات TTS المتاحة باستخدام getEngines(). تعرض هذه الطريقة قائمة بكائنات TextToSpeech.EngineInfo التي تتضمّن بيانات وصفية مثل رمز المحرّك والعلامة واسم الحزمة.

إنشاء محركات تحويل النص إلى كلام

في السابق، كانت المحركات المخصّصة تتطلب إنشاء المحرك باستخدام ملف رأس أصلي غير موثق. في نظام Android 4.0، توجد مجموعة كاملة من واجهات برمجة التطبيقات لإطار العمل لإنشاء محركات تقنية TTS.

يتطلّب الإعداد الأساسي تنفيذ دالة TextToSpeechService تتوافق مع هدف INTENT_ACTION_TTS_SERVICE. يحدث العمل الأساسي لمحرك تحويل النص إلى كلام أثناء معاودة الاتصال بـ onSynthesizeText() في الخدمة التي تمد TextToSpeechService. يسلم النظام كائنين في هذه الطريقة:

  • SynthesisRequest: يتضمّن ذلك بيانات مختلفة تشمل النص المطلوب تجميعه واللغة المحلية ومعدّل سرعة الكلام ودرجة الصوت.
  • SynthesisCallback: هذه هي الواجهة التي يعرض من خلالها محرك TTS بيانات الكلام الناتجة كبث صوتي. أولاً، يجب أن يتصل المحرّك بـ start() للإشارة إلى أنّ المحرّك جاهز لإرسال الصوت، ثم يتصل بـ audioAvailable()، لتمريره البيانات الصوتية إلى مخزن بايت للبايت. بعد أن يجتاز المحرّك كل الصوت عبر المخزن المؤقت، اتصل بـ done().

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

للاطّلاع على مثال لمحرك تحويل النص إلى كلام يستخدم واجهات برمجة التطبيقات الجديدة، يُرجى مراجعة نموذج التطبيق محرك تحويل النص إلى كلام.

إحصاءات استخدام الشبكة

يمنح Android 4.0 المستخدمين مستوى رؤية دقيقًا لحجم بيانات الشبكة التي تستخدمها تطبيقاتهم. يوفر تطبيق "الإعدادات" عناصر تحكم تسمح للمستخدمين بإدارة الحدود المعينة لاستخدام بيانات الشبكة وحتى إيقاف استخدام بيانات الخلفية لتطبيقات فردية. ولتجنب تعطيل المستخدمين للوصول إلى تطبيقك من الخلفية، يجب عليك وضع استراتيجيات لاستخدام اتصال البيانات بكفاءة وضبط استخدامك اعتمادًا على نوع الاتصال المتاح.

إذا كان تطبيقك يجري الكثير من معاملات الشبكة، يجب توفير إعدادات للمستخدم تسمح له بالتحكّم في عادات استخدام التطبيق للبيانات، مثل معدّل مزامنة التطبيق للبيانات، وما إذا كان يجب إجراء عمليات تحميل أو تنزيل فقط عند الاتصال بشبكة Wi-Fi، وما إذا كان يجب استخدام البيانات أثناء التجوال، وما إلى ذلك. ومع توفُّر عناصر التحكّم هذه، يقلّ احتمال إيقاف وصول تطبيقك إلى البيانات عند اقترابه من الحدّ الأقصى لاستخدام البيانات، إذ يمكنهم بدلاً من ذلك استخدام الحدود القصوى للبيانات. في حال تقديم نشاط مفضّل باستخدام هذه الإعدادات، عليك تضمين فلتر أهداف للإجراء ACTION_MANAGE_NETWORK_USAGE في بيان البيان. مثلاً:

<activity android:name="DataPreferences" android:label="@string/title_preferences">
    <intent-filter>
       <action android:name="android.intent.action.MANAGE_NETWORK_USAGE" />
       <category android:name="android.intent.category.DEFAULT" />
    </intent-filter>
</activity>

ويوضح فلتر الأهداف هذا للنظام أن هذا هو النشاط الذي يتحكّم في استخدام البيانات في تطبيقك. وبالتالي، عندما يفحص المستخدم مقدار البيانات التي يستخدمها تطبيقك من تطبيق "الإعدادات"، يتوفّر زر "عرض إعدادات التطبيق" يُطلق نشاطك المفضّل حتى يتمكّن المستخدم من تحسين مقدار البيانات التي يستخدمها تطبيقك.

عليك أيضًا الانتباه إلى أنّ سياسة getBackgroundDataSetting() متوقّفة نهائيًا وتعرض القيمة "صحيح" دائمًا، ويمكنك استخدام السمة getActiveNetworkInfo() بدلاً منها. قبل إجراء أي معاملات عبر الشبكة، يجب دائمًا طلب الرمز getActiveNetworkInfo() للحصول على NetworkInfo التي تمثّل الشبكة الحالية وطلب البحث عن isConnected() للتحقق مما إذا كان الجهاز متصلاً أم لا. يمكنك بعد ذلك التحقق من خصائص الاتصال الأخرى، مثل ما إذا كان الجهاز في حالة التجوال أو متصلاً بشبكة Wi-Fi.

Enterprise

يوسّع Android 4.0 إمكانيات تطبيقات المؤسسات باستخدام الميزات التالية.

خدمات VPN

تتيح سياسة VpnService الجديدة للتطبيقات إنشاء شبكة افتراضية خاصة (VPN) تعمل باسم Service. تنشئ خدمة الشبكة الافتراضية الخاصة واجهة لشبكة افتراضية تحتوي على عناوينها وقواعد توجيه خاصة بها وتُجري جميع عمليات القراءة والكتابة باستخدام واصف ملف.

لإنشاء خدمة شبكة VPN، استخدِم السمة VpnService.Builder التي تتيح لك تحديد عنوان الشبكة وخادم نظام أسماء النطاقات ومسار الشبكة وغير ذلك. عند الانتهاء، يمكنك إنشاء الواجهة عن طريق استدعاء establish()، الذي يعرض ParcelFileDescriptor.

بما أنّ خدمة VPN يمكنها اعتراض حِزم البيانات، قد تكون هناك بعض التداعيات الأمنية. وبالتالي، إذا كنت تنفّذ VpnService، يجب أن تطلب خدمتك من BIND_VPN_SERVICE لضمان أنّ النظام فقط هو من يمكنه ربطه بها (ولن يتم منح هذا الإذن إلا للنظام، ولا يمكن للتطبيقات طلبه). لاستخدام خدمة VPN بعد ذلك، على المستخدمين تفعيلها يدويًا من خلال إعدادات النظام.

سياسات الأجهزة

يمكن الآن للتطبيقات التي تدير قيود الجهاز إيقاف الكاميرا باستخدام setCameraDisabled() والسمة USES_POLICY_DISABLE_CAMERA (التي يتم تطبيقها مع العنصر <disable-camera /> في ملف ضبط السياسة).

إدارة الشهادات

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

أجهزة استشعار الجهاز

تمت إضافة نوعين جديدين من أجهزة الاستشعار في Android 4.0:

  • TYPE_AMBIENT_TEMPERATURE: جهاز استشعار الحرارة الذي يوفر درجة الحرارة المحيطة (الغرفة) بالدرجات المئوية.
  • TYPE_RELATIVE_HUMIDITY: جهاز استشعار للرطوبة يوفّر نسبة الرطوبة النسبية في البيئة المحيطة (الغرفة)

إذا كان الجهاز يحتوي على كل من المستشعرَين TYPE_AMBIENT_TEMPERATURE وTYPE_RELATIVE_HUMIDITY، يمكنك استخدامهما لحساب نقطة الندى والرطوبة المطلقة.

تم إيقاف جهاز استشعار الحرارة السابق TYPE_TEMPERATURE نهائيًا. يجب استخدام أداة استشعار TYPE_AMBIENT_TEMPERATURE بدلاً من ذلك.

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

شريط الإجراءات

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

تقسيم شريط الإجراءات

إذا كان شريط الإجراءات الخاص بك يتضمن العديد من عناصر الإجراءات، فلن يتناسب جميعها مع شريط الإجراءات على شاشة ضيقة، لذلك سيضع النظام المزيد منها في القائمة الكاملة. ومع ذلك، يسمح لك Android 4.0 بتفعيل "شريط إجراءات التقسيم" لكي تظهر المزيد من بنود الإجراءات على الشاشة في شريط منفصل أسفل الشاشة. لتفعيل شريط الإجراءات المقسّم، أضِف علامة android:uiOptions التي تحتوي على العلامة "splitActionBarWhenNarrow" إلى علامة <application> أو علامات <activity> الفردية في ملف البيان. عند تفعيل هذه الميزة، سيضيف النظام شريطًا إضافيًا في أسفل الشاشة لجميع عناصر الإجراءات عندما يكون عرض الشاشة محدودًا (لن تظهر أي بنود إجراءات في شريط الإجراءات الأساسي).

إذا أردت استخدام علامات تبويب التنقّل المتوفّرة من خلال واجهات برمجة تطبيقات ActionBar.Tab، ولكن لا تحتاج إلى شريط الإجراءات الرئيسي في الأعلى (إذا كنت تريد أن تظهر علامات التبويب فقط في أعلى الشاشة)، فعِّل شريط الإجراءات المقسّم على النحو الموضّح أعلاه، ويمكنك أيضًا الطلب من setDisplayShowHomeEnabled(false) لإيقاف رمز التطبيق في شريط الإجراءات. ولا يتبقى أي شيء في شريط الإجراءات الرئيسي، يختفي كل ما يتبقى هو علامات تبويب التنقل في الأعلى وبنود العمل في الجزء السفلي من الشاشة.

أنماط شريط الإجراءات

إذا أردت تطبيق نمط مخصّص على شريط الإجراءات، يمكنك استخدام سمتَي النمط الجديدتَين backgroundStacked وbackgroundSplit لتطبيق لون أو قابل للرسم في الخلفية على الشريط المكدّس والشريط المقسّم، على التوالي. يمكنك أيضًا ضبط هذه الأنماط في وقت التشغيل باستخدام setStackedBackgroundDrawable() وsetSplitBackgroundDrawable().

مقدّم الإجراءات

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

على سبيل المثال، علامة ShareActionProvider هي إضافة للرمز ActionProvider تسهِّل إجراء "مشاركة" من شريط الإجراءات. بدلاً من استخدام بند العمل التقليدي الذي يستدعي هدف ACTION_SEND، يمكنك الاستعانة بمقدّم الإجراء هذا لتقديم عرض إجراء مع قائمة منسدلة من التطبيقات التي تعالج هدف ACTION_SEND. عندما يختار المستخدِم تطبيقًا لاستخدامه للإجراء، يتذكّر ShareActionProvider هذا التحديد ويوفّره في "عرض الإجراء" للوصول بشكلٍ أسرع إلى المشاركة مع ذلك التطبيق.

للإعلان عن موفِّر إجراء لعنصر عمل، يجب تضمين السمة android:actionProviderClass في العنصر <item> لقائمة خيارات نشاطك، مع إضافة اسم فئة موفّر الإجراء كقيمة. مثلاً:

<item android:id="@+id/menu_share"
      android:title="Share"
      android:showAsAction="ifRoom"
      android:actionProviderClass="android.widget.ShareActionProvider" />

في طريقة معاودة الاتصال في onCreateOptionsMenu() لنشاطك، استرِدّ مثيلاً من مقدّم الإجراء من عنصر القائمة وحدِّد النية:

Kotlin

override fun onCreateOptionsMenu(menu: Menu): Boolean {
    menuInflater.inflate(R.menu.options, menu)
    val shareActionProvider = menu.findItem(R.id.menu_share)?.actionProvider as? ShareActionProvider
    // Set the share intent of the share action provider.
    shareActionProvider?.setShareIntent(createShareIntent())
    ...
    return super.onCreateOptionsMenu(menu)
}

Java

public boolean onCreateOptionsMenu(Menu menu) {
    getMenuInflater().inflate(R.menu.options, menu);
    ShareActionProvider shareActionProvider =
          (ShareActionProvider) menu.findItem(R.id.menu_share).getActionProvider();
    // Set the share intent of the share action provider.
    shareActionProvider.setShareIntent(createShareIntent());
    ...
    return super.onCreateOptionsMenu(menu);
}

للحصول على مثال باستخدام ShareActionProvider، يُرجى الاطّلاع على ActionBarShareActionProviderActivity في ApiDemos.

عروض الإجراءات القابلة للتصغير

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

للإشارة إلى أنّ بند عمل يحتوي على عرض إجراء قابل للتصغير، يجب تضمين العلامة “collapseActionView" في السمة android:showAsAction للعنصر <item> في ملف XML للقائمة.

لتلقّي استدعاءات عند تبديل عرض الإجراء بين توسيع عرض إجراء وتصغيره، سجِّل مثيل MenuItem.OnActionExpandListener مع MenuItem ذي الصلة من خلال طلب setOnActionExpandListener(). يجب عادةً إجراء ذلك أثناء معاودة الاتصال بـ "onCreateOptionsMenu()".

للتحكّم في عرض إجراء قابل للتصغير، يمكنك استدعاء collapseActionView() وexpandActionView() على MenuItem المعني.

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

واجهات برمجة التطبيقات الأخرى لشريط الإجراءات

  • تتيح لك علامة setHomeButtonEnabled() تحديد ما إذا كان الرمز/الشعار يعمل كزر للانتقال إلى الصفحة الرئيسية أو الانتقال للأعلى (عليك ضبط الحقل"true" ليكون بمثابة زر).
  • يتيح لك كل من setIcon() وsetLogo() تحديد رمز أو شعار شريط الإجراءات في وقت التشغيل.
  • تتيح لك علامة Fragment.setMenuVisibility() تفعيل أو إيقاف ظهور عناصر قائمة الخيارات التي حدّدها الجزء. يكون هذا مفيدًا إذا تمت إضافة الجزء إلى النشاط، ولكنه غير مرئي، لذلك يجب أن تكون عناصر القائمة مخفية.
  • FragmentManager.invalidateOptionsMenu() يسمح لك بإلغاء صلاحية قائمة خيارات النشاط خلال الحالات المختلفة لدورة حياة الأجزاء التي قد لا تتوفر فيها استخدام الطريقة المكافئة من Activity.

واجهة المستخدم وطرق العرض

يقدم Android 4.0 مجموعة متنوعة من طرق العرض الجديدة ومكونات واجهة المستخدم الأخرى.

تنسيق الشبكة

GridLayout هي مجموعة مشاهدة جديدة تضع عروض الأطفال في شبكة مستطيلة. على عكس TableLayout، يعتمد GridLayout على تسلسل هرمي مسطح ولا يستفيد من طرق العرض المتوسطة مثل صفوف الجدول لتوفير البنية. بدلاً من ذلك، تحدد العناصر الثانوية الصفوف والأعمدة التي يجب أن تشغلها (يمكن أن تمتد الخلايا إلى صفوف و/أو أعمدة متعددة)، ويتم افتراضيًا وضعها بشكل تسلسلي عبر صفوف الشبكة وأعمدتها. ويحدِّد الاتجاه GridLayout ما إذا كان يتم وضع العناصر الثانوية المتسلسلة أفقيًا أو عموديًا تلقائيًا. يمكن تحديد المسافة بين العناصر الثانوية إما باستخدام نُسخ افتراضية من طريقة عرض Space الجديدة أو من خلال ضبط معلَمات الهوامش ذات الصلة على العناصر الثانوية.

يمكنك مراجعة ApiDemos للاطّلاع على نماذج باستخدام GridLayout.

عرض الزخرفة

TextureView هو طريقة عرض جديدة تتيح لك عرض عملية بث المحتوى، مثل فيديو أو مشهد OpenGL. بالرغم من تشابهها مع SurfaceView، فإن TextureView فريدة من حيث أنها تعمل مثل العرض العادي، بدلاً من إنشاء نافذة منفصلة، لذا يمكنك التعامل معها مثل أي كائن View آخر. على سبيل المثال، يمكنك تطبيق التحويلات أو تحريكها باستخدام ViewPropertyAnimator أو ضبط مستوى التعتيم باستخدام setAlpha().

يُرجى الانتباه إلى أنّ TextureView لا تعمل إلا ضمن نافذة تسريع الأجهزة.

لمزيد من المعلومات، اطّلِع على مستندات TextureView.

تبديل التطبيق المصغّر

تطبيق Switch المصغّر الجديد هو مفتاح تبديل ذو حالتين يمكن للمستخدمين سحبه إلى أحد الجانبين (أو النقر عليهما) للتبديل بين حالتين.

يمكنك استخدام السمتَين android:textOn وandroid:textOff لتحديد النص الذي سيظهر على مفتاح التبديل عند تفعيل الإعداد وإيقافه. تتيح لك السمة android:text أيضًا وضع تصنيف بجانب مفتاح التحكّم.

للحصول على نموذج حول استخدام مفاتيح التحكّم، يمكنك الاطّلاع على ملف التنسيق switches.xml ونشاط Switch المعنيَّين.

قدم Android 3.0 ميزة PopupMenu لإنشاء قوائم سياقية قصيرة تظهر عند نقطة الارتساء التي تحددها (عادةً عند العنصر المحدد). يوسع Android 4.0 PopupMenu من خلال بعض الميزات المفيدة:

  • يمكنك الآن تضخيم محتوى قائمة منبثقة بسهولة من مورد قائمة بتنسيق XML باستخدام inflate()، مع تمرير معرّف مورد القائمة له.
  • يمكنك الآن أيضًا إنشاء PopupMenu.OnDismissListener لتلقّي إشعار عند إغلاق القائمة.

الإعدادات المفضّلة

ويتم استخدام فئة مجردة جديدة من TwoStatePreference كأساس للخيارات المفضّلة التي توفّر خيار تحديد الحالة في حالتَين. الإصدار الجديد من SwitchPreference هو إضافة في TwoStatePreference يوفّر التطبيق المصغَّر Switch في عرض الإعدادات المفضّلة للسماح للمستخدمين بتبديل إعداد أو إيقافه بدون الحاجة إلى فتح شاشة أو مربّع حوار إضافيَين للإعدادات المفضّلة. على سبيل المثال، يستخدم تطبيق "الإعدادات" SwitchPreference لإعدادات شبكة Wi-Fi والبلوتوث.

مظاهر النظام

المظهر التلقائي لجميع التطبيقات التي تستهدف Android 4.0 (عن طريق ضبط targetSdkVersion أو minSdkVersion على “14" أو إصدار أحدث) هو الآن المظهر "التلقائي للجهاز": Theme.DeviceDefault. قد يكون هذا هو مظهر Holo الداكن أو مظهرًا داكنًا مختلفًا يتم تحديده بواسطة الجهاز المحدد.

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

إذا أردت أن يندمج تطبيقك مع المظهر العام للجهاز (مثلاً عندما يوفّر مصنِّعون أصليون مختلفون مظاهر تلقائية مختلفة للنظام)، عليك تطبيق المظاهر من مجموعة "Theme.DeviceDefault" صراحةً.

زر قائمة الخيارات

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

لتقديم أفضل تجربة للمستخدم، على التطبيقات الجديدة والمحدَّثة استخدام ActionBar بدلاً من ذلك لتوفير إمكانية الوصول إلى عناصر القائمة، وضبط targetSdkVersion على "14" للاستفادة من أحدث السلوكيات التلقائية لإطار العمل.

عناصر التحكُّم في إمكانية رؤية واجهة مستخدم النظام

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

حتى هذا اليوم، يمكنك إخفاء شريط الحالة على الهواتف المحمولة باستخدام علامة FLAG_FULLSCREEN. في Android 4.0، تم تحديث واجهات برمجة التطبيقات التي تتحكم في مستوى رؤية شريط النظام لتعكس سلوك كل من شريط النظام وشريط التنقل بشكل أفضل:

  • تحل العلامة SYSTEM_UI_FLAG_LOW_PROFILE محل علامة STATUS_BAR_HIDDEN. عند ضبط هذه العلامة، يتم تفعيل وضع "الملف الشخصي المنخفض" لشريط النظام أو شريط التنقل. يتم أيضًا إخفاء أزرار التنقل، كما يتم إخفاء العناصر الأخرى في شريط النظام. يُعد تفعيل هذا الخيار مفيدًا لإنشاء ألعاب أكثر شمولية بدون تشتيت للانتباه لأزرار التنقل في النظام.
  • تحلّ العلامة SYSTEM_UI_FLAG_VISIBLE محلّ علامة STATUS_BAR_VISIBLE لتطلب إظهار شريط النظام أو شريط التنقّل.
  • علامة SYSTEM_UI_FLAG_HIDE_NAVIGATION هي علامة جديدة تطلب إخفاء شريط التنقل تمامًا. يُرجى العلم أن هذا الإجراء لا يعمل إلا مع شريط التنقل الذي تستخدمه بعض الهواتف الذكية (لا يخفي شريط النظام على الأجهزة اللوحية). يعود شريط التنقل للعرض بمجرد أن يتلقى النظام إدخال المستخدم. يُعدّ هذا الوضع مفيدًا بشكل أساسي لتشغيل الفيديو أو غير ذلك من الحالات التي تحتاج فيها الشاشة بأكملها إلى استخدام البيانات التي يدخلها المستخدم.

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

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

يمكنك الاطّلاع على فئة OverscanActivity للحصول على عرض توضيحي للخيارات المختلفة لواجهة مستخدم النظام.

إطار عمل الإدخال

يدعم Android 4.0 أحداث التمرير بالمؤشر والأحداث الجديدة لقلم الشاشة وزر الماوس.

أحداث التمرير

تتيح فئة View الآن أحداث "التمرير" لتفعيل تفاعلات أكثر ثراءً من خلال استخدام أجهزة المؤشر (مثل الماوس أو الأجهزة الأخرى التي تعرض مؤشرًا على الشاشة).

لتلقّي أحداث التمرير على طريقة عرض، نفِّذ View.OnHoverListener وسجله باستخدام setOnHoverListener(). عند وقوع حدث تمرير فوق العرض، يتلقّى المستمع مكالمة إلى الرقم onHover()، مع توفير View الذي استقبل الحدث وMotionEvent يصف نوع حدث التمرير الذي حدث. يمكن أن يكون حدث التمرير أي مما يلي:

من المفترض أن تعرض View.OnHoverListener القيمة "صحيح" من onHover() إذا كانت تعالج حدث التمرير. وإذا عرض المستمع خطأ، سيتم إرسال حدث التمرير إلى طريقة العرض الرئيسية كالمعتاد.

إذا كان تطبيقك يستخدم أزرارًا أو تطبيقات مصغّرة أخرى تغيّر مظهرها استنادًا إلى الحالة الحالية، يمكنك الآن استخدام السمة android:state_hovered في قائمة الحالات القابلة للرسم لتوفير خلفية مختلفة قابلة للرسم عندما يمرِّر مؤشر الماوس فوق طريقة العرض.

للحصول على عرض توضيحي لأحداث التمرير الجديدة، يُرجى الاطّلاع على فئة Hover في ApiDemos.

أحداث قلم الشاشة وزر الماوس

يوفر Android الآن واجهات برمجة تطبيقات لتلقي الإدخال من جهاز إدخال بقلم الشاشة مثل جهاز طرفي لجهاز رقمي أو شاشة تعمل باللمس تمكّن قلم الشاشة.

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

يمكن لتطبيقك التمييز بين الإدخال باستخدام الإصبع والماوس وقلم الشاشة والممحاة من خلال طلب البحث عن "نوع الأداة" المرتبط بكل مؤشر في MotionEvent باستخدام getToolType(). أنواع الأدوات المحدّدة حاليًا هي: TOOL_TYPE_UNKNOWN وTOOL_TYPE_FINGER وTOOL_TYPE_MOUSE وTOOL_TYPE_STYLUS وTOOL_TYPE_ERASER. عند الاستعلام عن نوع الأداة، يمكن لتطبيقك اختيار التعامل مع إدخال قلم الشاشة بطرق مختلفة بدءًا من الإدخال بالإصبع أو الماوس.

يمكن لتطبيقك أيضًا طلب البحث عن أزرار الماوس أو قلم الشاشة التي يتم الضغط عليها من خلال الاستعلام عن "حالة الزر" في MotionEvent باستخدام getButtonState(). حالات الأزرار المحدّدة حاليًا هي: BUTTON_PRIMARY وBUTTON_SECONDARY وBUTTON_TERTIARY وBUTTON_BACK وBUTTON_FORWARD. لتسهيل الأمر، يتم ربط زرَّي الماوس للخلف وللأمام تلقائيًا بمفتاحَي KEYCODE_BACK وKEYCODE_FORWARD. يمكن لتطبيقك معالجة هذه المفاتيح لدعم زر الماوس استنادًا إلى التنقل للخلف وللأمام.

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

لعرض أنواع الأدوات وحالات الأزرار ورموز المحاور الجديدة، يمكنك الاطّلاع على فئة TouchPaint في ApiDemos.

الخصائص

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

على سبيل المثال، إذا كنت تريد ضبط قيمة الحقل bar على الكائن foo، كنت تنفّذ ما يلي في السابق:

Kotlin

foo.bar = value

Java

foo.bar = value;

إذا كنت تريد استدعاء دالة setter لحقل خاص أساسي bar، كنت تفعل ما يلي في السابق:

Kotlin

foo.setBar(value)

Java

foo.setBar(value);

ومع ذلك، إذا كنت تريد تمرير المثيل foo وضبط بعض الرموز الأخرى على قيمة bar، فلا توجد طريقة فعلاً لإجراء ذلك قبل الإصدار Android 4.0.

باستخدام الفئة Property، يمكنك الإعلان عن كائن Property BAR في الفئة Foo بحيث يمكنك ضبط الحقل على المثيل foo من الفئة Foo على النحو التالي:

Kotlin

BAR.set(foo, value)

Java

BAR.set(foo, value);

تستعين الفئة View الآن بالفئة Property للسماح لك بضبط حقول مختلفة، مثل خصائص التحويل التي تمت إضافتها في Android 3.0 (ROTATION وROTATION_X وTRANSLATION_X وما إلى ذلك).

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

تسريع الأجهزة

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

إذا لزم الأمر، يمكنك إيقاف ميزة "تسريع الأجهزة" يدويًا باستخدام السمة hardwareAccelerated لعناصر <activity> الفردية أو العنصر <application>. يمكنك بدلاً من ذلك إيقاف ميزة "تسريع الأجهزة" للملفات الشخصية الفردية من خلال الاتصال بـ setLayerType(LAYER_TYPE_SOFTWARE).

لمزيد من المعلومات حول تسريع الأجهزة، بما في ذلك قائمة بعمليات الرسم غير المتوافقة، راجع مستند تسريع الأجهزة.

التغييرات في مؤشر JNI

في الإصدارات السابقة من نظام التشغيل Android، لم تكن مراجع JNI المحلية هي الأسماء المعرِّفة غير المباشرة، بل استخدم Android مؤشرات مباشرة. لم تكن هذه مشكلة طالما أن جامع البيانات المهملة لم يحرّك الكائنات، ولكن بدا أنه يعمل لأنه تمكّن من كتابة تعليمات برمجية للخطأ. في Android 4.0، يستخدم النظام الآن مراجع غير مباشرة لاكتشاف هذه الأخطاء.

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

لا يؤثّر هذا التغيير في تنفيذ مؤشر JNI إلا في التطبيقات التي تستهدف الإصدار Android 4.0 من خلال ضبط targetSdkVersion أو minSdkVersion على “14" أو إصدار أحدث. في حال ضبط هذه السمات على أي قيمة أقل، ستتصرف مراجع JNI المحلية بالطريقة نفسها التي تعمل بها في النُسخ السابقة.

مجموعة أدوات الويب

  • تم تحديث WebKit إلى الإصدار 534.30
  • إتاحة الخطوط الهندية (الديفاناغارية والبنغالية والتاميلية، بما في ذلك إتاحة استخدام الأحرف المعقدة اللازمة لدمج الحروف الرسومية) في WebView والمتصفّح المدمَج
  • دعم الخطوط الإثيوبية والجورجية والأرمينية في WebView والمتصفِّح المُدمَج
  • يسهّل دعم WebDriver اختبار التطبيقات التي تستخدم WebView

متصفح Android

يضيف تطبيق المتصفح الميزات التالية لدعم تطبيقات الويب:

الأذونات

إليك الأذونات الجديدة:

  • ADD_VOICEMAIL: السماح لخدمة البريد الصوتي بإضافة رسائل البريد الصوتي إلى الجهاز.
  • BIND_TEXT_SERVICE: يجب أن تطلب الخدمة التي تنفِّذ SpellCheckerService هذا الإذن لنفسها.
  • BIND_VPN_SERVICE: يجب أن تطلب الخدمة التي تنفِّذ VpnService هذا الإذن لنفسها.
  • android.Manifest.permission#READ_PROFILE: لمنح الإذن بالاطّلاع على معلومات مقدّم خدمة "ContactsContract.Profile"
  • android.Manifest.permission#WRITE_PROFILE: يتيح هذا الإذن إمكانية الكتابة لموفِّر "ContactsContract.Profile".

ميزات الجهاز

في ما يلي ميزات الجهاز الجديدة:

  • FEATURE_WIFI_DIRECT: إقرار بأنّ التطبيق يستخدم شبكة Wi-Fi لإجراء الاتصالات من نظير إلى نظير

للحصول على عرض تفصيلي لجميع التغييرات في واجهة برمجة التطبيقات في الإصدار Android 4.0 (المستوى 14 من واجهة برمجة التطبيقات)، يمكنك الاطّلاع على تقرير الاختلافات في واجهة برمجة التطبيقات.

واجهات برمجة التطبيقات السابقة

بالإضافة إلى كل ما سبق، يدعم Android 4.0 بشكل طبيعي جميع واجهات برمجة التطبيقات من الإصدارات السابقة. بما أن نظام Android 3.x الأساسي لا يتوفر إلا للأجهزة ذات الشاشات الكبيرة، فإذا كنت تطوِّر تطبيقك بشكل أساسي للاستخدام مع الهواتف الجوّالة، فقد لا تكون على دراية بجميع واجهات برمجة التطبيقات التي تمت إضافتها إلى Android في هذه الإصدارات الحديثة.

إليك نظرة على بعض من أبرز واجهات برمجة التطبيقات التي ربما فاتتك والمتوفرة الآن على الهواتف أيضًا:

الإصدار 3.0 من نظام التشغيل Android
  • Fragment: هو مكوّن إطار عمل يتيح لك فصل العناصر المميّزة لأحد الأنشطة إلى وحدات مستقلة تحدّد واجهة المستخدم ودورة الحياة. راجع دليل مطور الأجزاء.
  • ActionBar: بديل لشريط العناوين التقليدي في أعلى نافذة النشاط. يتضمن شعار التطبيق في الزاوية اليسرى ويوفر واجهة جديدة لعناصر القائمة. يُرجى الاطّلاع على دليل مطوّر شريط الإجراءات.
  • Loader: مكوِّن إطار عمل يُسهِّل التحميل غير المتزامن للبيانات مع مكوّنات واجهة المستخدم لتحميل البيانات ديناميكيًا بدون حظر سلسلة التعليمات الرئيسية. اطّلع على دليل مطوّر برامج Loaders.
  • حافظة النظام: يمكن للتطبيقات نسخ البيانات ولصقها (بخلاف النصوص) من وإلى الحافظة على مستوى النظام. يمكن أن تكون البيانات التي يتم اقتطاعها نصًا عاديًا أو معرّف موارد منتظمًا (URI) أو هدفًا. يمكنك الاطّلاع على دليل المطوِّر حول النسخ واللصق.
  • السحب والإفلات: مجموعة من واجهات برمجة التطبيقات المضمّنة في إطار عمل العرض والتي تسهِّل عمليات السحب والإفلات. راجع دليل المطوِّر السحب والإفلات.
  • يتيح لك إطار الصور المتحركة المرن الجديد إمكانية تحريك الخصائص العشوائية لأي كائن (عرض، قابل للرسم، جزء، كائن أو أي شيء آخر) وتحديد جوانب الرسوم المتحركة مثل المدة والاستيفاء والتكرار وغير ذلك. يجعل إطار العمل الجديد الرسوم المتحركة في Android أكثر سهولة من أي وقت مضى. يُرجى الاطّلاع على دليل مطوّري الصور المتحركة للموقع.
  • رسومات RenderScript ومحرك الحوسبة: توفّر RenderScript عرضًا للرسومات ثلاثية الأبعاد وحوسبة واجهة برمجة التطبيقات عالية الأداء على المستوى الأصلي، وهو ما تكتبه وفقًا لمعيار C (معيار C99)، ما يوفّر نوع الأداء الذي تتوقعه من البيئة الأصلية مع الاحتفاظ بإمكانية حمله عبر مختلف وحدات المعالجة المركزية (CPU) ووحدات معالجة الرسومات. يمكنك الاطّلاع على دليل المطوّر RenderScript.
  • الرسومات الثنائية الأبعاد المسرّعة للأجهزة: يمكنك الآن تفعيل عارض OpenGL لتطبيقك عن طريق ضبط {android:hardwareAccelerated="true"} في عنصر <application> لعنصر البيان أو لعناصر <activity> الفردية. يؤدي ذلك إلى الحصول على رسوم متحركة أكثر سلاسة وتمرير أكثر سلاسة وأداء أفضل بشكل عام والاستجابة لتفاعل المستخدم.

    ملاحظة: في حال ضبط إعدادات minSdkVersion أو targetSdkVersion في تطبيقك على "14" أو إصدار أحدث، يتم تفعيل ميزة "تسريع الأجهزة" تلقائيًا.

  • وغير ذلك الكثير. راجِع ملاحظات نظام Android 3.0 الأساسي للحصول على مزيد من المعلومات.
الإصدار 3.1 من نظام التشغيل Android
  • واجهات برمجة تطبيقات USB: واجهات برمجة تطبيقات جديدة وفعّالة لدمج الأجهزة الملحقة المتصلة مع تطبيقات Android. تستند واجهات برمجة التطبيقات إلى حِزم USB وخدمات مدمَجة في النظام الأساسي، بما في ذلك دعم كل من مضيف USB وتفاعلات الجهاز. يُرجى الاطّلاع على دليل المطوِّر حول مضيف وملحقات USB.
  • واجهات برمجة تطبيقات MTP/PTP: يمكن للتطبيقات التفاعل مباشرةً مع الكاميرات المتصلة وأجهزة PTP الأخرى لتلقي الإشعارات عند توصيل الأجهزة وإزالتها وإدارة الملفات والتخزين على هذه الأجهزة ونقل الملفات والبيانات الوصفية منها وإليها. تنفِّذ واجهة برمجة تطبيقات بروتوكول نقل الوسائط (MTP) المجموعة الفرعية لبروتوكول نقل الصور (PTP) من مواصفات بروتوكول نقل الوسائط (MTP). يمكنك الاطّلاع على مستندات android.mtp.
  • واجهات برمجة تطبيقات RTP: يعرض نظام التشغيل Android واجهة برمجة تطبيقات لحزمة بروتوكول النقل في الوقت الفعلي (RTP) المدمَجة، التي يمكن للتطبيقات استخدامها لإدارة بث البيانات عند الطلب أو التفاعلي. وعلى وجه الخصوص، يمكن للتطبيقات التي توفر بروتوكول الصوت على الإنترنت (VOIP) وميزة الضغط إلى التحدث ومكالمات الفيديو والبث الصوتي استخدام واجهة برمجة التطبيقات لبدء الجلسات ونقل أو استقبال مصادر البيانات عبر أي شبكة متاحة. يمكنك الاطّلاع على مستندات android.net.rtp.
  • دعم أذرع التحكم وغيرها من مدخلات الحركة العامة.
  • اطّلِع على ملاحظات نظام Android 3.1 الأساسي لمعرفة المزيد من واجهات برمجة التطبيقات الجديدة.
الإصدار 3.2 من نظام التشغيل Android
  • تتوافق الشاشات الجديدة مع واجهات برمجة التطبيقات التي تمنحك قدرًا أكبر من التحكم في طريقة عرض تطبيقاتك عبر أحجام شاشات مختلفة. تعمل واجهة برمجة التطبيقات على توسيع نموذج دعم الشاشة الحالي مع إمكانية استهداف نطاقات أحجام محددة للشاشة بدقة حسب الأبعاد، والتي تُقاس بوحدات البكسل المستقلة عن الكثافة (مثل عرض 600 بكسل مستقل الكثافة أو 720 بكسل مستقل الكثافة)، بدلاً من أحجام الشاشات العامة (كالكبيرة أو الكبيرة). على سبيل المثال، يُعد هذا أمرًا مهمًا من أجل مساعدتك على التمييز بين جهاز مقاس 5 بوصة وجهاز 7 بوصة، وكلاهما يتم تجميعهما عادةً كشاشات "كبيرة". يُرجى الاطّلاع على مشاركة المدونة أدوات جديدة لإدارة أحجام الشاشات.
  • ثوابت جديدة في <uses-feature> لتعريف متطلبات اتجاه الشاشة الأفقي أو العمودي.
  • يتغير إعداد "حجم شاشة" الجهاز الآن أثناء تغيير اتجاه الشاشة. إذا كان تطبيقك يستهدف المستوى 13 من واجهة برمجة التطبيقات أو مستوى أعلى، عليك التعامل مع تغيير إعدادات "screenSize" إذا كنت تريد أيضًا التعامل مع تغيير إعدادات "orientation". يمكنك الاطّلاع على android:configChanges للحصول على مزيد من المعلومات.
  • راجِع ملاحظات نظام Android 3.2 الأساسي للاطّلاع على واجهات برمجة التطبيقات الجديدة الأخرى.

مستوى واجهة برمجة التطبيقات

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

لاستخدام واجهات برمجة التطبيقات التي تم تقديمها في Android 4.0 في تطبيقك، يجب تجميع التطبيق في نظام Android الأساسي الذي يتوافق مع المستوى 14 من واجهة برمجة التطبيقات أو المستوى الأعلى. قد يُطلب منك أيضًا إضافة السمة android:minSdkVersion="14" إلى العنصر <uses-sdk>، وذلك حسب احتياجاتك.

لمزيد من المعلومات، يُرجى الاطّلاع على القسم ما هو مستوى واجهة برمجة التطبيقات؟