هل التطوير باستخدام Android Studio يصنع فارقاً في العرض — وهل يربطني هذا الخيار؟

نظرًا لأن Android Studio هي بيئة التطوير الرسمية، فإن إصدارات Android الجديدة التي تصدرها Google سنوياً، ومتطلبات مستويات API المستهدفة، وتحديثات الأمان تصل إلى هنا مباشرة من اليوم الأول. بينما في الأنظمة الهجينة تضطر أحياناً للانتظار 3-4 أشهر لتحديث المكتبات.

عند تقييم العروض قم بهذا التمييز: هل ستُستخدم في شركتك أجهزة أندرويد اللوحية/أجهزة القراءة فقط؟ إذا كان الأمر كذلك، فإن Android Studio والبرمجة الأصيلة (native) هي الطريق الأقوى بلا منازع. لكن إذا أراد الموظفون الميدانيون استخدام أجهزة iPhone الخاصة بهم غداً، فإن البنية الهجينة تحل الطرفين بميزانية واحدة.

في 2022 ما لقيناش وكالة ترضى تستلم تطبيق إدارة المستودعات (B2B) بتاعنا اللي كان مكتوب بتكنولوجيا هجينة (hybrid)، لأن الفريق اللي عمله استخدم مكتبات غريبة اختفت من السوق. اضطرينا نعيد كتابته من الصفر بـ Android Studio و Kotlin؛ وكلفنا الموضوع 160.000 TL و4 شهور شغل.

تحذير هام: ضيفوا بند في العقد بخصوص "تسليم مفتاح التوقيع (keystore/upload key)". الوكالة ممكن تكتب كود ممتاز على Android Studio، بس لو ما سلمتكمش المفتاح مش هتعرفوا تعملوا تحديث للتطبيق على Google Play، وهتضطروا تنزلوا تطبيق جديد تماماً من الصفر.

تعديل: كتبت خطأً أعلاه، أرجو المعذرة.

الكود الأصلي (Native) معاييره عالية مع صح، بس لو تطبيق طلبات الموزعين ما فيهوش رسومات 3D أو اتصال تقيل عبر Bluetooth، التقنيات الهجينة هتقوم بالواجب وزيادة. ممكن تكون الوكالة بتفضل الـ Native عشان ما بتعرفش غير Android، اسألوهم في التفصيلة دي.

android studio في النهاية برنامج مش احتكار للوكالة يعني... بصراحة افتحوا حساب على gitlab أو github وخلوهم يرفعوا الكود على المستودع بتاعكم من أول يوم وخلاص، مش هتبقوا تحت رحمة حد.

هل كل الموزعين عندكم بيستخدموا Android؟ وهل فيه احتمال في المستقبل تفتحوا الطلبات للمستخدم النهائي من بره الشركة؟ لو إجابتكم نعم، هل مستعدين تدفعوا دلوقتي 210 ألف TL للـ Android وبعد 6 شهور تدفعوا نفس المبلغ عشان iOS؟

أنا أيضًا أوافق على هذا الرأي. أكثر ما أهدر وقتنا كان عدم وضوح من يتخذ القرار.

كل من يستعجل في تطوير android studio يتعثر في نفس النقطة. هذه وجهة نظري، ولا أدعي أنها الحقيقة المطلقة.

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

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

أوافق. يجب ربط جدول المدفوعات بمراحل العمل، وليس بالتقويم.

هذا كل شيء، أرجو المعذرة إذا أطالت.

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

تدوين الملاحظات لمدة أسبوعين يعطي نتائج أفضل من التخمين لمدة ستة أشهر.

نعم، الوضع في موضوع تطوير android studio هو بالضبط هكذا. لا تترددوا في السؤال، فالسائل يدفع ثمناً أقل دائماً.

تدوين الملاحظات لمدة أسبوعين يعطي نتائج أفضل من التخمين لمدة ستة أشهر.

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

لو كنت مكانك، لسلك هذا المسار.

هذا العنوان مؤرشف. كلما كان التراجع عن القرار أصعب، كان يجب اتخاذه ببطء أكبر.

كل من يستعجل في تطوير android studio يتعثر في نفس النقطة.

صحيح نظرياً، لكنه لا يسير هكذا عملياً. الكود بدون وثائق تثبيت لا يُعتبر ملكك حتى لو كان بين يديك.

تقرير التقدم الأسبوعي المكتوب أكثر فائدة من السؤال المستمر عن المواعيد. هذا كل شيء، أرجو المعذرة إذا أطالت.

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

مثبت بالتجربة.

أتابع الموضوع.

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

إذا كتبت النتيجة هنا، فستفيد الآخرين أيضاً.