Githawk: دفع الإخطارات

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

سوف أحب هذا بالرغم من ذلك

نعم ، أشعر بك. أعتقد أن حل درجة الحرارة المتوسطة الجيدة سيكون وظيفة bg التي تحمل شارات التطبيق. يمكننا أيضًا جدولة إشعارات الدفع المحلية بوظيفة bg! لكن بالنسبة لي شخصيًا ، فإن الدوافع ستكون مزعجة.

ومع ذلك يمكننا وضع كل هذا في الإعدادات.

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

أحيانًا (مثل خدمات الاقتراع) أميل إلى التفكير في تجربة المستخدم من أجل فهم الحل الأفضل.

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

أنا 100٪ مع أنه يجلب الخلفية بالرغم من ذلك. لقد أجريت اختبارًا شاملاً مع هذا خلال الأسبوعين الماضيين ووجدت أنه موثوق تمامًا. يتم التشغيل كل ساعة تقريبًا أو نحو ذلك مع تطبيقي الذي أستخدمه عدة مرات في اليوم.

أعتقد أنه حل قابل للتطبيق على المدى الطويل وكذلك tbh.

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

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

من خلال إضافة var var هذا ، سترى مجموعة من الإحصائيات عند بدء تشغيل تطبيقك في وحدة التحكم في تصحيح الأخطاء في Xcode. يمكن أن يكون مفيدا حقا. يقترحون أن التطبيق الخاص بك يجب أن يكون قادرًا على التشغيل في أقل من 400 مللي ثانية ، وأنا أميل إلى استهداف 2-300 شخصيًا.

من الواضح أنه يمكن التحقق من استخدام الطاقة من Xcode أو الأدوات.

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

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

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

1+ أن الهدف هو تسجيل التطبيق وإخطاره اختياريًا عندما تكون هناك أشياء جديدة عندما لا تكون في التطبيق. دعنا نتمسك بمهام bg في الوقت الحالي.

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

ربما يمكننا حتى تقسيم الإخطارات عن طريق الريبو؟

rnystrom رائع جدا

سؤال: حصل التطبيق على شارة على الشاشة الرئيسية ولكن عندما فتحته ، حصلت على رمز: tada: واضطررت إلى السحب للتحديث .. هل هذه هي الطريقة الحالية؟

لقد تم أيضًا إيقاف الشارة ، لكنني ما زلت أعرضها 😔

Sherlouk يمكنك إيقاف تشغيله باستخدام الإعدادات / الإشعارات / وقت الفراغ .. قم بإلغاء تحديد السماح بالإشعارات

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

هناك أيضًا مفتاح تبديل تمت صياغته ، أو على الأقل فسرته بواسطتي ، على أنه "إيقاف تشغيل الشارة" - والذي لا يعمل

حسنًا ، قصدت لك إصلاح هذا في هذه الأثناء :)

Sherlouk لذا أنت أعطيته disBled في الإعدادات لكن لا يزال شارة؟ آه القرف أعتقد أنني أعرف لماذا. سيتم إصلاح.

الإخطارات المحلية ستكون موضع ترحيب كبير. أنا حاليًا أستخدم تطبيق CodeHub (المدفوع) لتلقي الإشعارات ثم يتعين علي تذكر عدم النقر عليها ولكن لفتح GitHawk بدلاً من ذلك.

+1 للإخطارات المحلية.

أنا على الإطلاق 100٪ من أجل إخطارات الدفع الحقيقية من جانب الخادم. أعلم أن GitHub ليست خدمة مراسلة ، ولكن وقت رد الفعل لا يزال مهمًا ويمكن أن تساعد الاستجابة السريعة في زيادة سرعة التحويلات وبالتالي حل المشكلات بشكل أسرع. أنا في الواقع محير في GitHub نفسها ما زالت لم تقدم تطبيقًا رسميًا مع الدفع.

_{مرسلة مع GitHawk}

المشكلة الرئيسية التي أتوقعها هي مجرد حدود السعر ، لقد اقتربنا بالفعل من الوصول إليها بمجرد كوننا مستخدمًا نشطًا في التطبيق! هذا دون إجراء تصويت على الإشعارات كل بضع دقائق! من الناحية الفنية ، هذا ليس صعبًا للغاية ، لكننا سنحتاج إلى معرفة كيفية عمل ذلك دون قفل تطبيق github!

_{مرسلة مع GitHawk}

أنا أستخدم CodeHub للإشعارات. لست متأكدًا من كيفية القيام بذلك ولكن كان علي أن أدفع لتفعيل الميزة. علي فقط أن أتذكر فتح GitHawk بدلاً من ذلك.

هنا تذهب ، إنه مفتوح المصدر أيضًا: CodeHub-Push

_{مرسلة مع GitHawk}

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

_{مرسلة مع GitHawk}

أم أنها مجرد حالة نجربها ونرى ما إذا كانت مشكلة بالنسبة لمعظم الناس؟ قد يكون التتبع الأفضل لهذا الأمر مفيدًا - ماذا لو استخدمنا القماش ونشرنا حدثًا عندما تجاوز المستخدم الحد الأقصى للمعدل حتى نعرف متى تكون المشكلة؟ مرة أخرى لا جدوى من وضع حلول بديلة لمشكلة عدم الوجود!

_{مرسلة مع GitHawk}

من أين تأتي معظم استدعاءات API؟ هل من الممكن تحسينها عن طريق تخزين بعض البيانات مؤقتًا؟

_{مرسلة مع GitHawk}

بالنظر إلى CodeHub-Push (شكرًا schrodincat !) يبدو أن نهجهم هو _per-user_ (أنا ، أنت ، إلخ) وليس _per-app_ (GitHawk) ، لذا لا ينبغي أن يكون تحديد المعدل مشكلة؟

إن مشكلات حد المعدل التي أراها هي لكل مستخدم - يجب علينا ، وبالتأكيد في الماضي ، النظر في تحسين الأشياء ، ولكن في النهاية إذا فتحت 50 إشعارًا فهذا عدد كبير من مكالمات واجهة برمجة التطبيقات! لا يمكننا القيام بالكثير حيال ذلك!

_{مرسلة مع GitHawk}

rnystrom مع هذا الدمج ، هل سنتلقى إشعارات من GitHawk على iOS لأي تحديث في الريبو الخاص بنا على Github؟

mesqueeb أي شيء تتلقى إشعارًا بشأنه على الموقع.