iphone خوادم - كيفية مزامنة اي فون البيانات الأساسية مع خادم الويب ، ثم دفع إلى الأجهزة الأخرى؟




الانترنت ما (9)

لقد كنت أعمل على طريقة لمزامنة البيانات الأساسية المخزنة في تطبيق iPhone بين أجهزة متعددة ، مثل جهاز iPad أو Mac. لا توجد العديد من أطر المزامنة (إن وجدت) لاستخدامها مع Core Data على iOS. ومع ذلك ، كنت أفكر في المفهوم التالي:

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

هل هناك أي شيء يتوهم أن أكون أفكر فيه؟ لقد نظرت في أطر REST مثل ObjectiveResource ، والموارد الأساسية ، و RestfulCoreData . بالطبع ، هذه كلها تعمل مع Ruby on Rails ، والتي لا أرتبط بها ، لكنها مكان للبدء. المتطلبات الرئيسية لدي لحلي هي:

  1. يجب إرسال أي تغييرات في الخلفية دون الإيقاف المؤقت لمؤشر الترابط الرئيسي.
  2. يجب أن يستخدم النطاق الترددي أقل قدر ممكن.

لقد فكرت في عدد من التحديات:

  1. التأكد من أن مُعرّفات الكائن لمخازن البيانات المختلفة على أجهزة مختلفة موصولة على الخادم. بمعنى أنه سيكون لدي جدول معرفات الكائنات ومعرفات الأجهزة ، التي يتم ربطها عبر مرجع إلى الكائن المخزن في قاعدة البيانات. سيكون لدي سجل (DatabaseId [فريد لهذا الجدول] ، ObjectId [فريد من نوعه في قاعدة البيانات بأكملها] ، Datafield1 ، Datafield2) ، يشير حقل ObjectId إلى جدول آخر ، AllObjects: (ObjectId ، DeviceId ، DeviceObjectId). بعد ذلك ، عندما يدفع الجهاز لأعلى مجموعة تغيير ، فإنه يمر على طول معرف الجهاز والكائن من كائن البيانات الأساسي في مخزن البيانات المحلي. بعد ذلك ، يتحقق خادم السحابة من معرف العنصر والجهاز في جدول AllObjects ، ويبحث عن السجل لتغييره في الجدول الأولي.
  2. يجب أن تكون جميع التغييرات الطابع الزمني ، بحيث يمكن دمجها.
  3. سيتعين على الجهاز استطلاع الخادم ، دون استخدام الكثير من البطارية.
  4. ستحتاج الأجهزة المحلية أيضًا إلى تحديث أي شيء محفوظ في الذاكرة إذا تم استلام التغييرات من الخادم.

هل هناك أي شيء آخر مفقود هنا؟ ما هي أنواع أطر العمل التي يجب أن أنظر إليها لجعل ذلك ممكنًا؟


Answers

لقد فعلت شيئًا مشابهًا لما تحاول القيام به. اسمحوا لي أن أخبركم ما تعلمته وكيف فعلت ذلك.

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

أضفت أربعة حقول للمساعدة في المزامنة:

  1. sync_status - أضف هذا الحقل إلى نموذج البيانات الأساسي فقط. ويستخدمه التطبيق لتحديد ما إذا كان لديك تغيير معلق في العنصر. يمكنني استخدام الرموز التالية: 0 يعني عدم وجود تغييرات ، 1 يعني أنه في قائمة الانتظار ليتم مزامنتها إلى الخادم ، و 2 يعني أنه كائن مؤقت ويمكن تطهيرها.
  2. is_deleted - أضف هذا إلى الخادم ونموذج البيانات الأساسية. يجب ألا يحذف حدث الحذف فعليًا صفًا من قاعدة البيانات أو من طراز العميل لأنه لا يترك لك أي شيء للمزامنة مرة أخرى. من خلال الحصول على هذا العلم البسيط البسيط ، يمكنك تعيين is_deleted إلى 1 ، ومزامنته ، وسيكون الجميع سعداء. يجب أيضًا تعديل التعليمة البرمجية على الخادم والعميل للاستعلام عن العناصر غير المحذوفة باستخدام "is_deleted = 0".
  3. last_modified - أضف هذا إلى الخادم ونموذج البيانات الأساسية. يجب أن يتم تحديث هذا الحقل تلقائيًا بالتاريخ والوقت الحاليين بواسطة الخادم كلما حدث أي تغيير في هذا السجل. يجب ألا يتم تعديله من قبل العميل.
  4. guid - إضافة حقل معرّف فريد عالميًا (انظر http://en.wikipedia.org/wiki/Globally_unique_identifier ) إلى الخادم ونموذج البيانات الأساسي. يصبح هذا الحقل هو المفتاح الأساسي ويصبح مهمًا عند إنشاء سجلات جديدة على العميل. عادةً ما يكون المفتاح الأساسي الخاص بك هو عدد صحيح متزايد على الخادم ، ولكن يجب أن نضع في اعتبارك أنه يمكن إنشاء المحتوى دون اتصال ومزامنة في وقت لاحق. يتيح لنا المعرّف الفريد العمومي (GUID) إنشاء مفتاح أثناء عدم الاتصال.

على العميل ، قم بإضافة التعليمة البرمجية لتعيين sync_status إلى 1 على كائن النموذج الخاص بك كلما تغير شيء ما ويجب أن تتم مزامنته إلى الخادم. يجب أن تنشئ كائنات طراز جديد GUID.

التزامن هو طلب واحد. يحتوي الطلب على:

  • The MAX last_modified time stamp of your model objects. هذا يخبر الخادم أنك تريد فقط التغييرات بعد هذا الطابع الزمني.
  • مصفوفة JSON تحتوي على جميع العناصر باستخدام sync_status = 1.

يحصل الخادم على الطلب ويفعل ذلك:

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

يتلقى التطبيق الاستجابة ويفعل هذا:

  • فإنه يأخذ محتويات من مجموعة JSON وتعديل أو يضيف السجلات التي يحتوي عليها. يحصل كل سجل على sync_status من 0.

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



2017

فيما يتعلق بهذا السؤال القديم بشكل لا يصدق.

سيكون يشبه إلى حد كبير السؤال

"أريد أن أشتري جهازًا وهو هاتف يمكنني حمله معي - ولكن أيضًا استخدمه في العديد من مهام الحوسبة ، بل وتصفح WWW!"

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

في هذه الأيام ، سيكون إنشاء نظام OCC من الصفر جنونًا مثل إنشاء قاعدة بيانات SQL من البداية.

من الواضح ، بالنسبة لـ OCC ، والذي هو النموذج الأساسي لجميع التطبيقات غير العادية الآن ، فإنك تستخدم

  • Firebase
  • PubNub
  • Couchbase

وهكذا ، ببساطة ، التقدم الكبير في مجال التكنولوجيا البشرية في السنوات القليلة الماضية .

اليوم ، لن تحتاج بعد الآن إلى إنشاء OCC من الصفر

  • اكتب نظام التشغيل الخاص بك من الصفر

  • اكتب قاعدة بيانات SQL الخاصة بك من الصفر

  • اكتب الخط الخاص بك تقديم من الصفر

لاحظ أنه من الناحية المهنية ، لا يمكنك أن تكون "مبرمج ios" أو "مبرمج أندرويد" أكثر من ذلك.

من يهتم بمعرفة كيفية تخطيط الجداول والأزرار؟

أنت خبير في Firebase / أيا كان ، وكقضية جانبية عرضية تعرف كيفية تخطيط الأزرار ، إلخ على ios أو android.

القضية الوحيدة هي التي تستخدم BAAS - على سبيل المثال ، ربما PlayFab إذا كانت لعبة موجهة ، وربما PubNub إذا كان حقا رسالة مدفوعة ، ربما ably.io ، ربما kinvey إذا كنت الشركات - أيا كان.


لاحظ المستخدم لتحديث البيانات عبر إشعار الدفع. استخدم مؤشر ترابط الخلفية في التطبيق للتحقق من البيانات المحلية والبيانات على خادم السحابة ، في حين يحدث التغيير على الخادم ، وتغيير البيانات المحلية ، والعكس بالعكس.

لذلك أعتقد أن الجزء الأكثر صعوبة هو تقدير البيانات في أي جانب غير صالح.

آمل أن هذا يمكن أن يساعد ش


لقد قمت للتو بنشر الإصدار الأول من واجهة برمجة تطبيقات Core Data Cloud Syncing الجديدة ، والمعروفة باسم SynCloud. يحتوي SynCloud على الكثير من الاختلافات مع iCloud لأنه يسمح بواجهة مزامنة Multi-user. كما تختلف أيضًا عن واجهة برمجة التطبيقات للمزامنة لأنها تسمح ببيانات متعددة الجداول والعلاقات.

يرجى الاطلاع على المزيد في http://www.syncloudapi.com

يمكنك البناء باستخدام iOS 6 SDK ، وهو محدث تمامًا اعتبارًا من 9/27/2012.


أقترح بعناية قراءة وتنفيذ استراتيجية المزامنة التي ناقشها دان غروفر في مؤتمر iPhone 2009 ، والمتوفرة here كملف pdf.

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

تزامن الملفات مع أزواج الوقت المتجه

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

تصحيح:

يبدو أن ملف pdf في Grover لم يعد متاحًا (رابط معطل ، آذار 2015). UPDATE: الرابط متاح من خلال آلة Back Back here

تم إهمال إطار عمل Objective-C الذي أطلق عليه ZSync والذي طوره Marcus Zarra ، نظرًا لأن iCloud يبدو في النهاية أنه يدعم مزامنة البيانات الأساسية الصحيحة.


أولاً ، يجب إعادة التفكير في عدد البيانات والجداول والعلاقات التي ستحصل عليها. في حلّي ، قمت بتنفيذ المزامنة عبر ملفات Dropbox. ألاحظ التغييرات في MOC الرئيسية وحفظ هذه البيانات إلى ملفات (يتم حفظ كل صف كما json gzipped). إذا كان هناك اتصال بالإنترنت يعمل ، أتحقق من وجود أي تغييرات على Dropbox (صندوق Dropbox يعطيني تغييرات دلتا) ، وقم بتنزيلها ودمجها (أحدث عمليات الفوز) ، وأخيراً قم بوضع الملفات التي تم تغييرها. قبل المزامنة ، أضع ملف التأمين على Dropbox لمنع العملاء الآخرين من مزامنة بيانات غير كاملة. عند تنزيل التغييرات ، من الآمن تنزيل البيانات الجزئية فقط (على سبيل المثال ، اتصال الإنترنت المفقود). عند الانتهاء من التنزيل (كليًا أو جزئيًا) ، يبدأ تحميل الملفات إلى البيانات الأساسية. عندما تكون هناك علاقات غير محلولة (لا يتم تنزيل جميع الملفات) ، يتوقف عن تحميل الملفات ويحاول إنهاء التنزيل لاحقًا. يتم تخزين العلاقات فقط كـ GUID ، حتى أتمكن بسهولة من التحقق من الملفات التي سيتم تحميلها للحصول على تكامل البيانات الكامل. تبدأ المزامنة بعد إجراء تغييرات على البيانات الأساسية. إذا لم تكن هناك تغييرات ، فإنه يتحقق من التغييرات على دروببوإكس كل بضع دقائق وعلى بدء التطبيق. Additionaly عندما يتم إرسال التغييرات إلى الخادم أبعث البث إلى أجهزة أخرى لإعلامهم بالتغييرات ، حتى يتمكنوا من المزامنة بشكل أسرع. يحتوي كل كيان تمت مزامنته على خاصية GUID (يتم استخدام guid أيضًا كاسم ملف لملفات التبادل). لدي أيضًا قاعدة بيانات Sync حيث أقوم بتخزين تنقيح Dropbox لكل ملف (يمكنني مقارنته عندما تقوم دلتا Dropbox بإعادة تعيين حالته). تحتوي الملفات أيضًا على اسم الكيان ، وحالة (محذوفة / غير محذوفة) ، ودليل (نفس اسم الملف) ، ومراجعة قاعدة البيانات (للكشف عن عمليات ترحيل البيانات أو لتجنب المزامنة مع إصدارات التطبيق أبداً) وبالطبع البيانات (إذا لم يتم حذف الصف).

يعمل هذا الحل مع آلاف الملفات وحوالي 30 كيانًا. بدلاً من Dropbox يمكنني استخدام مخزن المفاتيح / القيمة كخدمة REST على شبكة الإنترنت التي أريد القيام بها لاحقًا ، ولكن ليس لدي وقت لهذا :) الآن ، في رأيي ، حلّي أكثر موثوقية من iCloud وهو أمر مهم جدًا ، لدي السيطرة الكاملة على كيفية عمله (لأنه رمز خاص بي).

الحل الآخر هو حفظ تغييرات MOC على شكل معاملات - سيكون هناك ملفات أقل بكثير يتم تبادلها مع الخادم ، ولكن من الصعب إجراء التحميل الأولي بالترتيب الصحيح في البيانات الأساسية الفارغة. تعمل iCloud بهذه الطريقة ، وكذلك حلول المزامنة الأخرى لديها نهج مماثل ، على سبيل المثال TICoreDataSync .

-- تحديث

بعد فترة ، هاجرت إلى Ensembles - أوصي بهذا الحل على إعادة اختراع العجلة.


أعتقد حل جيد لمشكلة GUID هو "نظام المعرفات الموزعة". لست متأكدًا من المصطلح الصحيح ، ولكن أعتقد أن هذا هو ما استخدمته مستندات خادم MS SQL للاتصال به (يستخدم SQL / يستخدم هذه الطريقة لقواعد البيانات الموزعة / المتزامنة). انها بسيطة جدا:

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

أعتقد أن هذا يتفوق على استخدام المعرفات الفريدة العمومية العشوائية لأن المعرفات الفريدة العمومية (GUIDs) غير آمنة 100٪ ، وعادةً ما تحتاج إلى أطول من معرّف قياسي (128-بت مقابل 32 بت). عادةً ما يكون لديك فهارس عن طريق رقم التعريف وكثيراً ما تحتفظ بأرقام التعريف في الذاكرة ، لذا من المهم الاحتفاظ بها صغيرة.

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


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

[[UIApplication sharedApplication] openURL:[NSURL URLWithString:@"twitter://status?id=12345"]];

تويتر: // المستخدم SCREEN_NAME = lorenb

تويتر: // المستخدم معرف = 12345

تويتر: // وضع معرف = 12345

تويتر: // جدول زمني

تويتر: // يذكر

تويتر: // رسائل

تويتر: // قائمة SCREEN_NAME = lorenb وسبيكة = ABCD

تويتر: // بعد رسالة = مرحبا٪ 20world

تويتر: // بعد رسالة = مرحبا٪ 20world وin_reply_to_status_id = 12345؟

تويتر: // بحث الاستعلام =٪ 23hashtag

ملاحظة: قد يكون من المهم التأكد من تثبيت Twitter على المستخدم أو سيؤدي ذلك إلى حدوث عطل. لذا أوصي بإضافة هذا في عبارة if قبل محاولة إرسالها إلى twitter.

[[UIApplication sharedApplication] canOpenURL:[NSURL URLWithString:@"twitter://"]];




iphone ios core-data sync data-synchronization