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

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

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

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

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

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

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

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

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

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

إعداد البيان

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

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

للإبلاغ عن نشاطك، يُرجى فتح ملف البيان وإضافة <activity> كعنصر فرعي <application> العنصر. مثلاً:

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

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

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

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

فلاتر الأهداف هي ميزة فعّالة جدًا في نظام 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> نوع البيانات التي التي يمكن أن يرسلها هذا النشاط. يوضح مقتطف الرمز التالي كيفية استدعاء النشاط الموضح أعلاه:

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

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

onResume()

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

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

onPause()

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

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

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

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

onStop()

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

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

onstart()

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

يلي معاودة الاتصال هذه دائمًا onStart()

onDestroy()

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

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

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