Droid Hub✨

کروتین از واژه‌ی cooperative routines تشکیل شده است. یعنی روتین‌هایی که با یکدیگر همکاری می‌کنند. این بدین معناست که هنگامی که یک روتین در حال اجراست سایر روتین‌‌ها با suspend کردن خودشان ارتباطشان با cpu ، memory و هر ریسورس دیگری را قطع می‌کنند تا از بلاک کردن آن‌ها جلوگیری شود. کوروتین ها یک مکانیسم lightweight و موثر در concurrency هستند که می توانند در Kotlin برای نوشتن کدهای ناهمزمان و غیر مسدود کننده استفاده شوند. آن‌ها در مقایسه با مدل‌های threading سنتی مزایای زیادی دارند، از جمله: ا Simplicity: فهم کروتین‌ در مقایسه با threading API ها آسان تر است و برای توسعه دهندگان با هر سطحی از دانش قابل دسترس تر است. ا Efficiency: کروتین ها lightweight هستند و کم‌ترین میزان overhead را دارند. بنابراین می‌توان تعداد بسیار زیادی از آن هارا بدون آنکه روی عملکرد سیستم تاثیر گسترده‌ای بگذارد ایجاد کرد. ا Asynchrony: کروتین‌ها می‌توانند برای نوشتن کد‌های asynchronous و non-blocking استفاده شوند. آن‎‌ها می‌توانند فعالیت‌های طولانی مدت(long-running) را بدون بلاک کردن ترد اصلی سیستم انجام دهند. ا Exception handling: کروتین به صورت built-in از قابلیت Exception handling پشتیبانی می کند. این بدین معناست که به ارور‌ها اجازه می‌دهد تا در سلسله مراتب به سمت بالا حرکت کنند تا به handler مناسب خودشان برسند. این کار نوشتن کدی را که در برابر خطاها مقاوم باشد آسان‌تر می‌کند. ا Structured concurrency: کروتین به صورت built-in از قواعد Structured concurrency پشتیبانی می‌کند. این پترن مطمئن می‌شود آغاز، اجرا، پایان یا کنسل شدن کروتین‌ها در یک زمان قابل پیشبینی و در یک مسیر امن صورت بپذیرد. این امر باعث می‌شود تا کروتین‌ها دچار ریسورس leak نشوند و از شر ارور‌های رایج در اعمال concurrency در امان بمانند. در آینده به معرفی structured concurrency خواهیم پرداخت. #coroutines

دوستان من سعی میکنم از این به بعد با هشتک #coroutines یه سری مطالب تئوری تر رو راجب کروتین براتون مطرح کنم که هم به درد مصاحبه بخوره هم اینکه بعدا بتونیم در رابطش با هم تعامل بیش تری داشته باشیم. سعی میکنم تو این مطالب از چیز های ساده تر شروع کنم بعد کم کم بریم سراغ مطالب دیپ تر

سوناتایپ اعلام کرده که طی یک بررسی متوجه شده که 83 درصد از پهنای باند maven central فقط توسط 1 درصد از ip ها داره مصرف میشه و کانسپتی به نام tragedy of the commons رو مطرح میکنه که به این معنیه که وقتی یک چیزی به طور عمومی و رایگان در دسترسه یه سری از افراد فقط در جهت منافع شخصی خودشون عمل میکنن و سعی میکنن انقدر ازش استفاده کنن تا خرابش کنن. بعد مطرح میکنه که بررسی کردن که 1 درصد از ip ها از کجا هستن و به طور مشخص متوجه شدن که چند تا شرکت خاص ان که دارن این حجم از پهنای باند رو مشغول میکنن. به خاطره همین اعلام کرده که به زودی این IP هارو بلاک میکنه و توصیه کرده که این شرکت ها برن و سرور خودشون رو بخرن و مخزن رو روی سرور خودشون بیارن بالا! همچنین اعلام کردن که از این به بعد سیاست های سخت گیرانه تری در رابطه با این مورد اعمال میکنن تا عدالت بین همه برقرار بشه و بتونن هزینه های خودشون رو کاهش بدن تا این سرویس رو همچنان رایگان نگه دارن

تو گیتهاب drop box یه سری پلاگین باحال گریدلی وجود داره که اگر دوست داشتید میتونید تو پروژه ها ازش استفاده کنید. https://github.com/dropbox/dependency-guard https://github.com/dropbox/focus https://github.com/dropbox/AffectedModuleDetector

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

یکی از کامنت های معروف در android sdk این کامنت در کلاس Process هست. beat up = ضرب و شتم

قبلا‌ من maestro رو که برای تست e2e اپ ها استفاده میشد رو در لینکدین معرفی کرده بودم. حالا همین رو اومدن و با ai ترکیبش کردن و یه ابزار قدرتمند برای این کار ایجاد کردن. روش کارش به این صورته که شما سناریو رو برای ai توضیح میدی و بعد خودش استپ بای استپ جلو می‌ره تا فلو رو به پایان برسونه اگر همه چیز اوکی بود که success میشه و در صورت دریافت نتیجه ی غیر قابل انتظار fail میشه. این ابزار خفن هنوز پابلیک نشده اما شما میتونید تو waitlist اش جوین بشید. https://www.mobile.dev/copilot

https://slackhq.github.io/circuit/ https://github.com/cashapp/molecule https://www.youtube.com/playlist?list=PLY-K9deHTAW7w28X1RL1YKAk9gCrvVr54 ایده ای که در این جا مطرح میشه خیلی جالبه. فقط من نمیدونم استفاده ازش به جای view model چه قدر کار درستیه

من تو اندروید استادیو نسخه کوالا به شدت به مشکل خوردم، قسمت analyze در compiler frontend که وظیفه ی بررسی خطا ها در هر فایل kt به صورت ران تایم رو داره عملا کار نمیکنه و من در حین کد نویسی نمیتونم متوجه بشم که کجای کد مشکل داره. ترمینال اندروید استادیو کرش میکنه و باز نمیشه. پلاگین sqldelight هم کار نمیکنه. مجبور شدم که به نسخه ی ایگوانا دانگرید کنم. نمیدونم این مشکل برای همه ست یا وابسته است به پروژه ی من.

Advanced goat recognition technology in the Android SDK

The Monkey is a program that runs on your emulator or device and generates pseudo-random streams of user events such as clicks, touches, or gestures, as well as a number of system-level events. You can use the Monkey to stress-test applications that you are developing, in a random yet repeatable manner. https://developer.android.com/studio/test/other-testing-tools/monkey

این بده !

این امکان union types with error در کاتلین که فکر کنم هنوز هم کامل منتشر نشده، چیز واقعا جالبیه. در واقع دست افراد رو برای هندل کردن سناریو های شامل خطا و exception باز می گذاره. سابقا برای این کار از wrapper هایی مانند Result و یا Either استفاده می کردیم تا بتونیم ارائه ای از یک value و یا خطا های آن داشته باشیم. اما به کمک این امکان جدید احتیاجی به ایجاد یک ابجکت جدید برای Either و یا Result نداریم (در واقع صرفا مانند یک تایپ جدید با آن ها رفتار میکنیم) به علاوه اینکه Union types with errors میتونه شامل operator های زیادی باشه به ویژه operator هایی برای بررسی اینکه نتیجه success شده و یا شامل error است. !: operator) a !: b translates to if(a is Error) b else a !! operator) a!! translates to if(a is Error) a.throw() else a

جالبه بدونید که خود گوگل هم از این روش استفاده میکنه. در AGP (Android Gradle Plugin) یک مکانیسمی وجود داره که بررسی میکنه که به کدام فایل ها و وابستگی ها میتونه اعتماد کنه و در صورت یافتن یک فایل untrusted فرایند build رو متوقف میکنه. این یک اقدام امنیتی به جهت جلوگیری از تولید apk با فایل های مخرب و حاوی آسیب پذیری هست. یکی از روش هایی که برای تشخیص صحت فایل در AGP استفاده میشه همین روش بررسی امضای دیجیتال فایل هاست. پ.ن) آیدی هایی که در تصویر هست، همون امضای دیجیتال فایل هاست.

اگر خواستید که وقتی اپ تون توسط یک شخص دیگه Modify شد در زمان ران تایم از کار بیفته و قابل استفاده نباشه میتونید signature اپتون رو بررسی کنید و یا اینکه در تمام رمزنگاری های برنامتون به کلید ها اضافش کنید. وقتی یک attacker برنامه ی شمارو modify میکنه اولین چیزی که در برنامه شکسته میشه همین original signing key هست. بنابراین میتونید اطمینان حاصل کنید که signature در برنامه ی شما یک پارامتر غیر قابل جعل هست. پ.ن) تو این تابع هش رو hardCode کرده شما این کار رو نکنید و در یک جای امن مثل سرور ازش نگهداری کنید.

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

معمولا اپ های بانکی تو ایران زیاد به معماری single-activity اعتقادی ندارن

پ.ن : screenshot testing روشی است که در آن یک اسکرین شات از قسمتی از ui که در حال حاضر رندر شده است گرفته می شود و با تصویری که به عنوان رفرنس صحیح معرفی کرده ایم مقایسه می شود و در صورت عدم تطابق تست fail شده و test reporter یک گزارش از تفاوت پیدا شده ایجاد می کند.