Swiftyinsta: الطريق إلى "2.0"

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

• وسائط عالية الجودة [فيديو أو صورة]
• وسائط منخفضة الجودة [فيديو أو صورة]
• صورة مصغرة لوسائل الإعلام
• وظائف الإحصاء (حساب إجمالي الإعجابات ، التعليقات ، ...)
• ميزة تأخير أكثر مرونة (تحريرها في وقت التشغيل ، أو تشغيلها وإيقاف تشغيلها) بطرق أسهل.
• وإلخ....
  مما يوفر الكثير من الوقت للمستخدمين ، فهذه مجرد أفكار.
  نظرًا لأن المكتبة تنمو بمرور الوقت ، تحتاج المكتبة بالتأكيد إلى التوثيق .
  نحن بالتأكيد بحاجة إلى إصلاح اصطلاحات التسمية ، لأن هناك أخطاء كبيرة. وأحببت فكرة UserReference التي كانت لطيفة.
  هناك حاجة أيضًا لفرع development .
  يجب أن ندعو المستخدمين الآخرين للمساهمة ومشاركة الأفكار هنا لجعل الإصدار التالي أكثر قوة.
  شكرا لك مرة أخرى.
  يعتبر.

1. معالج أذونات أسهل ، وإسقاط نموذج Singleton وكل .shared ، مما يسمح للمستخدمين بتشغيل حسابات متعددة في نفس الوقت [قد أبدأ العمل على هذا اليوم أو غدًا ، إذا كان الأمر جيدًا]

لقد بدأت العمل على هذا. آلية المصادقة الفعلية في مكانها الصحيح ، فأنا فقط بحاجة لإنهاء إعادة كتابة كل طريقة على حدة لجميع المعالجات المختلفة (😱) ، وبعد ذلك كل ما يتطلبه الأمر هو إجراء نفس التغييرات على Siwa .

ما فعلته حتى الآن:

• اختفى APIBuilder و HttpSettings و RequestMessageModel . أنت الآن تقوم بإنشاء مثيل مباشرة APIHandler مع أخذ بعض Settings (اختياري) delay ، queues ، device (التحديث التلقائي User-Agent ) و session ( URLSession ).
• لا يوجد المزيد من البروتوكولات *Handler . لم يكن هناك نقطة حقيقية بالنسبة لهم. يمكن الآن استدعاء كل *Handler من خلال المثال APIHandler ( UserHandler هو .accounts ، FeedHandler هو .feeds ، إلخ. .) ، إنها خصائص كسولة وهي خاصة بالمثال نفسه. لقد فعلت الشيء نفسه مقابل HttpHelper و PaginationHelper (الملقب PaginationHandler 1.* ). يؤدي هذا إلى إزالة كل تكرار الكود حيث يجب إعادة كتابة كل طريقة مقابل APIHandler ، وهذا يعني " تعدد المهام " مع APIHandler s لعدة مستخدمين مسجلين مختلفين.
• تتم معالجة المصادقة الآن من خلال طريقة واحدة في المثال APIHandler : authenticate(with request: Login.Request, completionHandler: escaping (Result<(Login.Response, APIHandler), Error>) -> Void) ، حيث Login.Request enum يمكن أن يأخذ SessionCache item (وهو مشابه لـ 1.* SessionCache ) ، ويتم استخدامه لـ "تسجيل الدخول مرة أخرى" ومع Siwa (في المستقبل) ، أو LoginWebView (المعروف أيضًا باسم InstagramLoginWebView ) - وهو أبسط بكثير مما هو عليه الآن. مكالمة واحدة حرفيا وانتهيت. يؤدي هذا إلى إزالة كل تكرار الرمز بين Siwa و SwiftyInsta : إذا كنت تريد مصادقة "بدون رأس" ، فاستخدم Siwa وقم بتمرير sessionCache ، وإلا استخدم _web view_ in SwiftyInsta .
• كل طريقة واحدة تقبل إما _user_ pk أو username تأخذ الآن عنصر UserReference بدلاً من ذلك.

أعتمد على إنهاء كل شيء بحلول يوم غد ، وبعد ذلك يمكنني دفعه إلى development لمزيد من الاختبارات. أنا متحمس جدًا حقًا 💪
أنا أتطلع إلى معرفة أفكارك وآرائك.

يبدو أن التغييرات جيدة جدًا ، تمت إضافة فرع development أيضًا.
أنا أعمل على قائمة من الميزات والأدوات مثل Logger وما إلى ذلك.
وحول المصادقة ، تدعم هذه الطريقة الجديدة جميع أنواع المصادقة الثلاثة؟

1. تسجيل الدخول الخاص بواجهة برمجة التطبيقات
2. تسجيل الدخول عبر الويب
3. سيوة

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

وحول المصادقة ، تدعم هذه الطريقة الجديدة جميع أنواع المصادقة الثلاثة؟

في الوقت الحالي ، يدعم _web login_ و Siwa (نظريًا لأن Siwa يستخدم *.shared ، لذلك ستحتاج إلى التحديث ، لكنني أخطط للقيام بذلك في أسرع وقت ممكن - وهذا يعني أنه صحيح الآن ، في هذه الأثناء ، يمكنك اختباره فقط باستخدام _web login_). أشعر أن المصادقة username + password المقدمة مع SwiftyInsta لم تكن على قدم المساواة. ونظرًا لأنك قمت بعمل رائع مقابل ذلك في Siwa ، أشعر حقًا أنه يمكن إسقاطها من المكتبة الرئيسية (لكن هذا رأيي فقط).
أعتقد بشدة أن المستخدمين الذين يرغبون في إجراء مصادقة username + password يجب أن يفعلوا ذلك بشكل صحيح من البداية (أي مع Siwa ) ، دون المبالغة في تعقيد كل شيء آخر ، وتكرار قواعد التعليمات البرمجية. مرة أخرى ، فقط رأيي.
يمكن أيضًا إضافته مرة أخرى 😊

(حاولت إصلاح الأخطاء المطبعية والأخطاء على طول الطريق عندما رصدتها ، لكني أشعر أن بعض الأساليب - على سبيل المثال ، الطريقة الغريبة POST ، قد لا تعمل كما هو مخطط لها. لم تكن في 1.* وقد لا يكونون في 2.0 . Idk)

تضمين التغريدة
المزيد من الأفكار؟ أي تحديث؟

دعم watchOS و tvOS و macOS

كنت أفكر في دعم أنظمة تشغيل متعددة # 61
سأحاول العمل عليه لاحقًا.

ردود التنظيف

• وسائط عالية الجودة [فيديو أو صورة]
• وسائط منخفضة الجودة [فيديو أو صورة]
• صورة مصغرة لوسائل الإعلام
• وظائف الإحصاء (حساب إجمالي الإعجابات ، التعليقات ، ...)
• ميزة تأخير أكثر مرونة (تحريرها في وقت التشغيل ، أو تشغيلها وإيقاف تشغيلها) بطرق أسهل.
• وإلخ....

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

على سبيل المثال ، بدلاً من دفع MediaModel كما هي ، إعادة شيء أقرب إلى ...

public struct MediaModel: Codable {
    /// `MediaModelJSON` would be equal to current `MediaModel`.
    public let rawResponse: MediaModelJSON

    // Accesories
    public var pk: Int! { return rawResponse.pk }
    public lazy var date: Date! = { return self.rawRespone.takenAt.flatMap { Date(timeIntervalSince1970: $0) }}()
    /* etc */
}

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

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