نكتب الواجهة التي تعمل. أو كيف تصبح مهندسًا من مطور. الجزء الأول

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

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

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

من الأفضل أن ترى مرة واحدة من أن تسمع مائة مرة


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

تمهيدي


  1. يجب أن تكون البطاقة قادرة على شغل أحد المناصب الثلاثة. 1 - تمت تهيئة البطاقة ، 2 - سحب المستخدم البطاقة لأعلى (فتحها) ، 3 - قام المستخدم بتمرير البطاقة لأسفل لإزالتها.


  2. الحد الأدنى لحجم البطاقة هو 50vh ، الحد الأقصى غير محدود (يعني إمكانية التمرير في الموضع 2)

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

على سبيل المثال:



مخطط الإجراءات عالي المستوى يبدو شيئًا كهذا ، ليس معقدًا للغاية:



فكر في إجراء DragUp:



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

الصعوبة هي فقط تصنيف البطاقات في الحجم. يجب أن نصنف البطاقة على أنها صغيرة لمنع سحبها أعلى من 50vh ، ولا يجب أن ترتفع البطاقة متوسطة الحجم فوق ارتفاعها (وإلا فإنها معلقة في "الهواء") ، ولكن لا يجب سحب البطاقة كبيرة الحجم أعلى من Y = 0 (أعلى شاشة).

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

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



الآن المعلمة العامة للبطاقات من جميع الأحجام في أي موقف (داخلي ، مفتوح) هي احتياطي الطاقة.

يمكن وصف الرسم التخطيطي لمعالجة إجراء السحب الأعلى على النحو التالي:



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



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



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



مجموع


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

All Articles