واجهات برمجة تطبيقات 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 كمكون قابل للتنزيل لحزمة تطوير البرامج (SDK) لنظام التشغيل Android. وتشتمل المنصة القابلة للتنزيل على مكتبة 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. ومع ذلك، من المفترض ألا تحتاج معظم التطبيقات إلى قراءة الملف الشخصي للمستخدم، حتى عند المساهمة بالبيانات في الملف الشخصي. إنّ قراءة الملف الشخصي للمستخدم هي إذن حساس، وعليك أن تتوقّع أن يكون المستخدمون حريصين على عدم التعامل مع التطبيقات التي تطلب ذلك.

دعوة النية

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

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

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

يتيح Android الآن استخدام الصور العالية الدقة لجهات الاتصال. والآن، عند إرسال صورة إلى سجل جهة الاتصال، يعالجها النظام في صورة مصغّرة بحجم 96×96 (كما في السابق) و"صورة عرض" بحجم 256×256 يتم تخزينها في متجر صور جديد مستند إلى ملف (قد تختلف الأبعاد الدقيقة التي يختارها النظام في المستقبل). يمكنك إضافة صورة كبيرة إلى جهة الاتصال عن طريق وضع صورة كبيرة في عمود 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 موفّر المحتوى لـ Voicemail Provder. توفِّر الفئتان الفرعيتان 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.

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

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

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

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

  • الإصدار 3 من بروتوكول البث المباشر 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 التي يهتم بها تطبيقك. لمزيد من المعلومات عن Tag Dispatch، اطّلِع على دليل المطوِّر حول NFC.

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

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

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

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

اتصال Wi-Fi P2P

يتوافق Android الآن مع اتصالات شبكة Wi-Fi من نظير إلى نظير (P2P) بين الأجهزة التي تعمل بنظام التشغيل 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 Demo.

أجهزة Bluetooth Health

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

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

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

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

لمزيد من المعلومات حول استخدام الملف الشخصي لميزة Bluetooth Health، يُرجى الاطّلاع على وثائق "BluetoothHealth".

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

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

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

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

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

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

يُرجى العلم أنّ سلوك طريقة sendAccessibilityEvent() قد تغيّر في الإصدار 4.0 من نظام التشغيل Android. كما في الإصدار السابق من نظام التشغيل 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> يوضِّح معلومات الإعداد للمدقق الإملائي.

راجع نموذج تطبيق خدمة المدقق الإملائي ونموذج تطبيق برنامج المدقق الإملائي للتعرف على الرمز.

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

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

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

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

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

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

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

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

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

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

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

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

يوفر 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 واجهة لشبكة افتراضية باستخدام قواعد خاصة بها للعناوين والتوجيه، وتجري جميع عمليات القراءة والكتابة باستخدام واصف ملف.

لإنشاء خدمة 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() تحديد ما إذا كان الرمز/الشعار يعمل كزر للانتقال إلى الصفحة الرئيسية أو للأعلى (استخدِم القيمة"صحيح" لجعله يعمل كزر).
  • يتيح لك كل من 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 ونشاط مفاتيح التبديل المعني.

قدّم 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;

إذا كنت تريد استدعاء دالة الضبط لحقل خاص أساسي 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، وهي الطريقة الأسرع والأكثر فعالية وأكثر أمانًا من حيث الكتابة من النهج المستند إلى السلاسل.

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

بدءًا من الإصدار 4.0 من نظام التشغيل Android، يتم تفعيل ميزة "تسريع الأجهزة" لجميع النوافذ بشكل تلقائي إذا كان التطبيق قد ضبط إما 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: مكوِّن إطار عمل يسهِّل التحميل غير المتزامن للبيانات إلى جانب مكوّنات واجهة المستخدم لتحميل البيانات ديناميكيًا بدون حظر سلسلة التعليمات الرئيسية. راجِع دليل مطوِّر تحميلات التحميل.
  • حافظة النظام: يمكن للتطبيقات نسخ البيانات ولصقها (بخلاف النص) من وإلى الحافظة على مستوى النظام. وقد تكون البيانات التي يتم قطعها عبارة عن نص عادي أو معرّف موارد منتظم (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>، وذلك حسب احتياجاتك.

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