إطار Flutter

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

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

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

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

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