معرفی و برسی Android Architecture Components

استاندارد

گوگل در کنفرانس I/O 2017 بعد از مدت‌ها و بعد از درخواست‌های زیاد ، یک معماری پیشنهادی برای پیاده‌سازی اپلیکیشن‌های اندرویدی ارائه داد .
همچنین گوگل یک سری کتابخانه برای استفاده از این معماری پیشنهادی معرفی کرد ، که اسم این مجموعه کتابخونه‌ها Android Architecture Components هست . البته این کتابخانه‌ها حتی وقتی شما قصد استفاده از معماری پیشنهادی گوگل رو هم نداشته باشید میتونن بسیار مفید و به درد بخور باشند .
این کتابخونه‌ها به توسعه‌دهند‌ه‌ها کمک میکنه تا به راحتی لایه‌های اپلیکیشن‌شون رو از هم جدا کنند(تقریبا) وکد‌های تمیزتری داشته باشن . در ادامه این componentهای معرفی شده رو نام میبرم و دربارشون کمی توضیح میدم  :

  • Lifecycle-Aware
  • LiveData
  • ViewModel
  • Room ORM

  1. Lifecycle Aware : قطعا برای هممون پیش اومده که توی کد‌هامون گاهی نیاز داشته باشیم تکه کدی رو در یک نقطه از Lifecyle مربوط به Fragment/Activity قرار بدیم تا مثلا بتونیم مطمئن بشیم که این تیکه کد وقتی اجرا میشه که Activity/Fragment ما برای کاربر قابل مشاهده است .
    این کار میتونه مشکلات و پیچیدگی‌های بسیار زیادی رو در روند توسعه و نگهداری اپلیکیشن‌ها بر توسعه دهنده تحمیل کنه . از جمله‌ اینکه باعث میشه توابعی مثل onStrat و onPause و onResume و … بسیار پیچیده و شلوغ بشه  و همچنین با کمی بی‌دقتی امکان بوجود اومد باگ یا memory leak خیلی زیاد خواهد شد .
    برای رفع این مشگل گوگل پروسه کار با Lifecycle رو به دو قسمت تقسیم کرده. بخش اول  Lifecycle Owner ها ، مثل Activity/Fragment ها و بخش دوم Lifecycle Observer ها که همون متد‌ها یا تکه‌کدهای ما هستند که Lifecycle براشون اهمیت داره و میخوایم اجراشون رو وابسطه به وضعیت Lifecycle کنیم .
    درسته که با این تغییرات احتمالا کد‌های شما خیلی کاهش پیدا نکنه ، ولی در عوض جای قرار گیری اون‌ها درست و منطقی‌تر میشه. همچنین این قابلیت به شما این امکان رو میده که بتونید وضعیت Lifecylce رو جایی خارج از Activity/Fragment تون چک کنید و حتی تغییر وضعیت اون رو Observe کنید .
  2. LiveData یک کلاس برای نگهداری دیتا‌ها هست . که به همراه خودش مکانیزم Observable رو هم داره . یعنی برای این کلاس داده میتونیم به راحتی چندین Observer ست کنیم ، که مثلا این Observerها میتونن Activity/Fragment ما باشند .
    تفاوت عمده LiveData با داده‌های Observable دیگه که خودمون میتونیم بسازیم در درک اون از Lifecycle هست . با توجه به این قابلیت دیگه لازم نیست ما نگران subscribe/unsubscribe کردن observer مون باشیم . و فقط با تغییر مقدار ، LiveData تغییرات رو به Observer‌های فعال انتقال میده . بذارید یه مثال ساده بزنم . فرض کنید ما یک LiveData داریم که در داخل ۲ تا Activity از اون استفاده میکنیم و اون رو Observe میکنیم . یکی از Activityهای ما باز هست و کاربر داره باهاش کار میکنه و Activity دیگه داخل backstack وجود داره . حالا LiveData ما از طریق یک Service بروزرسانی میشه و اتفاقی که میوفته اینکه LiveData تغییر انجام شده رو به Observer ای میده که کاربر با Activity میزبانش داره کار میکنه ،  به این Observer اصطلاحا active گفته میشه . حالا چون Observer دیگمون در backstack هست‌ ( به این Observer اصطلاحا inActive میگن ) ، پس نیازی هم نیست که تغییرات اعمال شده بهش ارسال بشه ، و فقط وقتی که این Observer دوباره active بشه ، LiveData دیتای صحیح و تغییر یافته رو بهش میرسونه .
  3. ViewModel یکی کلاس برای نگهداری و مدیریت دیتاهای مربوط و در ارتباط با UI هست .
    بعضی مواقع پیش میاد که Activity/Fragment ما به واسطه عملی که کاربر انجام میده یا تصمیمی که سیستم عامل میگیره از بین میره (Destroy) یا دوباره ساخته (reCreate )میشه و در این موارد این اتفاق در کنترل ما نیست . وقتی اینجور اتفاق‌ها میوفته دیتاهایی هم که توی این  Activity/Fragment هست طبیعتا از بین میره و باید دوباره لود بشن ( از سرور و یا لوکال )‌ . خب این مسئله اگر هم مشکلی برای ما ایجاد نکنه و خطایی رخ نده ، خیلی اتفاق خوشایندی نیست . چون کاربر باید منتظر لود دیتایی باشه که قبلا یکبار لود شده . قبل از این ما تو Activity هامون میتونستیم  به وسیله متد onSaveInstanceState یک سری اطلاعات مربوط به UI یا اطلاعات کوچیک دیگه‌ای رو بازیابی کنیم . ولی از این متد برای بازیابی اطلاعات حجیمی مثل یک لیست از موجودیت کاربر نمیتونستیم استفاده کنیم. درصورتی که به وسیله ViewModel میشه این کار رو خیلی راحت انجام داد.
    همینطور ViewModel به ما کمک میکنه که Activity/Fragment‌ ها رو از حالتی که مسئول تمام عملیات باشن خارج کنیم و تمرکز اون‌ها رو معطوف به ارتباط با کاربر و سیستم‌عامل کنیم . با این کار هم پیچیدگی رو کاهش میدیم و هم در هم تنیدگی کد‌ها کم میشه . علاوه بر این موارد ، تست کردن هم خیلی راحتر‌تر و سریع‌تر خواهد شد .
    یکی دیگه از کاربرد‌های ViewModel ساده کردن انتقال دیتا بین Fragment ها هست . به این شکل که برای Activity میزبان دو یا چند Fragment ، میشه یک ViewModel ست کرد و به این واسطه ، ViewModel رو بین Fragment ها به اشتراک گذاشت .
  4. Room ORM :  به طور کلی کاری که ORM ها انجام میدن ، تبدیل Object های ما به نوع داده‌ای قابل ذخیره در Relational Databaseها  هست و برای ما یک پایگاه داده‌ای شی-گرا رو شبیه سازی میکنن . ما با استفاده از ORM میتونیم کارهایی که تا الان با استفاده از دستورات طولانی sql انجام میدادیم رو خیلی ساده‌تر وسریع‌تر انجام بدیم .
    تا قبل از اینکه کتابخونه Room معرفی بشه کتابخونه‌های خوبی برای استفاده ار مفهوم ORM در java و اندروید وجود داشته ، مثل Sugar ORM (که اینجا میتونید راجع‌به اون بخونید ) و … اما تفاوت‌ اصلی Room با ORMهای قبلی خودش ، سازگاری با معماری معرفی شده توسط گوگل هست . مثلا درک LiveVeiw توسط Room به شما این امکان رو میده تا Activity/Fragment‌ های شما داده‌های پایگاه‌داده‌تون رو observe کنن و در صورت تغییر یافتن داده‌ها از هرجایی ، بتونن خودشون رو اپدیت کنن . در Room بیشتر کار‌ها رو با استفاده از annotation ها انجام میدیم . کار با Room بسیار ساده است و جوری طراحی شده که تقریبا مثل کتابخونه Retrofit ازش استفاده میشه .
    Room همینطور Sql های شما رو متوجه میشه و توانایی این رو داره که در زمان کامپیال اشتباهات احتمالی شما رو متوجه بشه .

مطالب بالا خلاصه‌ای بود از Android Architecture Components ، برای اینکه در مورد موارد ذکر شده خیلی دقیقتر بخونید میتونید به گایدلاین‌های گوگل مراجعه کنید.

همچنین در پست‌های آینده سعی میکنم برسی دقیق‌تری روی هر کدوم از این component ها انجام بدم .

1 دیدگاه در “معرفی و برسی Android Architecture Components

پاسخ دهید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *