https://virgool.io/feed/@husen Software Engineer (Django/Python | Flutter/Dart) fa 2026-06-10 12:50:18 https://files.virgool.io/upload/users/14255/avatar/oiSRty.png?height=120&width=120 https://virgool.io/@husen https://virgool.io/coderlife/%D8%AA%D9%88%D8%A7%D8%A8%D8%B9-immutable-%D9%88-%D8%A7%D8%B1%D8%AA%D8%A8%D8%A7%D8%B7-%D8%A2%D9%86-%D8%A8%D8%A7-val-%D8%AF%D8%B1-%DA%A9%D8%A7%D8%AA%D9%84%DB%8C%D9%86-uvqeiqaz2vg6 Kotlin Immutabilityمباحث این مقاله :مفهوم تغییرناپذیریاثبات تغییرناپذیر نبودن valپیاده سازی val تغییرناپذیرانواع توابع تغییرناپذیر https://gist.github.com/husen-hn/a8f717844c3076b7b666e8f8ed084d94 یک شیء یا ویژگی mutable بعد ساخته شدن قابل تغییر است، و در مقابل immutable شیء یا ویژگی است که حالت یا ویژگی آن پس از ایجاد تغییر نمی یابد، اگر نیاز به تغییر باشد باید یک نسخه جدید تغییر یافته از آن ساخته بشود. و در حالت کلی ما حالت یا state شی را تغییر نمی دهیم.در کاتلین بحث تعریف متغیر با var با ویژگی mutable و با val با ویژگی Immutable است، که val جای بحث بیشتری دارد. کاتلین به این صورت بیان می کند که val همون Immutable است، فقط اینکه همیشه Immutable بماند را گارانتی نمیکند.در ادامه مفصل تر توضیح میدم:درست نیست که ما val را Immutable بدانیم. طبق داکیومنت کاتلین val به عنوان "فقط خواندنی" شرح داده شده و این با Immutable بودن تفاوت دارد، چطور؟! https://gist.github.com/husen-hn/267d9decdff056d403fee5cff957c82d یه کلاس میسازیم که تعداد اشکال رو برای ما محاسبه میکند. https://gist.github.com/husen-hn/f87020104a6c7502aa7f085741d90bc2 از کلاس یه آبجکت میسازیم و سعی میکنیم که مقدار space.all که با val تعریف شده رو تغییر بدیم، در جواب اول که با مقدار های اولیه جواب ۴۷ و بعد از تغییر مقدار space.squares جواب به ۸۴ تغییر پیدا کرده بنابراین نمیشه به val برچسب Immutable زد. https://twitter.com/samdvr/status/1232011833143259136?s=20 آیا read-only با immutability متفاوت است؟میشود Immutable را با read-only برابر دانستن. به صورت دیگری، یعنی ما immutability را یک نوع deep read-only یا فقط خواندنی عمیق میدانیم. (میتوانیم متغیر فقط خواندنی (val) در کاتلین را همان immutability بدون گارانتی یا به نوعی فقط خواندنی سطحی بدانیم)پیاده سازی val تغییرناپذیرخب تا اینجا فهمیدیم که val فقط خواندنی است و قابل تغییر هم است؛ در ادامه سعی میکنیم این قابل تغییر بودن را هم سلب کنیم و یک متغیر deep read-only با val بسازیم. https://gist.github.com/husen-hn/576dbe241191c6d313842c744b597aac در کد مربوطه امکان نمونه سازی از کلاس MyValue وجود ندارد، ولی بجاش از MyValue.Immutable یا MyValue.Mutable نمونه سازی می کنیم. زیربنای پراپرتی value را با val تعریف کردیم و در MyValue.Mutable آن را override کردیم به var.در کاتلین چنین امکانی وجود دارد که با var یک پراپرتی val را override کرد ولی امکان برعکس این وجود ندارد، چون val یک getter دارد و شما میتوانید هنگام مشتق کردن با override، یک setter به آن اضافه کنید ولی شما نمیتوانید یک setter را در پراپرتی var در پایه را حذف کنید و با val آن را override کنید.با استفاده از این الگوی کاملا ساده، اجرای واقعی تغییرناپذیری را در compile-time به دست می‌آوریم: https://gist.github.com/husen-hn/73af94e31a395331953f4be95000e7af همچنین لازم به ذکر است که یک ترفند بسیار زیبا وجود دارد که می توانیم از آن برای ساختن یک خاصیت var تغییرناپذیر استفاده کنیم: https://gist.github.com/husen-hn/e6382ba6ca3b795645ef8581ee56ce7f هرچند value با var تعریف شده است، ما میتوانیم private setter بسازیم و value جوری رفتار کند که انگار با val تعریف شده: https://gist.github.com/husen-hn/06640639d733813b20af3c6ab7da6c5c علاوه بر این ها ما const val را هم داریم که برای ما immutability را گارانتی میکند، ولی انعطاف پذیری خیلی کمی دارد و فقط بعضی data type های اولیه رو پشتیبانی میکند، که نمیتواند در مسیر کد زنی سرویس دهی خوبی داشته باشد.خب! تا اینجا سعی کردیم با روش OOP تغییرناپذیری را تجربه کنیم، اساسا تغییر ناپذیری بر پایه Functional Programming است که یکی از پارادایم های تحت پشتیبانی کاتلین محسوب میشود که در ادامه به آن می پردازیم. (کاتلین برخلاف زبان هایی مثل کلوژور، هسکل و... pure نیست، یعنی بصورت خالص تابع گرا نیست دلیل آنهم مشهود است کاتلین زبانی اساسا شی گرایی است و تابع گرایی قدرتمندی را هم باخود دارد و با این اوصاف نمیتواند خالص باشد. تابع گرایی دقیقا جایی است که immutability از آنجا نشأت میگیرد، به همین خاطر کاتلین immutability قدرتمند مثل زبان های pure را دارا نیست)تغییرناپذیری در کاتلینبحث immutability را با انواع آن شروع میکنیم :تغییرناپذیری مرجع (Referential immutability)مقادیر تغییرناپذیر (Immutable values) https://media.giphy.com/media/SueY1pCpzCwne/giphy.gif تغییرناپذیری مرجع (Referential immutability)تغییر ناپذیری مرجع، درواقع بیان میکند که اگر رفرنسی یکبار اختصاص یابد، نمیتواند دوباره اختصاصی صورت بگیرد. تصور کنید یک پراپرتی val از یک کلاس خاص دارید یا MutableList یا MutableMap؛ بعد از ارجاع اولیه شما نمیتوانید ارجاع دیگری داشته باشید. بجز ویژگی آبجک ارجاع داده شده، برای مثال به کد زیر دقت کنید: https://gist.github.com/husen-hn/9946fa42c96185eb9df17b0316de3ae4 خروجی:MutableObj MutableObj(value='') MutableObj MutableObj(value='Changed') [a, b, c, d, e] [a, b, c, d, e, f]خب ما اینجا دو پراپرتی val داشتیم یکی list و یکی با mutableObj. ما mutableObj را با آبجکت MutableObj() مقدار دهی کردیم و چون این پراپرتی با val است mutableObj همیشه به آبجکت MutableObj() اشاره خواهد کرد. ولی اگر در کامنت (2) متوجه شدید ما ویژگی mutableObj را تغییر دادیم، از آنجایی که پراپرتی کلاس MutableObj تغییرپذیر (var) است.همین کار رو با list هم انجام دادیم، ما میتونیم بعد از مقدار دهی اولیه لیست، آیتم های دیگه ای را اضافه کنیم، هردو list و mutableObj مثال خوبی از تغییرناپذیری مرجع یا immutable reference هستند. پراپرتی ها مقداردهی اولیه میشوند و دیگر نمیشود که چیز دیگری اختصاص داد، اما مقادیر اساسی آنها قابل تغییر است. دلیل این، نوع داده ای است که برای اختصاص به آن پراپرتی ها استفاده می کنیم. هم کلاس MutableObj و هم ساختمان داده MutableList قابل تغییر هستند، بنابراین ما نمی توانیم تغییرات مقدار را برای نمونه های (instance) آنها محدود کنیم.مقادیر تغییر ناپذیر (Immutable values)طرف دیگر مقادیر تغییر ناپذیر یعنی در مقادیر آن هیچ تغییری صورت نگیرد؛ و نگهداری بسیار پیچیده ای دارد. در کاتلین const val تغییر ناپذیری مقادیر را برای ما نشان میدهد که از لحاظ انعطاف پذیری خیلی مشکل دارد و فقط type های اصلی را پشتیبانی میکنه (قبلا درموردشون بحث کردیم) که همین محدودیت میتواند در سناریو های واقعی باعث دردسر بشود.مجموعه های تغییرناپذیر (Immutable collections)کاتلین درحد ممکن در هر جایی immutability رو ترجیح داده، کاتلین برای این امر گزینه هایی رو برای استفاده در زمان و جای خودش در اختیار توسعه دهنده قرار داده است. این قدرت این زبان را نشان میدهد، برخلاف بسیاری از زبان هایی که mutability را ترجیح داده اند (جاوا، C# و ...) و یا آنهایی که فقط immutability رو ترجیح دادند مثل هسکل، کلوژور،... . کاتلین هردو ویژگی را بصورت جداگانه دارد و این توسعه دهنده است که انتخاب میکند immutable باشد یا mutable. (چون کاتلین pure fp نیست قابلیت های بسیاری رو از دست داده ولی در عوض به بهترین شکل ممکن mutability و immutability رو یکجا جمع کرده است).کاتلین دو اینترفیس برای آبجکت های کالکشن دارد. Collection و MutableCollection؛ همه کلاس های کالکشن (مثل List, Set, یا Map) یکی از آن دو را پیاده سازی میکند. همانطور که از نامشان پیداست، این دو اینترفیس به ترتیب برای سرویس دهی به کالکشن های تغییرناپذیر و قابل تغییر طراحی شده اند. برای مثال: https://gist.github.com/husen-hn/1923fcd531953458fb84fe10a2f79b1d خروجی:Immutable List [1, 2, 3, 4, 5, 6, 7] Mutable List [1, 2, 3, 4, 5, 6, 7] Mutable List after add [1, 2, 3, 4, 5, 6, 7, 8] Mutable List after add [1, 2, 3, 4, 5, 6, 7]اینجا با کمک متد listOf، لیست immutable ساختیم (کامنت 1). متد listOf یک لیست immutable میسازد. این متد یک generic type نیز دارد که اگر المنت های آرایه خالی نباشند نیازی به آن نیست. متد listOf یک نسخه mutable نیز دارد. mutableListOf() هیچ تفاوتی ندارد بجز در اینکه MutableList برمیگرداند.ما میتونیم یک لیست immutable را به لیست mutable به کمک تابع افزونه (extension function) toMutableList() تبدیل کنیم (کامنت 2). و در کامنت 3 یک المنت جدید اضافه میکنیم. به هرحال خروجی را اگر چک کنیم لیست تغییر ناپذیر اصلی بدون هیچ تغییری باقی مانده است، با این حال المنت به جای آن به لیست جدید ایجاد شده که MutableList است، اضافه می شود.در این مقاله باهم یاد گرفتیم که تغییر ناپذیری در کاتلین به چه صورتی است. این ویژگی زیبای ارث رسیده از دنیای functional programming رو باید عمیق تر یاد بگیریم و امکانات بسیار قدرتمندی که کاتلین بر اساس fp توسعه داده است حداکثر استفاده را بکنیم، برای این امر دو کتاب Functional Kotlin و Functional Programming in Kotlin در زمان نوشتن این مقاله در بازار موجود است.کتاب دومی خیلی بهتر از اولی است ولی کامل نیست هنوز، کتاب اولی بیشتر به معرفی میپردازه و من تجربه خوبی با آن نداشتم. همچنین کتاب Programming Kotlin فصل ۳ که درمورد برنامه نویسی فانکشنال است خیلی خوب از صفر و پایه ای شروع میکنه ولی حقیقت در اینه که برای یادگیری عمیق و درک خوب و درست از برنامه نویسی فانکشنال خوبه که با یک زبان فانکشنال خالص سروکله بزنیم. مثل: لیسپ، کلوژور، هسکل، الکسیر و... . حسین حسن نژاد حسین حسن نژاد Fri, 02 Oct 2020 12:33:10 +0330 https://virgool.io/@husen/%DA%86%DB%8C%D8%B2%DB%8C-%DA%A9%D9%87-2-%D8%B3%D8%A7%D9%84-%D8%AA%D9%88%D8%B3%D8%B9%D9%87-%D8%A7%D9%86%D8%AF%D8%B1%D9%88%DB%8C%D8%AF-%D8%A7%D8%B2-%D8%B1%D8%A7%D9%87-%D8%B3%D8%AE%D8%AA-%D8%A8%D8%B1%D8%A7%DB%8C%D9%85-%D8%A2%D9%85%D9%88%D8%AE%D8%AA-asqfdgpo00uw 1. اختراع دوباره چرخ نکنیدابتدا، من یک ایده بد داشتم ، برای استفاده نکردن از کتابخانه های منبع باز. هر چقدر که نیاز داشتم ، میخواستم خودم بسازم. واقعا ایده وحشتناکی بود.اگر هنگام طراحی برنامه خود مشکلی داشته باشید، و اگر آن مشکل پیشتر توسط شخص دیگری حل شده است و از یک راه خوب، چرا از آن استفاده نکنیم؟ شما می توانید زمان زیادی را صرفه جویی کنید.بیشتر در مورد منطق کسب و کار اصلی برنامه خود تمرکز کنید. اگر می خواهید تماس های شبکه ای را در برنامه خود بگنجانید، نیازی نیست که Retrofit خودتان را بسازید.نکته: Android Arsenal یک پایگاه داده از تقریبا همه کتابخانه های اندروید که تاکنون ساخته شده اند است. حتما چک کنید.2.کتابخانه ها را عاقلانه انتخاب کنیدتعداد زیادی از کتابخانه های منبع باز موجود در Github برای استفاده شما به صورت رایگان وجود دارد. اما خیلی هیجان زده نشوید و کورکورانه شروع به استفاده از کتابخانه ها نکنید.بصورت ویژه تعداد ستاره های کتابخانه ها را چک کنید، هرچه بیشتر بهتر. بررسی کنید که آیا نویسنده این کتابخانه ،کتابخانه های محبوب دیگری را نیز ایجاد کرده است یا خیر. موضوعات را بررسی کنید (هردو مورد باز و بسته)، که می‌تواند ایده بهتری از میزان پایداری و ثبات کتابخانه به شما بدهد.اگر به حد کافی وقت دارید، باید به کد آن کتابخانه شیرجه بزنید و خودتان کدها را چک کنید، اگر واقعا ارزشش را دارد.شما فقط می خواهید اطمینان حاصل کنید کد مورد استفاده شما قابل اعتماد، بدون خطا و با کیفیت بالا است.نکته: با Dryrun به کتابخانه های اندرویدی، مستقیم از کامند لاین دسترسی داشته باشید.3. یک فنجان قهوه بردار و بشین و بیشتر کد بخوانما بیشتر وقتمان را صرف خواندن کدهای دیگران میکنیم تا نوشتن آن ها. اگر این کار را نمیکنید، استارتش را از امروز بزنید.هر کدی که امروز شما میتوانید بزنید فقط بخواطر این است که یه چیزی را، یه جایی، یه روزی، یاد گرفتید. این فقط انعکاسی از آن چیزی است که شما در حال حاضر می دانید. شما فقط می توانید با خواندن و یادگیری از کارهای دیگر، خود را رشد و پیشرفت دهید.یک چیز بزرگ در مورد اندروید این است که این پلت فرم کاملا منبع باز است. توی کدها شیرجه بزن و بررسی کنید که چگونه این فریم ورک را اجرا کرده‌اند. هزاران کتابخانه منبع باز در Github وجود دارد. فقط یک کتابخانه را انتخاب کنید و ببینید که چگونه دولوپر آن را اجرا کرده است.نکته: در اینجا یک لیست از برخی از بهترین کتابخانه ها است و در اینجا یک لیست از تقریبا تمام برنامه های کاربردی اندروید منبع باز در دسترس است. خواهش میکنم :-)4.فقط بخاطر خدا، استانداردهای مناسب کدزنی را حفظ کنیداگر کدزدن را با نوشتن مقایسه کنید، کدزنی استاندارد همانند دست خط شماست.اگر شما کدهای دیگران را بیشتر مطالعه کنید، دیگران هم کدهای زیادی از شما را خواهند خواند، اینطور نیست؟ اگر شما در یک سازمان کار می‌کنید و به شدت با دیگر توسعه دهندگان همکاری میکنید، توجه خاصی به این مسائل داشته باشید.کوتاه نویسی، کدهای تمیز و خوانا را شما و دیگران میخوانند و باهم لذت میبرید. باید کدهای شما را مثل یک داستان خواند. کد شعر است.اگر یک قطعه کد بنویسید و همکاران تان چند روز با شما صحبت نکنند شکایت نکنید.جایزه: برای شروع، شما باید به طور کامل این و این موضوع را حل کنید. [ راهنمای استایل کد زنی کاتلین ]5.شما به ProGuard نیاز دارید، بله، نیاز دارید!هرگز هرگز این اشتباه را نکنید که برنامه خود را بدون استفاده از ProGuard در Play Store منتشر کنید. ProGuard باعث می‌شود که کد شما برای مهندسین معکوس برای درک کدها، تکثیر آنها و دستکاری آن، سخت‌تر باشد.کاملا رایگان است و بصورت یک باندل با Android SDK همراه است، هیچ دلیلی برای استفاده نکردن از آن وجود ندارد.من چندین توسعه دهنده را دیده ام که برنامه خود را بدون استفاده از ProGuard در مارک منتشر میکنند. بیش از چند ساعت طول نمی کشد که یک هکر مبتدی یک برنامه منتشر شده بدون استفاده از ProGuard را دستکاری کند.توصیه: اما اگر شما یک امنیت درجه یک می خواهید، پس ProGuard مانند یک تکه مقوا است در حالی که شما به یک امنیت مطمئن نیاز دارید، و در اینجا، به شما DexGuard را معرفی میکنم.6.از یک معماری مناسب استفاده کنیدشما بخاطر انتخاب معماری مناسب در اولین فرصت همیشه از خودتون تشکر خواهید کرد.شما می‌توانید از معماری (MVP (Model-View-Presenter استفاده کنید که می‌تواند کد شما را به لایه‌های مختلف آسان کند در نتیجه انعطاف‌پذیری کد را بهبود می‌بخشد و زمان نگهداری را به شدت کاهش می‌دهد.برای شروع یک پروژه دمو عالی اینجا برای شما وجود دارد. و اگر شما زمان زیادی را اختصاص داده اید، در اینجا یک راهنمای دقیق برای مبتدیان است.جایزه: این لینک و این لینک را چک کنید، این لینک را مهمتر از همه حتما چک کنید. همه اینها تا حد زیادی می تواند در اجرای MVP در پروژه شما کمک کنند.7.واسط کاربر مانند شوخی است، اگر باید توضیح دهید، بد استاگر برای هر سازمانی که نقش "فقط" یک توسعه دهنده Android را بازی می کنید، شما احتمالا بیش از این نگران نباشید زیرا طراحان UI / UX برای مراقبت از این کار وجود دارند.اما اگر شما یک توسعه دهنده شخصی هستید، شما باید این را مستقیم به سرتان ببرید. من توسعه دهندگانی را دیده ام که برنامه های واقعا خوب با قابلیت های عالی ایجاد کرده اند، اما UI آن وحشتناک بود و UX آن یک تجربه دردناک برای استفاده کننده داشت. رابط کاربری تمیز، ساده و زیبایی را طراحی کنید این یک دید سبک و روانی را به مخاطب میدهد. شما نباید فقط مثل یک توسعه دهنده فکر کنید، در عوض شما باید بر روی طراوت پنهان داخل خود تمرکز کنید.با ایجاد یک رابط کاربری زیبا، سعی کنید یک اثر پایدار بر روی کاربران خود ایجاد کنید، به طوری که آنها اغلب بیشتر از دیگران به برنامه شما می آیند و تمایل به تبدیل بیشتر دارند (ممکن است نسخه premium شما را بخرند). شما باید از گزینه حذف عناصر از طرح خود، به جای گزینه اضافه کردن، استفاده کنید. آنها را پاک و درحداقلی نگه دارید.نکته: شما همیشه میتوانید از طریق Dribble یا MaterialUp از طرح های محبوب الهام بگیرید. و اگر شما علاقمند به طراحی باشید، این کتابی است که شما احتمالا دوست دارید بخوانید.8.تجزیه و تحلیل بهترین دوست شماستاگر می خواهید یک برنامه واقعا شگفت انگیز ایجاد کنید،شما بشدت نیازمند ابزار تجزیه و تحلیل هستید برای تحلیل کردن کارایی و کاربرد بخش های مختلف برنامه شما.با تجزیه و تحلیل، من به هر دو گزارش خرابی (crash reporting)و ردیابی استفاده از برنامه(app usage tracking) مراجعه میکنم و شما به هر دو آنها نیاز دارید.هر کاری انجام دهید، شما هرگز نمیتوانید چیز کاملی را بسازید. زمانی که کاربران واقعی با دستگاه های اندرویدی متفاوت با نسخه های مختلف اندروید، شروع به استفاده از اپ شما بکنند، حتی بهترین کدهایتان که نوشته اید را خواهید دید که با زمین یکسان خواهند شد.ابزارهای گزارش سازی خرابی (Crash reporting tools) می تواند به شما در ردیابی و رفع آنها کمک کند، یک Crash در یک زمان.شما همچنین به عنوان یک بازاریاب باید شروع به فکر کردن کنید و استفاده از بخش های مختلف برنامه خود را تجزیه و تحلیل کنید. این چیزی است که به شما کمک می کند شکاف بین آنچه را که انجام داده اید و آنچه که کاربران واقعا می خواهند را از بین ببرید.توصیه: من به شدت توصیه می کنم از ابزار crash reporting در Instabug استفاده کنید. شما حتما عاشقش میشین.9.یک نینجای بازاریابی باشیداگر شما یک توسعه دهنده شخصی هستید، شما باید فراتر از "یک توسعه دهنده" فکر کنید و باید بازاریابی را نیز درک کنید. من محصولات خوبی را دیدم که به دلیل عدم بازاریابی مناسب شکست خوردند، و آنهایی که خیلی خوب نبودند فقط به دلیل بازاریابی عالی موفق شدند.اگر شما در مورد کار خود جدی هستید و میخواهید که آن به مخاطبان زیادی برسد، شما باید زمان و پول خود را برای بازاریابی در برنامه خود سرمایه‌گذاری کنید. اما قبل از شروع فعالیت های بازاریابی خود، اطمینان حاصل کنید که برنامه شما کاملا با تمام ویژگی های پایدار آماده است. تو بیشتر از هر پولی که خرج می‌کنی رو می خوایی، مگه نه؟زمانی را صرف تحقیق درباره اینکه رقبای شما چه کسانی هستند و چگونه می‌توانید آن‌ها را شکست دهید صرف کنید. آن‌هایی را که می‌توانید سریعا با آن‌ها رقابت کنید مشخص کنید و آن‌هایی که باید برای یک مبارزه آینده کنار بگذارید.توصیه: در اینجا یک ابزار تجزیه و تحلیل بازار مقرون به صرفه است، من دوست دارم از آن استفاده کنم.10.زمان بهینه سازی برنامه شماستاین چیزی است که اکثر ما عموما انجام نمی‌دهیم، اما شما باید و باید…تفاوت زیادی بین نوشتن کد و نوشتن کد بهینه شده وجود دارد. کدی را وارد کنید که به سرعت اجرا می شود، memory کمتر و حافظه دستگاه کمتری را مصرف می کند.یک برنامه غیر بهینه در شرایط عادی خوب کار میکند، اما هنگامی که در موقعیت های مختلف استرس زا می شود، می‌تواند رنگ‌های واقعی خود را به شما نشان دهد.مقدار حافظه مورد استفاده، توسط برنامه خود را بررسی کنید و به نشت حافظه (memory leaks) توجه کنید. به یاد داشته باشید، یک نشت کوچک می تواند یک کشتی بزرگ را غرق کند. زمانی را صرف درک نحوه کار زباله روب در جاوا کنید، محل انباشت زباله (heap dumps) ایجاد و اشیا (objects) زنده خود را آنالیز کنید.توصیه: از Leak Canary برای کشف نشت حافظه خود استفاده کنید، این کار می‌تواند زمان زیادی را با خودکار کردن این امر برای شما حفظ کند.11.ذخیره بیش از ۵ ساعت در هر هفته با ساختارهای Gradle:خیلی محتمل است که شما برای توسعه اندروید از اندروید استادیو استفاده می کنید و از Gradle برای ساخت سیستم تان استفاده میکنید. Gradle عالی است، اما کند است و زمانی که اندازه پروژه شما شروع به رشد می کند، از یک حلزون کندتر می شود.من به یاد دارم که ساعت های بیشماری را نشستن و منتظر ماندن برای پایان عملیات ساختاری Gradle هدر داده ام. در یک روز کاری سخت، من به راحتی حدود یک ساعت فقط در مورد Gradle هدر می دادم و مثل اینکه 5 ساعت در هفته توی گل لای گیر بیوفتی.اما، اینجا راه هایی برای افزایش سرعت آن است.شما میتوانید این و این پست را دنبال کنید و بطور قابل ملاحظه ای سرعت خود را افزایش دهید. پس از بهینه سازی مناسب زمان build من از 4 دقیقه تا کمتر از 30 ثانیه کاهش یافت.12.تست کنید، تست کنید و زمانی که شما پروژه را به اتمام رساندید، دوباره تست کنید!هیچ چیز مهمتر از تست نیست. این چیزی است که باید در بالای لیست شما باشد.تا جایی که ممکن است اپ خود را کامل تست کنید. وقت خود را برای نوشتن تست های خودکار صرف کنید. شرایط مختلف استرس زا برای برنامه خود ایجاد کنید و ببینید آیا می تواند زنده بماند.من یکبار از روی عجله ریلیز اشتباهی از برنامه خودم را منتشر کردم و زمان مناسبی را برای تست آن صرف نکردم. منتظر بودم که کاربرانم با اشکالات مواجه شوند، آن را گزارش کنند و سپس آنها را برطرف کنم.هرگز، هرگز، هرگز چنین کاری نکنید. شما ممکن است یک روز یا دو یا یک هفته را با کاهش زمان از تست، صرفه جویی کنید، اما احتمالا باید بیش از دو برابر بعدا برای آن صرف کنید. هیچ کار عجولانه ای انجام ندهید، وقت خود را صرف کنید و به مدت طولانی فکر کنید. یک چشم اندازداشته باشید. اکنون سیر کنید، بعدا بپزید.13.اندروید Fragmentation یک شیطان در لباسی دیگر استعمل Fragmentation یکی از بزرگترین مشکلات در اندروید است و بنظر میرسد گوگل برای درست کردن آن بی میل است، اما شما باید با آن زندگی کنید.انواع مختلفی از دستگاه های اندرویدی با اندازه های مختلف صفحه نمایش وجود دارد و مشخصات سخت افزاری از طیف وسیعی از دستگاه های تولید کننده که سیستم عامل را در محتوای قلب خود سفارشی می کنند.اضافه شدن ورژن های مختلف اندروید گوگل قابلیت های API ها را اضافه یا حذف کرده باعث افزایش حجم کاری میشود (به مثال).برای مثال، یک توسعه دهنده اندروید کار خود را بدون استفاده از SharedPreferences API تمام نمی کند. این خیلی رایج است، هنوز در Samsung Galaxy S نسخه 2.2 اندروید مشکل دار است (گزارش اشکال).زمان بیشتری برای ایجاد layout های مختلف برای اندازه های مختلف صفحه نمایش صرف کنید. بر روی دستگاه های مختلف تست کنید، داشتن نسخه های مختلف، مشخصات مختلف و از سازندگان مختلف OEM. هرگز فکر نکنید که چیزی آن طور که بنظر میرسد، دارد کار میکند.14. شروع Git، امروز!اگر هنوز از Git استفاده نمی کنید، پیش بروید و از آن استفاده کنید.زمانی که من به توسعه اندروید شروع کردم، من به اندازه کافی بدبخت بودم که بفهمم Git چی بود. من قبلا هر پروژه خودم را کپی میکردم و یک نسخه پشتیبان در هارد درایو و یا در ابر ذخیره میکردم. به نظر احمقانه میاد؟بله، کاملا احمقانه بود.Git می تواند به طور چشمگیری گردش کار شما را بهبود بخشد. اگر کسی از من بخواهد یک ابزار را که من هر روز استفاده می کنم نام ببرم که نمی توانم متوقفش کنم!! هر زمان Git و Git است.و احتمالا پس از استفاده از آن برای چند روز شما عاشق آن می شوید و می خواهید بدانید چگونه Git در داخل کار می کند، بنابراین اینجا برای شما آماده است.و بعد از مدتی شما شروع به یک پروژه بزرگ خواهید کرد و در مورد چگونگی حفظ یک مدل مناسب شاخه ای سردرگم می شوید، پس بفرمایید. جایزه: اگر شما تازه شروع کرده اید و نمی توانید مبلغ اشتراک ماهانه برای نگهداری ریپازیتوری خصوصی در GitHub پرداخت کنید، می توانید BitBucket را امتحان کنید که به شما این امکان را بصورت رایگان می دهد.15.برای هکرها مشکل‌سازی کنیدطبیعت منبع باز بودن اندروید چیزی است که آن را در مقابل حملات آسیب پذیر میکند. هر اپ اندرویدی به راحتی میتواند decompile، مهندسی معکوس ، ripped open، تجزیه و تحلیل و دستکاری شود.شما نمی‌خواهید که این اتفاق برای برنامه شما بیفتد، درست است؟شما باید بدانید چگونه کلیدهای API را بصورت محلی در برنامه خود ذخیره کنید. اگر با اطلاعات حساس کاربران برخورد می کنید، پس شما باید بدانید که چگونه آنها را رمزگذاری کنید، چه الگوریتمی را انتخاب کنید(ایمن و در عین حال سریع).شما همچنین باید کلیدهای رمزگذاری را به صورت امن در سرور یا بصورت لوکال (در صورت نیاز) ذخیره کنید. شما باید مانع از پشتیبانی از داده‌های اپ از طرف (ADB (Android Debug Bridge شوید. اگر داده‌های حساس را در پایگاه‌داده ذخیره می‌کنید، آن را در نظر بگیرید.اگر برنامه شما یک نسخه premium دارد که crack شده و رایگان منتشر میشود. در تجارت ضرر بزرگی به دست می آورید، درسته؟چندین چیز که می توانید انجام دهید برای جلوگیری از آسیب رساندن به برنامه شما وجود دارد. هیچ چیز مانند امنیت 100٪ وجود ندارد. هر هکر ماهر و متعهد با منابع، ابزار و صبر مناسب می تواند برنامه شما را کرک کند.تمام چیزی که شما میخواهید انجام دهید این است که برای هکر عملیات کرک را سخت و سخت تر کنید.نکته: خواندن این و این باید شروع خوبی برای امنیت برنامه شما باشد.16.در یک دستگاه سطح پایین توسعه دهیدهرکسی دوست دارد که از گوشی سطح بالا اندرویدی استفاده کند، منم همینطور. اما به یاد داشته باشید که آن را فقط برای استفاده شخصی خود نگه دارید و هرگز از آن برای اهداف توسعه استفاده نکنید.یک دستگاه سطح بالا، هنگام طراحی برنامه شما، بسیاری از معایب را پنهان می کند. فرض کنید شما دارید کاری را در موضوع UI انجام می‌دهید که راه خود را برای یک UI بی ارزش هموار می سازید، اما در یک وسیله سطح بالا، ممکن است هرگز به آن توجه نکنید.یک دستگاه قدیمی و با کیفیت پایین که با تعداد زیادی از برنامه‌ها رها شده، آن را برای یک دستگاه توسعه، ایده‌آل می‌سازد.17.سرمایه گذاری در یادگیری الگوهای طراحیاین سرمایه گذاری است که همیشه برای شما پرداخت خواهد کرد.در حال توسعه برنامه های بزرگ و پیچیده، شما با برخی از مشکلات رایج روبرو خواهید شد که احتمالا قبلا توسط کسی که صلاحیت بیشتری نسبت به شما دارد، روبرو شده است، این زمانی است که الگوهای طراحی به بازی می آیند.شروع به صرف زمان زیادی از امروز برای یادگیری الگوهای طراحی جاوا. در اینجا یک پروژه Github است که تمام الگوهای طراحی شناخته شده برای بشر را نشان می دهد.برای شروع، مهم‌ترین آن‌ها را یاد بگیرید مثل:Singleton, Adapter, Factory Method, Iterator, Dependency Injection, Event Driven Architecture, Builder, Callback, Strategy, Facade and Producer Consumer به نظر خیلی میاد؟ در واقع نیست، هنگامی که داخل این موضوعات شیرجه می روید، آنها را دوست خواهید داشت.توصیه: کتاب هایی برای مطالعه مثل GoF’s Design Patterns و Refactoring by Martin Fowler و Effective Java by Joshua Bloch و Design Pattern with Kotlin by Alexey Soshin18.وقت آن است که به عقب بر گردیمهمه ما از افراد اطراف مان و از اینترنت بسیار کمک گرفته ایم.بگذارید اعتراف کنم.هر زمان که مشکلی دارید، اولین چیزی که شما می توانید انجام دهید این است که گوگل آن را پیدا کرده و اولین لینک را از StackOverflow پیدا کنید. گاهی اوقات شما عجله دارید و شما در نهایت راه حل را از پاسخ با بالاترین رأی Copy و Paste خواهید کرد.تاکنون تعداد کتابخانه هایی که از Github به صورت رایگان استفاده می کنید فکر کرده اید و چگونه آنها زمان و تلاش شما را برای توسعه کم کردند. به این دلیل که کسی جایی زمان را برای ساختن آن به کار گرفته است و به بهبود جامعه کمک می کند.آن روز را به یاد دارید، زمانی که در درک یک مفهوم دشوار یا چیزی که کاملا برای شما تازه است، مانده بودید، و در نهایت یک پست وبلاگ عالی پیدا کردید، که آن را فوق العاده برای شما آسان کرد. این به این دلیل است که کسی از زمان یک فیلم خود زد و این مقاله را نوشت. وقتش است که برگردی. هر چی بیشتر بدست بیاری بازم بیشتر میتونی برگردی.ما همه در کار خود مشغول هستیم و برای اینکه چیز دیگری را برای دیگران انجام دهید، مدیریت زمان بسیار دشوار است. اما برای کمک و ایجاد جامعه باشکوه تر اندرویدی سعی کنید زمانی را در هر هفته اختصاص دهید.من سعی کردم تا برخی از درسهایی را که در این سفر کوتاه با توسعه اندروید آموخته ام به اشتراک بگذارم. سفر من را ادامه دهید، بیشتر یاد بگیرید و حتی بیشتر به اشتراک بگذارید. امیدوارم به کسی کمک کرده باشم و زندگی را کمی ساده تر کرده باشم.اگر شما این مقاله را دوست دارید، نظر بدهید، لایک کنید و با دوستانتان به اشتراک بگذارید. حسین حسن نژاد حسین حسن نژاد Fri, 30 Nov 2018 12:17:10 +0330 https://virgool.io/devAndroid/%D8%AA%D9%81%D8%A7%D9%88%D8%AA-%D8%A8%DB%8C%D9%86-%D9%86%D8%B3%D8%AE%D9%87-%D9%87%D8%A7%DB%8C-rc-%D9%88-beta-%D9%88-canary-%D8%AF%D8%B1-android-studi-rgwtqe5f4stf آیا تابحال فکر کرده اید که تفاوت بین نسخه های RC و Beta و Canary در Android Studio چیست؟اگر شما از کانال پایدار(stable channel) استفاده میکنید شاید متوجه شده اید که همه آپدیت ها را دریافت نمیکنید.منظورم از کانال پایدار چیست؟ شما فقط نسخه تست و منتشر شده "پایدار" را دریافت خواهید کرد، اما اگر شما در کانال قناری (canary channel) باشید ، شما همه آپدیت ها اعم از تست شده یا تست نشده را دریافت خواهید کرد. بنابراین اگر شما میخواهید جدیدترین امکانات را در اولین زمانی که منتشر میشوند را تست کنید، باید از کانال قناری استفاده کنید. چگونگی تغییر کانال :File > Settings (on Windows/Linux), or Android Studio > Preferences (on Mac)در پنل چپ Appearance & Behavior > System Settings > Updatesو از طریق drop-down میتوانید کانال خود را تغییر بدهید(مطمعن باشید که گزینه چک آپدیت اتوماتیک فعال باشد).اگر شما یک نسخه ناپایدار و نسخه پایدار اندروید استادیو کنار هم و جداگانه میخواهید، میتوانید نسخه قناری را از این لینک دانلود کنید.خب، شما میخواهید امکانات جدید را تست کنید و برخی از باگ ها را گزارش بدهید، اما جز کانال قناری، کانال Dev و بتا هم وجود دارد. کدام کانال مناسب شماست :کانال قناری کانال قناری جدیدترین ریلیزها را دریافت میکند (شامل ریلیزهای پایدار هم هست).بدین معنیست که شما میتوانید جدیدترین امکانات را به محض ساخت آن تست کنید. معمولا آپدیت ها بصورت هفتگی منتشر میشوند و اغلب برای نمایش جدیدترین و بهترین ویژگی های جدید استفاده می شود. شما نباید انتظار یک تجربه بدون باگ را داشته باشید.کانال Devکانال Dev شامل ریلیزهای گلچین شده از ریلیزهای قدیمی کانال قناری که برای مدتی تست شده اند، هست.درست مثل کانال قناری، این کانال برای نشان دادن، در اسرع وقت جدیدترین امکاناتی که محتملا پایدار منتشر خواهد شد، استفاده میشود. هنوز این کانال خیلی ناپایدار است و باید فقط برای تست ویژگی های جدید مورد استفاده قرار گیرد. معمولا ریلیزهای کانال Dev بصورت هفتگی یا ماهانه منتشر میشود.کانال بتااگر شما علاقمند به استفاده از امکانات جدید هستید، با کمترین ریسک، کانال بتا برای شماست. ریلیزهای کانال بتا بطور معمول حاوی تمام امکاناتی هست که یک تیم تصمیم میگیرد که در آن قرار گیرد، اما هنوز انتظار میرود که بعضی باگ ها را داشته باشد و همچنین مشکلات مربوط به عملکرد.کانال پایدارنهایتا، کانال پایدار. این کانال ریلیزهای کاملا تست شده را دریافت میکند و بهترین گزینه بدون مشکل است. در این کانال اندروید استادیو ورژن های جاری را زیاد تغییر نمیدهد. شما باید انتظار عملکرد قابل اطمینان و خوبی را داشته باشید. این احتمالا دلیلی بر استفاده همه از این کانال برای تولید محصول است.خب، من تفاوت بین کانال ها را توضیح دادم و احتمالا نگاهتون به لیست پایینی افتاده، کانال های پایین تر، بیشتر و بیشتر پایدارتر هستند.بنابراین اکنون بر روی ریلیز های مختلف تمرکز می کنیم. به عنوان مثال من برای توضیح از نسخه 3 اندروید استادیو استفاده خواهم کرد. این نسخه از IDE در نسخه های زیر منتشر شد:ریلیز قنارینسخه 3 اندروید استادیو سفر خود را با ریلیز قناری شروع کرد، زیرا همانطور که قبل از ریلیز قناری اشاره کردم ،هدف این است که ویژگی های جدید را به نمایش بگذارند. با اینکه این ریلیزها تست میشدند، باز بسیار ناپایدار بودند. ورژن 3.0 اندروید استادیو 9 ریلیز قناری داشت. هر ریلیز قناری تقریبا همیشه موقعیت رفع برخی از اشکالات را فراهم میکرد یا گاها برخی از امکانات جدید را شامل میشد. مستندات آخرین ریلیز قناری را می توانید در اینجا ببینید.ریلیز بتاریلیز قناری برخی از رفع اشکالات را شامل میشد و قدم بعدی ریلیز بتا میباشد. ریلیز بتا معمولا پایدارتر و قابل استفاده تر است، اما هنوز تجربه بعضی باگ ها کاملا طبیعیست. ورژن 3.0 اندروید استادیو، 7 ریلیز بتا داشت و آن را به آرامی به محصول نهایی تبدیل میکرد. اگر شما علاقمند به آخرین نسخه بتا منتشر شده باشید، شما می توانید به مستندات در اینجا دسترسی پیدا کنید.ریلیز RCریلیز RC نامزدی از آخرین ریلیزی که قرار است منتشر شود است و آن را به عنوان "گام نقره ای" میشناسند. این آخرین مرحله قبل از ریلیز پایدار است .در این مرحله ورژن 3.0 اندروید استادیو برای استفاده در سایت تولید آماده است، اما در صورتی که باگ های بیشتری ظاهر شوند به عنوان یک نسخه پایدار مشخص نمی شود.نسخه 3.0 اندروید استادیو دارای 2 نسخه RC بود و فقط با رفع اشکالات عمومی معرفی میشد. آخرین مستندات RC منتشر شده را در اینجا می توانید پیدا کنید.ریلیز پایدارریلیز پایدار ، همانطور که ممکن است آن را حدس بزنید، به عنوان "گام طلایی" شناخته می شود.این ریلیزی است که بیشتر مردم از آن استفاده می کنند، چون امیدوار هستند اشکالات آزار دهنده ای نداشته باشد و قابل اجرا و قابل اعتماد باشد. لینک مستندات.خب، بلاخره دفعه بعد زمانی که نسخه جدید از اندروید استودیو منتشر شد، شما می دانید فرایند ها به چه صورتی خواهند بود.ممنونم که این پست را مطالعه کردید! اگر موردی در متن بیان نشده یا هر مشکل و اشتباهی متوجه شدید ممنون میشم برام اطلاع بدید. حسین حسن نژاد حسین حسن نژاد Wed, 24 Oct 2018 15:18:18 +0330