
ما الفرق بين Telegram والمرسلين المشهورين الآخرين؟ إنه مفتوح!
يمتلك الرسل الآخرون أيضًا واجهة برمجة تطبيقات ، ولكن لسبب ما ، هل تُعرف البرقية بأنها الأكثر انفتاحًا والأكثر شعبية؟
بادئ ذي بدء ، لدى Telegram عميل مفتوح بالكامل حقًا
كود . لسوء الحظ ، لا نرى عمليات ارتكاب كل يوم مباشرة على GitHub ، ولكن لدينا رمز بموجب ترخيص مفتوح. تشير بنية Telegram إلى أن كلا من Bot و API يمتلكان نفس الأساليب تقريبًا - https://core.telegram.org/methods .
في الواقع ، ليست Telegram مجرد مراسلة للدردشة ، بل هي منصة اجتماعية ، يمكن الوصول إليها لأنواع مختلفة من التطبيقات. يمكنهم توفير رقائق إضافية للمستخدمين ، بدلاً من ذلك باستخدام شبكة جاهزة من المستخدمين والخوادم لتسليم الرسائل. يبدو الأمر جذابًا للغاية لدرجة أننا أردنا محاولة كتابة "عميلنا" في Telegrams.
جوهر التطبيق
نتعامل بشكل أساسي مع الخرائط والملاحة ، لذلك نظرنا على الفور إلى شيء متعلق بالموقع الجغرافي. لقد أحببت حقًا أنه في Telegram ، قبل جميع التطبيقات الأخرى ، كانت هناك طريقة ملائمة لمشاركة موقعك في الوقت الفعلي ( https://telegram.org/blog/live-locations ) وغالبًا ما أستخدمه: ساعدني في توجيه نفسي وإظهار طريقي و أهم شيء هو الإجابة على السؤال الرئيسي "متى تكون؟". من حيث المبدأ ، هذا يكفي لمعظم الناس ، ولكن كما هو الحال دائمًا هناك سيناريوهات عندما لا تكون الفرص البسيطة كافية. على سبيل المثال ، يمكن أن تكون مجموعة تتكون من أكثر من 10 أشخاص ، بأجهزة مختلفة (قد لا تكون بعض الأجهزة هواتف) وأشخاص مختلفين. سيكون من المناسب لهؤلاء الأشخاص تبادل الرسائل في مجموعة ، وكذلك رؤية بعضهم البعض يتحركون على الخريطة.
ركزنا على مهمة إنشاء قيمة إضافية لـ Telegram ، وعدم محاولة استخدامها لأغراض أخرى. لم نرغب في أن يرى الأشخاص الذين ليس لديهم عميل Telegram خاص فوضى الرسائل في الدردشة أو أي شيء غير واضح. الأشخاص الذين لديهم عميل "محسّن" لديهم فرص إضافية ، على سبيل المثال:
- إدارة الوقت بشكل أفضل عند إرسال المواقع في الوقت الحقيقي للدردشة.
- عرض موقع جهات الاتصال على الخريطة.
- الاتصال بدردشة أجهزة المرشد من خلال واجهة برمجة تطبيقات خارجية (Bot).
كيف فعلنا ذلك
لحسن الحظ ، جميع التعليمات البرمجية التي نكتبها هي مفتوحة المصدر ، لذا يمكنني على الفور إعطاء رابط لتطبيقها - تطبيق Bot وتنفيذ عميل Telegram على Kotlin .
بوت - الأساسيات
هناك الكثير من الوثائق والأمثلة حول تنفيذ برنامج Bot ، ولكن ما زلت أريد أن أتحدث وأتحدث عن بعض المزالق. بادئ ذي بدء ، كتبنا جانب الخادم
في Java واخترت مكتبة org.telegram: telegrambots. نظرًا لأن خادمنا هو SpringBoot عادي ، فإن التهيئة بسيطة للغاية:
// Gradle implementation "org.telegram:telegrambots:3.6" TelegramBotsApi telegramBotsApi = new TelegramBotsApi(); telegramBotsApi.registerBot(new TelegramLongPollingBot() {...});
السمة الرئيسية لنقل الموقع هي أنه يحتاج إلى التحديث بشكل متكرر ، ويحتاج البوت إلى تعديل الرسائل المرسلة بالفعل. إذا لم تكن هناك مثل هذه الفرصة ، فإن بوت سيقوم فقط بإرسال رسائل غير مرغوب فيها للدردشة وبالطبع ستكون ملحمة الفشل. الحمد لله Telegram يعطي البوت الحق في تعديل الرسائل لمدة 24 ساعة (الحد الأدنى ، وربما لفترة أطول).
هناك طرق عديدة لإرسال رسالة. هناك نوع Plain Text ، Venue ، Location ، Game ، Contact ، Invoice ، إلخ. يبدو أن الموقع كان مثاليًا لمهمتنا ، ولكن تم الكشف عن ميزة غير سارة. لا يمكن نقل الموقع إلا من جهاز واحد إلى حساب واحد أو بوت واحد في كل مرة! تخيل أن لديك هاتفين ومن هاتفين قمت بإرسال موقعك في دردشة واحدة. لذلك ، سيحدث خطأ على الخادم وستتوقف مشاركة الموقع الأولى ببساطة. يبدو أن هذه حالة عصبية بشكل واضح ، ولكن تخيل أن لديك الكثير من المنارات الصينية التي يمكنها إرسال الموقع إلى عنوان URL معين ، ولكن لا يمكنهم الإرسال مباشرة إلى Telegram. تكتب Bot ، الذي يلتقط من الخادم ويدفع البرقيات. هذا هو المكان الذي يخرج فيه أن Bot لن يتمكن من إرسال أكثر من رسالة منارة مع نوع الموقع. اتضح أن هذا أمر رائع للإرسال لمرة واحدة ، ولكنه غير مناسب للموقع المباشر.
الحل بسيط - إرسال رسائل نصية ، وسوف يقوم العميل بتحليل النص وإظهار المواقع على الخريطة. لسوء الحظ ، لن تظهر سوى الرسائل النصية في عميل Telegram القياسي ، ولكن يمكنك إدراج رابط هناك لفتح الخريطة.
بوت - مطبات
لسوء الحظ ، كان على بوت أن يعيد كتابة 2.5 مرة. المشكلة الرئيسية هي التصميم الخاطئ للتواصل.
- لسبب ما ، بدا في البداية فكرة جيدة إذا كان البوت سيكون مشاركًا كاملًا في الدردشة وإرسال الرسائل. ولكن ، هذا أمر سيئ من حيث خصوصية المراسلات ومن حيث التفاعل مع الروبوت. القرار الصحيح ، استخدم الروبوتات المضمنة . وبالتالي ، فمن المؤكد أن البوت لا يرى أي شيء آخر غير موقعه ويمكن استخدامه في أي دردشة. من الناحية الإنسانية ، من غير الثقافي سحب برنامج الروبوت الخاص بك إلى نوع من الدردشة العامة ، ولكن عليك التحدث إلى برنامج الروبوت واحد على واحد وتكوينه ، وبعد ذلك سيكون قادرًا على إرسال الرسائل اللازمة إلى أي دردشة محددة.
- هناك نوعان من التفاعل تاريخيا في Telegram Message API: الأزرار الموجودة تحت النص ((الأزرار المضمنة) [ https://core.telegram.org/bots/2-0-intro#switch-to-inline-buttons ]) وإجابات للبوت مباشرة نص. بشكل عام ، فإن إجابات البوت قديمة بشكل يائس. الأزرار أكثر تعقيدًا قليلاً من وجهة نظر التنفيذ ، ولكن يتم دفع هذا المبلغ بالكامل من خلال سهولة الاستخدام ويجب استخدامها لجميع المدخلات غير النصية.
- كمثال على الروبوت ، يمكنك مشاهدةvote_bot الشهير أوosmand_bot.
عميل برقية
لم نتمكن من العثور على أمثلة لعميل برقية جاهز ، باستثناء العميل الرئيسي ، لكن هيكل tdlib البسيط ساعدنا على إنشاء عميل أساسي في غضون يومين فقط.
إعداد Gradle: task downloadTdLibzip { doLast { ant.get(src: 'https://core.telegram.org/tdlib/tdlib.zip', dest: 'tdlib.zip', skipexisting: 'true') ant.unzip(src: 'tdlib.zip', dest: 'tdlib/') } } task copyNativeLibs(type: Copy) { dependsOn downloadTdLibzip from "tdlib/libtd/src/main/libs" into "libs" } task copyJavaSources(type: Copy) { dependsOn downloadTdLibzip from "tdlib/libtd/src/main/java/org/drinkless/td" into "src/org/drinkless/td" } dependencies { implementation fileTree(dir: 'libs', include: ['*.jar']) }
تقريبا كل الأجزاء الداخلية من Telegram مكتوبة بلغة C ++ ومن وجهة نظر Android ، فقط فئة API مرئية على طرق الوكيل 1.5 MB TdApi.java . من خلال مقارنة وثائق الروبوتات واسم الطرق ، يمكنك ببساطة معرفة مكان الانتقال.
تهيئة العميل باستخدام المعالج العالمي: fun init(): Boolean { return if (libraryLoaded) {
طلب صورة المستخدم: private fun requestUserPhoto(user: TdApi.User) { val remotePhoto = user.profilePhoto?.small?.remote if (remotePhoto != null && remotePhoto.id.isNotEmpty()) { downloadUserFilesMap[remotePhoto.id] = user client!!.send(TdApi.GetRemoteFile(remotePhoto.id, null)) { obj -> when (obj.constructor) { TdApi.Error.CONSTRUCTOR -> { val error = obj as TdApi.Error val code = error.code if (code != IGNORED_ERROR_CODE) { listener?.onTelegramError(code, error.message) } } TdApi.File.CONSTRUCTOR -> { val file = obj as TdApi.File client!!.send(TdApi.DownloadFile(file.id, 10), defaultHandler) } else -> listener?.onTelegramError(-1, "Receive wrong response from TDLib: $obj") } } } }
عميل برقية - المزالق
- التسجيل / تسجيل الدخول والخروج. عند التسجيل ، من الضروري أن تأخذ في الاعتبار سيناريوهات مختلفة: عندما يتم إرسال رمز الوصول عن طريق الرسائل القصيرة أو إلى عميل برقية آخر ، إذن ثنائي العامل ، إلخ. التحدي الأكبر هو الاختبار. أدى أي تفويض أكثر من 3 مرات إلى حظر الحساب لمدة 24 ساعة ، لذلك كان اختبار تسجيل الخروج ممتعًا بشكل خاص. على الرغم من حقيقة أن التسجيل مطلوب مرة واحدة فقط ، فمن المحتمل أن يكون هذا هو الجزء الأكثر صعوبة في التكامل.
- حدد كيف وبأي ترتيب لقراءة الرسائل. يمكن لأي عميل الوصول إلى جميع الرسائل في جميع المحادثات ، ولكن يجب قراءتها بالتتابع. في حالتنا ، يجب التخلص من 99٪ من الرسائل. أولاً ، لسبب ما ، قرأنا جميع الرسائل في آخر 3 أيام باستخدام تسجيل الدخول ، ولكن في وقت لاحق تسبب في حدوث مشاكل فقط ، وعندما أعيد تشغيلنا ، اختفت الرسائل. لذلك ، نقرأ الآن الرسائل الجديدة فقط ، وبالنسبة لتلك الرسائل التي نحتاجها ، نحفظ المعرّف في قاعدة البيانات الداخلية.
ماذا حدث
ربما ، بمعرفة جميع المزالق ، يمكن للمرء أن يفعل كل شيء بشكل أسرع عدة مرات ، ولكن تبين أن حوالي 1-2 أشهر لثلاثة أشخاص. يمكن العثور على التطبيق النهائي على Google Play .

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