Butter Knife: ease to bind view in activity

ButterKnife is an open source that eases the way to bind view in activity class.

Below is the example:

1. In build gradle,
          
 compile 'com.jakewharton:butterknife:8.5.1' 
 annotationProcessor 'com.jakewharton:butterknife-compiler:8.5.1'

2. Suppose there are two buttons having id - android:id="@+id/hiBtn" android:id="@+id/byeBtn"

3. In activity .java class,

    a. Initialize your binding button variable as-


      @BindView(R.id.hiBtn)
      Button hiBtn;

      @BindView(R.id.byeBtn)
      Button byeBtn;


    b.

        For Activity class, in onCreate() method,


       ButterKnife.bind(this);

        For Fragment class, in onCreateView() method





       View view = inflater.inflate(R.layout.fancy_fragment, container, false);
       ButterKnife.bind(this, view);


   c.  And the button click event as,


      @OnClick(R.id.hiBtn)
      public void sayHi(Button hiBtn) {
         hiBtn.setText("Hello!");
      }

      @OnClick(R.id.byeBtn)
      public void sayBye(Button byeBtn) {
         byeBtn.setText("Bye!");
      }



Butter Knife comes with the flexibility to bind color, drawable, etc. using annotation like @BindColor, @BindDrawable.





Also, in case there are buttons having same functionality, ButterKnife provides @OnClick annotation for them as below:


@OnClick( {R.id.buttonOne, R.id.buttonTwo, R.id.buttonThree, R.id.buttonFour,
        R.id.buttonFive, R.id.buttonSix, R.id.buttonSeven, R.id.buttonEight, R.id.buttonNine})
public void buttonClicked(Button button) {
  }







































Comments











Post a Comment



















Popular posts from this blog









@Overrride annotation introduced in Java1.5 





















 Whenever we have a subclass that implements parent method it is marked with annotation as @Override. This is to make compiler know that the child overrides the method defined or declared in parent.   If @Overrride annotation is commented, the subclass will work as it was.  But if in future, the signature of parent class changes, the compiler wont ask to implement the method instead it will think subclass has overloaded the method present in base class.   If you uncomment @Override annotation, the compiler will throw compile time error as method signature in parent class has changed.   Annotation should be used as standard as-    It ensures that for any change in method signature of parent class, compiler will ask to change it for the subclasses.     Also it is better to resolve issue in compile time rather than runtime    








Read more










Open-Closed Principle





















  'A class should be open for extension closed for modification.'    The above principle explains that a class once defined should not be changed(closed for modification). This is because it may impact other parts of application.  Hence, if modification is needed, that class behaviour should be extended and modification should be done. (open for extension)   Consider a scenario where area of a shape(like rectangle, square, circle) is calculated within Main class. Now addition of any new shape will lead to change in Main class. This concludes that the Shape is tightly coupled with Main class.   In order to avoid this Shape should be inherited by diff Shape classes like Rect, Triangle, Circle implementing the behaviour of calculating area() and Main class should be loosely coupled by using Shape.area() (as Triangle, Rectangle are Shape).  Hence, Shape interface is contract between its concrete classes and Main class. This allows us to add new shape class without any impact on exi...








Read more










S.O.L.I.D. Class Design Principles 





















      Abbreviation    Full Form    Definition    Reason      S   Single Responsibility Principle  A class should have only one reason to change i.e. should have only one purpose to serve.   - loosely coupled  - less change lead to less break down of application  - helps to change identity of object without affecting other modules        O   Open-Closed Principle  A class should be open for extension closed for modification.  - Anyone need to make change in your class has to inherit the class and change. This allows the existing functionality to stay intact.     L   Liskov Substitution Principle  Derived types should always be substitutable by its parent class (base type).  Derived types should be compatible with its base type.  For e.g.: Square is a Rectangle i.e. Square represents a Rectangle.  In case, if we try to set dimension of a Rectangle reference pointing to Square instance, the flow will be weird as it will always override the dimension of rectangle.     I   Interface Seg...








Read more