میخواستم وقتی رسپبری‌پای خریدم، از کارهای جالبی که باهاش میکنم توی کانال و بلاگم بنویسم! ولی خب متاسفانه خیلی فرصت نمیشه سراغش برم، این تعطیلات چند روزه باعث شد تا بعد مدت‌ها سعی کنم کارهایی که میخواستم باهاش انجام بدم رو عملی کنم. مهمترین کارم این بود که بجای وصل کردن لپ‌تاپ به تلویزیون از رسپبری‌پای برای دیدن سریال یا ویدئوهای یوتیوب استفاده کنم. یه روزی درگیر این بودم که یه فیلم FullHD رو روی رسپبری‌پای با زیرنویس فارسی اجرا کنم که آخرشم نشد. (البته میخواستم اینکار رو روی Raspbian انجام بدم، OMXPlayer فیلمو خیلی خوب پخش میکرد ولی با زیرنویس فارسی مشکل داشت)

به این فکرمیکردم که چیکار کنم، یادم افتاد تلویزیون یه بخشی داره که مستقیم به یوتیوب وصل میشه ولی خب اینترنت ایران اون رو باز نمیکنه. درواقع اگر من بتونم یه شبکه‌ای داشته باشم که این قضیه دسترسی رو حل کنه! نه تنها میتونم با همون تلویزیون ویدئوهای یوتیوب رو ببینم، هرجایی که مشکلاتی از قبیل تحریم و دسترسی داشتم (مثل کنسول PS4 یا بیلد کردن پروژه‌های اندروید) با وصل شدن به این شبکه حل میشه!

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

 

آموزش ساخت Hotspot

برای شروع اول باید از تنظیمات wpa_supplicant.conf یه بک‌آپ گرفت تا بعدا اگر نیاز شد بشه تنظیمات اصلی رو برگردوند.

بعد با استفاده از یه ادیتور مثل nano فایل wpa_supplicant.conf که الان خالیه رو ویرایش کنید و متن پایین رو داخلش ذخیره کنید.

برای اینکه بشه رسپبری‌پای رو تبدیل به اکسس پوینت کرد، استفاده از RaspAP کارو خیلی راحت میکنه. توی ریپوی گیت‌هابشون در موردش میتونید بخونید. با یه خط دستور نصب میشه.

بعد اینکه نصب تموم بشه، رسپبری‌پای ریست میشه. اگر همه چی درست بوده باشه، اگر wifiهای در دسترس رو چک کنید با raspi-webui رو ببینید. من خودم چندبار اینکارو کردم ولی چیزی نیومد. ip رسپبری‌‌پای رو توی مرورگر زدم و با یوزنیم admin و پسورد secret وارد پنل مدیریت raspi شدم. دیدم موقع استارت کردن hotspot خطا میده که hostapd اجرا نمیشه.

دوباره سرچ کردم و دیدم با دستور زیر میشه بصورت دستی hostapd رو اجرا کرد.

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

بعد نصب بکچ به ترتیب دستورات زیر رو زدم. البته دستور اول برای اینه چک کنید و یه لیست بهتون میده، بعد دستور دوم با اسم پراسس رو میگیره و هر پراسسی با اون اسم هست رو kill میکنه.

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

در نتیجه hotspot هم به درستی ساخته شد و تونستم با گوشی بهش وصل بشم. رمز پیشفرضش ChangeMe هست. برای اون قضیه دسترسی و مشکلات تحریمی هم روی رسپبری‌پای Cisco رو کانکت کردم. در نتیجه دیگه هرکی به hotspot وصل میشد، چون کل ترافیکش از Csico رد میشد از اینترنت بدون فیلتر استفاده میکرد.

راستی بعضی وقتا hostapd نصفه نیمه بسته میشه. اگر اینجوری شد، میتونید با دستور زیر شماره processشو پیدا کنید و دستی با دستور kill ببندینش.

 

منابع

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

Create a Wi-Fi hotspot in less than 10 minutes with Pi Raspberry!

Hostapd error nl80211: Could not configure driver mode

How to install aircrack-ng latest version

 

تقریبا یکسال پیش بود که پست کوتاهی در مورد “منابع الهام بخش برای ساخت UI اپ موبایل” نوشتم و تعدادی سایت رو معرفی کردم ولی یه مشکلی وجود داشت، اونم این بود که همه‌ی UIها با زبان انگلیسی درست شده بودند و معمولا وقتی همین UI‌ها رو با زبان فارسی درست می‌کنید، درصد زیادی از زیباییشون از دست میدن. برای حل این مشکل با بچه‌های هارمس تصمیم گرفتیم خودمون زمان بذاریم و از اپ‌های اندرویدی معروف ایرانی اسکرین‌شات تهیه کنیم تا در اختیار همه‌ی برنامه‌نویسان و طراحان فارسی‌زبان بذاریم.

خروجی این تصمیم، سایت UI Screenshots شده که با آدرس http://uiscreenshots.ir میتونید بهش دسترسی داشته باشید. به دو صورت میشه تصاویر رو فیلتر کنید، روش اول با استفاده برچسب‌هایی که سمت راست صفحه لیست شده‌اند و روش دوم با استفاده از جستجوی نام برنامه‌ای که میخواهید تصاویرشو ببینید.

الان که دارم این پست رو مینویسم، تقریبا ۵۰۰ عدد اسکرین‌شات از اپ‌های معروف و زیبای ایرانی روی این سایت آپلود شده، امیدواریم که در آینده نه تنها تعداد این تصاویر بیشتر بشه بلکه بتونیم قابلیت‌های بیشتری رو در اختیار برنامه‌نویسان و طراحان ایرانی قرار بدیم.

چند وقت پیش یه AMA (فکرکنم معادل فارسیش میشه “از هرچیزی بپرس”) توی reddit بود که تیم توسعه‌دهنده‌ی دگر سوالاتی که ازشون پرسیده شده رو جواب دادن. دیشب وقت کردم بخونمش و نکاتی که بنظرم جالب رو بود رو در ادامه نوشتم. البته اگر میخواید خودتون همه‌ی سوال‌ و جواب‌هارو بخونید، میتونید به لینک زیر برید.

لینک AMA تیم دگر توی reddit

 

ضعف داکیومنت
یه سری از دولوپرها در مورد اینکه داکیومنت خوب نیست، تذکر داده بودند. چند نفر گیر داده بودن به لغت Thermosiphon که توی مثال استفاده شده :)) توشون یه انگلیسی زبان بود که نوشته بود با اینکه انگلیسی زبانم ولی این لغت رو تا حالا نشنیده بودم!

یکی از اعضای اصلی تیم توسعه‌دهنده‌ جواب داده بود که قبول دارند باید داکیومنت رو بهتر کنند. البته گفته بود پیدا کردن مثال برای توضیح دگر سخته، دلیلشم اینه اگر مثال خیلی ساده باشه، مزایای دگر رو نشون نمیده و اگر خیلی پیچیده باشه، یادگرفتنش سخت میشه. یه بخش جدید هم به اسم semantics به داکیومنت اضافه کردند و داخلش توضیح دادند دگر از چیا درست شده و واژه‌هایی که توی دگر استفاده شده معنیشون چیه.

https://google.github.io/dagger/semantics

 

انتشار نسخه ۳

یکی پرسیده بود که نسخه‌ ۳ دگر چه موقع منتشر میشه که گفته بودند تصمیمی برای این قضیه ندارند و فعلا روی همین نسخه‌ی ۲ کار میکنند.

 

دیداری‌سازی (Visualization)

دو نفر در رابطه با Visualization توی دگر پرسیده بودند. مزیت Visualization اینه میشه object graphیی که دگر ساخته رو مثل یه گراف واقعی دید و بررسی کردش.

یکی از اعضای تیم توسعه دهنده خبر از انتشار SPI رو داده بود که هدفش همین کار هست. انگار object graph رو تبدیل میکنه به فایل‌هایی با فرمت dot و میشه این فایل رو از طریق graphviz دید. البته SPI کاملا آزمایشی منتشر شده، مثال هم براش گذاشتند ولی حقیقتش من اصلا نفهمیدم چطوری میشه ازش استفاده کرد. لینک مثال

لینک مثال استفاده از SPI

 

دگر و custom views

یکی پرسیده بود که چطوری میشه از دگر توی custom viewها استفاده کرد که باز یکی از اعضای تیم توسعه دهنده گفته بود که کلا توصیه میکنیم اینکارو نکنید. dependencyهارو باید یه سطح بالاتر از view توی fragment یا Conductor یا هر کنترلر دیگه‌ای که دارید inject کنید.

 

دگر و kotlin

یکی پرسیده بود توی kotlin چطوری از دگر استفاده کنیم بهتره؟ یکی از اعضای تیم توسعه دهنده این لینک رو که منم قبلا توی بلاگ گذاشتمش رو معرفی کرد. توی این issue در مورد best practiceهای استفاده از دگر توی kotlin صحبت میکنند.

https://github.com/google/dagger/issues/900

 

ویدیو آموزشی دگر

یکی سوال پرسیده بود برای کسی که با دگر اصلا آشنا نیس، چه آموزشی رو پیشنهاد میکنید؟ یکی از اعضای تیم این لینک رو معرفی کرده بود

Understanding Dagger 2’s Generated Code

چندتا کاربر دیگه هم اینا لینک‌هارو توصیه کرده بودن

Dependency Injection Made Simple

 The Future of Dependency Injection with Dagger 2

TwistedEquations – Dagger 2 Android Tutorial

 

ماژول اندروید dagger

یکی پرسیده بود دلیل اینکه dagger.android رو منتشر کردید چیه و بعد چند پیام با یکی از اعضای تیم توسعه‌دهنده صحبت کرده. چون طولانیه، اینجا نمیذارمش و مستقیم برید توی reddit بخونیدش.

لینک به پیام‌ها توی reddit

یه جای دیگه هم یکی گفته بود حتما بجای روش قدیمی getNetComponent().inject(this توی اندروید با از dagger.android و AndroidInjection.inject(this استفاده کنیم؟ یکی از اعضای تیم توسعه‌دهنده گفته بود که میتونید از هرکدوم که میخواید استفاده کنید ولی تیم ما dagger.android رو توصیه میکنه! بعد گفته بود دلیل توصیه‌مون هم مشخصه، چون خودمون درستش کردیم :))

اگر یادتون باشه آخرین نمونه پروژه‌ای که توی گیت‌هاب گذاشتم (SingleAcitvityPattern) با زبان کاتلین نوشته شده بود. هدف اصلیم از این پروژه پیاده‌سازی الگوی Single Activity با استفاده از فرگمنت‌ها و هدف فرعیم آشنایی بیشتر با کاتلین بود. قبلا در مورد هدف اصلی یه پست بلاگ نوشتم و الان میخوام در رابطه با هدف فرعی صحبت کنم. استفاده از کاتلین زمان بیشتری ازم گرفت ولی در عوض با نکات مختلفی آشنا شدم که در ادامه براتون تعریف میکنم.

 

ترکیب کاتلین و Dagger

دیروز چندساعتی درگیر این بودم که چطوری توی پروژه‌ میتونم NavigationManager رو از طریق Dagger به فرگمنت‌ها اینجکت کنم. با توجه به ایده‌ای که در مورد NavigationManager داشتم، میشه توی یه پروژه چندتا NavigationManager داشت که هرکدوم مدیریت تعدادی از فرگمنت‌هارو به عهده داشته‌ باشه (اگر پست قبلی بلاگمو در مورد این پروژه خوندید و ایده‌مو در رابطه با NavigationManager متوجه نشدید، دلیلش اینه توضیحش توی متن سخته! شاید بعدا یه ویدیو برای توضیحش درست کردم)، این ایده استفاده از Dagger برای اینجکت کردنو خیلی سخت کرده بود. البته توی این چند ساعت، درگیر دو تا مشکل دیگه هم داشتم.

اولین مشکل این بود که وقتی Dagger رو به پروژه اضافه کردم، موقع اجرا خطای NoClassDefFoundError میداد!!! آخرش بعد از کلی تلاش و سرچ کردن، فهمیدم مشکل از من نیست! مشکل از Dagger هست و نسخه جدید ۲٫۱۴٫۱ رو فقط به خاطر حل این مشکل ریلیز کردن.😑

مشکل دوم این بود که وقتی میخواستم بصورت همزمان دو انوتیشن @inject و یه qualifire به اسم @PerFragment رو برای یه فیلد استفاده کنم، برنامه کرش میکرد!! بعد از کلی دیباگ کردن و بررسی سورس‌های جنریت شده‌ی Dagger، متوجه شدم qualifireیی که میذارم اصلا اثر نمیکنه، انگار وجود نداره!! در نهایت با سرچ کردن، فهمیدم اگر میخوام همچین کاری رو توی کاتلین بکنم، باید از یه انوتیشن به اسم @field استفاده کنم. وقتی کد رو به شکل زیر تغییر دادم، برنامه درست شد.

این نکته رو از یه issue توی ریپوی Dagger یاد گرفتم. کلا داخل این issue در مورد Best Practiceهای استفاده از Dagger توی کاتلین صحبت میکنن. نکته‌های جالبی داخلش هست.

https://github.com/google/dagger/issues/900

 

تفاوت onCreateView با onViewCreated

همون شبی که پروژه رو توی گیت‌هاب گذاشتم، شایان پوروطن لطف کرد و ۲ ۳ ساعتی در مورد جزییات پیاده‌سازی پروژه صحبت کردیم. جدای همه نکته‌هایی که ازش یاد گرفتم، یه نکته جالب و ساده هم یادم داد. قضیه این بود که من غر میزدم چرا نمیتونیم داخل متد onCreateView فرگمنت از قابلیت static layout imports کاتلین استفاده کنیم و مجبوریم بجاش کدمون رو توی متد onViewCreated بنویسم، اینجا بود که شایان بهم گفت خب درستش همینه و نه اونکاری که من تا الان میکردم😀

تا اون لحظه، هرچی سورس و مثال دیده بودم، همشون توی onCreateView کار findview رو انجام داده بودن و این باعث شده بود که فکرکنم راه درستش اینه!!! درصورتی که اشتباه بود. البته خیلی کم پیش میاد که این اشتباه باعث باگ بشه ولی بهرحال امکانش هست. دلیل اشتباه بودنش اینه که اگر layout پیچیده باشه، احتمال داره بعضی از viewها هنوز توی onCreateView ساخته نشده باشند!! برای اطمینان بیشتر باید هرکاری با view دارید، توی onViewCreated انجام بدید.

 

کشف ریپوهای کاتلینی-اندرویدی

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

اولی android-ktx که extensionهای کاربردی اندروید هست.

https://github.com/android/android-ktx

دومی kotlin-guides که راهنمای استفاده از کاتلین در پروژه‌های اندروید هست.

https://github.com/android/kotlin-guides

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

حالا برسیم به اصل موضوع که چطوری میشه ارائه‌ی خوبی داشته باشیم. شرایط نسبت به سالهای گذشته تغییر کرده و رویداد‌های زیادی توی کشور برگزار میشن، بطور مثال @irlogcat که برای اندروید هس هر ماه داره برگزار میشه. در نتیجه این فرصت برای همه هست که بتونن دانششون رو در اختیار بقیه بذارن، شاید همین الان شما هم داوطلب ارائه توی یکی از این رویدادها باشید یا حداقل تصمیم گرفته باشید در آینده اینکارو بکنید. اما یه نکته‌ی مهم اینه بخاطر وجود سایت‌هایی مثل Youtube و بالا رفتن سرعت اینترنت خیلی از کسایی که توی رویدادهای داخلی شرکت میکنند، ارائه‌هایی که خارج از ایران برگزار میشن رو هم دیدن و انتظارشون بالاتر رفته. برای همین بهتره اگر میخوایم جایی ارائه بدیم، سعی کنیم با تمرین کیفیت ارائه‌مون رو بالاتر ببریم و به ارائه‌های خوب خارجی نزدیک کنیم.

یکی از نکات عجیبی که من توی توییتر میبینم، اینه که خیلیا به این قضیه افتخار میکنند که مثلا یکساعت قبل ارائه اسلایدهارو درست کردن و بعد رفتن ارائه دادن یا فقط یه روز برای آماده‌سازی کل ارائه وقت گذاشتند. بنظر من این قضیه بیشتر از اینکه نشون بده یه نفر خیلی باحال و خفن هس، نشون میده برای اونا که میخوان ارائه‌اش رو ببینن اهمیت قائل نیس. در این رابطه مقاله‌ی “How to Prepare a Talk” که در ادامه لینکشو میذارم یه نکته جالب گفته، اونم اینه که میگه برای آماده‌سازی یه ارائه حداقل باید ۲۰ساعت وقت بذارید! بعد خودش مثال زده که اگر احساس میکنید این زمان خیلی زیاده، اینجوری فکرکنید که ۵۰۰نفر ارائه‌ی ۳۰دقیقه‌ای شمارو میبینند (حضوری،آنلاین یا بعدا ضبط شده)، اگر ۵۰۰*۳۰ رو حساب کنید میشه ۱۵۰۰۰دقیقه نفر-دقیقه که همون ۲۵۰نفر-ساعت هست. حالا واقعا ارزش نداره شما ۲۰ساعت وقت بذارید تا ۲۵۰ساعت بقیه الکی هدر نره؟!

همه‌ جای مقاله‌ “How to Prepare a Talk” که خوبه ولی یه بخش دیگشم برام خیلی جالب بود، همیشه فکرمیکردم من عجیبم که خوشم نمیاد روی کاغذ نکته‌ای بنویسم و همراه خودم برای ارائه ببرم! (چون اینو به عنوان توصیه‌ی خوب برای ارائه زیاد شنیدم)، دلیلشم اینه که سعی میکنم اینقدر تمرین کنم تا با دیدن اسلایدها نکاتی که میخوام بگم یادم بیاد و اگرم نکته‌ای یادم رفته! کلا دیگه یادم بره، نه اینکه توی کاغذ یه چیزی ببینم که نوشته باشم بگم ولی یادم نیاد!!!!! درواقع دوس ندارم دیگه درگیر یه کاغذ بشم و میخوام تمرکزم همون ارائه دادن باشه. حالا وقتی این مقاله رو خوندم، فهمیدم من عجیب نیستم! واقعا این روشی هس که بعضیا استفاده میکنند. تا حالا به کسی اینکاری که خودم میکردمو توصیه نمیکردم، از این به بعد به بقیه پیشنهاد میدم چون ارائه دادن رو راحت‌تر میکنه.

حتما اگر ارائه دادن رو دوست دارید یا میخواید ارائه بدید این مقاله‌ی طولانی رو بخونید. نکاتش خیلی بیشتر از این هست که من بتونم دونه دونه بنویسم و بهتره برید خودشو بخونید.  هرچقدر ازش تعریف کنم، کم هس. تک تک نکته‌هایی که در مورد مراحل آماده‌سازی یه ارائه میگه واقعا تاثیرگذار و کاربردیه. کاشکی به جای اون مطالبی که توی درس “درس شیوه ارائه مطالب علمی وفنی” داخل دانشگاه میگن (البته از همه دانشگاه‌ها خبر ندارم،برای ما که مسخره بود)، از این جور مقاله‌ها معرفی کنن. لینک مقاله “How to Prepare a Talk”:

https://www.deconstructconf.com/blog/how-to-prepare-a-talk

توی پست قبلی در مورد الگوهای مختلف ساخت پروژه‌های اندروید صحبت کردم و خلاصه‌ای از تحقیقاتمو نوشتم. خروجی اون تحقیقات یه پروژه تمرینی براساس الگوی “تک اکتیویتی، چند فرگمنت” شده که در ادامه بیشتر در موردش توضیح میدم و میتونید از طریق گیت‌هابم به سورسش دسترسی پیدا کنید.

توی این پروژه تمرکزم روی این قضیه بوده که چطوری جا به جایی بین صفحه‌های برنامه (همون فرگمنت‌ها) رو مدیریت کنم. برای همین فعلا الگوهای معماری مثل MVP یا Dagger2 و RxJava رو قاطی پروژه نکردم. در ضمن از زبان Kotlin برای ساخت پروژه استفاده کردم تا با این زبان بیشتر آشنا بشم ولی بدیهی هس که هرکاری توی این پروژه کردم رو میشه خیلی راحت توی یه پروژه‌ی جاوایی انجام داد.

 

چالش‌ها

سعی کردم انواع چالش‌هایی که بخاطر استفاده از فرگمنت‌ها توی پروژه‌های واقعی پیش میاد رو توی این پروژه پیاده کنم تا اگر پیاده‌سازیم مشکلی داره سریعتر متوجه بشم. چالش‌هایی که به ذهنم رسید این موارد بوده: (اگر چالش دیگه‌ای به ذهنتون میرسه بهم بگید تا در موردش بیشتر صحبت کنیم)

۱- استفاده از BottomNavigationView: جدیدا در بیشتر برنامه‌ها از Bottom Navigation استفاده میشه، به همین دلیل منم برای شروع این مدل نویگیشن رو انتخاب کردم. البته در آینده میشه مثال‌ رو با navigation drawer هم پیاده کرد یا مدیریت backstack رو از حالتی که الان هست به حالتی شبیه اینستاگرام تغییر داد که هر تب برای خودش backstack جدا داشته باشه.

۲- مدیریت دکمه‌ی Back: بصورت پیشفرض این دکمه رو اکتیویتی مدیریت میکنه ولی خیلی وقتا پیش میاد بعضی از فرگمنت‌ها نیاز دارند که خودشون اینکارو به جای اکتیویتی میزبان مدیریت کنند.

۳- استفاده از Tab به همراه ViewPager در فرگمنت: گاهی پیش میاد یه فرگمنت داخلش تعدادی تب داره که هر تب خودش فرگمنت جدایی هس، توی این حالت مدیریت فرگمنت‌های داخلی به عهده‌ی اداپتر ViewPager هست

۴-  استفاده از فرگمنتی که داخلش تعدادی فرگمنت دیگه داره: در ظاهر میتونه شبیه حالت قبلی باشه ولی فرقش توی اینه مدیریت فرگمنت‌های داخلی با فرگمنت والد هست.

۵- مدیریت ویوهای داخل اکتیویتی: گاهی توی اپلیکیشن نیاز هست وقتی کاربر روی آیتمی کلیک کرد، به جزییاتش بره. توی این حالت دیگه نیاز نیست Bottom Navigation رو ببینه یا شاید لازم باشه دکمه‌ی FAB نشون داده بشه.

 

ایده‌ها

برای اینکه بتونم این چالش‌های بالارو حل کنم، از ایده‌‌های زیر استفاده کردم.

ایده اول – مدیریت جا به جایی صفحات یا همون navigation رو به یه کلاس به اسم NavigationManager سپردم. البته خیلی از مثال‌های توی گیت‌هاب اینجوری بودند. اینکار باعث رعایت شدن اصل Single Responsibility که حرف S در اصول SOLID هست میشه. این کلاس برای مدیریت navigation نیاز به یدونه FragmentManager و شناسه لیوتی که قراره کانتینر فرگمنت‌ها باشه داره. وقتی مدیریت navigation در یک کلاس جدا باشه، در آینده میشه مثلا بدون اینکه بقیه بخش‌های برنامه رو خیلی تغییر داد، بجای backstack اندروید از یه backstack کاستوم استفاده کرد. درکل دست آدمو برای توسعه‌های بعدی باز میذاره.

ایده دوم- برای اینکه بتونم ساختار تو در تو بودن فرگمنت‌هارو در جاهایی که خود فرگمنت شامل تعدادی فرگمنت دیگه باشه رو مدیریت کنم، از پیاده‌سازی Dagger2 ایده گرفتم. ایده اینه هر کلاسی که اینترفیس HasNavigationManager رو پیاده‌سازی کرده باشه وظیفه داشته باشه فرگمنت‌های داخلشو مدیریت کنه ( از ماژول اندروید Dagger2 و نحوه‌ی کمک گرفتنش اینترفیس‌های HasActivityInjector یا HasFragmentInjector الگو گرفتم). قضیه اینه هر فرگمنت وقتی داره لود میشه چک میکنه چه کسی مدیریتشو داره و ازش یه object از نوع NavigationManager میگیره تا کارهایی که نیاز داره رو انجام بده. اون کلاسی که اینترفیس HasNavigationManager رو پیاده میکنه، باید در پیاده‌سازی متد provideNavigationManager یه object از نوع NavigationManager برای فرگمنت‌های که مدیریت میکنه فراهم کنه تا اونا به روشی که گفتم ازش استفاده کنند. اینکار باعث میشه چالش ۴ راحت‌تر حل بشه و مدیریت سلسله مراتبی باشه، در نتیجه اکتیویتی میزبان همه‌ی این فرگمنت‌ها خیلی شلوغ نشه!

ایده سوم- فرگمنت‌هایی که نیاز داشته باشند دکمه‌ی back رو مدیریت کنند، میتونند متد onBackPressed رو که داخل BaseFragment هست، override کنند. اکتیوتی وقتی دکمه‌ی بک زده میشه، چک میکنه فرگمنت جاری (من فرض کردم همیشه یه فرگمنت به عنوان فرگمنت جاری باشه! این فرض رو میشه در آینده عوض کرد. الان هر فرگمنتی که آخرین بار نشون داده شده باشه میشه فرگمنت جاری) میخواد بک رو هندل کنه یا نه؟! اگر کرد که اکتیویتی کاری نمیکنه و اگر نکرد، خود اکتیویتی کار همیشگیش رو انجام میده.

ایده چهارم- برای اینکه هر فرگمنت بتونه المان‌های داخل اکتیویتی رو برای خودش مدیریت کنه، یه سری متد توی اینترفیس FragmentInteractionListener تعریف کردم. فرگمنت‌ها برای ارتباط با اکتیویتی میزبان از اینترفیس‌های خودشون مثل OnNotificationFragmentInteractionListener یا OnProfileFragmentInteractionListener استفاده میکنند که همشون از FragmentInteractionListener ارث‌بری میکنند، در نتیجه همه فرگمنت‌ها میتونن متد‌های داخل اینترفیس FragmentInteractionListener که اکتیویتی میزبانشون پیاده‌سازی کرده رو صدا بزنند.

در آخر تاکید کنم این پروژه تمرینی در حال توسعه هست و امکان داره جاهاییش اشکال داشته باشه یا حتی در آینده تغییر بکنه، در نتیجه با اینکه تلاشم اینه همه‌ی BestPracticeهارو داخلش رعایت کنم ولی فعلا زوده که خیلی خیلی مطمئن از ساختارش توی پروژه‌هاتون استفاده کنید.

میتونید سورس کامل پروژه رو توی گیت‌هابم و ریپوی SingleActivityPattern ببینید.

از وقتی اندروید رو شروع کردم، خیلی رابطه‌ی خوبی با فرگمنت نداشتم و فقط جاهایی که مجبور بودم ازش استفاده کردم. تا الانم پیش نیومده پروژه‌ای رو بطور کامل با فرگمنت درست کنم. چند وقته که خیلی وسوسه شدم به سمت استفاده‌ی بیشتر از فرگمنت برم و دو سه روزی هست که دارم روی این موضوع تحقیق میکنم. سعی کردم مقاله‌ها و سورس‌های مختلفی که به این موضوع ربط دارند رو دونه دونه بخونم و روی فرق‌هاشون فکرکنم. البته در مورد فرگمنت‌ها و مخصوصا FragmentManager هم بیشتر مطالعه کردم، تقریبا هیچ دیدی از نحوه‌ی کار FragmentManager نداشتم ولی الان خیلی بهتر شدم😃. این پست بیشتر از اینکه قرار باشه الگوی خاصی رو تایید کنه یا قضیه‌ای رو اثبات کنه، خلاصه‌ای از تحقیقات شخصیم هس که در نهایت خروجیش یه پروژه‌ی تمرینی با الگوی “تک اکتیویتی، چند فرگمنت” شده که چند روز آینده توی گیت‌هاب میذارم. ادامه …

اگر خیلی پروژه‌ی اندروید روی لپ‌تاپتون داشته باشید، کلی از هاردتون رو پر میکنند. البته بخش‌های اصلی پروژه خیلی فضا نمیگیرند و اصولا ۸۰درصد از فضای اشغال شده بخاطر فولدرهای build هست. چند روز پیش دیدم که هاردم پر شده و هرچی گشتم چیزی پیدا نکردم که بشه پاک کرد تا هارد خالی بشه. واسه همین رفتم سراغ پروژه‌های اندرویدم تا فولدرهای build اون پروژه‌هایی که دیگه خیلی ازشون استفاده نمیکنم رو پاک کنم. چندتایی رو پاک کردم اما دیدم خیلی طول میکشه😴 واسه همین تصمیم گرفتم به جای اینکه یه کار تکراری رو پشت هم انجام بدم، یه shell script بنویسم که همینکارو برام بکنه😎

بعدی کمی سرچ کردن، آخرش تونستم به نتیجه‌ای که میخوام برسم. این اسکریپ که نوشتمو اگر توی فولدر پروژه‌هاتون اجرا کنید، دونه دونه ازتون میپرسه که میخواید فولدرهای build کدوم پروژه رو پاک کنه! اگر y یا Y جواب بدید، همه فولدرهای build رو پاک میکنه😃 با این کار تونستم ۵گیگ هاردمو خالی کنم، بدون اینکه چیز مهمی رو پاک کنم!😃 لینک اسکریپت:

https://gist.github.com/abbas-oveissi/2d85b8178c11952ae8960392d834b03a

‼️نکته‌ی مهم: اگر میخواید اسکریپت رو تست کنید، حتما از پروژه‌هاتون نسخه‌ی پشتیبان داشته باشید. چون من تخصصی توی اینجور چیزا ندارم و تازه دارم یاد میگیرم😃یهو مشکلی برای پروژه‌هاتون پیش نیاد!

هنوز یه هفته از زلزله‌ی قبلی نگذشته که دوباره یک ساعت پیش یه زلزله‌ی ۴.۲ ریشتری اومد. اومدن زلزله به آدم استرس و نگرانی میده، ولی بدتر از خود زلزله این صحبت‌هایی هست که بعضیا به استناد این کانال پیش‌بینی زلزله (@pishbiniezelzele21) میکنند. هفته‌ی پیش در مورد این کانال زیاد صحبت میشد اما اصلا فکرنمیکردم موضوع دنباله‌داری باشه و مطمئن بودم که حتما توسط پلیس دستگیر میشه و کانال رو مسدود میکنند. حالا نه تنها کانالش مسدود نشده، حتی ۱۰۰هزار نفر به عضو‌هاش اضافه شدن!!!!!

ادعای پیش‌بینی زلزله

صاحب کانال آقای علی اصغر برهمند هست، ایشون ادعا میکنند اولین کانال پیش بینی علمی زلزله رو دارند که از طریق دریافت‌ اطلاعات ماهواره‌ای ومحاسبات ریاضی وتغییرات تکتونیکی زمین! میتونند با دقت ۷۰ درصد زلزله رو پیش‌بینی کنند. البته من که کانالشون رو بررسی میکردم فقط مختص به ایران نیس و زلزله‌های ایتالیا یا جاهای دیگه رو هم پیش‌بینی میکنند. توی کانالشون گفتند که اگر بهش کمک کنند، دقت پیش‌بینیشو به ۸۵ درصد میرسونه! ادامه …

سایت یوتیوب، یکی از منابع مهم یادگیری برنامه‌نویسی هس! بطور مثال توی پست “منابع آموزشی برای افزایش مهارت در برنامه‌نویسی اندروید” در مورد این صحبت کردم که میشه از طریق یوتیوب به ویدئو‌ی کنفرانس‌های اندروید دسترسی داشت. بخاطر اینکه بعضی از دوستان توی دیدن ویدئو‌ها مشکل داشتند، یه پیام توی کانال تلگرام نوشتم و روش‌هایی که برای دانلود از یوتیوب استفاده میکنم رو معرفی کردم. بعد این پیام، تعدادی از دوستان هم روش‌های دیگه‌ای رو معرفی کردند که بعضی‌هاش خیلی خوب بودند. در ادامه میتونید این روش‌هارو ببینید. (ترتیبشون دلیل خاصی نداره و همه رو چک کنید تا روشی که باهاش راحت‌ترید رو پیدا کنید) ادامه …