معماری ها در اندروید

برنامه های اندرویدی

 

در این مقاله قصد داریم به مبحث معماری ها در اندروید بپردازیم . در اکثر موارد ، برنامه های دسکتاپ دارای یک نقطه ورود واحد از یک برنامه یا launcher هستند و بعد از آن به عنوان یک فرآیند یکپارچه اجرا می‌شوند. از طرف دیگر برنامه های اندرویدی ساختار بسیار پیچیده تری دارند. یک برنامه Android معمولی شامل چندین مؤلفه برنامه ، از جمله activity ها ، fragment  ها  ، services, content providers, and broadcast receivers است.

شما اکثر این مؤلفه های برنامه را در manifest  برنامه خود تعریف می کنید. سپس سیستم عامل اندروید با استفاده از اطلاعات manifest و با توجه به اصول ux  درمورد این بخش ها برای راه اندازی برنامه خود تصمیم گیری می کند.

با توجه به اینکه یک برنامه Android شامل چندین مؤلفه و بخش است و اغلب کاربران در یک بازه زمانی کوتاه با چندین برنامه ارتباط برقرار می کنند ، برنامه ها باید با انواع مختلفی از کارها و وظایف کاربر سازگار شوند.

به عنوان مثال ، در نظر بگیرید هنگام به اشتراک گذاری یک عکس در برنامه های شبکه های اجتماعی مورد علاقه شما چه اتفاقی می افتد:

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

سرانجام ، کاربر به برنامه شبکه های اجتماعی باز می گردد و عکس را به اشتراک می گذارد.

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

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

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

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

اگر برای ذخیره داده ها و وضعیت برنامه ها نباید از اجزای برنامه استفاده کنید ، چگونه باید برنامه خود را طراحی کنید؟

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

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

یک اصل مهم دیگر این است که شما باید UI خود را با یک مدل ، ترجیحاً یک مدل مداوم ، هدایت کنید. Model ها مؤلفه هایی هستند که وظیفه پردازش داده ها برای یک برنامه را دارند. آنها از View ها و مؤلفه های برنامه مستقل هستند .

در نتیجه با این روند :

اگر سیستم عامل Android برنامه شما را برای آزادسازی منابع از بین ببرد ، کاربران شما داده ها را از دست نمی دهند.

برنامه شما در مواردی که اتصال به اینترنت دچار قطعی است و یا در دسترس نباشد ، همچنان به کار خود ادامه می دهد.

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

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

معماری ها در اندروید


موضوع انتخاب معماری در سالهای اخیر برای انجمن های اندرویدی کاملا بحث برانگیز بوده است. گوگل در سال ۲۰۱۷ با انتشار مؤلفه های معماری اندرویدی ، رویکرد خود را درباره  معماری استاندارد برای آسانتر کردن کار توسعه دهندگان ارائه کرد.

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

معماری ها مبتنی بر اصول برنامه نویسی است.

چرا باید به معماری برنامه اهمیت داد؟

مسئولیت ( MVP (Model-View-Presenter) / MVVM (Model-View-ViewModel جدا کردن UI از کد است.

ما از Presenter / ViewModel برای نوشتن هر کد منطقی از (View  (Activity / Fragment استفاده می کنیم.

این جدایی مستلزم VP / VVM است که با Model) M) کار می کند که وظیفه آن تهیه داده به Presenter / ViewModel است.

برنامه های ما حتی بدون معماری می توانند عملکردی عالی داشته باشند پس چرا باید وقت اضافی برای معماری برنامه بگذاریم ؟

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

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

درست است که ما نمی توانیم همه چیزهایی را که در آینده  برنامه ممکن است اتفاق بیافتد ، پیش بینی کنیم ، اما یک معماری خوب انعطاف پذیری کافی برای تنظیم با آن تغییرات ناشناخته آینده را دارد.

معمولاً وقتی کار با Android را شروع می کنیم ، بیشتر فعالیت های خود را با کار بر روی activity  ها یا fragment  ها انجام می دهیم. که در واقع ، برای برنامه های کوچک  کاملا مناسب است .

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

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

حال در نظر بگیرید که تغییرات جدیدی در برنامه مورد نیاز است ، شما چاره‌ای جز بازسازی کل پروژه نخواهید داشت .

برای رفع این مشکلات بهترین روش استفاده از معماری هاست که مشهورترین آنها عبارتند از:

MVC: Model-View-Controller

MVP: Model-View-Presenter

MVVM: Model-View-ViewModel

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

به همین دلیل پروژه شما modular می شود . در انتها قطعات کد جدا شده ، تست پذیرتر هستند و برنامه شما برای تغییرات مداوم انعطاف پذیر می شود.

اما تفاوت های اصلی این معماری ها در اندروید در چیست؟

معماری ها در اندروید


معماری  Model-View-Controller  :MVC

الگوی MVC  اولین الگوی معماری در  Android است که قدمت بالاتری دارد. این الگو پیشنهاد می کند که کدهای خود را به ۳ لایه مختلف تقسیم کنید:

مدل (Model  ) – لایه داده ها : مسئول رسیدگی به منطق business  و ارتباط با لایه های شبکه و پایگاه داده را دارد .

نمایش (View ) – لایه رابط کاربر  (UI) :  بخش view یک تجسم ساده از داده های مدل است.

کنترل کننده (Controller)  – لایه منطقی : رفتار کاربر را تحلیل می کند و در صورت لزوم مدل را به روز می کند.

در معماری MVC هر دو Controller و View به مدل بستگی دارند.  Controller  ، داده ها را به روز می کند ، View   داده را می گیرد.

در حالی که Model  به صورت مستقل از UI  ، می تواند آزمایش شود.

چند روش برای نحوه استفاده از الگوی MVC وجود دارد.

یک روش این است که activity  ها و fragment  ها مانند Controller عمل می کنند. آنها وظیفه پردازش داده ها و به روزرسانی View ها را بر عهده دارند.

مشکل این رویکرد معماری این است که activity  ها و fragment   ها می توانند بسیار بزرگ شوند که آزمایش آنها بسیار دشوار است.

روش دوم که منطقی تر به نظر می رسد این است که activity  ها و fragment   ها باید یک View  در MVC  باشند.

Controller  باید دارای کلاس های جداگانه ای باشد که از کلاس های  Android  استفاده نمی کند. مشابه model  ها .

به هر حال اگر درباره MVC بیشتر تحقیق کنید ، می فهمید که برای یک پروژه اندرویدی با این معماری ، لایه های کد به یکدیگر وابسته هستند. به همین دلیل بهتر است برای پروژه های بسیار بزرگ از این معماری استفاده نشود.

معماری ها در اندروید


معماری The Model View Presenter:  MVP

پس از معماری MVC  که جذاب به نظر نمی آمد ، توسعه دهندگان Android به سوی معماری MVP  حرکت کردند که یکی از محبوب ترین الگوهای معماری ها در اندروید ، معماری MVP محسوب می شود و همچنان مورد استفاده قرار می گیرد. برای هر کسی که برنامه نویسی  Android را شروع می کند نیز یادگیری آن بسیار آسان است.

مدل Model  – لایه داده ها :  که مشابه الگوی MVC است. مسئول رسیدگی به منطق business  و ارتباط با لایه های شبکه و پایگاه داده را دارد.

نمایش View   – لایه رابط کاربر(UI) : داده ها را نشان می دهد و در مورد اقدامات کاربر اطلاع می دهد.

ارائه دهنده Presenter   – داده های مدل را بازیابی می کند : منطق UI را اعمال می کند و وضعیت View را مدیریت می کند همچنین تصمیم می گیرد چه چیزی را نمایش دهد و به ورودی های کاربر واکنش نشان می دهد .

این معماری نه تنها  به View گره نخورده است بلکه علاوه بر آن تنها یک interface یا رابط است.

معماری MVP نشان می دهد که View  و Presenter  ارتباط نزدیکی با هم دارند. آنها نیاز به مراجعه به یکدیگر دارند. رابطه آنها از طریق یک کلاس رابط  یا interface برقرار است.

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

معماری MVP  مشتق شده از الگوی معماری MVC  است که بیشتر برای ساخت رابط های کاربر استفاده می شود.

 

معماری ها در اندروید


معماری  Model-View-ViewModel : MVVM

الگوی MVVM سومین معماری ارائه شده برای اندروید است. که این الگوی معماری توسط  تیم اندروید  نیز توصیه شده است.

مدل Model  – خلاصه منبع داده است .ViewModel برای دریافت و ذخیره داده با Model کار می کند.

نمایش View  – که ViewModel را از اقدامات کاربران آگاه می کند.

لایه ViewModel  :  جریان داده های مربوط به View را نشان می دهد.

معماری ها در اندروید

 

تفاوت معماری MVP با MVVM   در این است که در معماری MVVP  بخش ViewModel مرجعی به View  برخلاف Presenter ندارد . در MVVM  بخش  ViewModel جریانی از رویدادهایی را که View  های مختلف می توانند به آن وصل شوند ، نشان می دهد.

از طرف دیگر ، در MVP بخش Presenter مستقیماً View را نشان می دهد.

در MVVM بخش View به ViewModel اشاره دارد. ViewModel هیچ اطلاعاتی در مورد View ندارد. بین View و ViewModel رابطه ای چند به یک وجود دارد.

تفاوت بین MVC و MVP

Model View Controller :

Controller ها مبتنی بر رفتار هستند و می توانند چندین view  را به اشتراک بگذارند.

View ها  می توانند به طور مستقیم با Model ارتباط برقرار کنند

Model View Presenter :

View  از Model  مستقل است . Presenter  واسطه بین Model و View است.آسانتر برای ایجاد تست های واحد است ، معمولاً بین View و Presenter ارتباط یک به یک وجود دارد ، با امکان استفاده از چندین Presenter   برای نمایش های پیچیده .

 

معماری ها در اندروید

 

مقایسه MVC در مقابل MVP و MVVM

در اینجا یک جدول آورده شده است که خلاصه ای از تمام معماری ها که در مورد آنها صحبت کردیم وجود دارد.

همانطور که ممکن است متوجه شده باشید ، در هنگام ساختن یک برنامه مدرن ماژولار و قابل آزمایش ، MVC در مقایسه با MVP و MVVM چندان مناسب نیست.

اما هر معماری مزایا و معایب خاص خود را دارد. اگر دقیقا متناسب با نیازهای شما باشد .

ما در دوره دولوپر برتر قصد داریم شما را به طور کامل با مبحث معماری ها در اندروید آشنا کنیم .

 

0 پاسخ

دیدگاه خود را ثبت کنید

تمایل دارید در گفتگوها شرکت کنید؟
در گفتگو ها شرکت کنید.

پاسخی بگذارید