488 قسمت چهارم. آژاکس به عنوان مثال

ربات ها، و سرور را فراخوانی می کند، که به صورت پویا داده های پاسخ را بر اساس مقدار رشته پرس و جو ارسال شده ایجاد می کند. اولین پارامتر تابع LoaciXMLXSLTDoc () URL صفحه PHP است که سند XML را تولید می کند، که با یک رشته پرس و جو ارجاع به مقادیر فیلد HTML فرم O الحاق شده است. پارامتر دوم نام XSLT © است. فایل مورد استفاده در تبدیل داده XML. سومین پارامتر مورد نیاز تابع LoadXMLXSLTDoc () شناسه عنصر div است که نتایج جستجو را در آن قرار می دهد. شناسه نام رشته عنصر خروجی است، نه مرجع شی. در این مورد، رشته "نتایج" به عنوان شناسه استفاده می شود.

در مرحله بعد از متدهای DOM برای افزودن تصویر نشانگر به صفحه وب استفاده می کنیم. یک عنصر image © ایجاد می شود و ویژگی منبع تصویر O تنظیم می شود.این عنصر ایجاد شده به عنصر © div نتیجه اضافه می شود. به این ترتیب، وقتی تابع ما از onsubmit رویداد handler فرم فراخوانی می شود، یک فایل تصویری در صفحه قرار می گیرد. به طور کلی، برای کاربر مهم است که بازخورد بصری ایجاد کند - یک پیام یا تصویر - که نشان می دهد پردازش در حال انجام است. این باعث می‌شود که کاربر مکرراً روی دکمه نقص کلیک نکند و فکر کند که هیچ اتفاقی نمی‌افتد (به یاد داشته باشید، فرآیند Ajax "نامرئی" است).

آخرین مرحله فراخوانی تابع LoadXMLXSLTDoc () ® است که فرآیند ارسال اطلاعات به سرور را آغاز می کند. تابع LoadXMLXSLTDoc () که در بخش 12.4 توضیح داده شده است، تماس با شی ContentLoader () را مدیریت می کند که اسناد را از سرور درخواست می کند. با مشخص کردن یک موقعیت خروجی به عنوان یک پارامتر (به‌جای کدگذاری سخت مقدار در تابع LoadXMLXSLTDoc ())، می‌توانیم از تابع در همان صفحه بدون نیاز به چندین رویه یا دستور if برای جداسازی عملکرد استفاده مجدد کنیم. بنابراین، نتایج جستجوهای مختلف را به قسمت های مختلف صفحه هدایت می کنیم. با این حال، قبل از انجام همه این کارها، بیایید نگاهی به نحوه ایجاد اسناد XML و XSLT بر روی سرور بیندازیم.

12.3. کد سمت سرور: PHP

V در این قسمت یک پویایی برای پروژه ایجاد می کنیمسند XML با استفاده از PHP - یک زبان برنامه نویسی منبع باز محبوب (همانطور که می دانید، چارچوب Ajax با هر زبان یا پلت فرم سمت سرور سازگار است). سند XML به صورت پویا از مجموعه نتایج دریافت شده در پاسخ به درخواست مشتری به پایگاه داده تولید می شود. علاوه بر این، ما به شما نشان خواهیم داد که چگونه یک سند XSLT استاتیک ایجاد کنید که بر روی سرور میزبانی می شود و هر بار که یک فایل پویا درخواست می شود، بازیابی می شود. هر دوی این اسناد زمانی که شی ContentLoader در دو درخواست جداگانه درخواست می شود، به طور مستقل به مشتری بازگردانده می شوند (فهرست 12.7). کد XSLT سند XML پویا ما را در سمت مشتری تغییر می دهد و یک جدول HTML ایجاد می کند که به کاربر نمایش داده می شود.

فصل 12 جستجوی زنده با استفاده از XSLT 489

12.3.1. ایجاد یک سند XML

از آنجایی که ما از XSLT استفاده می کنیم، به یک سند XML ساختاریافته نیاز داریم که یک رکورد ساده از اطلاعات است تا فایل XSL بتواند یک تبدیل استاندارد را انجام دهد. در این پروژه زمانی که مشتری یک فایل PHP را درخواست می کند، یک فایل XML پویا ایجاد می کنیم.

توسعه ساختار XML

قبل از شروع ساخت فایل XML، باید یک قالب برای آن ایجاد کنیم. این الگو باید ساختار داده های بازگردانده شده توسط جستجو را منعکس کند. در فرمول مشکل انتخاب شده (دفترچه تلفن)، نام شرکت، نام تماس، کشور و شماره تلفن را برمی گردانیم. فهرست 12.3 یک الگوی پایه XML را با چهار فیلد نشان می دهد.

فهرست 12.3. فایل XML پایه

نام شرکت نام تماس نام کشور شماره تلفن

اولین مورد دفترچه تلفن است. مورد بعدی یک عنصر ورودی حاوی عناصر فرعی با تمام جزئیات است که با تمام شماره های تماس موجود در درخواست مرتبط است. اگر پنج نتیجه داشته باشیم، پنج عنصر ورودی در سند XML وجود خواهد داشت. نام شرکت در عنصر شرکت ظاهر می شود. علاوه بر این، نام شخص تماس، نام کشور و شماره تلفن را اضافه کرده ایم. ما فقط به فیلدهای مشخص شده محدود نمی شویم. بسته به اطلاعاتی که باید نمایش داده شود، می توان فیلدها را اضافه یا حذف کرد.

اگر نتیجه ای یافت نشد، به جای نمایش پیام هشدار، می توانید آیتمی ایجاد کنید که این اطلاعات را به کاربر نمایش دهد. STO بازگرداندن نتیجه به کاربر را برای ما آسان تر می کند و نیازی به کد اضافی در سمت مشتری برنامه نخواهد داشت. کد موجود در فهرست 12.4 تقریباً با کد فهرست 12.3 یکسان است، اما این بار متنی را به عناصر XML که می‌خواهیم به کاربر نمایش دهیم تزریق می‌کنیم تا نشان دهد هیچ نتیجه‌ای پیدا نشد.

فهرست 12.4. فایل XML بدون نتیجه

هیچ نتیجه ای

// О به جای نام شرکت، "No R e s u l t s" نمایش داده می شود N / A

490 قسمت چهارم. آژاکس در نمونه ها

// © "N / A" برای حاشیه های باقی مانده نمایش داده می شود

N / A

N / A

با این کد یک خط به کاربر نمایش می دهیم که نشان می دهد اطلاعات درخواستی موجود نیست. شرکت توصیفگر O اطلاعاتی را نمایش می دهد که نشان می دهد هیچ نتیجه ای وجود ندارد. سایر توصیفگرها 0 به کاربر می گویند که هیچ اطلاعاتی وجود ندارد. اگر نمی خواهیم متن "N / A" ("در دسترس نیست") نمایش داده شود، می توانیم به جای آن یک فضای بدون شکست اضافه کنیم که سلول های جدول را نشان می دهد. اگر اصلاً اطلاعاتی اضافه نکرده بودیم، سلول های جدول ظاهر نمی شدند.

همانطور که می بینید، فرمت XML ساختار بسیار ساده ای دارد. اگر این فایل XML ثابت بود، اضافه کردن یک مشترک جدید به فایل برای کاربر نسبتاً آسان بود. از آنجایی که به صورت پویا تولید می شود، ما به یک حلقه نیاز داریم که یک سند XML را روی مجموعه نتایج ایجاد کند.

ایجاد یک سند XML پویا

مثل همیشه یک سند XML روی سرور ایجاد می کنیم. با رعایت سیاست استفاده از مثال‌های مختلف سمت سرور در مثال‌ها، کد سمت سرور این فصل به زبان PHP نوشته شده است. به عنوان یادآوری، زیرساخت Ajax را می توان با استفاده از هر زبان سمت سرور ایجاد کرد و ما فقط نحوه پیاده سازی کد سمت سرور را بدون پرداختن به جزئیات توضیح خواهیم داد. بنابراین لیست 12.5 کد قسمت پشتی برنامه را نشان می دهد. کد یک پارامتر رشته کوئری را می گیرد و نتایج جستجوی پایگاه داده زیادی را ایجاد می کند. سپس مجموعه نتایج را طی می کنیم و با استفاده از الگوی فهرست 12.4 برای هر شماره تلفن دریافتی در پاسخ به درخواست، یک عنصر XML ایجاد می کنیم.

لیست 12.5. اسکریپت PhoneXML.php: سند XML را روی سرور ایجاد کنید

// O نوع MIME را اعلام کنیدهدر ("نوع محتوا: متن / xml")؛ اکو ("\ n");

// © اتصال به پایگاه داده

$ db = mysql__connect ("localhost"، "ajax"، "action"); rnysql_select_db ("ajax"، $ db)؛

$ result = mysql_query ("SELECT *

FROM Contacts WHERE نام تماس مانند "%". // © درخواست را پر کنید

$ _GET ["q"]. "%" "، $ Db);؟>

// О نتایج را بررسی کنید

if ($ myrow = mysgl_fetch_array ($ نتیجه)) (do (

// © از چندین نتیجه عبور کنید

فصل 12. جستجوی زنده با XSLT 491

001">

) while ($ myrow - mysql_fetch_array ($ نتیجه)); ) دیگر (

12.3.2. ایجاد یک سند XSLT

با استفاده از XSLT، فایل XML ما می تواند به یک جدول HTML زیبا با چند خط کد تبدیل شود. سند XSLT امکان تطبیق الگو را در صورت نیاز برای نمایش داده ها در هر قالب مورد نیاز می دهد. هنگامی که با یک الگو مطابقت دارد، ساختار الگو برای نمایش داده ها استفاده می شود. در این حالت از گره های درخت عبور می کنیم

492 قسمت چهارم. آژاکس به عنوان مثال

منبع wa با استفاده از XSLT. یک سند XSLT یک فایل XML ساخت یافته را می گیرد و آن را به قالبی تبدیل می کند که مشاهده، به روز رسانی و تغییر آن آسان است. در مورد ما، سند XSLT به صورت ایستا تعریف شده است.

ساختار XSLT

یک تبدیل XSLT حاوی قوانینی برای ترجمه درخت مبدا به درخت مقصد است. کل فرآیند XSLT تطبیق الگوی ساختار یافته است. هنگامی که عناصر درخت مبدا با ساختار داده شده مطابقت داشته باشند، درخت هدف مطابق با الگوی سند ایجاد می شود.

ساختار درخت هدف نباید به ساختار درخت مبدا مرتبط باشد. بنابراین، فایل XML اصلی را می توان به هر فرمتی که می خواهید تبدیل کرد. استفاده از نمای جدولی مجموعه داده ضروری نیست.

تبدیل XSLT یک stylesheet نامیده می شود زیرا استایل درخت مقصد را تعریف می کند. شیوه نامه شامل قوانین قالب دو قسمتی است. بخش اول یک ساختار الگوی است که گره های درخت منبع با آن مقایسه می شوند. هنگامی که یک تطابق پیدا کرد، پردازنده XSLT از قسمت دوم، الگوی حاوی توصیفگرها برای ساختن درخت منبع استفاده می کند.

ایجاد یک سند XSLT

ایجاد یک تبدیل XSLT برای این پروژه نسبتا آسان است. از آنجایی که می‌خواهیم جدولی دریافت کنیم، هیچ تطبیق الگوی فانتزی لازم نیست. ما به سادگی تمام گره های عنصر درخت منبع را به صورت متوالی طی می کنیم. در زیر ما یک قالب ایجاد می کنیم که یک جدول HTML با چهار ستون را تشکیل می دهد. فایل XSLT مربوط به این پروژه در فهرست 12.6 نشان داده شده است.

فهرست 12.6. فایل XSLT

"ISO-8859-l"؟>

// О نسخه XML و رمزگذاری را تنظیم کنید

// © Set XSLT Namespace"http://www.w3.org/1999/XSL/Transform">

// © قوانین قالب را تنظیم کنید

// O اضافه کردن عنصر جدول

// © ایجاد خط عنوان

فصل 12 جستجوی زنده با استفاده از XSLT 493

// 0 به ترتیب عناصر دفترچه تلفن را مرور کنید

select = "phonebook / entry"> // © فرمت خروجی

شرکت	مخاطب	کشور	تلفن

هنگامی که یک تبدیل XSLT ایجاد می کنید، باید کدگذاری و XML نسخه O را مشخص کنید و فضای نام XSLT © را مشخص کنید. فضای نام قوانین و مشخصاتی را که یک سند باید با آنها مطابقت داشته باشد را تعریف می کند. عناصر موجود در فضای نام XML در سند منبع شناسایی می شوند، اما در سند نتیجه شناسایی نمی شوند. همه عناصر ما در فضای نام XSLT با پیشوند xsl هستند. در مرحله بعد، می توانید یک قانون الگو ایجاد کنید - به دنبال ساختار / © باشید که با کل سند مطابقت دارد.

اکنون می توانیم شروع به ایجاد یک الگو برای جدول کنیم که نتایج ما را نمایش می دهد. ما یک توصیفگر جدول O اضافه می کنیم که به شناسه جدول نگاشت می شود. سپس ردیف سرصفحه جدول (C) وارد می شود که حاوی نام ستون هایی است که به کاربر نشان می دهد که جدول حاوی چه اطلاعاتی است.

با عبور متوالی از مجموعه گره های درخت منبع، بقیه ردیف های جدول را دریافت می کنیم. در این مورد، از یک حلقه برای هر © استفاده می شود، در فرآیند پردازش ورودی ها، گره های واقع در دفترچه تلفن / ورودی را خروجی می دهد.

از آنجایی که ما به طور متوالی در درخت سند قدم می زنیم، باید مقادیر ستون ها را انتخاب کنیم. برای انتخاب مقادیر از گره ها، از عملگر value-of برای بازیابی مقدار عنصر XML و افزودن آن به جریان خروجی تبدیل استفاده می شود. برای تعیین عنصر XML که متن آن را می خواهیم بازیابی کنیم، از ویژگی select با نام عنصر استفاده می کنیم. اکنون که فایل XSLT خود را تکمیل کرده‌اید و کد تولید پویا یک سند XML را ایجاد کرده‌اید، می‌توانید کد جاوا اسکریپت خود را تکمیل کنید و ببینید که چگونه ترکیب یک تبدیل XSLT با یک فایل XML ساختاریافته یک جدول قابل مشاهده را ایجاد می‌کند.

در مرحله بعد، ما به سمت کلاینت بازیابی فایل هایی که به تازگی با پاسخ HTTP ایجاد کرده ایم، بازگشته ایم.

بسیاری از مدرن برنامه های کاربردی برای سیستم عامل های تلفن همراه(iOS، Android، و غیره) در پشت سر هم با یک سرور کار می کند. برنامه ای با داده های قدیمی کاربرد خود را از دست می دهد. بنابراین، اطمینان از به روز نگه داشتن اطلاعات از سرور به دستگاه بسیار مهم است. این برای برنامه های آفلاین که باید بدون اینترنت کار کنند، صدق می کند. برای برنامه‌های کاملاً آنلاین که بدون اینترنت کار نمی‌کنند (یا بی‌فایده هستند) (مثلاً Foursquare، Facebook) ویژگی‌هایی وجود دارد که از حوصله این مقاله خارج است.

با استفاده از مثال یکی از برنامه های آفلاین ما، به شما خواهم گفت که از چه رویکردهایی برای همگام سازی داده ها استفاده کرده ایم. در نسخه های اول ما توسعه داده ایمالگوریتم های ساده و در آینده، با تجربه، آنها را بهبود بخشیم. توالی مشابهی در مقاله ارائه شده است - از روش های ساده ساده تا موارد پیچیده تر.

لازم به توضیح است که مقاله فقط در یک جهت به انتقال داده می پردازد: از سرور به دستگاه. در اینجا سرور منبع داده است.

مقررات کلی برای همه رویکردها

به عنوان مثال، ما انتقال فهرستی از ظروف ("ظروف") به دستگاه را در نظر خواهیم گرفت. ما فرض می کنیم که دستگاه درخواست URL "/ service / dishes / update" می کند، تبادل از طریق پروتکل http در قالب JSON انجام می شود ( www.json.org). سرور دارای جدول "ظروف" با فیلدهای زیر است: شناسه (شناسه رکورد)، نام (نام ظرف)، به روز شده (در لحظه ای که ظرف به روز شد، بهتر است فوراً پشتیبانی منطقه زمانی را انجام دهید، "YYYY-MM -DDThh: mm: ssTZD، به عنوان مثال، "1997 -07-16T19: 20: 30 + 01: 00")، is_deleted (نشانه رکورد حذف شده).

تذکر در خصوص حضور آخرین میدان. به‌طور پیش‌فرض، مقدار آن 0 است. در برنامه‌ای که موجودیت‌ها بین مشتری و سرور همگام‌سازی می‌شوند، حذف فیزیکی داده‌ها از سرور توصیه نمی‌شود (برای جلوگیری از خطا). بنابراین، is_deleted = 1 برای ظروف حذف شده تنظیم می شود، وقتی موجودی با is_deleted = 1 به دستگاه می رسد، از دستگاه حذف می شود.

با هر رویکردی که در زیر در نظر گرفته می شود، سرور آرایه ای از اشیاء را به دستگاه های JSON برمی گرداند (ممکن است خالی باشد):

[
(شناسه: ، نام: ، به روز شد: ، حذف شده است: },…
]

نمونه پاسخ سرور:

[
(ID: 5625، نام: "نان"، به روز شده: "2013-01-06 06:23:12"، حذف شده است: 0)
(ID: 23، نام: "بلغور پخته"، به روز شده: "2013-02-01 14:44:21"، حذف شده است: 0)، (

نام: "سوپ ماهی"،

به روز شده: "2013-08-02 07:05:19"،

اصول به روز رسانی داده ها در یک دستگاه

1. اگر عنصری که روی دستگاه است آمد و Deleted = 0 باشد، به روز می شود
2. اگر عنصری وارد شده باشد که در دستگاه نیست و Deleted = 0 باشد، اضافه می شود
3. اگر عنصری که روی دستگاه است آمد و Deleted = 1 باشد، حذف می شود
4. اگر عنصری وارد شده باشد که روی دستگاه نیست و Deleted = 1 باشد، هیچ کاری انجام نمی شود

رویکرد 1: همه چیز همیشه هماهنگ است

این ساده ترین روش است. دستگاه لیستی از غذاها را از سرور درخواست می کند و سرور کل لیست را ارسال می کند. هر بار که کل لیست می آید. مرتب نشده است.

درخواست مثال: null یا "()"

مزایای:

• منطق روی سرور ساده است - ما همیشه همه چیز را می دهیم
• منطق روی دستگاه ساده است - ما همیشه همه چیز را بازنویسی می کنیم

معایب:

• اگر لیست را اغلب (هر 10 دقیقه) درخواست کنید، ترافیک اینترنتی زیادی وجود خواهد داشت
• اگر به ندرت لیست را درخواست می کنید (یک بار در روز)، ارتباط داده ها نقض می شود

حوزه کاربرد:

• برای برنامه های کم ترافیک
• انتقال داده های بسیار نادر در حال تغییر (فهرست شهرها، دسته ها)
• انتقال تنظیمات برنامه
• در ابتدای پروژه اولین نمونه اولیه یک برنامه تلفن همراه

روش 2: فقط موارد به روز شده را همگام کنید

دستگاه فهرستی از ظروف را درخواست می کند که از همگام سازی قبلی به روز شده است. فهرست بر اساس "به روز" به ترتیب صعودی (اختیاری، اما راحت) مرتب شده است. دستگاه مقدار "به روز رسانی" را برای آخرین ظرف ارسال شده ذخیره می کند و در درخواست بعدی، آن را در پارامتر "lastUpdated" به سرور ارسال می کند. سرور لیستی از غذاهای جدیدتر از "lastUpdated" (به روز رسانی> lastUpdated) را ارسال می کند. در اولین درخواست به سرور "lastUpdated" = null.

درخواست مثال: (آخرین به روز رسانی: "2013-01-01 00:00:00")

در نمودار: "last_updated" مقداری است که در دستگاه ذخیره می شود. معمولاً یک جدول جداگانه روی دستگاه ایجاد می شود تا این مقادیر "آخرین_به روز رسانی" را برای هر موجودیت (ظروف، شهر، سازمان و غیره) ذخیره کند.

این رویکرد برای همگام سازی لیست های خطی ساده که در آن قوانین ورود برای همه دستگاه ها یکسان است، مناسب است. برای همگام‌سازی انتخابی‌تر، به «رویکرد 5: همگام‌سازی با اطلاعات موجود در دستگاه» مراجعه کنید.

این رویکرد معمولا اکثر نیازها را پوشش می دهد. فقط داده های جدید به دستگاه می آید، می توانید حداقل هر دقیقه همگام سازی کنید - ترافیک کم خواهد بود. با این حال، مشکلات مرتبط با محدودیت های دستگاه های تلفن همراه وجود دارد. اینها حافظه و پردازنده هستند.

رویکرد 3: همگام سازی به صورت دسته ای

رم دستگاه های موبایل کم است. اگر 3000 دیش در فهرست وجود دارد، تجزیه یک رشته json بزرگ از سرور به اشیاء روی دستگاه ممکن است باعث کمبود حافظه شود. در این صورت برنامه یا خراب می شود یا این 3000 ظرف را ذخیره نمی کند. اما حتی اگر دستگاه قادر به هضم چنین رشته ای باشد، عملکرد برنامه در لحظه های همگام سازی در پس زمینه کم خواهد بود (تأخیر رابط، پیمایش صاف و غیره) بنابراین، درخواست لیست ضروری است. در بخش های کوچکتر

برای انجام این کار، دستگاه یک پارامتر دیگر ("مقدار") را ارسال می کند که اندازه بخش را تعیین می کند. لیست باید بر اساس قسمت "به روز شده" به ترتیب صعودی مرتب شده ارسال شود. دستگاه، مشابه روش قبلی، مقدار "به روز رسانی" آخرین موجودیت ارسال شده را به خاطر می آورد و آن را به قسمت "lastUpdated" ارسال می کند. اگر سرور دقیقاً به همان تعداد موجودیت ارسال کرده باشد، دستگاه به همگام سازی ادامه می دهد و دوباره درخواست می کند، اما با "lastUpdated" به روز شده. اگر سرور تعداد کمتری را ارسال کرده باشد، به این معنی است که داده های جدید بیشتری ندارد و همگام سازی به پایان می رسد.

در نمودار: "last_updated" و "amount" مقادیری هستند که در اپلیکیشن موبایل... "Last_item" - آخرین موجودیت (ظروف) ارسال شده از سرور. جدیدتر از این مقدار است که لیست بعدی درخواست می شود.

درخواست مثال: (آخرین به روز رسانی: "2013-01-01 00:00:00"، مقدار: 100)

مزایای:

• دستگاه به اندازه ای که قادر به پردازش در یک زمان است داده دریافت می کند. اندازه سرو با آزمایش های عملی تعیین می شود. موجودیت های ساده را می توان 1000 در یک زمان همگام کرد. اما همچنین اتفاق می افتد که موجودیت هایی با تعداد زیادی فیلد و منطق پردازش ذخیره سازی پیچیده به طور معمول بیش از 5 قطعه همگام سازی می شوند.

معایب:

• اگر 250 ظرف با همان آپدیت وجود داشته باشد، با مقدار = 100، 150 ظرف آخر به دستگاه ها ارسال نمی شود. این وضعیت کاملا واقعی است و در رویکرد زیر توضیح داده شده است.

رویکرد 4: زمان بندی دسته ای صحیح

در رویکرد قبلی، ممکن است که اگر جدول حاوی 250 غذا با همان "به روز رسانی" (به عنوان مثال، "2013-01-10 12:34:56") و اندازه 100 باشد، آنگاه فقط 100 غذای اول باشد. رکوردها خواهد آمد 150 باقیمانده سخت بریده می شوند (به روز شده> lastUpdated). چرا این اتفاق می افتد؟ هنگامی که 100 رکورد اول درخواست می شود، lastUpdated روی "2013-01-10 12:34:56" تنظیم می شود و درخواست بعدی دارای شرایط خواهد بود (به روز رسانی> "2013-01-10 12:34:56"). حتی نرم کردن شرایط (به روز شده> = "2013-01-10 12:34:56") کمکی نمی کند، زیرا دستگاه به طور بی پایان 100 رکورد اول را درخواست می کند.

وضعیت با همان "به روز شده" چندان نادر نیست. به عنوان مثال، هنگام وارد کردن داده ها از یک فایل متنی، فیلد "به روز رسانی" روی NOW () تنظیم شد. وارد کردن یک فایل با هزاران خط ممکن است کمتر از یک ثانیه طول بکشد. همچنین ممکن است اتفاق بیفتد که کل دایرکتوری همان "به روز رسانی" را داشته باشد.

برای رفع این مشکل، باید از قسمتی از دیش استفاده کنید که حداقل در یک لحظه منحصر به فرد باشد ("به روز"). فیلد "id" در کل جدول منحصر به فرد است، بنابراین باید از آن در همگام سازی نیز استفاده کنید.

بنابراین، اجرای این رویکرد به این شکل است. سرور فهرستی را که بر اساس «به‌روزرسانی» و «id» مرتب شده است، برمی‌گرداند و دستگاه‌ها با استفاده از «lastUpdated» و پارامتر جدید «lastId» داده‌ها را درخواست می‌کنند. در سرور، شرایط انتخاب پیچیده تر است: ((به روز رسانی> lastUpdated) یا (به روز رسانی = lastUpdated و id> lastId)).

در نمودار: "last_updated"، "last_id" و "amount" مقادیری هستند که در برنامه تلفن همراه ذخیره می شوند. "Last_item" - آخرین موجودیت (ظروف) ارسال شده از سرور. جدیدتر از این مقدار است که لیست بعدی درخواست می شود.

رویکرد 5: همگام سازی با دانش از آنچه در حال حاضر در دستگاه است

رویکردهای قبلی این واقعیت را در نظر نمی گیرند که سرور واقعاً نمی داند داده ها با چه موفقیتی در دستگاه ذخیره شده است. دستگاه به دلیل خطاهای غیرقابل توضیح نمی تواند برخی از داده ها را ذخیره کند. بنابراین، دریافت تأییدیه از دستگاه مبنی بر حفظ همه (یا نه همه) ظروف خوب است.

علاوه بر این، کاربر اپلیکیشن می تواند اپلیکیشن را به گونه ای پیکربندی کند که تنها به بخشی از داده ها نیاز داشته باشد. برای مثال، کاربر می‌خواهد ظرف‌ها را فقط از 2 شهر از 10 شهر همگام‌سازی کند.

ایده پشت این رویکرد به شرح زیر است. سرور (در یک جدول جداگانه "stored_item_list") اطلاعات مربوط به ظروف موجود در دستگاه را ذخیره می کند. این فقط می تواند لیستی از جفت های "id - به روز شده" باشد. این جدول شامل تمام لیست‌های جفت ظرف «id - به‌روزشده» برای همه دستگاه‌ها است.

دستگاه اطلاعات مربوط به ظروف موجود در دستگاه (فهرست جفت های "id - به روز شده") را همراه با درخواست همگام سازی به سرور ارسال می کند. در صورت درخواست، سرور بررسی می‌کند که چه ظروفی باید روی دستگاه باشد و کدام‌ها اکنون هستند. سپس تفاوت به دستگاه ارسال می شود.

چگونه سرور تعیین می کند که چه ظروفی باید روی دستگاه باشد؟ در ساده‌ترین حالت، سرور درخواستی را ارائه می‌کند که فهرستی از جفت‌های "id - updated" از همه دیش‌ها را برمی‌گرداند (به عنوان مثال، SELECT id، به‌روزرسانی‌شده FROM dishes). در نمودار، این کار با روش "WhatShouldBeOnDeviceMethod ()" انجام می شود. این نقطه ضعف رویکرد است - سرور باید آنچه را که باید روی دستگاه باشد محاسبه کند (گاهی اوقات پرس و جوهای سنگین sql انجام می دهد).

سرور چگونه تشخیص می دهد که چه ظروفی روی دستگاه است؟ در جدول "stored_item_list" برای این دستگاه پرس و جو می کند و لیستی از جفت های "id - updated" دریافت می کند.

با تجزیه و تحلیل این دو لیست، سرور تصمیم می گیرد چه چیزی به دستگاه ارسال شود و چه چیزی حذف شود. در نمودار، این "delta_item_list" است. بنابراین، درخواست حاوی "lastUpdated" و "lastId" نیست، وظیفه آنها توسط جفت "id - updated" انجام می شود.

سرور چگونه از ظروف موجود در دستگاه مطلع می شود؟ در درخواست به سرور، یک پارامتر جدید "اقلام" اضافه می شود که حاوی لیستی از شناسه غذاهایی است که در آخرین همگام سازی به دستگاه ارسال شده است ("device_last_stored_item_list"). البته می توانید لیستی از شناسه تمام ظروف موجود در دستگاه ارسال کنید و الگوریتم را پیچیده نکنید. اما اگر 3000 ظروف روی دستگاه وجود داشته باشد و همه آنها هر بار ارسال شوند، هزینه های ترافیکی آن بسیار بالا خواهد بود. در اکثریت قریب به اتفاق همگام‌سازی‌ها، پارامتر "اقلام" خالی خواهد بود.

سرور باید دائماً "stored_item_list" را با داده هایی که از دستگاه در پارامتر "اقلام" آمده است به روز کند.

شما باید مکانیزمی برای پاک کردن داده های سرور در stored_item_list پیاده سازی کنید. به عنوان مثال، پس از نصب مجدد یک برنامه بر روی یک دستگاه، سرور فرض می کند که دستگاه هنوز به روز است. بنابراین هنگام نصب اپلیکیشن، دستگاه باید به نحوی به سرور اطلاع دهد تا لیست stored_item_list را برای این دستگاه پاک کند. در برنامه ما، یک پارامتر اضافی "clearCache" = 1 در این مورد ارسال می کنیم.

نتیجه

جدول خلاصه ای از ویژگی های این رویکردها:

№	یک رویکرد	حجم ترافیک(5 - بزرگ)	شدت کار توسعه(5 - بالا)	استفاده از حافظه دستگاه(5 - بالا)	صحت داده های موجود در دستگاه(5 - بالا)	شما می توانید یک دستگاه خاص را انتخاب کنید
1	همه چیز همیشه هماهنگ است	5	1	5	5	خیر
2	فقط به روز شده	1	2	5	3	خیر
3	همگام سازی به صورت دسته ای	1	3	1	3	خیر
4	همگام سازی صحیح در دسته ها	1	3	1	3	خیر
5	همگام سازی با آگاهی از آنچه قبلاً در دستگاه وجود دارد	2	5	2	5	آره

"صحیح بودن داده ها در دستگاه" احتمال این است که دستگاه حاوی تمام داده هایی است که توسط سرور ارسال شده است. در مورد رویکردهای # 1 و # 5، 100٪ اطمینان وجود دارد که دستگاه تمام داده های مورد نیاز خود را دارد. در موارد دیگر چنین تضمینی وجود ندارد. این بدان معنا نیست که نمی توان از روش های دیگر استفاده کرد. فقط این است که اگر بخشی از داده ها در دستگاه از بین برود، امکان تعمیر آن از سرور وجود نخواهد داشت (و حتی بیشتر از آن برای اطلاع از آن در سمت سرور).

شاید در صورت وجود تعرفه اینترنت نامحدود و وای فای رایگان، مشکل محدودیت ترافیک ایجاد شده توسط یک اپلیکیشن موبایل کمتر مطرح شود. اما در حالی که باید به سراغ انواع ترفندها بروید، رویکردهای هوشمندانه تری را ارائه دهید که می تواند هزینه های شبکه را کاهش دهد و عملکرد برنامه را افزایش دهد. همیشه کار نمی کند. گاهی اوقات بسته به موقعیت "ساده تر، بهتر" است. امیدواریم از این مقاله، بتوانید رویکردی را انتخاب کنید که به کارتان می آید.

به طور شگفت انگیزی توضیحات کمی از همگام سازی سرور در اینترنت و دستگاه های تلفن همراه... علاوه بر این، برنامه های بسیاری وجود دارد که طبق این طرح کار می کنند. برای علاقه مندان، چند لینک.

پشتیبان گیری

چرا به پشتیبان گیری در یک پلت فرم تلفن همراه نیاز دارید؟

کارشناسان می دانند که گاهی اوقات برنامه های تلفن همراه در 1C چقدر غیرقابل اعتماد هستند: ممکن است در هر زمان خطاهایی رخ دهد که به همین دلیل پایگاه کاربر به سادگی از بین می رود. در عین حال، ما با غیرقابل اعتماد بودن خود دستگاه ها روبرو هستیم: آنها می توانند شکسته شوند، گم شوند، ممکن است به سرقت بروند و کاربران می خواهند اطلاعات خود را حفظ کنند. و تا نسخه 8.3.9 ما مکانیزم پلتفرمی برای ذخیره یک نسخه پشتیبان نداشتیم.

از آنجایی که کاربران قبلاً دکمه "ذخیره یک کپی" نداشتند، توسعه دهندگان برنامه Boss مجبور بودند نسخه پشتیبان خود را تهیه کنند. ما چگونه این کار را انجام دادیم؟

داده های پایگاه داده را در قالب XML ذخیره می کنیم.

توصیه می شود چندین گزینه برای ذخیره کپی ها به کاربر ارائه دهید - اول از همه، برای مشتریان راحت است، آنها می توانند بهترین گزینه را برای خود انتخاب کنند: آپلود در ابر، ارسال به نامه خود، ذخیره در دستگاه.

بنابراین، توسعه دهندگان علاوه بر این، خود را بیمه می کنند. اگر مشکلی پیش آمد و مکانیسم ایجاد کپی در Google Drive یا Yandex Drive ناگهان خراب شد، همیشه می‌توانید به کاربر بگویید که توسعه‌دهنده در حال حاضر با یک خطا مواجه است، اما در حال حاضر او می‌تواند داده‌ها را به روشی جایگزین ذخیره کند. و کاربران راضی هستند زیرا می توانند در مورد داده های خود مطمئن باشند.

لزوما باید روی خدمات ابری تمرکز کرد، زیرا اگر دستگاه گم یا خراب شود و کاربر یک کپی را در همان دستگاه ذخیره کند، داده ها از بین می روند.

همچنین ما حتما نیاز به ایجاد نسخه پشتیبان را به کاربر یادآوری کنید.

در صورت تغییر پیکربندی چگونه می توان کپی ها را نگه داشت؟

وقتی از یک راه حل انبوه صحبت می کنیم، در مورد برنامه ای که دائماً در حال تغییر، تکامل و اصلاح است، رفتار مشتری باید در نظر گرفته شود. ممکن است کاربر بخواهد یک نسخه پشتیبان ذخیره شده در نسخه قدیمی برنامه را بازیابی کند که هیچ جزئیاتی ندارد. و سپس این وظیفه به وجود می آید: خواندن داده ها، سپس داده ها را مطابق منطق به روز رسانی نسخه قدیمی برنامه پر کنید. چگونه انجامش بدهیم؟ علاوه بر داده ها، خود ساختار داده را ذخیره کنید تا بعداً نحوه خواندن آن را بدانید.

چندین گزینه برای ذخیره سازی این ساختار داده وجود دارد، از جمله می توان آن را در خود پیکربندی ذخیره کرد. یعنی هر بار که نسخه جدیدی منتشر می شود، ساختار ابرداده نسخه قبلی را در یک طرح در پیکربندی نگه دارید.

فراموش نکنید که در یک برنامه تلفن همراه، پیکربندی نباید به همان اندازه رشد کند، ما باید برای مکان در آن ارزش قائل شویم، باید آن را تا حد امکان فشرده کنیم. اما برنامه در حال توسعه است و چنین طرح‌بندی‌های زیادی وجود خواهد داشت و با گذشت زمان بیشتر و بیشتر می‌شوند.

بنابراین، در مورد یک برنامه تلفن همراه، راه دیگری ترجیح داده می شود - ساختار ابرداده را مستقیماً در فایل داده ذخیره کنید... در خروجی، چنین فایلی را دریافت می کنیم، جایی که ابتدا برخی از داده های کمکی را ذخیره می کنیم - نسخه پیکربندی، طرح پیکربندی، مرزهای توالی، و پس از آن خود داده های کاربر را در قالب XML می نویسیم. علاوه بر این، در بخش "داده های کمکی" فایل، می توانید داده های مهم دیگری را نیز ذخیره کنید که به دلایلی نمی توانند در XML نوشته شوند.

ما طرح داده ای را که ذخیره کرده ایم در فایل می گیریم و بر اساس آن بسته XDTO را برای خواندن فایل می سازیم. ما یک شی مشابه را در پایگاه داده ایجاد می کنیم، آن را پر می کنیم، هنگام به روز رسانی، پردازش مجدد را انجام می دهیم و شی از قبل تمام شده را در پایگاه داده ذخیره می کنیم.

در زیر در تصویر می توانید راهنمایی در مورد نحوه زیبا نوشتن مدل XDTO این تنظیمات را مشاهده کنید. شرکتی که برنامه Boss را منتشر کرد، این کار را انجام داد، راه‌های مختلفی پیدا کرد، اما روی این گزینه برای ضبط طرح‌واره ابرداده تصمیم گرفت. هنگامی که خود فایل داده را باز می کنید، می توانید XML ساختار یافته معمولی را ببینید که قابل خواندن است، که تمام ابرداده های برنامه را فهرست می کند.

// طرح پیکربندی را بنویسید ModelXDTO = FactoryXDTO.ExportModelsXDTO ("http://v8.1c.ru/8.1/data/enterprise/current-config"); XDTO Factory.WriteXML (UploadFile، XDTO Model); // خواندن طرح پیکربندی Model XDTO = Factory XDTO. خواندن XML (خواندن XML، Factory XDTO. نوع ("http://v8.1c.ru/8.1/xdto"، "مدل")). UnloadFactory = New XDTOFactory (XDTOModel);

برای محافظت از کاربر، ضروری است که دوباره از او بپرسید که آیا نیاز به بازیابی نسخه پشتیبان دارد یا خیر. شاید او فقط آزمایش می کرد و روی همه دکمه های برنامه کلیک می کرد :) و اکنون ممکن است داده های فعلی از بین بروند. بنابراین، هنگام انجام اقدامات بالقوه "خطرناک"، ما همیشه مشخص می کنیم که آیا او واقعاً این را می خواهد و چگونه باید انجام شود. کاربر باید از اقدامات خود آگاه باشد.

هنگامی که ما در مورد یک راه حل مستقل صحبت می کنیم، زمانی که کاربر تمام داده ها را منحصراً در یک دستگاه تلفن همراه ذخیره می کند، باید مکانیزمی برای ایجاد پشتیبان وجود داشته باشد: کاربر می تواند دستگاه خود را از دست بدهد و سپس داده ها از بین می روند. و به نظر می رسد که اگر برنامه به طور مستقل کار نمی کند، اما به یک سرور مرکزی متصل است، کاربر نباید چنین مشکلی داشته باشد، زیرا اگر دستگاه گم شود، او به سرور متصل می شود، تمام اطلاعات خود را از سرور دوباره، و همه چیز درست خواهد شد.

با این حال، کاربران همیشه آنطور که ما انتظار داریم از پشتیبان گیری استفاده نمی کنند :) آنها اغلب از آنها برای "بازگرداندن" داده ها استفاده می کنند. این واقعاً رفتار بسیار عجیبی است، اما کاربران برنامه های تلفن همراه برای تشخیص اینکه در کجا ممکن است هنگام وارد کردن داده ها اشتباه کنند، تنبل هستند و به سادگی داده ها را به عقب برگردانده و داده های روز جاری را دوباره وارد می کنند. پس از تجزیه و تحلیل آمار کار با اپلیکیشن Boss، متوجه شدیم که این یک رویه عادی است و این رفتار کاربر بیشتر از چیزی است که انتظارش را داشتیم.

و اگر از همگام سازی با دستگاه های دیگر استفاده می کنید، باید آن را مدیریت کنید. در اینجا چندین راه حل وجود دارد:

• اتصال با سرور را قطع کنید و مشخص کنید که داده های موجود در آن همانطور که بوده باقی می مانند و کپی فقط در دستگاه کاربر بازیابی می شود.
• بهتر است کاربر به او اجازه دهد یک کپی را به یکباره در همه دستگاه ها بازیابی کند، زیرا قبلا چنین مکانیسم هایی را تجویز کرده است.

اینجا یک چیز دیگر وجود دارد. تا به حال، ما خودمان پشتیبان‌گیری‌ها را ذخیره می‌کردیم، کل فرآیند را کنترل می‌کردیم، وقتی کاربر دکمه «ذخیره یک کپی» را فشار می‌داد، دقیقاً در کد آن را ثبت می‌کردیم. همه اینها بعدا قابل پردازش است. در پلتفرم 8.3.9 امکان ذخیره نسخه پشتیبان دقیقاً توسط پلتفرم فراهم شد. و کاربر بدون اطلاع ما این کار را انجام می دهد. اگر از همگام سازی با پایگاه داده مرکزی استفاده شود، چنین سناریویی باید مدیریت شود. ما باید به نحوی در سرور خود متوجه شویم که کاربر یک نسخه ذخیره شده قبلی را بازیابی کرده است و باید نوعی راه حل به او ارائه دهد. ما نمی توانیم داده های ناهمگام داشته باشیم.

تبادل

وقتی در مورد یک راه حل خصوصی در یک پلت فرم تلفن همراه صحبت می کنیم، معمولاً مشتری داریم که مثلاً می خواهد از یک پلت فرم تلفن همراه برای نمایندگان فروش خود استفاده کند و به این ترتیب آنها داده ها را با یک پایگاه داده مرکزی تبادل می کنند. همه چیز در اینجا ساده است: یک پایگاه داده، چندین دستگاه، سرور را بالا می برید، با آن ارتباط برقرار می کنید. بنابراین مشکل تبادل بین دستگاه ها به راحتی قابل حل است.

اما اگر ما در مورد یک برنامه کاربردی انبوه صحبت می کنیم که در آن پایگاه داده های زیادی وجود دارد که هر کدام تعداد بسیار زیادی کاربر دارند، وضعیت پیچیده تر می شود. کاربران برنامه را از بازار دانلود کرده اند و می خواهند با یکدیگر همگام شوند. مثلاً شوهری برای حسابداری مالی شخصی اپلیکیشنی دانلود کرده و حالا می خواهد همسرش هم وصل شود و با هم در یک اپلیکیشن کار می کنند. کاربران زیادی وجود دارد، برنامه در حال توسعه، رشد است و نیاز به تعداد زیادی پایگاه داده وجود دارد. چگونه همه اینها را سازماندهی کنیم؟ کاربران شخصاً با توسعه دهندگان تماس نمی گیرند تا یک پایگاه داده جداگانه برای آنها ایجاد کنند و همگام سازی را فعال کنند. آنها می خواهند یک دکمه را فشار دهند و بلافاصله کار کنند. در همان لحظه.

چگونه باید ادامه داد؟ اینجاست که مکانیسم به اشتراک گذاری داده به کمک می آید. این به شما امکان می دهد یک پایگاه داده واحد را سازماندهی کنید، جایی که یک پیکربندی مشترک وجود دارد، اما در همان زمان، تعداد نامحدودی از پایگاه های کاربر در یک پایگاه داده مشترک ذخیره می شود.

بهترین بخش این است که می توانید کاربران را به صورت پویا، برنامه نویسی و بدون مشارکت ما اضافه کنید. در واقعیت، کاربران به سادگی روی دکمه "ثبت نام در سرور" کلیک می کنند و همه چیز به خودی خود اتفاق می افتد: یک پایگاه داده شخصی برای او در سرور ایجاد می شود و او می تواند بلافاصله شروع به کار در آن کند.

چگونه انجامش بدهیم؟ اولین و ساده ترین راه حل این است که با این مکانیزم پایگاه سرور خود را بنویسید. هنگامی که شرکت ما شروع به ساخت برنامه Boss و تبادل در آن کرد، در نسخه اول ما دقیقاً این کار را انجام دادیم: یک پایگاه داده سرور با مکانیزم اشتراک داده نوشتیم. همه چیز کار می کرد، به خصوص از آنجایی که هیچ چیز پیچیده ای وجود نداشت - جداکننده پایه یک پایه معمولی است.

اما بعد متوجه شدیم که چرخ را دوباره اختراع می کنیم :) در واقع یک راه حل آماده وجود دارد و قبلاً نکاتی را که ما حتی به آنها فکر نکرده بودیم در نظر گرفته است. این 1C است: تازه.

مقیاس پذیری سرویس در اینجا در نظر گرفته شده است: وقتی داده ها و پایگاه های داده زیادی وجود دارد چه باید کرد، چگونه با همه اینها رشد کنیم. یک نکته در مورد ایجاد نسخه های پشتیبان از مناطق داده وجود دارد: یعنی ما فقط از یک پایگاه داده مشترک نسخه پشتیبان تهیه نمی کنیم، بلکه از یک کاربر خاص کپی می گیریم. علاوه بر این، مکانیسم وجود دارد به گونه ای که کپی ها فقط زمانی ساخته می شوند که واقعاً مورد نیاز باشند. اگر یک کاربر به مدت یک هفته وارد پایگاه داده نشده باشد، از او کپی نمی کنیم، زیرا چیزی در آنجا تغییر نکرده است. یکی دیگر از ویژگی های Fresh این است که این سرویس مکانیزمی را برای کاهش بار روی سرور پیاده سازی می کند که زمانی که پایگاه داده های زیادی دارید بسیار مهم است.

به طور کلی، Fresh برای ما چیزی جدید و جالب است. کم کم سعی می کنیم آن را کشف کنیم، اما در بیشتر موارد فقط از کار آن راضی هستیم.

انتقال داده. نحوه پیاده سازی آن برای تبادل بین دستگاه ها

این پلت فرم دو مکانیسم را ارائه می دهد - خدمات SOAP و http. نکات ظریفی در مورد نحوه دسترسی به این خدمات در زمانی که مکانیسم اشتراک داده درگیر است وجود دارد. به طور خاص، شما باید پارامترهایی را اضافه کنید که نشان دهنده تعداد خاصی از منطقه ای است که به آن دسترسی دارید، زیرا پلت فرم نمی تواند تعیین کند که به کدام پایگاه داده با نام کاربری دسترسی داشته باشد. علاوه بر این، یک کاربر می تواند با چندین پایگاه داده در یک پایگاه داده کار کند (تصویر را ببینید).

در مورد خدمات، برنامه Boss تبادل فوری را اجرا می کند: یک کاربر داده ها را وارد می کند و دیگری آن را دریافت می کند. کاربران برنامه های تلفن همراه به این واقعیت عادت کرده اند که همه چیز فورا اتفاق می افتد، بنابراین ما فکر کردیم که از کدام سرویس استفاده کنیم - SOAP یا http. سرعت اتصال نقش کلیدی داشت. در http سرعت اتصال بسیار بالاتر است و هنگام اتصال از طریق SOAP توضیحاتی در مورد سرویس دریافت می کنیم که سنگین است و بارگذاری آن زمان زیادی می برد. پلتفرم راهی برای ذخیره توضیحات یک سرویس دارد، اما به دلیل پارامترهایی که به صورت پویا اضافه می کنیم، نمی توانیم از منابع WS استفاده کنیم. علاوه بر این، دسترسی به خدمات http در تجربه ما راحت تر و انعطاف پذیرتر است.

بنابراین، هدف ما اجرای تبادل در زمان واقعی است. یعنی سعی می کنیم کاری نکنیم کاربر مجبور شود جایی برود، روی دکمه ای کلیک کند، به این فکر کند که داده های او چقدر مرتبط هستند، آیا باید آنها را به روز کند ... داده ها باید همیشه برای کاربران مرتبط باشند. آنها به کار در پیام رسان های فوری عادت دارند - یکی داده ها را ارسال کرد، دیگری بلافاصله آن را دریافت کرد. همه چیز فورا اتفاق می افتد. همین امر در مورد برنامه های مربوط به تجارت نیز صدق می کند: یکی از فروشنده ها فروش را صادر کرده است، دیگری باید فوراً بدون انجام هیچ اقدامی وضعیت فعلی را ببیند.

بنابراین، برنامه Boss از مشاغل پس‌زمینه برای مبادلات استفاده می‌کند. پس از نوشتن هر داده در پایگاه داده، یک کار پس زمینه شروع می شود که تبادل را آغاز می کند. بخش اول ارسال اطلاعات به سرور است. سپس دستگاه های دیگر باید بدانند که داده های جدیدی وجود دارد. برای این کار از اعلان های PUSH استفاده می کنیم. این طرح در حال حاضر کار می کند و به اندازه کافی سریع کار می کند.

اما ما آن را حتی سریع‌تر می‌خواستیم، زیرا در زمان واقعی کار می‌کنیم و معمولاً داده‌های کمی داریم. ما XML کوچک داریم، اما در عین حال یک پیام با این داده ها از دستگاه اول به سرور می فرستیم، سرور PUSH را به دستگاه دیگری می فرستد و سپس دستگاه دوم پس از دریافت PUSH، مبادله را از سمت خود آغاز می کند. سرور را آدرس می دهد و داده ها را درخواست می کند، این داده ها را دریافت می کند و سپس پاسخی مبنی بر دریافت داده ارسال می کند. این مدت زمان زیادی است، اما خود داده ها بسیار اندک بودند.

ما به این فکر کردیم که چگونه می توان این روند را تسریع کرد.

برای انجام این کار، متوجه شدیم که PUSH حاوی چه چیزی است، چگونه می توان از آن استفاده کرد. معلوم شد که PUSH حاوی فیلدهایی مانند داده و متن است. اسناد iOS و Android شامل محدودیت‌هایی در اندازه پیام‌های PUSH هستند، اما این برای ما کافی نبود و می‌خواستیم آن را به صورت تجربی کشف کنیم. و بررسی کردیم که مجموع کاراکترهای معتبر برای iOS 981 کاراکتر و برای اندروید 3832 کاراکتر باشد. در مورد دوم، استفاده از محدودیت کاملاً ممکن است؛ یک یا چند شی پایه را می توان در چنین حجمی جمع کرد. و سپس توسعه دهندگان شرکت طرح را کمی تغییر دادند. وقتی داده‌های زیادی وجود ندارد، آن‌ها را از یک دستگاه ارسال می‌کنیم، آن را روی سرور دریافت می‌کنیم، آن‌ها را در PUSH بسته‌بندی می‌کنیم و مستقیماً به دستگاه دیگری در آن ارسال می‌کنیم. این طرح کوتاهتر شد و مبادله حتی سریعتر شروع شد :)

نکته مهم استفاده از PUSH آزار نرساندن کاربران است.

خلاص شدن از این وضعیت بسیار آسان است: فقط تعداد زیادی پیام PUSH برای کاربر ارسال نکنید :) اگر او اکنون در برنامه کار می کند، می توانید پیام های زیادی ارسال کنید. هنگامی که پلتفرم در حال اجرا است، کاربر PUSH را نمی بیند، همه چیز به طور خودکار برای او اتفاق می افتد. اما وقتی برنامه بسته می شود، مشتری پیام های خوانده نشده زیادی دارد. بنابراین، تا زمانی که پاسخی از دستگاه دریافت نشود مبنی بر اینکه برنامه در حال اجرا، فعال است و PUSH قبلی قبلاً پردازش شده است، به هیچ وجه نباید PUSH بعدی ارسال شود.

یکی دیگر از نکات ظریف مبادله کار از طریق وب است. ما باید از ناهمزمانی حداکثر استفاده را ببریم. شما نمی توانید طبق معمول کار کنید - کد را بنویسید - تابع را فراخوانی کنید - منتظر بمانید تا اجرا شود - پاسخ را دریافت کنید - و همه چیز اوکی است. اگر از طریق وب کار می کنید، همچنان با محدودیت های خاصی مواجه خواهید بود، به عنوان مثال، اینترنت ناپایدار، وقفه های زمانی فعال در هنگام انجام عملیات طولانی مدت. بنابراین باید از قبل روی معماری فکر کرد.

بیایید به مثالی از ثبت یک دستگاه نگاه کنیم، وقتی کاربر می خواهد ثبت نام کند در یک برنامه چه اتفاقی می افتد. او مدتی سوابق را نگه می دارد، داده های زیادی را وارد کرده است، اما بعد از آن می خواهد که فروشنده نیز با این پایگاه داده کار کند. کاربر بر روی دکمه "ثبت نام" کلیک می کند. در ابتدا همه چیز بسیار ساده بود: آنها داده های او را گرفتند، روی سرور ضبط کردند و، لطفا، می توانید کار کنید و کاربران را به هم متصل کنید. اما پس از آن ما با وضعیتی مواجه شدیم که برای برخی از کاربران پایگاه های داده روی دستگاه تا زمان ثبت نام قبلاً بسیار رشد کرده بود. و این طرح دیگر کار نمی کند، زیرا در حالی که کل پایگاه داده روی سرور ضبط می شد، زمان اتصال راه اندازی شد یا اینترنت به سادگی قطع شد. بنابراین، ما یک تماس همزمان را با تعداد زیادی تماس کوتاه جایگزین کردیم. اکنون داده ها به جای انتقال یکباره به اشتراک گذاشته می شوند. ما به هیچ وجه منتظر پردازش و ضبط داده ها توسط سرور نیستیم. ما داده ها را ارسال کردیم، پاسخی دریافت کردیم که داده ها دریافت شده است، اتصال را بسته ایم. به صورت دوره ای باید از سرور نظرسنجی کنید که در آنجا چه اتفاقی می افتد و چگونه است و در این بین یک کار پس زمینه روی سرور در حال اجرا است که داده های دریافتی را ثبت می کند. به این ترتیب ما تماس های زیادی با سرور دریافت می کنیم، اما ما تضمین می کنیم که همه چیز خوب پیش خواهد رفت. و نه مهلت زمانی و نه بی ثباتی اینترنت مانع از آپلود تمام داده ها در سرور نمی شود.

به روز رسانی ها

تبادل بین دستگاه ها با نسخه های مختلف برنامه

از آنجایی که صحبت از یک اپلیکیشن انبوه است که به بازار عرضه می شود، باید برخی از ویژگی های به روز رسانی و فرآیند تبادل داده را در نظر بگیریم.

اگر برنامه‌ای را برای یک شرکت منتشر کرده‌اید و تصمیم گرفته‌اید آن را به‌روزرسانی کنید، معمولاً فقط دستوری می‌دهید تا همه کارمندان برنامه جدید را با هم نصب کنند. این کار را نمی توان با کاربرانی که برنامه را از بازار دانلود کرده اند انجام داد. شما اصلا نمی توانید به آنها بگویید چه کاری انجام دهند. به عنوان مثال، آنها در یک برنامه کاربردی کار می کنند و نمی خواهند آن را در حال حاضر یا هرگز به روز کنند. آنها به روز رسانی خودکار ندارند، بنابراین زمانی که چندین دستگاه به پایه مرکزی متصل می شوند و همه آنها با نسخه های مختلف هستند، وضعیت کاملاً رایج است. دلیل دیگر این پدیده زمان انتشار در بازارها است: برای iOS و اندروید متفاوت است. ما اغلب موارد کلیدی را پیاده سازی می کنیم، به عنوان مثال، باگ های مهم را رفع می کنیم، و نمی خواهیم منتظر بمانیم تا iOS نسخه جدید را به مدت دو هفته بررسی کند، حداقل فقط برای اندروید می خواهیم، ​​اما همین الان آپدیت را منتشر می کنیم.

ما حق نداریم به کاربران دستور دهیم. اگر بخواهند به روز می شوند و اگر نه هیچ کاری نمی کنند. تصویر نسبت نصب‌های برنامه Boss بر اساس نسخه‌های موجود در GooglePlay و همچنین آمار سرور ما را نشان می‌دهد - نسبت واقعی نسخه‌های برنامه نصب شده بر روی دستگاه‌هایی که طی هفته گذشته داده‌ها را با سرور رد و بدل کرده‌اند. در اینجا مجموعه ای برای کار وجود دارد. اینها نسخه های مختلف و متادیتا متفاوت هستند. و ما باید همزمان یک تبادل معمولی ترتیب دهیم :)

توسعه دهندگان با وظایف زیر روبرو هستند:

• همه اینها باید کار کنند. کاربران نباید از اینکه فراموش کرده‌اند ارتقا دهند احساس ناراحتی کنند. اصلاً نباید متوجه آن شوند. به روز شده - بهتر، خوب و خوب است.
• ما باید از امنیت داده ها اطمینان حاصل کنیم. به عنوان مثال، یک کاربر یک دایرکتوری و یک ابزار جدید دارد، در حالی که کاربر دیگری هنوز ندارد. علاوه بر این، اگر کاربری که جزئیات جدیدی ندارد، چیزی را در دستگاه خود تغییر دهد، داده های دستگاه های دیگر نباید از بین بروند.
• ما باید اطمینان حاصل کنیم که هنگام ارتقاء به نسخه جدید، داده ها به روز می شوند. هنگامی که کاربر تصمیم می گیرد که آماده به روز رسانی است، باید به طور خودکار تمام اطلاعات جدیدی را داشته باشد که فقط به دلیل داشتن نسخه قدیمی نداشته است.

ما چگونه این کار را انجام دادیم؟

1. ما از 2 طرح تبادل روی سرور استفاده می کنیم. اولی برای اشتراک گذاری بین دستگاه ها و دومی برای به روز رسانی است. به عنوان مثال، ما یک کتابچه راهنمای کاربر برای یک کاربر ارسال کردیم، اما او واحد اندازه گیری، یعنی داده های ناقص را ندارد. ما باید این را به خاطر بسپاریم. و زمانی که او به روز شد، باید تمام اطلاعاتی را که نداشت برای او ارسال کنیم. این همان چیزی است که طرح مبادله دوم برای آن است.

2. برای نوشتن و خواندن اشیا، از همان مکانیزمی استفاده می کنیم که برای پشتیبان گیری استفاده می شود، یعنی نسخه ابرداده را ذخیره می کنیم. در این مورد، ما با سرور کار می‌کنیم و می‌توانیم هر چیزی را که می‌خواهیم مستقیماً به پیکربندی اضافه کنیم، بنابراین به سادگی طرحواره‌های ابرداده را در قالب طرح‌بندی به هنگام توسعه برنامه اضافه می‌کنیم.

نحوه نظارت بر خطاهای بزرگ در هنگام تبادل و روی سرور

ابتدا باید در دسترس بودن خود سرور را کنترل کنید. این اتفاق برای سرورها می افتد - آنها سقوط می کنند. ما چیز خاصی برای مانیتورینگ اختراع نکردیم، بلکه فقط یک ربات در تلگرام پیدا کردیم که اگر مشکلی وجود داشته باشد، فریاد می زند. هر دقیقه عملکرد سرور را بررسی می کند و اگر سرور به طور ناگهانی در دسترس نباشد شروع به جیغ زدن می کند، ادمین ها آن را می بینند و سرور را بالا می آورند.

ما همچنین گزارش خطا را از لاگ جمع آوری می کنیم. همچنین هیچ چیز ماوراء طبیعی نیست - ما فقط هر سه ساعت یک بار گزارشی از خطاها را جمع آوری می کنیم، آنها را به ایمیل ارسال می کنیم و به طور دوره ای آنها را بررسی می کنیم. این به دیدن مشکلات رایج و برخی از موقعیت های استثنایی کمک می کند. خواندن نامه های خود، ردیابی و رفع سریع خطاها کار سختی نیست. اما این به شما امکان می دهد تا به سرعت مشکلاتی را که می توانند با رشد پایگاه های داده رشد کنند، شناسایی و حل کنید.

نکته مهم دیگر - مطمئن شوید که به کاربر فرصت "شکایت" می دهید. این وضعیت ما را در نظر آنها بهبود می بخشد و ما را نجات می دهد. کاربرانی هستند که ما آنها را "هیستریک" می نامیم که با کوچکترین اشتباهی شروع به ارسال یک سری پیام از طریق پست برای ما می کنند که هیچ چیز کار نمی کند ، پایگاه داده بارگیری نمی شود ، همه چیز به طرز وحشتناکی بد است. اما گاهی اوقات آنها واقعا ما را نجات می دهند، زیرا گاهی اوقات آنها چنین اشکالاتی را پیدا می کنند که دیگران به طور معجزه آسایی آنها را پیدا نکرده اند، اشکالات جدی.

کاربر را نمی توان بترساند. نه پیام های ترسناک، نه چیز دیگری. آنها باید همه چیز را به زیبایی توضیح دهند و پیشنهاد شکایت کنند. و ما قول می دهیم همه چیز را حل کنیم. سپس کاربران خوشحال می شوند، زیرا می بینند که از آنها مراقبت می شود و بلافاصله باور می کنند که به آنها کمک می شود :)

این مقاله بر اساس نتایج گزارش خوانده شده در کنفرانس INFOSTART EVENT 2016 DEVELOPER نوشته شده است. مقالات بیشتری را می توان خواند.

در سال 2020، ما از همه دعوت می کنیم تا در 7 نشست منطقه ای و همچنین سالگرد رویداد INFOSTART 2020 در مسکو شرکت کنند.

آفلاین بودن در گذشته، امروز آنلاین بودن یک امر ضروری است. حداقل برای دنیای تجارت مدرن. ارائه محصولات و خدمات برند، سفارش و تحویل آنلاین، حفظ پایگاه مشتری، برقراری ارتباط با مشتریان و موارد دیگر - همه اینها بدون حضور اینترنت غیرممکن است. اگر به یک برنامه نیاز دارید، باید هم Front-end (رابط وب) و هم Back-End (پشت انتهای برنامه خود) داشته باشید. و اگر می خواهید بتوانید محتوای برنامه خود را بدون دخالت توسعه دهندگان ویرایش کنید، به یک پنل مدیریت خوب نیاز دارید.

در حالی که Front-end در فضای برنامه های تلفن همراه با استفاده از فناوری هایی مانند X-Code و Java ساخته شده است، Back-end که پایگاه داده و تمام منطق برنامه در آن ذخیره می شود، به دانش حرفه ای یک زبان برنامه نویسی سمت سرور نیاز دارد. یک مثال خوب PHP است که مسلماً محبوب ترین زبان برنامه نویسی است که تقریباً برای هر توسعه سمت سرور استفاده می شود. این رهبر بلامنازع است.

کاربردهای زیادی برای PHP وجود دارد: وب سایت های ایستا و پویا + سیستم های مدیریت محتوای سفارشی، رسانه های اجتماعی، سیستم های تخصصی CRM، نرم افزارهای تجارت الکترونیک و غیره. البته قطعات سرور و کنترل پنل رایگان یا ارزان قیمت نیز وجود دارد. با این حال، در بسیاری از موارد سطح مورد نیاز راحتی، سفارشی‌سازی و ارتقاء را فراهم نمی‌کنند.

برنامه نویسان ما با فناوری ها کار می کنند تا طیف گسترده ای از راه حل ها را برای اهداف، نیازها و الزامات مختلف کسب و کار پیاده سازی کنند. ما سیستم مورد نیاز هر پروژه را به صورت جداگانه تجزیه و تحلیل می کنیم و از نرم افزارهای مختلف سرور تخصصی برای عملکرد بهینه برنامه تلفن همراه شما استفاده می کنیم.

اگر به دنبال تیمی هستید که بتواند شما را به هوشمندانه‌ترین و مقرون‌به‌صرفه‌ترین راه‌حل برای ساختن یک برنامه از ابتدا یا بازسازی یک برنامه موجود برای تجربه کاربری عالی راهنمایی کند، دیگر نیازی به جستجو ندارید. Appsmob آماده است تا به شما کمک کند بهترین راه حل را برای خود پیدا کنید.