Android developing in a wrong way
•Download as PPTX, PDF•
1 like•131 views
This document provides an overview of key topics for Android development including Gradle, libraries, networking, image loading, ORM, testing, Git, and continuous integration (CI). It discusses Gradle build files and configurations, popular Android libraries for networking, images, and databases. It also covers unit testing tools and strategies in Android including JUnit, Espresso, and Monkey. Finally, it summarizes Git, CI workflows, and additional CI tools.
Recommended
Recommended
More Related Content
What's hot
What's hot (13)
Similar to Android developing in a wrong way
Similar to Android developing in a wrong way (20)
Recently uploaded
Recently uploaded (20)
Android developing in a wrong way
- 1. Android Developing In a Wrong Way!
- 4. Gradle Build Automation System Groovy / Java / Scala Concepts of Released on 2007 / 2013 0n AndroidStudio
- 7. build.gradle Top Level Build File Module Level Build File
- 8. Top Level Build File
- 9. Module Level Build File
- 11. Android Configs
- 12. Dependencies
- 13. Libraries
- 17. Glide vs. Picasso From Internet From Cache
- 18. O/R Mapping (Database) ActiveAndroid Sugar ORM https://github.com/satyan/sugar https://github.com/pardom/ActiveAndroid
- 19. Professional Libs RxJava / RxAndroid EventBus Retrolambda https://github.com/greenrobot/EventBus RxJava: https://github.com/ReactiveX/RxJava RxAndroid: https://github.com/ReactiveX/RxAndroid https://github.com/orfjackal/retrolambda Socket.IO-client Java https://github.com/socketio/socket.io-client-java
- 22. Working Directory staging Area Local Repository Remote Repository offline online add Commit Checkout Merge push pull Git Structure
- 25. Why Unit testing Reduce bugs Good documentation Improve code quality Reduce cost to change
- 26. Unit Testing Isn’t Free Time to develop the skills Cost of training Setup Time Time To write and debug tests
- 27. Fast dive in Android Unit testing Instrumented Test Local Test
- 28. How Test Work
- 29. Android Unit Test Tools JUnit Android JUnit Runner Espresso UI Automator
- 30. Additional Android Testing Tools Monkey ➜ platform-tools ./adb shell monkey -v -v --throttle 10 -- pct-touch 20 --pct-anyevent 80 -p app.me.mycitestproject --ignore-security-exceptions 2000
- 31. Additional Android Testing Tools Monkey Runner Robolectric Robotium Appium Testdroid
- 33. Push C.I Progress Test & Build Result C.I Structure
- 34. Test & Build in progress Result of C.I Notify the result (to slack)
- 35. Other C.I Tools
- 36. Review Gradle What is Gradle? settings.build grade.build top level & module Android Configs Dependencies
- 37. Review Libraries Networking: Volley, Retrofit, OkHttp ImageLoader: Glide, Picasso ORM: Active Android, Sugar ORM Professionals: RxJava&Android, Eventbus, RetroLmabda, Socket
- 38. Review Git What is git? Git benefits Git structures
- 39. Review Android Unit Testing Why Unit testing? The Cost of Unit Testing Fast Dive Unit Testing How It is work Android Unit Tools Monkey Additional Android Testing Tools
- 40. Review Continues Integration (C.I) What is C.I? C.I Structure C.I Delivery System Other C.I tools
- 41. How to be a Geek?
- 42. Q & A
Editor's Notes
- چه برنامه ای داشتم واسه اینکه بیام اینجام بهترین تایتلی که تونستم مناسب این ارائه پیدا کنم، این بود که چطوری یه توسعه دهنده خفن بشیم
- من چیکار میکنم؟ چی بلدم؟ چی دوس دارم؟ ( این زبانهارو بلم، فلت این لاو روبی هستم. ) کجای میتونید منو پیدا کنید؟ سایتو توییترو تلگرامو فلان
- کی میشناسه این فیل کیه؟ بله گریدل که همتون باهاش کار کردیم احتمالا
- گردل چیست؟ یه نگاه گذرا به خود گردل بندازیم گردل یه بیلد آتوماشین سیستمه، سوال؟ این چیه؟ ( یک ابزاریه که فرآیند تست، بیلد، پکیجینگ، پراجکت دیپندنسی و دلیوری رو اتوماتیک میکنه) گردل از این زبانها درست شده. groovy چیه؟ گرووی یه Domain-Specific Language هست. اما DSL چیه؟ زبان خاص دامنه یا دیاِساِل (به انگلیسی: DSL) به زبان برنامهنویسیای گفته میشود که ارتباط تنگاتنگی با مسائل یک دامنهٔ بخصوص داشته باشد. این مفهوم در برابر زبانهای برنامهنویسی همهمنظوره مطرح میشود. زبانهای خاص دامنه ممکن است گرافیکی یا متنی باشند و به گونهای طراحی شدهاند که بتوانند، نسبت به زبانهای برنامهنویسی همهمنظوره، دستهای بخصوص از مسائل را سادهتر حل کنند. غالب این زبانها سطح بالا هستند و باید پیش از کاربردی شدن به یک شکل دیگر تبدیل شوند، برای نمونه یک مدل را تبدیل به کد و کد را تبدیل به یک پروندهٔ اجراپذیر کنند. گردل با جمع آوری نقاط قوت و افزودن ویژگی های قدرتمندتری وارد میدان شد. در فلان سال هم تولید شد
- اما بگذارید یه نگاهی بندازیم به گردل و اینکه چه چیزهایی داره این یه نمای کلی از گردل هست. احتمالا همتون این صفحه رو هرروز تو کد نویسیتون مشاهده کردین. گریدل یک ماهیت توصیفی دارد که شما تنها لازم است اعمالی را برای آن توصیف کنید تا بقیه کارها را انجام دهد. گریدل در پشت صحنه از یک "گراف جهت دار بدون دور" Directed Acycllic Graph یا به اختصار DAG استفاده میکند و طبق آن ترتیب وظایف یا taskها را دانسته و آنها را اجرا میکند. گریدل با این DAG، سه فاز آماده سازی، پیکربندی و اجرا را انجام میدهد. Build Scripts که فایلهای مربوط به گردل رو در اینجا مشاهده میکنید Test files فایلهای مربوط به تست Build Gradle تسک ها و روندهارو تعیین میکنیم
- در مرحله آماده سازی ما به گریدل میگوییم چه پروژه یا پروژههایی نیاز به بیلد شدن دارند. در اندروید استادیو، این مرحله در فایل settings.gradle انجام میشود؛ شما در این فایل مشخص میکنید چه پروژههای نیاز به بیلد شدن توسط گریدل دارند. در این فایل سه پروژه برای گریدل مشخص شدهاند. البته از نگاه Intellij سه ماژول معرفی شدهاند و این فایل برای یک پروژه اختیاری است. گریدل برای پیدا کردن این فایل، از الگوریتمهای متفاوتی استفاده میکند. در اولین مرحله انتظار دارد که فایل settings در دایرکتوری جاری باشد و اگر آن را پیدا کرد آن را مورد استفاده قرار میدهد؛ در غیر اینصورت مرحله بعدی را آغاز میکند. در مرحله دوم، در این دایرکتوری به دنبال دایرکتوری به نام master میگردد و اگر در آن هم یافت نکرد مرحله سوم را آغاز میکند. در مرحله سوم، جست و جو در دایرکتوری والد انجام میشود چنانچه این فایل را در هیچ یک از احتمالات بالا نیابد، همین پروژه جاری را تشخیص خواهد داد.
- هر پروژه آندروید استودیو حداقل دارای دو فایل build.gradle هست: ۱- Top Level Build File تنظیمات اصلی که مربوط به کل پروژه است در این فایل قرار میگیرد. ما نیازی به تغییر و دستکاری این فایل نداریم. ۲- Module Level Build File هر ماژول، دارای یک build.gradle جداگانه است که تنظیمات مربوط به ماژول مخصوص خودش داخل آن قرار میگیرد. میتوان گفت در اینجا ماژول به معنای پروژههای زیرمجموعه پروژه اصلیست. ما در طول مدت برنامهنویسی در اندروید استودیو همیشه با این فایل سر و کار داریم.
- محتویات این فایل همیشه ثابت هست و به هیچ عنوان نیازی به تغییر دادن داخل این فایل نیست. تنها نکته قابل ذکر اینه که خط ۸ معرفی کننده نسخه پلاگ-این گریدل آندرویداستودیو به پروژه است. در پروژه ای برای استفاده از یه سری سرویس ها خاص گوگل من اینجا به ClassPath از Google Service معرفی کرده بودم
- هر ماژول، دارای یک build.gradle جداگانه است که تنظیمات مربوط به ماژول مخصوص خودش داخل آن قرار میگیرد. میتوان گفت در اینجا ماژول به معنای پروژههای زیرمجموعه پروژه اصلیست. ما در طول مدت برنامهنویسی در اندروید استودیو همیشه با این فایل سر و کار داریم.
- defaultConfig از اسمش که پیداست، میایم تنظیمات دیفلات رو وارد میکنیم. مواردی مثل مینمیم وتارگت SDK و بعد ورژن نیم و ورژن کد رو. بزارید یه توضیح راجع به نحوه این بدم که چجوری نامگذاری میشه. در ادامه هم تنظیمات دیگری مثل MultiDex و ساپرت کردن VectorDesignAssets رو هم اینجا ذکر کردم. درواقع پیشنیاز ها و یکسری مواردی که نیاز هست در پروژه لحاظ بشه اینجا آورده میشه productFlavors ممکنه شما احتیاج باشه که مالتی پکیج کار کنید، و برای یه اپ چندتا پکیج خروجی بگیرین. برای مثال ما تو پروژه خودمون ۲تا سرویس پکیچ داشتیم که یکی رو استیج و تست بود و دیگری Real و روی هسته اصلی کار میکرد. buildTypes هم شما میاید میگید که این بیلدی که میخواید داشته باشید لازمه چه خصوصیاتی داشته باشه؟ مثلا ما Minify رو براش true میزاریم. بعد هم پروگارد رو بهش معرفی میکنیم. درواقع تظیمات بیلد فایل رو ما توی پروگارد انجام میدیم، مواردی مثل هش کردن کدها یا ایگنور کردن بعضی از فایلها. (توضیح بده راجع به مشکل minify کردن برای بعضی از Library ها)
- Dependencies یا همون وابستگی های پروژمون درواقع اونچیزاییه که ما بهش نیاز دارم و پروژمون بهش وابستس. بقول معروف آقااااا، لازم نیست چرخ رو از اول اختراع کنیم که. میتونیم از ابزارهایی که دوستانمون در اختیار ما قرار دادن استفاده کنیم. اگه قرار باشه همه چیز رو خودمون از صفر تولید کنیم پروژه ۳ ماهه ممکنه ۳ سال طول بکشه با کلی نقض و باگ ( و ماجرای کلا اوپن سورس بودن و فوایدش رو توضیح بده )
- Volley از این لایبرری برای ارتباط برقرار کردن از REST API استفاده میکنم. کار کردن باهاش راحته. به راحتی میتونید مدیریتش کنید. توجه کنید که این لایبرری روی گیتهاب Depricate شده و اومده جزو لایبرری های رسمی خود اندروید و اونجا پرزنت میشه. Retrofit این روزها میگن همه از رتروفیت استفاده میکنن. حتما این ابزار رو تست کنین. امکانات جالبی داره OkHttp هم بسیار لایبرری خوبیه چیزی از دوتای بالا از لحاظ کارایی و سرعت کم نداره، اما خوب چیزی که من بیشتر شنیدم اینه که تو پروژه های JAVA پیشنهاد میشه که از OkHttp استفاده کنند.
- مدل کش کردن: پیکاسو فایل رو کلا با سایز اصلیش دانلود میکنه، مثلا من یه عکس ۱۱۶۰ در ۷۵۰ داشتم، اون رو کامل تو کش ذخیره میکرد. و بعد هرجا که میخواستم استفاده کنم میرفت تو کش دیسک و عکس رو میگرفت، ریسازش میکرد و بعد دیکد میکرد میزاشتش تو ایمیج ویوو. اما جیلاید روشش فرق داره، جیلاید عکس رو دانلود میکنه، و همونجا اول ریسازش میکنه به اندازه ایمیج ویووتون بعد اون رو کش میکنه، سری بعد که بهش احتیاج داشتین همون ریسایز شدشو میده بهتون. دو تا آپشنی که جیلاید داره اما پیکاسو نداره: Animated Gif در جیلاید ساپورت میشه. و فقط کافیه شما به همون صورتی که عکس رو لود میکنید این رو هم لود کنید. و جالب اینجاست که لایف سایکل هم داره. Thumbnail هم هست. اگه مثلا یه عکس خیلی بزرگ دارید میتونید به جیلاید بگید یه Thumbnail ازش بهتون نشون بده و بعد تو دستور بعدی مثلا بعد کلیک، عکس با سایز اصلیشو نشون بده بهتون.
- عکس ها در دیکد فرمت ARGB_8888 لود شدند
- ORM (object relational mapper) برای استفاده کردن از این لایبرری ها احتیاج نیست برید دیتابیس بسازید هزارتا متد واسش پیاده کنید، مصرف رمتون بره بالا کرش کنید وسطاش و هزارتا دردسر دیگه با استفاده از قابلیت ها OOP شما با تعریف کردن چندتا کلاس و متد ساده میتونید یه دیتابیس خفن بسازید و کلی پرفرمنس کارتون رو ببرید بالا. (الالخصوص Sugar ORM تو پرفرمنس خیلی قوی و سبکه )
- RxJava بهتون کمک میکنه تا بتونید متد های Async بنویسید و درواقع متد هایی که شمارو در بک گراند پراسسینگ کم میکنه. EventBus اگه روزی قرار شد سوکت پروگرمینگ بکنید، این لایبرری به شدت میتونه به کارتون بیاد، و مسیج هایی که از طرف سوکت واستون ارسال میشه به متد های که توسط RxJava نوشته شده و در EventBus رجیستر شده برسونه و حالا اون عملیات مورد نظرتون رو انجام بدید RetroLambada بسیار بسیار بسیار لایبرری خوبیه در رابطه با قابلیت های Java8 . و شما میونید با استفاده از این لایبرری بسیاری از خصوصیات Java8 رو تو پروژتون پیاده کنید. یادم میاد تو یه بخشی ما میخواستیم یه لیستی از پروداکتامون رو مپ کنیم، که درحالت معمولی جیزی نزدیک به 20 25 خط نشوته بودیم و پرفرمنس به شدت پایین اومده بود، اما با افزودن لامبادا و بکارگیری متدهای جایگزین Java8 این تقریبا تو ۶ ۷ خط خلاصه شد. Socket iO هم یه ابزار بسسسیییاااار خوب و عالی برای سوکت پروگرمینکه و درواقعا اینکه شما اپتون رو حقیقتا لایو کنید مطالب و لایبرری ها زیاده نمیخوام این دپس شم تو اینا و الان درگریتون کنم چون جلوتر چیزای کاربردی خواهیم داشت و وقت هم کمه
- بزارید ماجرای گیت رو اینجوری شروع کنم. حتما براتون پیش اومده اون خیلی خیلی خیلی خیلی قبلها که با اینچیزها آشنا نبودین، اون موقع ها که هنوز با دایناسورا زندگی میکردیم صبحونه تخم دایناسور نیمرو میکردیم :)))) که یه پروژه رو که میخواستیم تقییرات بدیم یه کپی ازش میگرفتیم میزاشتیم تو یه پوشه به اسم بک آپ ۱، بعد میرفتیم جلوتر خلاصه همه چی اوکی بود یهو میومدن میگتن ممد، فلان چیزو به پروژه اضافه کن، بعد دوباره شما یه بک آپ ۲ درست میکردین میریختین اونتو و ادامه میدادین به توسعه. تازه این آخرش نبود. توسعه انجام میشد نسخه بیلد شده رو میدادین به مدیر پروژه بعد مدیر پروژه میگفت ا، ممد این چرا دایناسورش دو چشمه؟ من مثل اونی که تو کارخونه هیولاست میخوام ۶۰تا چش داشته باشه! شما میرفتین میزدن کد رو ، بعد بیلد میکردین که اسمشو میزاشتین دایناسور ۲. دایناسور ۳ داایناسور فینال، دایناسور دیگه فینال، دایناسور این دیگه خداییش آخریشه. تو بمیری این دیگه فلان. من فلانم اگه این آخری نباشه.
- گیت اومده که مارو نجات بده. اما چطوری؟ تازه همه چی وقتی بدتر میشد که دیوایس شما میسوخت یا سیستم عاملتون میپرید و مجبور بدید یه گلی به سر خودتون بگیری و پروژه! فرت!
- حتما همتون یه روزی به این مورد برخودین که ا، چرا این داره کار میکنه؟؟؟ قائدتا نباید کار میکرد ؟؟؟ :)))) و شاید برعکس، باید کار میکردو اما نمیکنه :(((((( یا حتا به این مشکل برخوردین که اپ رو دادین بیرون دست کاربر. و کاربر میگه که این کار نمیکنه! اما شما میگی نهه!!! من الان تست گرفتم رو دستگاه من که کار میکنه!!! اینا همشون نشون دهنده اینه که ما قبل از توسعه باید کدهامون رو تست کنیم، برنامه رو تست کنیم و از چیزی که مطمئن هستیم بدیمش به کاربر
- Reduce bugs اولین و مهمترین دلیل، یونیت تست حقیقتا بهتون کمک میکنه که باگ ها برنامه و متدهاتون رو تا جایی که میتونید بیارید پایین، یعنی از لحاظ برنامه نویسی شما دقیقا میزان باگتون باید صفر باشه! مگر اینکه مشکل بیزنس لاجیک داشته باشید یا اینکه از جاهایی باگ برنامه آب بخوره که براش تست ننوشتین. Good documentation یکی از مهمترین بدبختی ما برنامه نویسا همین داکیومنت نویسیه، وقتی که مدیر پروژه میگه صدرا، داکیومنت کن فلانچیزو، صدرا غمش میگیره شدیییید! :) اما شما وقتی تست نویسی میکنید درواقع دارید شرح میدید که این متد اصن برای چی استفاده میشه، چه پارامتر های ورودی داره و چه چیزهایی خارج میکنه. پس شما یه بار کد میزنین هم برنامتون رو تست کردین هم داکیومنتتون رو آماده. Improve code quality حقیقا تست نویسی باعث بالا رفتن کیفیت کدهاتون میشه، به ۲ دلیل، ۱- شما مجبورید متدهاتون رو استاندارد بنویسید که اصن بدرد کد نویسی بخوره و بتونید ازش نتیجه بگیرید، در نتیجه کدهای تمیزی خواهید داشت و ۲- اینکه وقتی کدهاتون تست بشه اونوقت یه سری متد دارین که تمیز و استاندارد نوشته شده و هیچ باگی نداره همین یعنی کیفیت کارتون میره بالا. بقول مارتین فالور، کدها بود دارن، کدهای که تمیزا اصولا خوش بوان و شما حقیقا میتونید کدهاتون رو بو بکشید، پس سعی کنید کداتون رو طوری بنویسید که بوی کوکوی سه شب مانده نده :))))) Reduce cost to change کد نویسی هزینه تغییر کد رو میاره پایین. یادون باشه گفتم تست که مینویسید یعنی کدهاتون رو داکیومنت میکنید و این داکیومنت کردن کمکتون میکنه بعدا بدونید چه متدی چیکار میکرد و چی میخواستون میداد. وقتی یکی میخواد ریفکتور کنه میاد تستتون رو نگاه میکنه ببینه که چیکار باید بکنه. جدا از اون وقتی شما یا هر فردی متدی اضافه میکنه یا تغییر میده تستها باید هشمون پاس بشن، اونوقته که دیگه نمیتونه متد های نوشته بشن که باگ دارن و برنامه رو از کار بندازن. در نتیجه تست نویسه هزینه برنامنه نویسی و دردسرهای بعدیش تا نهایت ممکن میاره پایین. و حالا این قضیه توی اندروید و کلا توسعه اپلیکیشن های موبایلی بیش از پیش خودش رو نشون میده. میدونید نزدیک به ۱۰۰هزار نوع دیوایس اندروید داریم که در اندازه صفحه نمایش، نوع و قدرت CPU ها، تفاوت سیستم های گرافیکی، و ورژن سیستم عاملشون زمین تا آسمون تفاوت دارن و شما باید برنامه ای بنویسید که روی همه اینها کار کنه! اینجاست که یونیت تست میاد و حقانیتشو ثابت میکنه! اییینهمه نشانه. ایمان نمیآورید؟ :))))))
- مثل کد نویسی، تست نویسی هم احتیاج به مهارت داره. اینکه شما بلد باشید چطوری یه تست بنویسید، چطوری اونو استاندارد کنید، چطوری در حین نوشتن تست واسش کامنت بنویسید، از چه نوع تستی چه موقع استفاده کنید و ازینجور چیزها. همه اینها وقت میخواد تا شما یاد بگیرید و خوب وقت گذاشتن برای این قضیه اینکه تیمتون رو به این مهارت مسلح کنید نیاز به وقت و هزینه کردن داره،که ابزارهارو آماده کنید اگه نیازه تیم رو به کلاس بفرستید و غیره اینکه بتونید تایم پروژه رو هم مدیریت کنید از سختی های دیگه تست نویسیه شما به مدیر پروژه اعلام میکنید که من یک هفته ای این رو تحویل میدم اما خب درفرآیند تست میبینید که ا یه مشکلی هست که تستهارو فیل میکنه و باید وقت بیشتری رو بگذارید و در نهایت وقتی که شما روی نوشتن تست، اعمال روند تست و دیباگ کردن تستها میگذارید از دیگر هزینه هایی هست که شما واسه تست نویسی میدید. بطور معمول تست نویسی سرعت توسعه رو یک و نیم تا ۲ برابر کندتر میکنه. اما در ریفکتور کردن دقیقا قضیه بعکس ضبدر دو میشه. یعنی ۳ تا ۴ برابر سرعت ریفکتور و دیباگتون بالاتر میره.
- شما قتی یه پروژه ایجاد میکنید بصورت پیشفرض دوتا فایل براتون ایجاد میشه که در تصویر هم میبینید. ما در اندروید ۲جور تست نویسی داریم، یکی Instrumneted و این یکی Local تست هست. Instrumneted Test به تست هایی گفته میشه که مبتنی بر UI نوشته میشه. و این تست ها روی امولاتور اجرا میشن، مثلا روی فلان دکمه کلیک بشه و فلان متد اجرا بشه و بعدش فلان ویو بسته بشه یا بره فلا اکتیویتی. بزارین راحتش کنم، اینسترومنتها تستهایین که توش ما از Android API ها استفاده میکنیم، حالا میخواد UI باشه یا میخواد سخت افزار ها او نرم افزارهای مختص به اندروید باشه. Local test اما لوکال تست هایی هستن که مربوط به خود متدهان، متد هایی که بطور Native زبان Java هستن، این تست هایی هستن که به هیچ وجه ربطی به اندروید و API اون ندارن. مثلا اینکه شما یه متدی دارین که میخوا حاصلظب ۲تا عدد رو محاسبه کنه. این تست ها روی JVM اجرا میشن مستقیما و اونجا کامپایل میشن. (java virtual machine)
- شما قتی یه پروژه ایجاد میکنید بصورت پیشفرض دوتا فایل براتون ایجاد میشه که در تصویر هم میبینید. ما در اندروید ۲جور تست نویسی داریم، یکی Instrumneted و این یکی Local تست هست. Instrumneted Test به تست هایی گفته میشه که مبتنی بر UI نوشته میشه. و این تست ها روی امولاتور اجرا میشن، مثلا روی فلان دکمه کلیک بشه و فلان متد اجرا بشه و بعدش فلان ویو بسته بشه یا بره فلا اکتیویتی. بزارین راحتش کنم، اینسترومنتها تستهایین که توش ما از Android API ها استفاده میکنیم، حالا میخواد UI باشه یا میخواد سخت افزار ها او نرم افزارهای مختص به اندروید باشه. Local test اما لوکال تست هایی هستن که مربوط به خود متدهان، متد هایی که بطور Native زبان Java هستن، این تست هایی هستن که به هیچ وجه ربطی به اندروید و API اون ندارن. مثلا اینکه شما یه متدی دارین که میخوا حاصلظب ۲تا عدد رو محاسبه کنه. این تست ها روی JVM اجرا میشن مستقیما و اونجا کامپایل میشن. (java virtual machine)
- Junit لایبرری نیتو و رسمی تست نویسی برای جاواست، و در اندروید Junit وظیفه اعمال تست و رولز ها رو بر عهده داره Android JUnit Runner برای اینکه JUNIT کار کنه، Unit Runner بالاتر از همه وظیفه مدیریت و انجام تست و دلویر کردن تنیجه تست رو بر عهده داره. درواقع کاملا از اسمش مشخصه که چیکار میکنه. Espresso کارش محیا کردن محیط برای نوشتن تستهای Instrumneted هست، همون تست های که از Api اندروید بهره میگرفت. UI Automtor و درنهایت این هم کار راه اندازی تست Instrumnted رو بالاتر از همه انجام میده و درواقع کار اصلی رو این انجام میده که میره کلیک میکنه، نمیدونم فلانکارو میکنه اینا
- monkey همونجور که از رو اسمش پیداست یه میمونه که شما گوشیتون رو در اختیار این میزارید و این میاد دیواستون رو میترکونه :))))))) جدا از شوخی، مانکی میاد در سرعت بالا تمامی کارهایی که میشه با یه گوشی انردوید کرد رو انجام میده، رندوم همه جا کلیک میکنه،تاچ میکنه،میکشه، مچرخونه، خاموش روشن یکنه و هزراتا کار دیگه البته شما میتونید مدیریتش کنید که مثلا چه حرکاتی رو انجام بده، یه چه کتگوری حرکتی رو بیشتر انجام بده. و یا چه مدت این تست ادامه داشته باشه. این تست کمک میکنه به شما تا اگر جایی خطایی دارید اون رو پیدا کنید. این سرویس به شما کم میکنه تا پرفورمنس اپتون رو مورد بررسی قرار بدید. و قبل از اینکه اپتون دست یه آدم مریض بیفته، شما از اتفاقات ناگوارش پیشگیری کنید :)
- Monkey Runner بر خلاف اسمش هیچ ربطی به Monkey قبلی نداره، یه ابزار کاملا جداست و تقریبا مثا UI Automator کار میکنه و شما میتونید اتفاقت کاربرانه ای که ممکنه بیافته رو با استفاده از این ابزار انجام بدید. این ابزار با پایتون نوشته شده. Robolectric یکی از معروفترین ابزارهای تست اپلیکیشن اندروید و بسیار هم محبوبه ابزارهای دیگه هم مثل robotium و Appium فرم ورک های دیگه ای برای تست هستن. و یه ابزار جالب دیگه Test Droid هست که به شما این امکان رو میده تا اپتون رو روی دیوایس های مختلفی تست کنید. و دیگه نیاز نباشه شما واسه تست گرفتن ۶۰۰ تا گوشی دم دستتون باشه :D
- Ci چیه و چرا من اصرار دارم که راجع به ci حرف بزنم؟ تو چندتا اسلاید قبلی راجع به گیت و اینکه چرا لازمه از گیت استفاده کنیم حرف زدم. یکی از قوانین و چیزهایی که شمارو ملاک میکنه به عنوان یه شرکت یه مجموعه یه تیم یا نفر اکسپرت و حرفه ای،اینه که کامیتی نزنین که پروژه رو بهم بریزه. یعنی شما کار میکنین توسعه میدید برنامه رو میرسونید به یه جا کامیت کامیت کامیت. حالا که میخواین اون رو پوش کنید نباید پوشی که میفرستین باعث بشه برنامه بهم بریزه و کل پروژه به غااار بره! این کار رو ما توی ci انجام میدیم. یعنی پروژه رو مینویسیم، پوش میکنیم، پروژه میره رو شبیه ساز یا VM بعد اگه تست ها پاس شد، بیلد میشه، و تست پاس شده و اطلاع داده میشه که آقا اوکی.
- Clean Code: Robert C. Martin Refactoring: Martin Fowler Working Effectively with Legacy Code: Micheal C. Feathers Design Patterns: ORelliy Head First Design patterns: ORelliy Java Concurrency In Practice: Brian Goetz & Tim Peierls 97 Things every Programmers Should Know: Orreily, Kelvin Henney The Programatic Programming: Andrew Hunt, David Thomas