آموزش کاربردی شبکه در اندروید - بخش اول

این اولین قسمت از سری مقالات " آموزش کاربردی شبکه در اندروید " است که ما می‌خواهیم در مورد لایه شبکه با دید متفاوتی صحبت کنیم، که معمولاً زیاد به آن پرداخته می‌شود، زیرا کار با شبکه در اندروید دشوار است، با چندین carriers، محتوای غنی و متفاوت، پخش جریانی(streaming) و همه این موارد باید بدون از دست دادن جزئیات به دست کاربران برسد.

بخش اول – Http و لایه شبکه
بخش دوم – TLS, Certificates, Pinning
بخش سوم – احراز هویت و رهگیرها(interceptors)
بخش چهارم – عملکرد، افزونگی و همزمانی
بخش پنجم – تست و ادغام

Http و لایه شبکه

http یک پروتکل شبکه است، اگر شما به اینترنت متصل می‌شوید و از آن استفاده کنید، یک تعریف زیبا برای آن این است: "یک پروتکل لایه اپلیکیشن برای سیستم‌های اطلاعاتی، توضیع شده، مشارکتی و ابر رسانه است"

این یعنی اگر شما در حال ساخت یک وبسایت، اپلیکیشن موبایل، اینترنت اشیاء و یا حتی بارگیری یک فایل هستید از این پروتکل استفاده می‌کنید، از صفحات وب با Html ساده به برنامه‌های تلفن همراه رشد کرده است، و تبدیل به یک لایه API شده است که معمولاً مورد استفاده قرار می‌گیرد.

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

Request – یک درخواست http به یک url ایجاد می‌کند
Response – درخواست، پاسخی را برمی‌گرداند که می‌تواند دارای خطا باشد و یا اینکه موفقیت‌آمیز باشد
داده‌ای که می‌تواند تجزیه شود – در تلفن همراه ما باید یک شئ، کلاس داده یا ساختار را که می‌توانیم داخل برنامه استفاده کنیم را تجزیه کنیم، با استفاده از برخی از کتابخانه‌ها مانند Json, Gson, Moshi و یا حتی می‌توانید یکی برای خودتان بسازید، اما وقتی به تلفن همراه می‌رسد فقط یک رشته ساده است.

معمولاً هر درخواست/پاسخ دارای موارد دیگری نیز است:

Uniform Resource Locator: url یک مکان خاص در اینترنت است، نشانی در جایی از اینترنت با یک متد خاص
Headers: به کلاینت و سرور اطلاعات اضافی را با درخواست/پاسخ http ارسال می‌کند. http header شامل یک نام حساس به حروف کوچک و بزرگ که به دنبال آن یک دو نقطه (:) و سپس مقدار آن وجود دارد.
Body: پاسخ واقعی، یک رشته ساده که محتوای body را در معرض دید قرار می‌دهد، که برای برخی از متدها می‌تواند خالی باشد

برای هر درخواست که ارسال می‌کنیم، مهم نیست که موفقیت‌آمیز نباشد، ما یک کد وضعیت برای آن داریم:

1xx – همه چیز خوب است، فقط کمی صبر کنید
2xx – همه چیز خوب است، این یک پاسخ موفقیت‌آمیز است
3xx – پاسخ در جای دیگری است، شما گم شده‌اید
4xx – درخواست از طرف کلاینت نادرست انجام شده است، بنابراین این یک خطا از طرف تلفن همراه است
5xx – سرور نتوانست درخواست را انجام دهد، بنابراین این یک خطا از طرف backend است

متدهای HTTP

چندین متد مختلف Http وجود دارد:

@GET: برای خواندن یا بازیابی اطلاعات مربوط به یک منبع استفاده می‌شود. درخواست‌های GET فقط برای خواندن اطلاعات استفاده می‌شود و برای تغییر اطلاعات استفاده نمی‌شود.
@POST: برای ایجاد منابع جدید استفاده می‌شود. نه ایمن است و نه idempotent(یعنی چند بار صدا زدن یک ریکوئست یکسان منجر به چند بار ایجاد کردن آن منبع نمی‌شود). بنابراین برای درخواست‌های non-idempotent توصیه می‌شود. ایجاد دو درخواست یکسان احتمالاً منجر به دو منبع حاوی اطلاعات یکسان خواهد شد.
@PUT: این متد برای بروزرسانی استفاده می‌شود. قرار دادن یک منبع URI شناخته شده به علاوه request body که شامل نمایه بروز شده منبع اصلی است. در این متد از آنجا که حالت را در سرور تغییر می‌دهد(یا ایجاد می‌کند)، idempotent است، به عبارت دیگر اگر منبعی را با استفاده از PUT بروزرسانی یا ایجاد کنید و سپس مجدد همان ریکوئست را اجرا کنید، منبع همچنان وجود دارد و همچنان همان وضعیتی را دارد که در اول داشه است.
@DELETE: برای حذف منبعی که توسط URL مشخص شده استفاده می‌شود.
@PATCH: این متد برای اصلاح درخواست استفاده می‌شود. درخواست PATCH فقط باید شامل تغییرات منبع باشد. PATCH نه ایمن است و نه idempotent.

به هر حال هر گونه تغییر در هر یک از این متدها می‌تواند برای برنامه موبایل خطرناک باشد، اجازه دهید برنامه‌ای را که متغیر را به صورت دوبرابر دریافت می‌کند را به تصویر بکشیم، اگر این به طریقی به Boolean تغییر یابد، تجزیه داده‌ها به مشکل می‌خورد، این یک اشکال بزرگ است که مهندسان backend هر بار که endpoint را تغییر می‌دهند در نظر داشته باشند که هنگام production با کلاینت این تغییر را درمیان بگذارند.

HttpClient

امروزه بیشتر برنامه‌های اندرویدی براساس API ساخته شده‌اند. به طور کلی API یک وب سرویس RESTFUl است(که می‌تواند موارد بسیاری باشد، این فقط یک نمونه است) که از طریق Http قابل دسترس است و منابعی را در اختیار کاربر قرار می‌دهد که به کاربر امکان تعامل با برنامه می‌دهد، ما به یک HttpClient نیاز داریم که به اینترنت متصل شویم و دریافت داده‌ها برای کاربران را شروع کنیم.

در داخل اندروید، ما یک کتابخانه باورنکردنی داریم که در عرض چند ثانیه یک HttpClient می‌سازد، که OkHttpCLient نامیده می‌شود، این یک Client با readTimeOut و ConnectionTimeOut ایجاد می‌کند، اگر سرور در این زمان هیچ پاسخی ارائه ندهد، در نهایت با یک اتصال ناموفق مواجه خواهیم شد. بخش بسیار مهمی از این client در زیر نشان داده شده است، ما همچنین می‌توانیم یک builder برای cache قرار دهیم(و تعداد زیادی چیز دیگر که بعداً در این سری از مقالات در مورد آنها صحبت خواهیم کرد).

Cache

واکشی اطلاعات از طریق شبکه هم کند و هم گران است، دلیل اصلی این امر این است که ما در تلفن همراه به موارد مختلفی وابسته هستیم، به عنوان مثال شبکه‌ای که کاربر در آن قرار دارد، از 5G تا 3G، از wifi با فیبر نوری تا کابل‌های ارتباطی.

Cache برای درخواست بهتر شبکه، برای همه طراحی شده است، حتی برای کاربران، زیرا بدون درخواست‌های غیر ضروری پایان می‌یابد. Caching هرگز جایگزین درخواست اصلی به DNS شما نمی‌شود، به عنوان مثال cache هرگز جایگزین واکشی داده‌ها از منبع آن نمی‌شود.

Database Caching

درواقع مربوط به لایه شبکه نیست، ما از APIهای خود اطلاعات را می‌پرسیم و آن را در SharedPrefrences, DataStore یا هر پایگاه داده‌ای که می‌تواند رابطه‌ای یا غیر رابطه‌ای باشد ذخیره می‌کنیم. عملکرد، هم در سرعت و هم در توان عملیاتی که پایگاه داده شما ارائه می‌دهد، می‌تواند تاثیر گذارترین عامل عملکرد کلی برنامه شما باشد.

شبکه تحویل محتوا(CDN)

وقتی ترافیک سرور شما در سراسر جهان است، همیشه یک روش آسان و مقرون به صرفه نیست که کل زیر ساخت‌های خود را در سراسر جهان تکثیر کنید، و برای این منظور ما CDN را داریم، که به شما امکان می‌دهد از شبکه موجود در موقعیت‌های مختلف جهان برای ارائه یک کپی از cache محتوای Apiهای خود، شامل عکس‌ها، streamها و فیم‌ها استفاده کنید.

DNS

هر درخواست دامنه‌ای که در اینترنت انجام می‌شود اساساً از سرورهای DNS cache به منظور پیدا کردن Ip مرتبط با نام دامنه است. DNS cache می‌تواند در بسیاری از سطوح از جمله سیستم عامل، ISPها و سرورهای DNS رخ دهد.

برای شبکه ما می‌توانیم برای HttpClient خود cache را فعال یا غیر فعال کنیم، برای مثال در برخی از برنامه‌ها ممکن است pull to refresh داشته باشیم که نیاز باشد cache را حذف کنیم و مستقیم داده را از سرور دریافت کنیم. برای اجباری کردن بروزرسانی کامل داده‌ها، no-cache را به CacheBuilder در HttpClient خود اضافه کنید، تصمیم گیری در مورد انجام این نوع کارها بیشتر مربوط به بخش محصول است.