RxJava کتابخانه ایست برای برنامه نویسی بصورت Reactive در جاوا. خود Reactive Programing چیه؟ Reactive Programing روش برنامه نویسی بر اساس جریان داده و تغییرات روی آن بر اساس یک واقعه یا Event است. نمی دونم چقدر با Event و یا Reactive programing آشنایی دارید اما اگر بخوام به زبان ساده بگم Event  این است که یک واقعه رخ می دهد و بعضی کلاس ها و آبجکت ها نسبت به آن واقعه حساسند و متوجه آن می شوند. فرض کنید بابای خونه نسبت به روشن کردن کولر ( ایونت روشن شدن کولر) حساسند و هروقت اتفاق میافتد به محض مطلع شدن عکس العمل مناسب را نشان می دهند! البته این یک شوخی بود اما واقعیت قضیه همین است. در ادامه موضوع رو بیشتر باز می کنم.

RxJava – Reactive Extensions for the JVM – a library for composing asynchronous and event-based programs using observable sequences for the Java VM.

خیلی خوب، گفتم که  برای برنامه نویسی بصورت Reactive در جاوا باید از RxJava استفاده کنیم. یک کامینوتی به نام ReactiveX است که تقریباً برای تمامی  زبان های برنامه نویسی مطرح، کتابخانه داده تا بتوان در آنها از امکانات Reactive استفاده کرد. مثلاً RxKotlin ،RxDart ،RxScala ،RxPHP و…. شاید بپرسید پس RxAndroid چیه؟ آیا اون هم پیاده سازی Reactive در اندرویده؟ اینجا باید بگم خیر!  RxAndroid جای گزین RxJava برای اندروید نیست. بلکه افزونه ای است متشکل از مجموعه ای از ابزار های Rx برای اندروید برای RxJava . یعنی ما در اندروید از RxAndroid به تنهایی نمی تونیم استفاده کنیم و باید در کنارش حتماً RxJava باشه. فکر می کنم در جلسات بعدی که میریم سراع مثال این مسائل این دو وابستگی را در کنار هم در Gradle مشاهده خواهید کرد.

پیش نویس این مقاله رو بیش از دو سال پیش شروع کردم. موقعی که هنوز استفاده از RxJava و RxAndroid خیلی باب نشده بود.  منتهی لازم دیدم که هرچه زود تر به این مبحث بپردازم و تا  سریعتر بتونم وارد مباحث معماری بشم  که خیلی بکارمون میاد و کمکمون می کنه. احتمالاً RxJava رو بتونم در دو یا سه جلسه تمومش کنم و امیدوارم براتون مفید باشه.

از تعاریف که بگذریم می رسیم به منطق و مفهوم کار: به نظر خود بنده Reactive Programming پیاده سازی Observer pattern در سطح برنامه نویسی است. همانطور که در ادامه مشاهده خواهید کرد، یکی از مفاهیمی که بسیارمورد استفاده در Reactive هست مفهومی به نام Observer یا نظاره گر است. پس لازم است که ببینیم این دیزاین پترن دقیقاً چی می خواد بگوید.

Observer pattern

داستان اینطوریه که کلاً سه تا مفهوم داریم. یکسری موضوع یا Subject داریم که حالت یا State خاص دارند و یک تعدادی نظاره گر یا Observer هستند که به تغییر State این Subject ها علاقه مند هستند. پس خود را برای تغیرات حالت موضوع مورد نظر مهیا می کنند و در هر تغییر حالت، این تغییر با مکانیزمی به آنها اطلاع داده شود.

در این مثال ما پدر نسبت به روشن شدن کولر حساس است و تا کولر روشن می شود آن را خاموش می کند. از طرفی روشن شدن کولر برای مادر یا فرزند اهمیتی ندارد. همینطور بوی سوختن غذا فقط برای مادر مهم است و بعد از شنیدن آن به سرعت خودش و به آشپزخانه می رساند، در صورتی که برای پدر و فرزند معنی خاصی ندارد و اصلا متوجهش نیستند. ( البته مثال خیلی انتزاعی است). RxJava هم به همین صورت است. یعنی اتفاقات و event ها بر اساس وارد شدن و یا تغییر اطلاعات فعال می شوند و یک تعدادی کلاس به آنها واکنش نشان می دهند.

حالا که پترن Observer را برسی کردیم می خواهیم مفاهیم متناظر آن در RxJava را ببینیم.

برای ملاحظه مقاله کامل به سایت بایت کد مراجعه کنید.

نوشته Rx java چیست؟ بخش اول اولین بار در Mahdi Tajik پدیدار شد.

در این جلسه قصد داریم با نحوه ساخته شدن و اجرا شدن برنامه اندروید آشنا شویم.  اول از همه اصطلاح “کامپایل” شدن را تعریف می کنیم. در این باره pc mag staff می گوید:

A compiler is computer software that transforms computer code written in one programming language (the source language) into another programming language (the target language). Compilers are a type of translator that support digital devices, primarily computers. The name compiler is primarily used for programs that translate source code from a high-level programming language to a lower level language (e.g., assembly language, object code, or machine code) to create an executable program.

کامپایل شدن به معنای کنارهم قرار دادن و تبدیل کدهای و منابع برنامه و ساخت فایلی قابل اجرا برای دستگاه مقصد است. به برنامه ای که این کار را انجام می دهد کامپایلر گفته می شود. ممکن است برنامه ای برای محیط ویندوز کامپایل شود ( برنامه های ویندوزی) و یا برای اندروید کامپایل شود. ( برنامه های اندرویدی) اما هرکدام دارای شرایط و فرمت خاصی هستند که کامپایلر آن را کنترل می کند. برای استفاده از کامپایلر های مختلف برنامه ها و ابزار توسعه خاص مورد نیاز است. به عنوان مثال برای کامپایل کردن برنامه های اندرویدی می توان از Ecilipes یا Android studio و Intellij IDEA و غیره استفاده کرد. برای ساخت و کامپایل برنامه های ویندوزی از Visual Studio، Borland delphi و غیره استفاده کرد. بحث اصلی ما در مورد کامپایل برنامه اندروید است…

برای دیدن مقاله کامل به سایت بایت کد مراجعه کنید.

نوشته برنامه اندروید چگونه کامپایل و اجرا می شود اولین بار در Mahdi Tajik پدیدار شد.

با سلام، ممکنه برای خیلی ها این سوال پیش اومده باشه که از هرکدوم از Handler یا Thread یا AsycTask استفاده کرده باشیم و لی در حقیقت تفاوت میان آنها را به درستی نشناسیم. در این مقاله می خواهیم این تفاوت ها و محل مناسب استفاده از هر یک را برسی کنیم.

اول لازم هست تا با تعریف هرکدام بیشتر آشنا شویم.

Thread

A thread is a thread of execution in a program. The Java Virtual Machine allows an application to have multiple threads of execution running concurrently.

ترد یا رشته واحد های کلی پردازش وظایف هستند که هر برنامه می تواند تعدادی ترد داشته باشد. هر ترد اولویتی در سیستم دارد و تردهای ایجاد شده توسط یک ترد دیگر، اولویت هم سطح خواهند داشت. در اندروید هر برنامه یک ترد اصلی یا Main thread دارد و وقتی  thread جدیدی ایجاد می کنیم پردازش ها جدا از اتفاقات ترد اصلی روی می دهد. اما برای هماهنگ کردن و یا به عنوان مثال بازگشت جواب باید اینکار را بصورت دستی توسط message یا callback مدیریت کنیم. ( مقاله کامل در اینجا) در صورتی که اگر تردی ایجاد کنیم دستورالعمل های آن باعث freeze شدن برنامه نمی شود زیرا در یک ترد دیگری جاریست اما در عوض به عناصر UI که در ترد اصلی هستند دسترسی نداریم و نمی توانیم بطور مستقیم UI را تغییر دهیم.

new Thread(new Runnable() {
    @Override
    public void run() {
        doSomething();
    }
}).start();

Handler

A Handler allows you to send and process Message and Runnable objects associated with a thread’s MessageQueue. Each Handler instance is associated with a single thread and that thread’s message queue. When you create a new Handler, it is bound to the thread / message queue of the thread that is creating it — from that point on, it will deliver messages and runnables to that message queue and execute them as they come out of the message queue

طبق تعریف خود گوگل با تعریف یک هندلر می توانیم پیغام یا Runnable ای را پردازش کنیم که دقیقاً در thread  کلاس تولید کننده آن قرار می گیرد و نحوه اجرا شدن آن هم به صف همان thread بستگی دارد. پس یعنی Handler های تولید شده در یک thread به ترتیب در همان thread اجرا می شوند. دستورالعمل هایی که در Handler اجرا می شوند در thread اصلی بوده و اصطلاحاً باعث  freeze  شدن برنامه می شود. اما اگر در ترد اصلی تولید شوند به عناصر UI برنامه دسترسی داریم و مثلا می توانیم یک ViewText ای را بروز رسانی کنیم.

new Handler().post(new Runnable() {
    @Override
    public void run() {
       doSomething();
    }
});

بطور معمول وقتی از Handler استفاده می کنیم که بخواهیم اتفاق خاصی در زمان خاصی بیافتد. مثلا فرض کنید می خواهید با تایمر View ای را آپدیت کنید.

new Handler().postDelayed(new Runnable() {
    @Override
    public void run() {
        // update UI after 1000 millisecons
    }
},1000);

Runable

یک اینترفیسی است که تمامی کلاس هایی که قرار است توسط  Thread اجرا شوند، باید آن را پیاده سازی کنند که یک متد run دارد. پس هرکلاس مشخص می کند که هنگام اجرا شدن توسط Thread چکاری را انجام دهد. ( آن کار در متد run پیاده سازی می شود.) که در تمامی مثال های قبلی قابل مشاهده است.

AsyncTask

برای ساخت آن باید کلاسی از آن مشتق کنیم و متد های آن را Override کنیم.

• doInBackground
• onPostExecute

متد doInBackground در یک ترد مجزا انجام می گیرد و جواب آن onPostExecute در ترد اصلی یا همان UI thread اتفاق می افتد که می توانیم توسط آن UI را آپدیت کنیم. البته متد های دیگری نیز دارد که تنها به این دو متد اشاره کردم. استفاده از AsyncTask بسیار در گرفتن اطلاعات از سمت web پرکاربرد است. ( در صورتی که نخواهیم از کتابخانه های نظیر Retrofit و Volley استفاده کنیم) و اصولاً در قدیم (حدود ۶ سال قبل) ترکیب HttpConnection و AsyncTask برای صدا زدن Api های سمت وب اجتناب ناپذیر بود!

private class MyAsycTask extends AsyncTask<Void, Void, Void> {

    @Override
    protected void onPreExecute() {
       //do something in Ui-thread before background work start
    }

    @Override
    protected Void doInBackground(Void... params) {
       //do something in background
        return null;
    }

    @Override
    protected void onPostExecute(Void aVoid) {
      //do something in Ui-thread
    }
}

نکته:

یک نوع استفاده دیگر از Handler وجود دارد که در ظاهر انگار  Thread است اما:

runOnUiThread(new Runnable() {
    @Override
    public void run() {
        doSomething();
    }
});

توجه کنید که runOnUiThread یک نوع خاصی از Handler است که فقط در ترد اصلی اتفاق می افتد.

هرگونه سوال و یا نکته ای داشتید خوشحال می شم که کامنت کنید.

منبع: بایت کد

نوشته تفاوت Handler و Thread و AsyncTask در اندروید اولین بار در Mahdi Tajik پدیدار شد.

thread یا رشته عبارتند از  واحد های کلی پردازش وظایف که هر برنامه می تواند تعدادی ترد داشته باشد. هر ترد اولویتی در سیستم دارد و تردهای ایجاد شده توسط یک ترد دیگر، اولویت هم سطح خواهند داشت. در اندروید هر برنامه یک ترد اصلی یا Main thread دارد و وقتی  thread جدیدی ایجاد می کنیم پردازش ها جدا از اتفاقات ترد اصلی روی می دهد. اما برای هماهنگ کردن و یا به عنوان مثال بازگشت جواب باید اینکار را بصورت دستی توسط message یا callback مدیریت کنیم.

در این مقاله می خواهیم نحوه ارتباط با این دو روش را برسی کنیم.

message

اصلی ترین راه ارتباط بین تردها پاس دادن پیام است. تردی که قرار است پیغام را دریافت کند باید دسترسی به صف پیغام ها داشته باشد که  messageQueue است و خود ترد ساده فاقد این کلاس است.

new Thread(new Runnable() {
    @Override
    public void run() {
        doSomething();
    }
}).start();

به شکل thread ساده و بدون messageQueue توجه کنید:

برای افزودن messageQueue از کلاس Looper استفاده می کنیم که messageQueue را برایمان فراهم می کند.

new Thread(new Runnable() {
    @Override
    public void run() {
        Looper.prepare();
        doSomething();
        Looper.loop();
    }
}).start();

و بدین ترتیب messageQueue برایمان محیا می شود.

حال تردی که می خواهد مسیج ارسال کند نیاز به یک Handler دارد. وظیفه Handler ارسال و پردازش پیغام مربوط به messageQueue ترد ساخته شده اش می باشد. ( همچنین اجرای Runnable که موضوع این آموزش نیست). وقتی یک Handler جدید می سازیم به threadhd ای که درون آن ساخته شده و messageQueue مربوطه متصل می شود و message ها و runnable ها را به messageQueue مربوطه می رساند و یا از روی آن اجرا می کند. در اینجا برای ارسال پیام کافیست که یک هندلر بصورتی تعریف کنیم هردو ترد دسترسی داشته باشند ( بصورت public یا پاس دادن بصورت properties) در یکی توسط آن Messagehvshg ارسال کنیم و در دیگری Message را گرفته و پردازش کنیم.

به مثال ذیل توجه کنید:

private void testThreadMessaging() {

    Handler handler;

    new Thread(new Runnable() {
        @Override
        public void run() {
            Looper.prepare();

            handler = new Handler(){

                @Override
                public void handleMessage(Message msg) {
                    super.handleMessage(msg);
                    Toast.makeText(MainActivity.this, "Job finish with ( "+(float) msg.getData().getLong("jobTime")/1000+" ) seconds", Toast.LENGTH_SHORT)
                            .show();


                }
            };
            Looper.loop();
        }
    }).start();

    new Thread(new Runnable() {
        @Override
        public void run() {
            long jobTime = doSomething(ITERATION_COUNT);
            Message message = new Message();
            Bundle bundle = new Bundle();
            bundle.putLong("jobTime",jobTime);
            message.setData(bundle);
            handler.sendMessage(message);

        }
    }).start();
}

private long doSomething(int iteration) {
    long startTime = System.currentTimeMillis();
    for (int i = 0; i < iteration; i++) {
        Log.i("mahdi", "run: "+i);
    }
    long endTime = System.currentTimeMillis();

    return endTime - startTime ;
}

ترد اول بعد از تمام شدن کارش زمان انجام کار را به ترد دوم پاس می دهد. در اینجا handler بصورت public تعریف شده بود.

Callback

در این روش ارتباط از طریق پاس دادن یک اینترفیس انجام می شود. برای اینکه مثال فرق کند ترد دریافت کننده پیام را در Ui thread قرار دادم. ( یعنی ترد جدیدی نساختم و در یک جایی در اکتیویتی تعریف کردم که می دانیم خود اکتیوتی در main thread یا همان Ui thread است).

private void testThreadCallBack(){

    //our receiver thread is main thread
    callBack = new ThreadCallBack() {
        @Override
        public void onMessage(Object o) {
            Log.i("mahdi", "Job finish with ( "+((Bundle) o).getLong("jobTime")/1000+" ) seconds");

        }
    };

    new Thread(new Runnable() {
        @Override
        public void run() {
            long jobTime = doSomething(ITERATION_COUNT);
            Bundle bundle = new Bundle();
            bundle.putLong("jobTime",jobTime);
            callBack.onMessage(bundle);
        }
    }).start();
}

interface ThreadCallBack{

    void onMessage(Object o);

}

برای درک بهتر کدها را اجرا کنید و نتایج را برسی کنید. در صورتی که سوال یا نکته ای داشتید کامنت کنید.

منبع: بایت کد

نوشته نحوه ارتباط بین thread ها اولین بار در Mahdi Tajik پدیدار شد.

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

fun fact(x: Long): Long {
    tailrec fun factTail(y: Long, z: Long): Long {
        return if (y == 0L) z
        else {
            return factTail(y - 1, y * z)
        }
    }
    return factTail(x, 1)
}

برای صدا زدن کافیست:

logg("$5! : ${fact(5)}")

استفاده از tailrec شرایط دارد از قبیل اینکه بعد از صدا زدن recursive نباید متد دیگری وجود داشته باشد و یا مثلا اینکه درون بلاک های try/catch/finally نمی توان استفاده کرد. مثال کامل Kotlin را می توانید در لینک ذیل مشاهده کنید.

منبع: بایت کد

نوشته tailrec در Kotlin چیست؟ اولین بار در Mahdi Tajik پدیدار شد.

Product Flavor به معنی عطر و طعم محصول است و استفاده از آن امکانات بسیار را به ما در Build گرفتن از پروژه می دهد. خود بخش defaultConfig در  gradle که اطلاعات مربوط به کمترین sdk، نام پکیج و غیره را وارد می کنیم، خود یک کلاس flavor است. با استفاده از flavor امکانات زیادی می توان به برنامه اضافه کرد، از قبیل minSdk, applicationId, targertSdkVersion  و کلاً تمام تنظیماتی که در بخش defaultConfig می نویسیم. حتی می توانید نسخه دیگری از برنامه با package دیگر را به کمک آن بدون نیاز به تکثیر کلاس ها داشته باشیم.

Creating product flavors is similar to creating build types: add them to the productFlavors block and configure the settings you want. The product flavors support the same properties as defaultConfig —this is because defaultConfig actually belongs to the ProductFlavor class. This means you can provide the base configuration for all flavors in the defaultConfig block, and each flavor can change any of these default values, such as the applicationId.

فرض کنید می خواهیم برنامه را در دو نسخه رایگان و پولی تهیه کنید که هرکدام دارای پکیج جداگانه است و می توانند همزمان روی گوشی نصب شوند. اگر این امکان یعنی flavor در gradle وجود نداشت باید دو پروژه با نام پکیج های مختلف ایجاد می کردیم. اما به کمک Flavor به راحتی می توان این کار را انجام داد. برای اضافه کردن flavor می توان از منوی بالا Build/Edit flavors اقدام کرد و یا بصورت دستی نام و مشخصات موردنیاز را در gradle سطح ماژول اضافه کرد.

productFlavors {
    primary {
        applicationId "ir.mtajik.negin"
    }

    freeVersion {
        applicationId "ir.mtajik.negin.freeVersion"
    }
}

ما دو flavor ساختیم که اطلاعات پیش فرض خود را از DefaultConfig  می گیرد. ما به  gradle گفتیم که در نسخه رایگان نام پکیج را تغییر دهد. در صورت انتخاب هرکدام و Build گرفتن، خود gradle اتومات پکیج مورد نظر را تولید می کند و لازم نیست دستی اینکار را انجام دهیم. حال فرض کنید که لازم است در نسخه رایگان در یکسری از کلاس ها اتفاقات دیگری بیافتد. برای اینکار لازم نیست  کلاس های مجزا (ولی همنام) را جداگانه برای هر flavor ایجاد کنیم. کافیست در هر کلاس که قرار است با توجه به flavor اتفاق خاصی بیافتد، بصورت زیر چک کنیم:

if(BuildConfig.FLAVOR.equals("freeVersion")){
    //do something
}

از طرفی اگر قرار است با توجه به flavor های گوناگون تغییری در resource ها داشته باشیم در این صورت باید فایل مربوط به آن را در پکیج همنام flavor ساخته شده قرار دهیم. مثلا فرض کنید قرار است در  freeVersion نام برنامه متفاوت بوده و صفحه اصلی برنامه کلاً فرق داشته باشد و همچنین دیتابیس Sqlite همراه پروژه نیز متفاوت باشد. (یعنی نمی خواهیم این تغییرات را از درون کد انجام دهیم بلکه می خواهیم خودش بطور خودکار resource مربوطه را استفاده کند! ) پس باید پکیج جدید را به همراه فایل های مورد نیاز که قرار است جایگزین شود بسازیم. یادتان باشد این قضیه فقط در مورد Resource ها می باشد و در کلاس ها ایجاد کلاس تکراری بخاطر اندک تفاوت درست نیست و افزونگی ایجاد می کند، بلکه همانطور که گفتم بهتر است با یک if ساده، اتفاقات مربوط به این flavor را در همان یک کلاس هندل کنید. حتماً توجه دارید که این قضیه در مورد کلاس های متفاوت صدق نمی کند ( قرار است یک کلاس خاصی در یک flavor خاصی وجود داشته باشد!)  و باید کلاس های متفاوت اضافه شوند. در تصویر زیر نحوه و محل ساخت قایل های flavor نمایش داده ام:

یک پکیج همنام با  flavor ایجاد شده موازی  main  در  gem/src/main . پس دیدیم که تمامی Resource هایی که قرار بود متفاوت باشند را قرار دادیم. از جمله DB، فایل CSS مربوطه نمایش وب ویو، layout مربوط به MainActivity و حتی strings که در آن نام برنامه و تعدادی متن دیگر را تغییر داده ام. در ضمن اگر قرار است کلاسی فقط در اینجا وجود داشته باشد همانطور که گفته شد آن را باتوجه به نیاز اضافه می کنیم و در داخل کد استفاده. خیلی راحت و خوش مزه!

حالا نوبت به نحوه استفاده از flavor ایجاد شده می رسد، قبلش یک نکته کوچک:

همانطور که حتماً مستحضر هستید می توان حالات مختلفی برای  Build با  BuildTypes   داشته باشیم. می توان متغیر تعریف کرد، obfuscate کرد و یا تسک خاصی را به همراه Build اجرا کرد. بطور مثال تفاوت آدرس های  api در Release و debbug را می توان با BuildTypes هندل کرد. به مثال زیر توجه کنید:

buildTypes {
    release {
        minifyEnabled true
        proguardFiles 'proguard-base.txt', 'proguard-rules.pro'
        buildConfigField "String", "SERVER_ADDRESS", "\"http://api.neginserver.com:8989\""
        buildConfigField "String", "API_VERSION", "\"v1\""
        buildConfigField "String", "SKU_PREMIUM", "\"premium\""

        signingConfig signingConfigs.negin

    }

    debug_in_main_server {
        initWith(buildTypes.debug)
        buildConfigField "String", "SERVER_ADDRESS", "\"http://api.neginserver.com:8989\""
        buildConfigField "String", "API_VERSION", "\"v1\""
        buildConfigField "String", "SKU_PREMIUM", "\"premium_debug3\""

    }

    debug {
        minifyEnabled false
        proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        buildConfigField "String", "SERVER_ADDRESS", "\"http://192.168.34.24:8989\""
        buildConfigField "String", "API_VERSION", "\"v1\""
        buildConfigField "String", "SKU_PREMIUM", "\"premium_debug3\""

    }
}

همانطور که ملاحظه می کنید در این سه نوع خروجی از برنامه سه تا متغیر تعریف شده که با توجه به انتخاب build خودش بطور خودکار انتخاب و در برنامه استفاده می شود. فقط کافیست درجایی از کد بصورت زیر استفاده کنید:

String serverAddress = BuildConfig.SERVER_ADDRESS;
String apiVersion = BuildConfig.API_VERSION;
String url_base_services = serverAddress + "/api/"+apiVersion;

خیلی خوب، بر می گردم سر موضوع اصلی یعنی نحوه استفاده از flavor

برای استفاده از flavor باید به منوی Build Varians در Android Studio رفته و بعد از انتخاب گزینه مورد نظر برنامه را لانچ یا build بگیریم. نکته جالب این است که می توان با ترکیب BuildConfig و Flavor حالات بسیار زیادی برای Build برنامه ایجاد کرد که واقعاً کاربردی و ضروری است یعنی به تعداد BuildType در تعداد flavor ، حالت Build خواهیم داشت ( همانطور که می بینید  ۴  = (debug | release )ضرب(freeVersion | primary) حالت داریم.) و به راحتی می توانیم درهرلحظه Build مورد نظر را با حداقل تغییرات در کد( تغریباً صفر!) انجام دهیم.

امیدوارم این آموزش براتون مفید بوده باشه. سوالات و نقطه نظرات خود را با من به اشتراک بگذارید.

منبع: بایت کد

نوشته مزایا و نحوه استفاده از Product Flavors در Gradle اولین بار در Mahdi Tajik پدیدار شد.

سلام دوستان عزیز، متاسفانه کمی طول کشید تا مطلب آموزشی بگذارم، کامنت ها و استقبال شما انرژی خاصی به من داد تا هرچه زود تر نسبت به کامل کردن این بحث اقدام کنم. خیلی خوب، در مقاله قبلی با نحوه استفاده از Dagger2 آشنا شدیم. در این بخش می خواهیم چند روش دیگر استفاده را به همراه امکانات بیشتر این کتابخانه مورد برسی قرار دهیم. همانطور که در آموزش قبلی به روز کردم به علت استفاده زیاد از این کتابخانه، گوگل امکان اضافه کردن آن را به صورت مستقیم داده و شما می توانید ازین پس بصورت زیر در gradle در سطح خود برنامه از آن استفاده کنید:

compile 'com.google.dagger:dagger:2.7'
annotationProcessor 'com.google.dagger:dagger-compiler:2.7'

می خواهیم کمی بیشتر با DI آشنا شویم و ابزار های آن را در Dagger2 ببینیم. ما چند نوع تزریق داریم.

Constructor injection

برروی کانستراکتور Inject@ گذاشته و در این صورت دیگر نیازی به نوشتن Module نداریم.

Fields injection

همینطور که در آموزش قبل ملاحظه کردید تزریق یک فیلد را گویند. ( در تمامی آموزش قبل از fields injection استفاده کردیم)

Methods injection

بروری یک متدی از یک کلاس Inject@ بگذاریم.

چند انوتیشن که باید در این جلسه با آنها آشنا شویم:

@Scope annotation

اصولا هدف استفاده از این انوتیشن معرفی Scope آبجک تولید شده است. یعنی Dagger2 به شما این امکان را می دهد تا Object های شما چرخه عمر متفاوت داشته باشند و شما فقط تعریف می کنید، مدیریتش با خود Dagger است. پیشنهاد من این است که برای این مقاله تا همین حد کافی است و بعد از اتمام این اموزش به مقاله کامل مراجعه کنید.

@Qualifier

وقتی از این انوتیشن استفاده می کنیم که متد ها همنام و و ورودی خروجی یکسان داشته باشند و به Dagger می فهمانیم کِی، چی را تزریق کند.

بسیار عالی. در آموزش قبل دیدیم که هرجا بخواهیم از DI توسط Dagger2 استفاده کنیم باید سه مرحله زیر را انجام دهیم:

۱- ساخت Provider ها در کلاس Module که مشخص می کنیم کلاس ها چگونه تولید شوند.

۲- ساخت اینترفیسی به نام Component که می گویم از کدام Module ها استفاده کند و متدی در آن قرار می دادیم که کلاسی که در آن Inject انجام شده بود وجود داشته باشد تا Dagger2 بفهمد کدام کلاس ها را جهت فیلد انجکشن اسکن و وایراپ کند و متوجه شدیم که Dagger متدها رو بصورت خودکار تولید می کند.

۳- در کلاس استفاده کننده ( قرار است Inject اتفاق بیافتد) متد تعریف شده در Component را از کلاس AutoGenerated توسط Dagger صدا بزنیم و  تمام!

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

حال یک سوال:

با توجه به مطالب یاد شده می توانیم هر بخش از برنامه را بصورت DI توسط Dagger2 بنویسیم. مثلا یکسری کلاس هایی را بصورت Inject در کلاس های دیگر استفاده کنید. اما سوال من این است که اگر بخواهیم در کل پروژه از DI استفاده کنیم چه باید کرد؟ یعنی کلاس هایی که به همدیگر ربط پیدا می کنند. (مثلا Context که در خیلی جاها لازم داریم و یا SharedPrefrence و یا خیلی کلاس های دیگر) این سوالی بود که برای خودم هم پیش آمد و بهترین جواب برای آن طراحی از بالا به پایین کل پروژه است! یعنی به جای اینکه بیاییم  از پایین به بالا برای تک تک کلاس های استفاده شده Module بنویسیم و سپس برسیم به سطح کامپوننت های اندروید مثل fragment و Activity که واقعاً نشدنی است و ارتباطات خیلی پیچیده می شود و از طرفی Inject های تکراری ایجاد می شد که Dagger2 آن را قبول نمی کند، بهتر است از سطح Application به پایین طراحی کنیم. این نکته را هم در نظر داشته باشید که Dagger2 در یک DI مجزا، امکان ساخت یک کامپوننت اصلی را می دهد ( به شکل بالا توجه کنید) و اگر کامپوننت های دیگری داشتیم باید در ارتباط با کامپوننت اصلی باشند.  ( این ارتباط یا از نوع Dependency است یا SubComponent که در انتهای این بحث به تفاوت آنها اشاره خواهم کرد.) البته این مساله در صورتی است که Dependency Injection های مرتبط به هم داشته باشید. اما اگر فقط می خواهید در بخش های خاصی از برنامه از DI استفاده کنید که به هم مرتبط نیستند هر کدام Component و Module مستقل از هم را خواهند داشت که مشکلی هم پیش نمیاید. مثلا در مساله آموزش قبل که DI را برای تولید خودرو استفاده کردیم، فرض کنید یک DI هم برای قایق یا کشتی بنویسیم که بخواهیم تولید قایق را برایمان مدیریت کند. برای این کار دقیقاً مانند DI خودرو Module و Component مربوطه آن را تشکیل می دهیم و ربطی هم به DI خودرو ندارد و از هم مستقل اند. تنها نقطه مشترک کلاسی هست که استفاده کننده است. ( مانند Activity)

می خواهیم مثالی ساده نوشته و  آن را باهم برسی کنیم. لطفاً به این بخش خیلی توجه کنید. به علت ارتباط بخش های مختلف ممکن است پیچیدگی ظاهری داشته باشد، اما واقعاً پیچیده نیست و تمامی قوانینی که در جلسه قبل گفتیم صادق است. تلاش من این است که تمامی حالت های ممکن برای ساخت DI را برسی کنیم تا تمامی سوالات برطرف شود.

شرح برنامه:

برنامه ای داریم که با استفاده از اطلاعات کاربری، درخواستی به وب زده و نتیجه را در پایگاه داده ذخیره می کند. توجه کنید که اتفاقات بصورت شماتیک است و هدف برسی روابط آنها در Dagger2 می باشد و صرفاً به ازای اکثر عملیات ها در کد، فقط لاگ کرده ایم. به شکل زیر دقت کنید: کلاس اپلیکیشن دارای کلاس های Context و User و Database (که وابسته به Context  و User است) و Activity است و خود کلاس Activity هم شامل NetworkCalss است که  وابسته به User است.

نکات برنامه:

کلاس Application به Database نیاز دارد تا آن را در اول برنامه Initilize کند از طرفی Database به User و Context نیاز دارد. سپس Activity یک Network Request می زند و نتیجه را در Database ذخیره می کند.اول از همه Module های مربوط به User و Database را ایجاد می کنیم تا Dagger بفهمد آنها را چگونه تولید کند.

@Module
public class UserModule {

    @Provides
    @Singleton
    User providesUser() {
        return new User("Farhad", "Majidi");
    }
}

@Module
public class DatabaseModule {

    @Singleton
    @Provides
    Database providesDatabase(Context context,User user){
        return new Database(context,user);
    }
}

@Singleton
@Component(modules = {ApplicationModule.class, DatabaseModule.class,UserModule.class})
public interface ApplicationComponent {

    void inject(DaggerTestApplication application);


    // Exported for child-components. (subcomponent need this to use Context or User or Database)

    Context getContext();

    User provideUser();

    Database provideDatabase();

}

سوال: چه چیزی را می خواهیم تزریق کنیم؟ جواب: DataBase و User

سوال: چطور ساخته می شود؟ جواب: در UserModule  و DatabaseModule مشخص شده است و آنها را به عنوان Module به Component داده ایم!

سوال: استفاده کننده نهایی کیست؟ جواب: DaggerTestApplication  است بنابر این یک متد با ورودی خودش نوشتیم تا Inject@ های روی فیلدهایش اسکن شود.

سوال: دوسه تا متد بعدی چیه؟ جواب: باید برای هر کلاسی که child ها به آن نیاز دارند یک متد Exporter  بنویسیم.

از آنجایی که می خواهم کلاس NetworkClass را فقط در Activity استفاده کنم و از طرفی NetworkClass به User نیاز دارد بنابراین یک کامپوننت جدا با Scope جدید می نویسیم. چون می خواهم مادامی که Activity وجود دارد NetworkClass نیز وجود داشته باشد. اما لازم است تا Component اصلی متدهایی داشته باشند تا کلاس User را برایم Export کنند. بنابر این من متدی اضافه کردم به نام provideUser که خروجی آن User است. خود Dagger پیداده سازی آن را مدیریت می کند. همچنین چون ممکن است Context برنامه را کلاس های دیگر بخواهند یک متد نیز برای آن نوشتیم و همچنین برای Database هم یک متد Export کننده نوشتم.( خواهید دید که DataBase در Activity جهت ذخیره مورد نیاز قرار خواهد گرفت. پس یک متد Export کننده لازم داشت.) این طراحی بالا به پایینی بود که اول مقاله گفتم. یعنی در Component اصلی که نحوه ارتباط ها را مشخص می کنیم برای فرزند ها نیز وابستگی های مشترک را در نظر بگیریم.

یک نکته دیگر در مورد context است. از آنجایی که کلاس های دیگری ممکن است به آن وابسته شوند یک متد برای آن نوشتیم، اما چون Context را ما نمی سازیم و خود سیستم تولید می کند لازم نیست برایش Module بنویسیم و ساخت و Handle آن توسط خود Dagger با Android system انجام می شود. البته در این پروژه استفاده ای از آن نکردیم، اما مطمئناً به آن نیاز پیدا خواهید کرد.

حال می رویم سراغ وابستگی های Activity و این بخش است که کمی برایمان تازگی دارد.

@Scope
@Retention(RetentionPolicy.RUNTIME)
public @interface ActivityScope {
}


@Module
public class ServiceModule {

    @ActivityScope
    @Provides
    NetworkClass providesNetworkClass(User user) {
        return new NetworkClass(user);
    }
}

@ActivityScope
@Component(dependencies = ApplicationComponent.class, modules = ServiceModule.class)
public interface ActivityComponent {

    void inject(MainActivity activity);

}

سوال: چه چیزی را می خواهیم تزریق کنیم؟ جواب: NetworkClass

سوال: چطور ساخته می شود؟ جواب: در ServiceModule مشخص شده است و آن را به عنوان Module به Component داده ایم!

سوال: اما نحوه ساخت یوزر را در ServiceModule  نداریم؟! جواب: در ActivityComponent  مشخص کردیم که

dependencies = ApplicationComponent.class ( یعنی وابستگی به ApplicationComponent داریم و هر کلاسی که در آن Export شده است را می توانیم استفاده کنیم. پس ServiceModule در ساخت NetworkClass یک User به عنوان ورودی می گیرد، و نحوه ساخت آن یوزر را ApplicationComponent  می داند.

سوال: چرا Scope جدید دادیم؟ جواب: برای اینکه می خواهیم مادامی که استفاده کننده آن (Activity ) وجود دارد، NetworkClass ما وجود داشته باشد. نحوه دقیق کار Scope در این آموزش موجود است.

سوال: این NetworkClass کجا استفاده می شود و Dagger از کجا می فهمد؟ جواب: این جواب رو دیگه شما هم می دانید و همانطور که در کلاس Activity ملاحظه می کنید چون درون دوتا فیلد اینجکشن داریم ( یکی NetworkClass و دیگری DataBase)  بنابر این یک متدی در Component قرار دادم تا ورودی آن از جنس MainActivity باشد تا تمامی Field injection های آن اسکن شود و ارتباط ها برقرار شود.

public class MainActivity extends AppCompatActivity {

 
    @Inject
    NetworkClass networkClass;

    @Inject
    Database database;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        initialize();
        webRequest();

    }

    private void webRequest() {

        networkClass.request("https://google.com");
        database.saveToDB();
    }

    private void initialize() {

        ((DaggerTestApplication)getApplicationContext()).getActivityComponent().inject(this);
    }


}

ملاحظه خواهید کرد که هم NetworkClass و هم DataBase به درستی در Activity تزریق شده اند و قابل استفاده هستند. حالا که نحوه کار با Dagger2 را متوجه شدیم می توانیم برای متوجه شدن بیشتر این کد را به چند صورت متفاوت نوشت و تغییر داد. که همه اینها در Github در شاخه های با نام های:lesson2, lesson2-type2, lesson2-type3, lesson2-subcomponent قرار گرفته اند.

روش های دیگر برای درک کامل

برای اینکه دقیقاً بفهمید Dagger2 چطور کار می کند حتماً این مثال ها را ببینید و درک کنید. در این چند مثال انواع روش های پیاده سازی را انجام داده ام و فهمیدن انها باعث از بین رفتن گنگی نسبی قضیه و تسلط کامل خواهد شد و جواب بسیاری از سوال هایی که در ذهن دارید را خواهید یافت. تلاشم تغییر روی یک کلاس واحد Database بود تا با ثابت بودن آن تغییر روش ها را ملاحظه نمایید.

شاخه lesson2 : همین کدی است که در این آموزش داشتیم.

شاخه lesson2-type2 :در کلاس Database خود User تزریق شده است. بنابراین ناچاریم تا متدی بنویسیم که ورودی آن Database باشد تا فیلد های تزریق شده اسکن شود.

شاخه lesson2-type3: در کلاس Database از Constructor Injection استفاده کردم. همانطور که در تعریف اول بحث مطرح کردم در این روش Inject@ در روی Constructor  کلاس می گذاریم و دیگر نیازی به نوشتن Module برای نحوه پیاده سازی آن نداریم و کلا DatabaseModule حذف می شود. البته ActivityComponent تغییری نمی کند.

public class Database {

    private static final String TAG = "mahditajik.ir";

    @Inject
    User user;
    private Context context;

    @Inject
    public Database(Context context) {
        this.context = context;

    }

    public void initialize() {
        Log.i(TAG, "initialize with context: " + context.toString());

    }

    public void saveToDB() {
        Log.i(TAG, "saveToDB: " + user.toString());
    }
}

@Singleton
@Component(modules = {ApplicationModule.class,UserModule.class})
public interface ApplicationComponent {

    void inject(DaggerTestApplication application);

    // Exported for child-components.

    Context getContext();

    User provideUser();

    //because it had Constructor injected and do not need for Module or exporter
//    Database provideDatabase();

}

شاخه lesson2-subcomponent : مثالی است در مورد مطلب مهمی که در اواسط آموزش به آن اشاره کردم:

Subcomponent vs Dependency

همانطور که در مثال ملاحظه کردید برای ارتباط ActivityComponent با ApplicationComponent از Dependencies استفاده کردیم

@Component(dependencies = ApplicationComponent.class, modules = ServiceModule.class)

و سپس هر Object که لازم بود را در ApplicationComponent برایش یک متد exporter نوشتیم. اما راه دیگر استفاده به عنوان Subcomponent است. در این روش انترفیس subcomponent به همه Object های Component دسترسی دارد و نیازی به نوشتن متد های exporter ندارد و کارایی آن هنگامی است که واقعاً به تمامی object ها نیاز داریم. برای شناساندن Subcomponent به Component اصلی فقط کافیست که یک متد Factory برایش در Component بنویسیم.

@MahdiScope
@Subcomponent(modules = ServiceModule.class)
public interface ActivityComponent {

    void inject(MainActivity activity);

}

@Singleton
@Component(modules = {ApplicationModule.class, DatabaseModule.class, UserModule.class})
public interface ApplicationComponent {

    void inject(DaggerTestApplication application);


    // Exported for child-components.

//    Context getContext();
//
//    User provideUser();
//
//    Database proDatabase();


    //sub component

    ActivityComponent providesActivityComponent(ServiceModule service);

}

و برای استفاده wire-up کردن هم متد ماژول ان را از کامپوننت اصلی بگیریم. ( خط ۲۷)

public class MainActivity extends AppCompatActivity {

    @Inject
    NetworkClass networkClass;

    @Inject
    Database database;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        initialize();
        webRequest();

    }

    private void webRequest() {

        networkClass.request("https://google.com");
        database.saveToDB();
    }

    private void initialize() {

        ((DaggerTestApplication) getApplicationContext()).getAppComponent()
                .providesActivityComponent(new ServiceModule()).inject(this);

    }
}

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

بعد از گرفتن پروژه یکبار اون رو import کنید تا قابل اجرا بشه.

منبع: بایت کد

نوشته کار با Dagger2 به زبان ساده بخش دوم (پیشرفته) اولین بار در Mahdi Tajik پدیدار شد.

@Scope annotation

اصولا هدف استفاده از این انوتیشن معرفی Scope آبجک تولید شده توسط Dagger2 است. یعنی Dagger2 به شما این امکان را می دهد تا Object های شما چرخه عمر متفاوت داشته باشند و شما فقط تعریف می کنید، پیاده سازی اش با خود Dagger است. فرض کنید که سه component به شرح زیر داریم و سلسله مراتب ارتباط و وابستگی Component ها هم مشخص است.

و ما برای آنها سه اسکوپ تعریف می کنیم. ActivityScope, UserScope, Applicationscope(singletone).

Dagger2 به طور پیش فرض singletone یا همان applicationScope را دارد و چرخه عمرآن با چرخه عمر Application یکی است. احتمالاً در کد autogenerated خودش بصورت static نگهداری می کند. استفاده از این اسکوپ ها مانند این است که tag تعریف کنیم و اسمشان اهمیتی ندارد. فقط Object ای که با اسکوپ خاصی تولید می شود، طول عمر و LifeCycle اش با صدا زننده آن یکی خواهد شد. مثلا اگر یک Object با ActivityScope@ داریم که در درون activity تزریق می شود، Lifecycle  آن با Lifecycle مربوط به activity یکی می شود و تا زمانی وجود دارد که Activty تزریق کننده آن وجود داشته باشد و کنترل کردن آن اتوماتیک توسط Dagger2 انجام می شود.

به تصویر زیر توجه کنید:

ApplicationScope در طول کل برنامه وجود دارد. پس ما برای هر آیتمی این اسکوپ را بگذاریم تا پایان برنامه وجود خواهد داشت. با شروع هر اکتیویتی، ActivityScope شروع و با بسته شدن آن اسکوپ هم تمام می شود. همچنین برای UserScope. با انتخاب یا ساخت هر یوزری شروع و  در نهایت با رهاکردن آن، تمام می شود.

پس یادمان باشد که نام Scope ها مهم نیست. بلکه این مهم است که برای چه Provider ای تعریف شده و آن Object در چه کلاسی Inject می شود. برای ساخت آن بدین صورت عمل می کنیم:

@Scope
@Retention(RetentionPolicy.RUNTIME)
public @interface ScopeName{
}

منبع: بایت کد

نوشته برسی Scope@ ها در Dagger2 اولین بار در Mahdi Tajik پدیدار شد.

حتماً شما هم افکت های زیبای Material Design را دیده اید که چگونه با اسکرول دادن لیست، toolBar و عناصر دیگر با یک افکت زیبا جمع شده و به بالا می روند. چی؟! راجع بهش می دونید و ازش استفاده می کنید؟ باشه من می خوام در این مقاله  نحوه صحیح پیاده سازی CollapsingToolBar  را  باهم برسی کرده و ابهامات احتمالی موجود در گوشه ذهنمون رو بر طرف کنم. پس چه دوستانی که با این کتابخانه آشنا هستند و چه شمایی که تازه می خواهید شروع کنید، تا آخر این مقاله با من باشید. پیشنهاد من اینکه یکبار مقاله را کامل بخوانید و بعد بروید سراغ کد. ۹۰ درصد سوالات برطرف می شود و اگر دوباره مقاله را بخوانید ۱۰ درصد بقیه نیز اوکی میشود. انشاء الله

تعریف:

CollapsingToolBar یک wrapper یا غلاف برای ToolBar هست که خودش مشتق شده از AppBar است و طراحی شده تا فرزند AppBarLayout باشد. خود AppBarLayout یک LinearLayout است با این امکان که اکثر افکت ها و امکانات Material Design  در فرزند های آن قابل استفاده است و اجازه می دهد تا ToolBar و View های دیگر نسبت اسکرول شدن View های وابسته (NestedScrollView و یا RecyclerView) عکس العمل نشان بدهند و افکت های Material Design را اعمال کنند.حتماً می دانید که AppBarLayout باید والد یا parent آن CoordinatorLayout باشد. خود CoordinatoLayout نیز Super FrameLayout است که معمولا به عنوان والد اصلی لیوت ها بکار گرفته می شود. برای جلو گیری از پیچیده شدن مطلب به نمودار زیر توجه کنید:

خیلی خوب بیاید یکبار بالعکس دفعه قبل از بالا به پایین برسی کنیم:

CoordinatorLayout لازم است تا بتوانیم AppBarLayout داشته باشیم. AppBarLayout هم باید باشد تا بتوانیم CollapsingToolBarLayout داشته باشیم. درون CollapsingToolBarLayout هم یک ToolBar برای برنامه می گذاریم و یک ImageView. ما می خواهیم با اسکرول خوردن لایه محتوا، کل CollapsingToolBarLayout و کامپوننت های داخل آن به جز ToolBarجمع شود. در هر کدام از این کامپوننت ها هم باید Property های مخصوص را به درستی مقدار دهی کنیم. اول اینکه در CollapsingToolBarLayout باید فلگ اسکرول را بدهیم که مشخص می کند نسبت به اسکرول لایه محتوا چه عکس العملی نشان دهد. در ضمن می توان برای ToolBar یا کامپوننت های داخل CollapsingToolBarLayout نوع جمع شدن ان را مشخص کرد که می تواند بصورت Paralex یا pin باشد. استفاده از paralex برای ImageView بسیار جالب خواهد بود و با سرعتی کمتر از سرعت اسکرول از صفحه خارج خواهد شد. ( سایت های paralex رو حتماً دیده اید!) البته گزینه pin فقط روی ToolBar کار می کند و توسط آن بعد از جمع شدن کل CollapsingToolBarLayout فقط ToolBar بالای صفحه باقی می ماند و به اصطلاح Pin می شود. البته توجه کنید که نمی توان Pin را مثلا روی ImageView اعمال کرد.

بسیار خوب، از طرفی هم به لایه محتوی باید بگوییم که قرار است تغییرات اسکرولش به AppBarLayout اطلاع داده شود که این امر با ست کردن  layout_behavior محقق می شود.

همه اینها در تصویر پایین رسم کرده ام تا بسیار راحت جمع بندی کنیم.

حالا می تونید برگردید و تعریف رو دوباره بخونید. خیلی خوب! ببینیم چطور می تونیم این افکت ها را ایجاد و مدیریت کنیم. استفاده از Component های یاد شده به همراه چند Scroll_flags باعث ایجاد افکت های Scrolll می شود که بصورت زیر است:

Scroll
اگر از فلگ

scroll

enterAlways
با استفاده از فلگ

enterAlways

scroll

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

exitUntilCollapsed

کد نمودار بالا بصورت زیر است:

<?xml version="1.0" encoding="utf-8"?>
<android.support.design.widget.CoordinatorLayout
    xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:fitsSystemWindows="true">
    <!-- fitsSystemWindows: hen enabled, the AppBarLayout assumes that the status bar is not available and it has to occupy the entire real estate. -->

    <android.support.design.widget.AppBarLayout
        android:id="@+id/app_bar"
        android:layout_width="match_parent"
        android:layout_height="256dp"
        android:theme="@style/AppTheme.AppBarOverlay">

        <android.support.design.widget.CollapsingToolbarLayout
            android:id="@+id/collapsingToolBar"
            android:layout_width="match_parent"
            android:layout_height="match_parent"
            app:contentScrim="@color/colorPrimary"
            app:layout_scrollFlags="scroll|exitUntilCollapsed">
            <!-- * contentScrim: when collapsing the toolbar color change to this, if you want to use this feature do not set background color for toolBar -->

            <ImageView
                android:layout_width="match_parent"
                android:layout_height="match_parent"
                android:scaleType="centerCrop"
                app:layout_collapseMode="parallax"
                android:src="@drawable/ic_back"/>

            <android.support.v7.widget.Toolbar
                android:id="@+id/toolbar"
                android:layout_width="match_parent"
                android:layout_height="?attr/actionBarSize"
                android:elevation="7dp"
                app:popupTheme="@style/ThemeOverlay.AppCompat.Light"
                app:layout_collapseMode="pin"/>

            <!-- * layout_collapseMode: indicate how our tool bar act to collapsing pin on top or paralex -->

        </android.support.design.widget.CollapsingToolbarLayout>


    </android.support.design.widget.AppBarLayout>

    <include layout="@layout/content_main"/>

    <android.support.design.widget.FloatingActionButton
        android:id="@+id/fab"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_margin="@dimen/fab_margin"
        app:layout_anchor="@id/app_bar"
        app:layout_anchorGravity="bottom|right"
        app:srcCompat="@android:drawable/ic_dialog_email"/>
    <!-- * layout_anchorGravity: layout_gravity should removed so the layout_anchorGravity works -->
    
</android.support.design.widget.CoordinatorLayout>

نکته۱:
گزینه

contentScrim

CollapsingToolbarLayout

toolBar

نکته۲:
گزینه

layout_anchor

CoordinatorLayout

floatingActionButton

appBarLayout

layout_anchorGravity

floatingActionButton

همانطور که می بینید با استفاده از کامپوننت های CollapsingToolBar  و AppBarLayout و CoordinatorLayout با دادن چند Property ساده تونستیم افکت زیبای Material Design را داشته باشیم. امیدوارم این مقاله براتون مفید بوده باشه.

کد کامل رو از اینجا بگیرید و خودتان تست کنید.

منبع: بایت کد

نوشته کار با CollapsingToolBar به همراه مثالی ساده اولین بار در Mahdi Tajik پدیدار شد.

چقدر خوب می شد اگر هر وقت نیازمندی داشتیم فقط آن را مطرح می کردیم و به سادگی برایمان فراهم می شد؟ مفهوم Dependency Injection یا به اختصار DI همین است، شما فقط می گویید من آن object را می خواهم و شخص دیگری آن را با تمام پیچیدگی هایش برایتان فراهم می کند! در ضمن تمام امور مربوط به تولید، نگهداری، چرخه حیات و مسائل مربوط آن شئی را برایمان کنترل می کند و باعث می شود ارتباطات بین کلاس ها ساده تر شود و در نتیجه نگهداری و توسعه ساده تر گردد. قرار است این کار را توسط Dagger2 در اندروید پیاده سازی نماییم.

مقدمه:

Dependency Injection is a set of software design principles and patterns that enable us to develop loosely coupled code.

Loose coupling makes code extensible, and extensibility makes it maintainable

Mark Seemann

یکی از اصول SOLID اصل Dependency Inversion Principle است که یکی از دیزاین پترن هایی که آن را پیاده سازی می کند Dependency Injection است که هدف اصلی آن کم کردن وابستگی ها برای نگهداری و توسعه راحت تر می باشد. در صورتی که علاقه مند به آشنایی بیشتر با این دیزان پترن هستید  می توانید کتاب Mark seemann را از اینجا دانلود کنید. در ضمن دوست و همکار عزیزم مثالی خوب و  ملموسی با نام “Dependency Injection in the Coffeeshop” دارد که دیدن آن خالی از لطف نیست. Dagger

  Dagger2 یک Dependency Injection FrameWork است که Dependency Injection را با استفاده از تولید خودکار کد بر پایه annotations بهره می گیرد (در مورد انوتیشن می توانید به این آموزش مراجعه کنید) یعنی برای استفاده از امکانات آن باید از annotation های خاصی استفاده کنیم که به توضیح آنها خواهم پرداخت. بخاطر اینکه  کار با Dagger2 کمی ابهام دارد و فهم آن برای خودم هم کمی طول کشید، مثال ساده ای آماده کردم که نحوه کار با Dagger2 را خیلی واضح و راحت باهم برسی کنیم. فقط توجه داشته باشید که هدف اصلی این مقاله نحوه کارکرد با Dagger2 است و نه پیاده سازی صددرصد صحیح Dependency Injection و تلاش می کنیم در مقاله دوم به این امر نیز پرداخته و پروژه را از هر نظر باهم تکمیل کنیم.

به نظرم یک از دلایل پیچیدگی های کار با Dagger2 ، روش های گوناگون پیاده سازی آن است که شاید بعضاً کار کند ولی از نظر DI درست نباشد و می توان با اطلاع  از این روش ها تسلط خوبی برآن پیدا کرد. بنابر این سعی می کنم به مرور کد را تمیز تر و به DI اصولی نزدیک تر کنم. پس تا آخر این مقاله با من باشید و درصورت وجود هرگونه ابهام یا ایراد یا سوال آن را با من در میان بگذارید تا در اسرع وقت پاسخ دهم.

قدم اول: اضافه کردن Dagger2 به پروژه

اول از همه اطلاعات زیر را به Gradle سطح پروژه اضافه کنید:

dependencies {
    
    classpath 'com.neenbedankt.gradle.plugins:android-apt:1.8'
}

سپس خط زیر را در آخر Gradle سطح برنامه اضافه کنید.

apply plugin: 'com.neenbedankt.android-apt'

و وابستگی های زیر را نیز به همان فایل اضافه نمایید

dependencies {
    compile 'com.google.dagger:dagger:2.7'
    apt 'com.google.dagger:dagger-compiler:2.7'
    provided 'javax.annotation:jsr250-api:1.0'
}

سپس Gradle خود را sync کنید.

به روز رسانی: اخیراً به علت کاربرد زیاد Dagger گوگل امکان اضافه کردن این کتابخانه را بصورت مستقیم فراهم کرده و می توان بدین صورت نیز عمل کرد:

compile 'com.google.dagger:dagger:2.7'
annotationProcessor 'com.google.dagger:dagger-compiler:2.7'

قدم دوم: آماده سازی کلاس هایی که می خواهیم برایمان تزریق شوند و ارتباط بین آنها (Wiring up)

مفاهیم اصلی مطرح در Dagger2 به شرح زیر می باشند که همانطور که اشاره کردم برای استفاده از این مفاهیم باید از انوتیشن های هم نام آنها استفاده کرد.

Provides@

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

Module@

کلاسی هست که Provider ها در آن قرار می گیرند.

Component@

اینترفیسی که ارتباط وابستگی ها و استفاده کننده آن را مطرح می کند. ما فقط اینترفیس را می نویسیم و پیاده سازی آن با خود Dagger است.

Inject@

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

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

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

public class Computer {

    private int voltage;
    private String model;

    public Computer(String model ,int voltage){

        this.model=model;
        this.voltage = voltage;
    }
}

public class Radiator {
    private String name;

    public Radiator(String name){
        this.name = name;
    }
}

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

public class Motor {

    @Inject
    public Computer computer;

    @Inject
    Radiator radiator;

    String name;

    public Motor(String name) {
        this.name = name;
    }

    public boolean startEngin() {
        if (computer != null && radiator != null) {
            return true;
        } else {
            return false;
        }
    }

    public Computer getComputer() {
        return computer;
    }


    public String getName() {
        return name;
    }

    public Radiator getRadiator(){
        return radiator;
    }
}

پس ما تا اینجا نحوه وابستگی کلاس ها را با انوتیشن Inject@ مشخص کردیم. یعنی به Dagger گفتیم که هنگام ساخت موتور رادیاتور و کامپیوتر را در اختیارم قرار بده! ( حالا نمی دانم چطوری، هرطور خودت صلاح می دونی!) ولی قبل آن لازم است تا یکبار نحوه ساخته شدن وابستگی ها را به Dagger را معرفی کنیم. برای اینکار کلاسی با نام ماژول می سازیم که از انوتیشن Module@ استفاده می کند و بخش های آن که نحوه ساختن وابستگی را شرح می دهند با انوتیشن Provides@ مشخص می کنیم.

@Module
public class MotorModule {

    String motoName;
    String computerName;
    String radiatorName;
    int voltage;

    public MotorModule(String computerName, int voltage , String radiatorName) {
        this.radiatorName = radiatorName;
        this.computerName = computerName;
        this.voltage = voltage;
    }


    @Provides
    @Singleton
    Motor provideMotor() {
        return new Motor(motoName);
    }

 

    @Provides
    @Singleton
    Computer provideComputer() {
        return new Computer(computerName, voltage);
    }


    @Provides
    @Singleton
    Radiator provideRadiator(){
        return new Radiator(radiatorName);
    }
}

اگر قرار است وابستگی های ما ورودی داشته باشند آن را در Constructor مربوط به Module پاس می دهیم. همانطور که می بینید اسم رادیاتور، اسم کامپیوتر و ولتاژ آن ( که جزو ورودی های ما بودند) به همراه Constructor پاس داده شد. ما در Module به Dagger می فهمانیم که وقتی آبجکتی خواستیم آن را چگونه تولید کند. در ضمن با استفاده  ازاسکوپ Singletone@ به Dagger می فهمانیم که همیشه یک نمونه از آن داشته باشد و هر دفعه یک نمونه جدید تولید نکند. برای مشاهده نحوه کار Scope به این مقاله مراجعه کنید.

کلاسی بعدی که به آن نیاز داریم interface ای هست که Dagger توسط آن می فهمد که کدام ماژول ها را در کجا باید تزریق کند و برای تولید کد خودکار Dagger مورد نیاز است، ولی اجازه بدهید تا این کلاس را بعد از نحوه استفاده از Dagger شرح دهم. فقط همین اندازه بدانیم که دو متد با نام دلخواه ( من نام هردو را void inject گذاشتم.) یکی با ورودی MainActivity و دیگری Motor ساختم.

@Singleton
@Component(modules = {MotorModule.class})
public interface MotorComponent {

    void inject(MainActivity activty);
    void inject(Motor moto);

}

خیلی خوب. حال همه چیز آماده است و نوبت به این می رسد که  object مورد نظرمان یعنی موتور را در کلاس تزریق و استفاده کنیم. فقط یک نکته باقی مانده است. لازم است تا Dagger کد خودکار را تولید کند و ورودی ماژول را به آن بدهیم تا کل ارتباطات کامل و تمامی آبجکت ها قابل تزریق باشد. اصطلاحاً سیم کشی یا Wiring up را تمام کنیم.  فقط توجه نمایید که برای اینکه dagger بتواند کدهای مربوطه خود را auto generate کند بعد از این بخش ( یعنی ساخت ماژول ها و کامپوننت) باید کل پروژه را Rebuild کنیم. به متد generateDaggerCode توجه نمایید:

public class MainActivity extends AppCompatActivity {

    @Inject
    public Motor motor;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        generateDaggerCode();

        createCar(motor);

    }

    private void createCar(Motor motor) {

        if (motor != null) {
            Toast.makeText(this, "car is created", Toast.LENGTH_SHORT).show();
        }

        startCar(motor);
    }

    private void startCar(Motor motor) {
        if (motor.startEngin()) {

            Toast.makeText(this, "it is started", Toast.LENGTH_SHORT).show();
            Toast.makeText(this, "motor name is:" + motor.getName(), Toast.LENGTH_SHORT).show();
        } else {
            Toast.makeText(this, "motor is not provided", Toast.LENGTH_SHORT).show();
        }
    }

    private void generateDaggerCode() {
        MotorComponent component = DaggerMotorComponent.builder().motorModule(new MotorModule
                (this, "Computer name",12, "radiator name")).build();

    component.inject(this);
    component.inject(motor);
      
    }
    
}

حال به تجزیه تحلیل کد دقت نمایید

اول از همه کد Dagger را تولید می کنیم که در ورودی آن ماژول را با ورودی آن پاس می دهیم. ( نام رادیاتور، نام کامپیوتر، ولتاژ) سپس دو متد موجود در Component را صدا می زنیم. حال ما هرجای این کد که یک موتور خواستیم کافی است آن را با Inject@ بیاوریم و خود Dagger آن را مدیریت می کند.

چند نکته و قانون وجود دارد که فهم آنها باعث می شود این پیچیدگی کم شود. اول اینکه اگر هرجایی Inject را در فیلد های یک کلاس انجام دادیم ( مثل همین جا که در MainActivity کلاس Motor را در اول کلاس تزریق کرده و سپس از آن استفاده کردیم) Dagger متوجه آن نمی شود مگر اینکه  یک متدی ( با نام دلخواه) در Component بنویسم که ورودی آن، همان کلاس استفاده کننده باشد تا Dagger بفهمد چه کلاسی در فیلد خود Inject انجام داده و بتواند کد خود را بصورت صحیح تولید کند. برای همین امر بود که در Component یک متد به نام inject ساختم که ورودی آن MainActivity بود. همانطور که ملاحظه می کنید چون خود Motor هم در داخل خودش field Injection داشت ( هم Computer و هم Radiator در خط ۴ و ۷ کلاس موتور) پس ناچاراً متدی هم برای آن در Component نوشتم تا ارتباط آنها را نیز متوجه بشود و به اصطلاح فیلداینجکشن ها را اسکن کند.

اگر برنامه را اجرا کنید Motor به درستی Inject شده و پیغام مناسب دریافت خواهید کرد و ما توانسته ایم با استفاده از Dagger2 وابستگی را به کد تزریق کنیم.

حال توجه شما را به یک پیاده سازی دیگر جلب می نمایم. در این روش برای ساخت موتور، اجزای لازم را بدون استفاده از انوتیشن Inject@ و با Constructor پاس می دهم. همانطور که در بالا گفتیم چون تزریق در فیلد انجام ندادیم پس در کامپوننت هم متد آن ( void inject(Motor moto)) را حذف می کنیم. بدین صورت:

public class Motor {

    private Computer computer;
    private Radiator radiator;
    private String name;

    public Motor(String name, Computer computer ,Radiator radiator) {
        this.name = name;
        this.computer = computer;
        this.radiator = radiator;
    }

    public boolean startEngin() {
        if (computer != null && radiator != null) {
            return true;
        } else {
            return false;
        }
    }

    public Computer getComputer() {
        return computer;
    }


    public String getName() {
        return name;
    }

    public Radiator getRadiator() {
        return radiator;
    }
}

پس Dagger می فهمد که برای ساخت موتور باید دو ورودی رادیاتور و کامپیوتر به موتور پاس دهد، از طرفی نحوه ساخت کامپیوتر و رادیاتور را می داند. پس همین کافی است که بتواند موتور را برایمان تولید کند و Component هم بصورت زیر می شود:

@Singleton
@Component(modules = {MotorModule.class})
public interface MotorComponent {

    void inject(MainActivity activty);

}

حال اگر از شما بپرسند چرا متدی قرار دادیم با نام inject که ورودی آن از جنس MainActivity است جواب دهید: بخاطر اینکه در MainActivity در فیلد Motor را تزریق کرده ایم! بله درست گفتید!

public class MainActivity extends AppCompatActivity {

    @Inject
    public Motor motor;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        generateDaggerCode();

        createCar(motor);

    }

    private void createCar(Motor motor) {

        if (motor != null) {
            Toast.makeText(this, "car is created", Toast.LENGTH_SHORT).show();
        }

        startCar(motor);
    }

    private void startCar(Motor motor) {
        if (motor.startEngin()) {

            Toast.makeText(this, "it is started", Toast.LENGTH_SHORT).show();
            Toast.makeText(this, "motor name is:" + motor.getName(), Toast.LENGTH_SHORT).show();
        } else {
            Toast.makeText(this, "motor is not provided", Toast.LENGTH_SHORT).show();
        }
    }

    private void generateDaggerCode() {
        DaggerMotorComponent.builder().motorModule(new MotorModule
                (this, "Computer name",12, "radiator name")).build().inject(this);


    }

}

همانطور که ملاحظه کردید هرجایی که بخواهیم وابستگی را تزریق کنیم باید  از Inject@ استفاده کنیم و بنابراین باید کلاسی که در آن تزریق کرده ایم را توسط متدی در Component به Dagger معرفی کنیم. به نظر می رسد که بهتر است در هنگام ایجاد و تعریف وابستگی ها (Register) تا حد امکان از Inject@ استفاده نکنیم و در صورت امکان بصورت ورودی به Constructor بدهیم. دلیل من هم این است که هم خوانایی کد بالا می رود و هم تعداد متدهای Component کمتر می شود و در هنگام Resolve از Inject@ استفاده کنیم. ( Register, Resolve, Release پترنی است که در DI Container مورد استفاده قرار می گیرد که در مقاله بعد بیشتر راجع به آن صحبت خواهم کرد. )

بسیار عالی. تا اینجا با نحوه استفاده از Dagger2 آشنا شدید و دو نمونه از پیاده سازی های آن را دیدید. Dagger2 امکانات بسیار زیاد دیگری نیز دارد که انشاء الله در آموزش بعدی به همراه برسی چند مورد نکته دیگر، به آنها پرداخته و پرونده را به کل می بندیم. در ضمن می توانید پروژه تست را از گیت دانلود کنید:

منبع: بایت کد

نوشته کار با Dagger2 به زبان ساده بخش اول اولین بار در Mahdi Tajik پدیدار شد.