- اختيار طريقة الصرف. وصف API.
- تنفيذ API على الجانب 1C.
- BroadcastReceiver. نتلقى الرمز الشريطي على مثال ATOL Smart.Lite.
- OnKeyUp. احصل على باركود من ماسحة ضوئية مضاهاة لوحة المفاتيح
- القائمة ، كائن مصاحب
- نحن ندرك تبادل البيانات وتخزينها. نستخدم التحديثية 2 ، الغرفة ، Coroutines.
- واجهة المستخدم LiveData ، قائمة الصفحات.
لمن
يمثل الفصلان الأولان محاولة لتنظيم تجربة دمج 1C مع التطبيقات الأخرى وخدمات الويب. أعتقد أن الدورة نفسها ستكون ممتعة لمبرمجي 1C الذين يحاولون تجاوز المنصة وتجربة شيء جديد. لن يتعلم مطورو تطبيقات Android شيئًا جديدًا لأنفسهم ، ولكن ربما يهتمون بكيفية ظهوره على الجانب 1C. بدءًا من الجزء الرابع ، ستكون هناك محاولة لدمج العديد من المقالات المبعثرة من الإنترنت حول استخدام المكتبات ، بالإضافة إلى تحديث البيانات عليها. تم تصميم الدورة ككتاب مدرسي ، والذي يصف تجربة تطوير تطبيق حقيقي. أنا نفسي لست مطور أندرويد. لكن بحلول نهاية السلسلة أتمنى أن أكون واحدة.
2. اختيار طريقة الصرف. وصف API
في شكله الحالي ، يمكن الاتصال بـ 1C بألف وطريقة واحدة. النظر في العديد من الخيارات ، ولماذا لم أستخدمها.
- المكون الأصلي - بالنسبة للجزء الأكبر ، من الجيد استخدامه للمشاركة دون الاتصال بالإنترنت. بالنسبة عبر الإنترنت ، يتم تكييفه بشكل سيء. أصبح الوضع أسوأ عندما بدأت شركة 1C في تطبيق معاييرها للتبادل مع المعدات التجارية. وأيضا يسمى هذا المكون على الجانب 1C. لا يناسبني
- خدمات WEB - مصممة أكثر للتبادل بين التطبيقات التي تطور فرق مختلفة. الوزن الثقيل ، استخدم XML. شخصياً ، من الصعب جدًا أن أتطور. وأصعب من الاندماج في JavaScript ، Golang ، إلخ. غير مناسب
- خدمات HTTP - مثل خدمات WEB تقريبًا ، ولكننا نصف منطق العمل وبروتوكولات التبادل بأنفسنا تمامًا. نحن هنا لا تقتصر على اختراع الدراجة الخاصة بنا. لهذا السبب ، تم اختيار آلية التبادل هذه.
المهام التي يحلها تطبيقنا. "كل ما يمكن القيام به على TSD يجب أن يتم على TSD." حسنًا ، كمجموعة قياسية: القبول ، المخزون ، التسميات ، علامات الأسعار.
قائمة كاملة من المهام- العمل مع البضائع: طباعة الملصقات وعلامات الأسعار ، وتعيين الرمز الشريطي (الباركود) ، والتحقق من الباركود ، وإزالة الباركود ، وعرض الأسعار والكميات في المستودعات.
- جرد - إجراء فعلا قوائم الجرد.
- الاستلام - قبول البضائع على الفاتورة ، وطباعة التناقضات ، وطباعة المستندات الداخلية ، وحالة الفاتورة.
- تحصيل البضائع ، الإدراك (البيع بالتجزئة) - الفكرة هي أن البائعين ليسوا في السجل النقدي ، لكن مع المشتري أو يجمع البضائع عند الطلب ، إلخ. يوجد شخص واحد فقط في عداد الخروج ، ويتم إرسال فحص جاهز من TSD. المشتري يدفع فقط للبضائع.
- جمع البضائع ، الإدراك (بالجملة) - نقوم بجمع البضائع على الحساب. نتحقق مما هو متاح. نحن نشكل شحنة (مع حزمة من الوثائق اللازمة). لا تنس التحقق من إمكانية الشحن للطرف المقابل.
- مجموعة البضائع ، التحضير للشحن - نقوم بجمع البضائع عند الطلب ، ونضعها على منصة نقالة ، ومستندات الطباعة: قائمة التعبئة ، إلخ.
- نقل - نحن جمع البضائع لنقل ، ونحن نقدم في التسليم.
- مجموعة البضائع ، قائمة اعتباطية - ضرورية لإعادة التقييم وتحديث علامات الأسعار والملصقات وعمليات أخرى مماثلة.
العودة إلى بنية API. التبادل بين TSD و 1 C سيكون بتنسيق JSON. في الإجابة ، لن يكون لدينا سوى كائنين
{النتيجة ، الحمولة} ، على التوالي:
النتيجة وحمولة البيانات . نتيجة لذلك ، سنرجع حقلين
{code، msg} . وسوف نرد دائمًا على كود HTTP 200. لذلك سيكون من السهل علينا من جانب العميل تحليل بنية الاستجابة. جميع الإجابات الأخرى سوف تأتي كسلسلة. 1C لا يسمح لنا بتخصيص الإجابات خارج المنصة.
لماذا هو أسهل لإعطاء 200معظم مكتبات العمل مع البيانات (بما في ذلك Retrofit) ، عند تلقي كود آخر بخلاف 200 ، لا تقوم بتحليل النتيجة. وعلينا أن "تحليل" مع الأقلام.
الآن نحصل على الرسم البياني التالي. إذا كانت الإجابة 200 ، فإن إجراءاتنا في 1C تعمل بشكل جيد. إذا كانت إجابة مختلفة ، لدينا مشكلة أدناه. هنا لا يمكننا أن نذهب بعمق ، ما الخطأ الذي حدث ، ولكن على الفور تظهر للمستخدم ما الخطأ ، ووصفه. قد يقول أحدهم أن الأخطاء تحتاج إلى معالجة دون تدخل المستخدم ، ولكن يمكننا أن نواجه حالتين: 1 - أعاد الخادم خطأ. 2 - مبتذل لا اتصال. في الحالة الأولى ، قد لا نعرف حتى أنه قد تم كسر شيء ما (على سبيل المثال ، الخطأ 404: طلب التطبيق طريقة غير موجودة. 500: تعطل النظام الأساسي مع استثناء). في الثانية ، لا يمكننا نقل نتيجة التحليل إلى الخادم. لذلك ، نعرض خطأ ، ونتطلع إلى مزيد من إجراءات المستخدم.
سوف تحتوي الحمولة على كائنات مختلفة. يمكن أن تكون هذه قائمة بالسلع ، وقائمة بالوثائق ، وسيتم إرسال قائمة بالإجراءات إلى هناك. على جانب التطبيق ، سنقوم بوصفهم بالموديلات ونطويهم بعناية في قاعدة البيانات. سنطلق قائمة الإجراءات للتنفيذ ، ونضيف النتائج بعناية إلى قاعدة البيانات.
ستكون دورة التبادل مع TSD كما يلي:
- يرسل التطبيق على الأمر طلبًا إلى 1C.
- 1C تشكل استجابة وإرجاع هيكل مع النتيجة والبيانات. في 1C ، تقوم سجلات المعلومات بتجميع البيانات التي تم تغييرها في سياق TSD (خدمة الويب).
- بناءً على طلب من التطبيق ، يتم إرسال قائمة بالطرق التي سيتم استدعاؤها.
تم اختيار مثل هذا المخطط لأنه يمكن إيقاف تشغيل TSD أو إيقاف تشغيل الشبكة ، إلخ. ولكن لا شيء يمنعنا من وضع اللمسات الأخيرة على 1C بحيث عند إخطار البيانات ، إخطار تطبيق آخر (خدمة ويب) حول هذا الموضوع. مع هذا التبادل ، نعلم أن هناك بيانات جديدة. يسأل التطبيق ما هي البيانات الموجودة ، وتكرر الحلقة. يتم عرض مثال للتبادل في الرسم التخطيطي.
هذا كل شيء. إذا كان لديك أسئلة وتعليقات واقتراحات ، يرجى الكتابة في التعليقات.