بیش از 9 سال است که در زمینه توسعه برنامه و بازی های اندرویدی فعالیت میکنم در محیط هایی مثل Eclipse ، Android Studio ، Unity و Flutter تجربه کار حرفه ای را کسب کردم. وحالا دیگر بسیاری از الگوهای طراحی و معماری در مجموعه ای از برنامه های مختلف خودم استفاده کردم. MVC ، MVP ، MVVM ، VIPER ، MVI ، CLEAN. همه آنها با فرض آسان کردن زندگی شما شروع می شوند به طوری که دیگر هرگز نمی خواهید زیر دوش گریه کنید ... ?
اما این کار همیشه به همین روش تمام می شود ، یک برنامه یکپارچه که تغییر یک چیز باعث می شود کل برنامه از کار بیفتد. دیباگ کردن و پیدا کردن مشکل که گاها تا یک هفته نیز ممکن است طول بکشد. اما یک روز توسط یکی از دوستانم با flux و گروه توسعه ان آشنا شدم و سعی کردم هرچند کم اما در توسعه این معماری به دوستان جدیدم کمک کنم.
جریان Flux (و Redux) چیست؟
من توضیح مفصلی در مورد این الگوها نمی دهم ، اطلاعات زیادی در مورد این موارد وجود دارد. این الگوهای معماری یک چیز مشترک دارد (مهمترین موارد برای من):
مورد اول دسته ای از مشکلات مشترک در برنامه های تلفن همراه را برطرف می کند و این که اطلاعات نشان داده شده در یک صفحه نمی تواند مانند صفحه دیگر باشد. برای حل این مسئله معمولاً باید اطلاعات را بار دیگر بارگیری کنیم تا از صحت آنها اطمینان حاصل کنیم.
مورد دوم به ما کمک می کند تا در هنگام اشکال زدایی ایمن خود را حفظ کنیم. شما آن اشکالی را به خاطر می آورید که باعث ایجاد برخی اوقات به صورت تصادفی شده است؟ و شما نمی دانید کجا صدا شده است؟ داشتن اطلاعات یک طرفه از جریان به شما کمک می کند تا domain flow خود را درک کنید ، باعث می شود برنامه شما انعطاف پذیرتر باشد و به راحتی بتوانید علت آن اشکال آزار دهنده را پیدا کنید.
و یک نکته مهم دیگر نیز وجود دارد: واکنش پذیری
این برچسب برای دو نقطه اول است. واکنش پذیر بودن کد شما به صورت درست باعث می شود برنامه شما همیشه آخرین اطلاعات را نشان دهد.
من در دو برنامه (در حال حاضر در دو برنامه دیگر کار می کنم) با استفاده از flux کار می کنم. ;که بیش از 800 هزار کاربر داریم. رتبه بندی برنامه های ما 4.5 ستاره است و نرخ crash free 99،99٪ است (Firebase اعشار دیگری ندارد). من می دانم که دستیابی به این اعداد بدون داشتن یک تیم عالی و معماری مستحکم دشوار است.
کامپوننت های معماری ما چیست:
Stores:
حاوی state تغییرناپذیری است. مشترک اشتراک Actions است. وقتی عملی به Stores می رسد ، وضعیت او تغییر می کند. با تغییر وضعیت ، به نمای مشترک شده در آن منتقل می شود.
Actions:
یک مورد استفاده را نشان دهید. یک اقدام می تواند این باشد: LoginAction ، RequestInfoAction.
Dispatcher:
شیئی که مراقبت از اعزام اقدامات ارسال شده به هر Storesرا به عهده دارد
اگر دوست دارید بیشتر با این معماری جذاب آشنا شوید در نظرات به من بگویید تا آن را به طور کامل آموزش دهم???
واقعاً از تغییرات وحشتناک اندروید 11 مطلع هستید؟
برای فهم بهتر پیشنهاد میدم که این مقاله را در اینجا مطالعه کنید:
https://mohammadabdipour.medium.com/new-and-effective-architecture-in-android-cfc5d8f2af9e
