Arabic:تطوير تطبيقات الهاتف

مقدمة

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

لا يفترض المقرر أن إطار عمل واحد مناسب لكل مشروع. يمكنك بناء تطبيق أصلي لنظام أندرويد باستخدام Kotlin وJetpack Compose، أو لنظام iOS باستخدام Swift وSwiftUI، أو اختيار إطار متعدد المنصات مثل Flutter عندما تكون مشاركة جزء كبير من قاعدة الشيفرة أولوية. القرار الهندسي الجيد يعتمد على متطلبات المنتج، وخبرة الفريق، والحاجة إلى تكامل عميق مع النظام، وأهداف الأداء، ودورة الصيانة.

التطبيق المحمول هو واجهة أمامية تتفاعل مع نظام التشغيل والبيانات والخدمات.

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

تحميل الفيديو

يوتيوب

قد يقوم يوتيوب بجمع البيانات الشخصية. سياسة الخصوصية

استمرار تجاهل

أهداف التعلم

بنهاية المقرر يُتوقع أن تكون قادرًا على:

1. تحليل مشكلة تطبيق محمول وتحويلها إلى قصص مستخدم ومتطلبات وظيفية وغير وظيفية.
2. تصميم تدفقات تنقل وواجهات متكيفة مع أحجام شاشات واتجاهات مختلفة.
3. تفسير بنية تطبيق طبقية وفصل واجهة المستخدم عن منطق المجال ومصادر البيانات.
4. بناء واجهة تفاعلية وإدارة حالتها وفق تدفق بيانات أحادي الاتجاه.
5. اختيار استراتيجية تخزين محلي مناسبة وتنفيذ عمليات قراءة وكتابة آمنة.
6. استهلاك واجهات برمجة تطبيقات شبكية ومعالجة النجاح والفشل والتحميل وانقطاع الاتصال.
7. كتابة اختبارات وحدات وتكامل وواجهات، وبناء خطة اختبار قابلة للتكرار.
8. تطبيق مبادئ الإتاحة، بما فيها الوصف الدلالي، والتباين، والتنقل بلوحة أو تقنيات مساعدة، ودعم العربية والاتجاه من اليمين إلى اليسار.
9. إعداد التطبيق للإصدار عبر التوقيع والإصدارات المرحلية ومراقبة الأعطال مع احترام الخصوصية.
10. تقييم المفاضلات بين التطوير الأصلي ومتعدد المنصات وتبرير قرار تقني بوضوح.

المتطلبات السابقة وبيئة العمل

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

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

بيئة التطوير المتكاملة تجمع تحرير الشيفرة والبناء والتشغيل والفحص في مكان واحد.

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

من الفكرة إلى تصميم تجربة الاستخدام

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

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

مثال أولي لواجهة تطبيق مهام باللغة العربية:

┌──────────────────────────────┐
│ مهامي                    بحث │
├──────────────────────────────┤
│ اليوم                        │
│ □ مراجعة المحاضرة            │
│ □ إرسال التقرير              │
│                              │
│              + إضافة مهمة    │
└──────────────────────────────┘

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

تساعد دراسة تطبيقات حقيقية على تحليل البحث والتنقل والتسلسل البصري للمعلومات.

اختيار التقنية وبنية التطبيق

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

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

البنية الطبقية تساعد على التحكم في التعقيد. نموذج عملي شائع:

المستخدم
   ↓ أحداث
طبقة واجهة المستخدم
   ↓ طلبات          ↑ حالة واجهة
طبقة المجال الاختيارية
   ↓
مستودع البيانات
   ↙             ↘
قاعدة محلية      خدمة شبكية

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

يوضح مكدس أندرويد أن التطبيق يعمل فوق طبقات نظام وتشغيل وعتاد متعددة.

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

بناء الواجهة وإدارة الحالة

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

مثال مبسط بواجهة Jetpack Compose:

@Composable
fun TaskScreen(
    tasks: List<String>,
    onAdd: () -> Unit
) {
    Column {
        Text(text = "مهامي")
        tasks.forEach { task ->
            Text(text = task)
        }
        Button(onClick = onAdd) {
            Text("إضافة مهمة")
        }
    }
}

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

مثال لحالة واجهة غير قابلة للتغيير من خارج الحامل:

data class TaskUiState(
    val items: List<String> = emptyList(),
    val isLoading: Boolean = false,
    val errorMessage: String? = null
)

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

التخزين المحلي والعمل دون اتصال

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

SQLite قاعدة بيانات علائقية مضمّنة شائعة في بيئات الهاتف. في أندرويد توفر مكتبة Room طبقة تساعد على تعريف الكيانات وواجهات الاستعلام والتحقق من أجزاء من SQL وقت البناء.

يمكن استخدام SQLite كأساس لتخزين علائقي محلي داخل تطبيقات الهاتف.

مثال كيان وواجهة وصول للبيانات:

@Entity(tableName = "tasks")
data class TaskEntity(
    @PrimaryKey val id: Long,
    val title: String,
    val completed: Boolean
)

@Dao
interface TaskDao {
    @Query("SELECT * FROM tasks ORDER BY id DESC")
    suspend fun getAll(): List<TaskEntity>

    @Insert
    suspend fun insert(task: TaskEntity)
}

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

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

واجهات برمجة التطبيقات والاتصال الشبكي

تربط واجهة برمجة التطبيقات التطبيق بخدمات بعيدة مثل الحسابات أو الطقس أو المقررات أو التجارة الإلكترونية. في واجهات REST تستخدم عادة HTTP وموارد وعناوين ومسارات، وغالبًا JSON لتمثيل البيانات. لا تفترض أن كل استجابة ناجحة؛ صمم للتأخير والانقطاع والرموز غير المتوقعة وانتهاء الجلسة.

مثال واجهة شبكية مبسطة:

data class TaskDto(
    val id: Long,
    val title: String,
    val completed: Boolean
)

interface TasksApi {
    @GET("tasks")
    suspend fun getTasks(): List<TaskDto>
}

ثم يحول المستودع نموذج الشبكة إلى نموذج التطبيق بدل تمرير تفاصيل الشبكة مباشرة إلى الشاشة:

class TaskRepository(
    private val api: TasksApi,
    private val dao: TaskDao
) {
    suspend fun refresh() {
        val remote = api.getTasks()
        remote.forEach { item ->
            dao.insert(
                TaskEntity(item.id, item.title, item.completed)
            )
        }
    }
}

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

صمم طبقة الشبكة بحيث يمكن استبدالها بمصدر مزيف في الاختبارات. إذا كان ViewModel ينشئ عميل الشبكة بنفسه يصبح الاختبار أبطأ وأكثر هشاشة؛ أما إذا استقبل مستودعًا عبر البناء فيمكنك حقن تنفيذ حقيقي أو مزيف حسب السياق.

الاختبار وضمان الجودة

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

مثال اختبار وحدة لمستودع مزيف:

@Test
fun addingTaskUpdatesList() = runTest {
    val repository = FakeTaskRepository()
    repository.add("قراءة الفصل")

    val items = repository.getAll()

    assertEquals(1, items.size)
    assertEquals("قراءة الفصل", items.first().title)
}

ومثال فكرة لاختبار واجهة:

composeTestRule
    .onNodeWithText("إضافة مهمة")
    .performClick()

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

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

الإتاحة والتدويل ودعم العربية

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

في Compose أعط العنصر المرئي وصفًا دلاليًا عندما لا يحمل معنى نصيًا واضحًا:

IconButton(onClick = onAdd) {
    Icon(
        imageVector = Icons.Default.Add,
        contentDescription = "إضافة مهمة"
    )
}

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

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

الأداء والخصوصية والأمان

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

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

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

النشر ودورة الإصدار

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

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

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

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

مشروع تطبيقي مصغر: تطبيق مهام جامعية

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

بنية الملفات المقترحة:

ui/
  TaskScreen
  TaskViewModel

domain/
  AddTaskUseCase

data/
  TaskRepository
  local/TaskDao
  remote/TasksApi

مسار حدث «إضافة مهمة» يكون كالتالي:

ضغط المستخدم
   ↓
واجهة المستخدم
   ↓
TaskViewModel
   ↓
AddTaskUseCase
   ↓
TaskRepository
   ↓
قاعدة محلية ثم مزامنة بعيدة
   ↑
حالة جديدة تعود إلى الواجهة

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

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

مهام تفاعلية

اختبار: اختبر معرفتك

ما السبب الأهم لفصل طبقة واجهة المستخدم عن طبقة البيانات؟ (تحسين قابلية الاختبار والصيانة) (!زيادة عدد الشاشات في التطبيق) (!منع استخدام قواعد البيانات المحلية) (!إلغاء الحاجة إلى إدارة الحالة)

ما المقصود بمصدر حقيقة واحد للبيانات؟ (وجود مرجع موثوق واحد للحالة الأساسية) (!نسخ البيانات في كل شاشة) (!حفظ كل البيانات في الذاكرة فقط) (!استخدام خدمة شبكية دون تخزين محلي)

أي حالة يجب أن يصممها المطور إضافة إلى حالة النجاح؟ (حالة الخطأ أو انقطاع الاتصال) (!حالة تغيير لون الشعار فقط) (!حالة زيادة حجم ملف التثبيت) (!حالة حذف أدوات الاختبار)

ما الدور المعتاد للمستودع في بنية التطبيق؟ (تنسيق الوصول إلى مصادر البيانات) (!رسم الأزرار والنصوص على الشاشة) (!توقيع حزمة التطبيق للنشر) (!تشغيل قارئ الشاشة للمستخدم)

متى تكون قاعدة بيانات محلية خيارًا مناسبًا؟ (عند الحاجة إلى سجلات واستعلامات مترابطة) (!عند عرض لون ثابت في الواجهة) (!عند كتابة عنوان شاشة واحد) (!عند تغيير رمز التطبيق فقط)

ما السلوك الصحيح عند استدعاء خدمة شبكية؟ (معالجة النجاح والفشل والتأخير) (!افتراض أن الاتصال دائمًا ناجح) (!تجاهل رموز الاستجابة) (!تنفيذ كل الطلبات على خيط الواجهة)

ما الفائدة الأساسية لاختبار الوحدة؟ (التحقق السريع من منطق معزول) (!استبدال جميع الاختبارات اليدوية) (!قياس جودة تصميم الشعار) (!رفع التطبيق تلقائيًا إلى المتجر)

ما الممارسة الصحيحة لتحسين الإتاحة؟ (اختبار التطبيق بتقنيات مساعدة فعلية) (!الاعتماد على اللون وحده لنقل المعنى) (!منع تكبير النص) (!تثبيت اتجاه الواجهة من اليسار إلى اليمين)

لماذا يفيد الطرح المرحلي للإصدار؟ (تقليل نطاق أثر العطل المحتمل) (!إلغاء الحاجة إلى توقيع التطبيق) (!منع جمع تقارير الأعطال) (!ضمان خلو التطبيق من جميع الأخطاء)

ما العامل الذي يجب مراعاته عند الاختيار بين تطوير أصلي ومتعدد المنصات؟ (متطلبات المنتج وخبرة الفريق والتكامل مع النظام) (!عدد ألوان الواجهة فقط) (!اسم المشروع في المستودع) (!نوع لوحة مفاتيح المطور)

لعبة الذاكرة

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

السحب والإفلات

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

كلمات متقاطعة

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

مهام مفتوحة

سهل

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

متوسط

1. قاعدة بيانات مصغرة: أنشئ كيانًا وجدولًا لمهام جامعية ونفذ عمليتي إضافة واستعلام، ثم وثق قرارك بشأن المفتاح الأساسي.
2. عميل واجهة برمجة: ابن مصدر بيانات شبكيًا تجريبيًا يعيد قائمة مهام من خدمة تدريبية أو مصدر مزيف، وتعامل مع حالتي النجاح والفشل.
3. اختبار وحدة للمستودع: اكتب اختبارين لمستودع مهام أحدهما للنجاح والآخر لفشل المصدر البعيد، ووضح السلوك المتوقع في كل حالة.
4. مراجعة الإتاحة: اختبر شاشة باستخدام قارئ شاشة أو أداة فحص إتاحة، وسجل ثلاث ملاحظات مع إصلاحات مقترحة دون جمع بيانات عن أشخاص آخرين.

متقدم

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

مجالات تعلم مرتبطة

تطوير تطبيقات الهاتف هندسة البرمجيات تصميم تجربة المستخدم قواعد البيانات واجهات برمجة التطبيقات اختبار البرمجيات أمن المعلومات الإتاحة الرقمية الخدمات السحابية

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

مسرد

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