از لیوت منیجر برای نحوه نمایش ریسایکلر ویو استفاده میکنیم. کلا سه نوع هست:
1. LinearLayoutManager
پارامتر دوم میگه نحوه نمایش عمودی هست و پارامتر سوم میگه لازم نیست لیست برعکس شه.
توی ریسایکلر ویو متد onCreateViewHolder (همون متد اول) که کار inflate رو انجام میده، تعداد فراخونیش محدود هست. متدی که به ازای هر آیتم کال میشه، متد onBindViewHolder هست. این یکی از ویژگی های مثبت ریسایکلر ویو به شمار میاد، چون فرآیند inflate کردن پر هزینه هست.
دریافت پوزیشن کلیک شده در ریسایکلر ویو: (خیلی به درد بخوره)
برای این کار دو تا متد هست که هر دو توی کلاس ViewHolder هستن:
1. دپریکیت شده.
getAdapterPosition()
2.
getLayoutPosition()
این دو تا متد خروجی int دارن و شماره آیتم فعلی کلیک شده در ریسایکلر ویو رو میدن.
ریسایکلر ویو خودش لیسنر نداره و بنابراین خودمون باس بنویسیم واسش!
یکی از فرق های ریسایکلر ویو با لیست ویو همینه که لیست ویو متدهای از پیش نوشته شده داره (مثل آیتم لیسنر) ولی ریسایکلر ویو نداره. اما ریسایکلر ویو انعطاف پذیری بیشتری داره و امکان کاستومایز شدنش خیلی زیاده.
کارد ویو خودش dependency داره ولی توی کتابخونه متریال دیزاین هم تعریف شده. من ترجیحم اینه که از نسخه متریال دیزاینش استفاده کنم.
ریسایکلر ویو هم dependency داره. فقط باید نسخه ش با متریال دیزاین یکی باشه تا توی preview نشون داده بشه! این مشکلی بود که الآن اینجوری حل شد!
implementation 'com.google.android.material:material:1.2.0-alpha02'
implementation 'androidx.recyclerview:recyclerview:1.2.0-alpha05'
کل دیروز این معماری رو میخوندم.
یه مقدار پیچیدگی داره ولی دیسیپلینش خیلی قشنگه.
توی این معماری باید کد رو به سه لایه، Model، View و presenter تقسیم کنیم. به طوری که:
- توی presenter هیچ کد اندرویدی نباشه.
- view و model هیچ رفرنسی به همدیگه ندارن.
- توی presenter هیچ context ای نداریم.
کلا به سه روش میشه توی اندروید دستورات sql رو اجرا کرد:
query: که متعلق به API اندروید هست.
execSql: که دستورات SQL ای میگیره و خروجی نداره. بنابراین برای select نمیشه از این استفاده کرد.
rowQuery: اینم دستورات SQL ای میگیره ولی خروجی داره. بنابراین برای select میشه ازش استفاده کرد.