سورس خوانی – کیک‌استارتر

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

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

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

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

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

فایل build.gradle:‌

– من همیشه اولین فایلی که از یه پروژه بررسی میکنم build.gradle هست. نکته‌های هیجان انگیزی میشه ازشون یاد گرفت. اولین نکته روشی هست که کیک استارتر توی ساین کردن استفاده کرده تا در زمانی که پروژه توسط CircleCI بیلد میشه به مشکل نخورن. نیاز به توضیح هم نداره، خودشون یه کامنت واضح و شفاف نوشتن.

release {
    minifyEnabled false
    if (isCircle) {
        // The release build generated on CircleCI doesn't need to be signed with our real
        // keystore - we just need a release build to verify that it compiles. Using the
        // debug keystore means we don't have to expose our keystore.
        signingConfig signingConfigs.debug
    } else {
        signingConfig signingConfigs.release
    }
}

release {

minifyEnabled false

if (isCircle) {

// The release build generated on CircleCI doesn't need to be signed with our real

// keystore - we just need a release build to verify that it compiles. Using the

// debug keystore means we don't have to expose our keystore.

signingConfig signingConfigs.debug

} else {

signingConfig signingConfigs.release

}

– یکی از بخش‌های هیجان انگیز فایل build.gradle بخش dependencies هست که میتونید تک تک کتابخونه‌هایی که کیک استارتر استفاده کرده رو ببینید و اگر براتون آشنا نیست در موردش جستجو کنید. با اینکار کلی کتابخونه‌ی کاربردی جدید پیدا میکنید.

– زیرِ بخش dependencies هم دو تا متد کاربردی کوچیک به اسم‌های commitSha و commitTime هست (البته خود برنامه‌نویسا کیک‌استارتر این متد‌ها رو از یه پروژه‌ی متن‌باز دیگه برداشتن و لینک اون پروژه رو گذاشتند). تا اونجایی که من چک کردم برای ریپورت باگ ازش استفاده میکنند تا اگر باگی ریپورت شد بهتر بتونن عیب‌یابی بکنن.

– نمیدونم تا حالا با به خطای hitting GC overhead limit گیر کردید یا نه، قبلا که میخواستم سورس تلگرام رو بیلد کنم خیلی پیش میومد. انگار وقتی کیک‌استارتر هم بیلد میشه این خطا پیش میاد. راه‌حلش این تیکه کد هس:

// Fixes build error hitting GC overhead limit
dexOptions {
    javaMaxHeapSize "3072M"
}

// Fixes build error hitting GC overhead limit

dexOptions {

javaMaxHeapSize "3072M"

}

– آخرین نکته توی این فایل هم مرتبط به flavorهاست. اگر پروژه‌ای multi dex هست میشه با درست کردن یه flavor و تغییر min sdk به ۲۱ سرعت بیلد رو بالا برد. مثل زیر:

min21 {
    // minSdkVersion 21 speeds up local development by generating multidex output much faster.
    // It should not be used for release builds. See:
    // https://developer.android.com/tools/building/multidex.html#dev-build
    dimension "API"
    minSdkVersion 21
}

min21 {

// minSdkVersion 21 speeds up local development by generating multidex output much faster.

// It should not be used for release builds. See:

// https://developer.android.com/tools/building/multidex.html#dev-build

dimension "API"

minSdkVersion 21

}

– راستی خود کامنت نوشتنشون هم جالب هست، داخل کامنت لینک میذارن تا بشه به منبع اصلی اون تیکه کد رجوع کرد. حالا لینک میتونه به داکیومنت اندروید باشه یا شبیه مثال بالا به یه ریپوی متن‌باز دیگه.

فایل styles.xml:

– جدیدا خیلی دوست دارم بیشتر و اصولی تر بتونم از قابلیت style و theme توی اندروید استفاده کنم. برای همین سراغ فایل style.xml میرم. اولین نکته توی فایل style.xml نحوه‌ی بک گراند دادن به اکتیویتی‌هاست. بجای اینکه توی فایل لیوت اکتیویتی اینکارو بکنن از android:windowBackground استفاده کردند. اگر با مفهوم overdraw توی اندروید آشنا باشید مزیت اینکارو متوجه میشید، اگر هم آشنا نیستید، میتونید ویدیو صحبت‌های رضا معلمی توی پنجشنبه بازار رو در آپارات ببینید.

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

ارتباط با وب‌سرویس:

– شاید خنده‌دار باشه ولی همیشه انتخاب اسم مناسب برای کلاس‌های جاوایی که به عنوان body توی درخواست‌های POST استفاده میکنم دغدغه بوده😃. خیلی وقته از این قرارداد استفاده میکنم، برای کلاسی که توی body درخواست استفاده میشه از پیشوندن req استفاده میکنم مثلا reqLogin و کلاس جواب درخواست Login خالی میشه. اما توی کیک استارتر از روش جالب‌تری استفاده میکنند، برای کلاس‌هایی که توی درخواست استفاده میشند از پسوند Body استفاده میکنن که خیلی بیشتر از کار من معنی میده! از این به بعد منم اینکارو میکنم. برنامه‌نویسا کیک‌استارتر برای مرتب‌تر شدن کلاس‌ها از دو پکیج apirequests و apiresponses استفاده کردند، اینجا میتونید ببینید.

– جالبه داخل اینترفیس رتروفیت با اینکه از rxjava استفاده میکنند، به جای اینکه متدهارو اینجوری تعریف کنند:

@GET("/v1/users/self")
Observable<User> currentUser();

1 2	@GET("/v1/users/self") Observable<User> currentUser();

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

@GET("/v1/users/self")
Observable<Response<User>> currentUser();

1 2	@GET("/v1/users/self") Observable<Response<User>> currentUser();

مزیتش اینه میتونند از متد‌های Response<> استفاده کنند مثلا با استفاده از متد isSuccessful بفهمن درخواست واقعا موفق بوده یا نه.

– زمانی که با وب‌سرویس کار میکنید، گاهی پیش میاد وب‌سرویس حتی وقتی خطایی رخ میده ( مثلا ولیدیشن اطلاعاتی که برای ثبت به وب‌سرویس ارسال شده مشکل داره)‌ در جواب به کلاینت یک json بفرسته. برای پارس کردن این json توی rxjava روش‌های متفاوتی وجود داره. کیک‌استارتر برای اینکار یه operator تعریف کرده و این لینک کلاسش هست. من خودم از یه روش دیگه استفاده میکنم بنظرم ساده‌تر هس ولی بالاخره اینم روشی هس.

نامگذاری پارامتر ورودی متد:

– این نکته با اینکه شاید ساده‌ترین نکته بود که از گیت‌هاب کیک استارتر یاد گرفتم ولی با اختلاف برام باحال‌ترینش بوده😃 نکته‌اش اینه گاهی پیش میاد موقع نامگذاری فقط تایپ پارامتر ورودی براتون مهم هست. اگر از dagger2 استفاده کنید، توی تعریف متد‌های inject داخل کامپوننت‌های دگر این قضیه خیلی پیش میاد. من از این روش برای نامگذاری استفاده میکردم که مثلا اگر متد inject برای اکتیویتی بود از act یا activity استفاده میکردم. اینجوری:

 void inject(MainActivity act);
 void inject(MainActivity activity);

1 2	void inject(MainActivity act); void inject(MainActivity activity);

اما از گیت‌هاب کیک‌استارتر روش جدیدی یاد گرفتم. اونم اینه:

void inject(AppRatingDialog __);
void inject(Koala __);

1 2	void inject(AppRatingDialog __); void inject(Koala __);

بنظرم کد خیلی باحال‌تر و خوانا‌تر میشه. اگر کسی کد رو ببینه متوجه میشه توی پارامتر‌های ورودی این متد، خود پارامتر خیلی اهمیت نداره و تایپش اهمیت داره.

recyclerview و pagination:

– داخل پکیج libs پروژه کلی کلاس باحال هست که میشه دونه دونه بررسی کرد. یدونه از این کلاس‌ها اسمش RecyclerViewPaginator هس. کاربردش هندل کردن pagination توی recyclerview با rxjava هست!! اگر rxjava بلد نباشید خیلی عجیب به نظر میاد، ولی بصورت کلی مثال جالبی از کاربرد‌های rxjava توی اندروید هست. بهترین راه یادگیری rxjava دیدن مثال‌های مختلف و کاربردی از rxjava هست

فایل dimens.xml:

– توی فایل dimens از یه سری آیتم به اسم grid تعریف کردند که ۶dp 6dp اضافه میشند. اینجوری:

  <!-- Kickstarter six-point grid keylines-->
  <dimen name="grid_1_half">3dp</dimen>
  <dimen name="grid_1">6dp</dimen>
  <dimen name="grid_3_half">9dp</dimen>
  <dimen name="grid_2">12dp</dimen>
  <dimen name="grid_5_half">15dp</dimen>
  <dimen name="grid_3">18dp</dimen>
  <dimen name="grid_7_half">21dp</dimen>
  <dimen name="grid_4">24dp</dimen>
  <dimen name="grid_9_half">27dp</dimen>
  <dimen name="grid_5">30dp</dimen>
  <dimen name="grid_11_half">33dp</dimen>
  <dimen name="grid_6">36dp</dimen>

برام جالب شد این قضیه six-point grid keylines چیه! توی اینترنت گشتم ولی به جای مقاله مرتبط با six-point grid keylines به این مقاله Intro to The 8-Point Grid System هست. داکیومنت متریال گوگل هم از ۸-Point Grid System استفاده میکنه. حالا نفهمیدم دیگه مزیت six-point چی هس که کیک استارتر دنبالش رفته! خیلی توی حوزه‌ی طراحی مطالعه نمیکنم، اگر کسی فهمید به منم بگه 😃

پایان بررسی اپلیکیشن اول!!!!!

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