مقدّمة عن الأنشطة

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

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

مفهوم الأنشطة

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

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

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

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

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

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

ضبط البيان

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

الإفصاح عن الأنشطة

للإعلان عن نشاطك، افتح ملف البيان وأضِف عنصر <activity> كعنصر ثانوي للعنصر <application>. مثلاً:

<manifest ... >
  <application ... >
      <activity android:name=".ExampleActivity" />
      ...
  </application ... >
  ...
</manifest >

السمة الوحيدة المطلوبة لهذا العنصر هي android:name، والتي تحدد اسم فئة النشاط. يمكنك أيضًا إضافة السمات التي تحدد خصائص النشاط مثل التسمية أو الأيقونة أو مظهر واجهة المستخدم. للمزيد من المعلومات حول هذه السمات وغيرها، يُرجى الاطّلاع على المستندات المرجعية الخاصة بالعنصر <activity>.

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

تعريف فلاتر الأهداف

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

يمكنك الاستفادة من هذه الميزة من خلال الإعلان عن سمة <intent-filter> في العنصر <activity>. يتضمن تعريف هذا العنصر عنصر <action> واختياريًا عنصر <category> و/أو عنصر <data>. يتم دمج هذه العناصر لتحديد نوع النية التي يمكن أن يستجيب لها نشاطك. على سبيل المثال، يعرض مقتطف الرمز التالي كيفية ضبط نشاط يرسل بيانات نصية، ويتلقى طلبات من أنشطة أخرى لإجراء ذلك:

<activity android:name=".ExampleActivity" android:icon="@drawable/app_icon">
    <intent-filter>
        <action android:name="android.intent.action.SEND" />
        <category android:name="android.intent.category.DEFAULT" />
        <data android:mimeType="text/plain" />
    </intent-filter>
</activity>

في هذا المثال، يحدد العنصر <action> أن هذا النشاط يرسل البيانات. من خلال تعريف العنصر <category> بأنه DEFAULT يمكّن النشاط من تلقّي طلبات الإطلاق. يحدد العنصر <data> نوع البيانات التي يمكن لهذا النشاط إرسالها. يوضح مقتطف الرمز التالي كيفية استدعاء النشاط الموصوف أعلاه:

Kotlin

val sendIntent = Intent().apply {
    action = Intent.ACTION_SEND
    type = "text/plain"
    putExtra(Intent.EXTRA_TEXT, textMessage)
}
startActivity(sendIntent)

Java

// Create the text message with a string
Intent sendIntent = new Intent();
sendIntent.setAction(Intent.ACTION_SEND);
sendIntent.setType("text/plain");
sendIntent.putExtra(Intent.EXTRA_TEXT, textMessage);
// Start the activity
startActivity(sendIntent);
إذا كنت تنوي أن يكون تطبيقك مستقلاً بذاته ولا تسمح للتطبيقات الأخرى بتفعيل أنشطته، لن تحتاج إلى استخدام أي فلاتر أهداف أخرى. الأنشطة التي لا تريد توفيرها للتطبيقات الأخرى يجب ألا تحتوي على فلاتر أهداف، ويمكنك بدؤها بنفسك باستخدام أغراض صريحة. لمزيد من المعلومات عن كيفية استجابة أنشطتك للأهداف، اطّلِع على فلاتر أهداف وأهداف.

الإفصاح عن الأذونات

يمكنك استخدام علامة <activity> الخاصة بالبيان لتحديد التطبيقات التي يمكنها بدء نشاط معيّن. لا يمكن لنشاط الوالدين بدء نشاط ثانوي ما لم يكن لكلا النشاطين نفس الأذونات في البيان. إذا أعلنت عن عنصر <uses-permission> لنشاط رئيسي، يجب أن يحتوي كل نشاط فرعي على عنصر <uses-permission> مطابق.

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

<manifest>
<activity android:name="...."
   android:permission=”com.google.socialapp.permission.SHARE_POST”

/>

بعد ذلك، لكي يُسمح لتطبيقك بالاتصال بـ SocialApp، يجب أن يتطابق تطبيقك مع الإذن المحدّد في بيان SocialApp:

<manifest>
   <uses-permission android:name="com.google.socialapp.permission.SHARE_POST" />
</manifest>

لمزيد من المعلومات حول الأذونات والأمان بشكل عام، يمكنك الاطلاع على الأمان والأذونات.

إدارة دورة حياة النشاط

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

onCreate()

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

عند انتهاء onCreate()، تكون رد الاتصال التالي دائمًا onStart().

onStart()

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

onCV()

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

ودائمًا ما يتبع معاودة الاتصال onPause() "onResume()".

onPause()

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

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

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

بعد انتهاء تنفيذ onPause()، تكون معاودة الاتصال التالية إما onStop() أو onResume()، بناءً على ما يحدث بعد دخول النشاط إلى الحالة "متوقف مؤقتًا".

onStop()

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

معاودة الاتصال التالية التي يستدعيها النظام هي onRestart()، في حال عاد النشاط للتفاعل مع المستخدم، أو عن طريق onDestroy() إذا كان هذا النشاط قد انتهى تمامًا.

on rename()

يستدعي النظام معاودة الاتصال هذه عندما توشك إعادة تشغيل نشاط بالحالة "متوقّفة". يستعيد onRestart() حالة النشاط من وقت توقّفه.

وتكون معاودة الاتصال هذه دائمًا متبوعة بـ onStart().

onDestroy()

يستدعي النظام معاودة الاتصال هذه قبل حذف النشاط.

معاودة الاتصال هذه هي الأخيرة التي يتلقّاها النشاط. يتم تنفيذ onDestroy() عادةً لضمان إصدار جميع موارد النشاط عند تدمير النشاط أو العملية التي تحتوي عليه.

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