2015. 5. 19. 04:03


오늘은 코드보다는 안드로이드 스튜디오에서 사용할 수 있는 유용한 plugin을 하나 소개하려고 한다. 예전에 안드로이드 라이브러리중 ButterKnife를 소개한 적이 있다. 오늘 소개할 plugin은 ButterKnife 라이브러리 사용시 같이 사용하면 코딩을 '두배'는 더 쉽고 편하게 하도록 도와준다. plugin의 이름은 'Android ButterKnife Zelezny'이다.


우선 플러그인을 다운 받기 위해서는, File -> Setting -> plugins 를 선택해도 되고 그냥 shift키를 두번누른 후 검색어에 'plugins'를 입력하면 아랫부분에 선택할 수 있다.plugins를 선택하면 아래와 같은 화면이 나온다.



이 화면에서는 검색해도 나오지 않고 아래쪽에 보이는 버튼 중 가운데 버튼인 'Browse repositories..'를 선택해야 한다.



선택하게되면 위와같은 화면이 나오는데 이때 검색 창에 'ButterKnife'를 입력하면 제일 위에 'Android ButterKnife Zelezny'가 뜨는 것을 확인할 수 있다. 초록색 Install plugin 버튼을 누르고 안드로이드 스튜디오를 재시작 하면 설치과정은 쉽게 끝이난다. 사용법도 간편하다.



위와 같이 레이아웃을 set해줄때, 해당레이아웃에 커서를 옮긴후 generate을 실행시켜주면 된다.(윈도우에서는 alt+insert, 맥에서는 command + n) 그러면 생성할 수 있는 여러 함수들 리스트가 나오는데 그중에 'generate butterKnife injection..'을 선택하면 된다.(버터나이프 마스코트가 왼편에 있다) 



그럼 위와 같은 화면이 뜨고 확인을 누르면,



ButterKnife를 통해 내가 레이아웃에 생성해둔 뷰들이 한번에 inject되는것을 볼 수 있다.


알아둘 점은 레이아웃에 생성한 모든 뷰를 inject하는 것이 아니라 그 중 id값을 추가해 준 뷰들만 inject한다. 또한 adapter에서 레이아웃을 inflate할때, 아래쪽에 있는 'create ViewHolder' 에 체크하면 ViewHolder Pattern에 사용하는 ViewHolder도 한번에 만들어 준다. 꼭 사용해서 조금 더 편한 코딩을 하길 바란다.

Posted by 미뤽
2015. 1. 27. 01:20




[Android pattern 02] 에서의 안정성과 [Android pattern 03] 에서의 가독성을 결합한 새로운 대안이 바로 빌더 패턴이다. 필수 인자를 포함한 빌더객체를 생성하고 선택인자들을 빌더객체에 추가완료한 후에 빌더객체를 통해 원하는 생성자의 객체를 생성한다. 이렇게 하여 만든 생성자의 객체는 변경 불가능(immutable) 객체이다. 설명만 들어서는 이해하기 힘드니 코드를 살펴보자.


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
public class NutritionFacts {
    private final int servingSize;                    // 필수
    private final int servings;                         // 필수
    private final int calories;                          // 선택
    private final int fat;                                  // 선택
    private final int sodium;                           // 선택
    private final int carbohydrate;                 // 선택
 
    public static class Builder {
        //    필수 인자
        private final int servingSize;
        private final int servings;    
        //    선택적 인자
        private int calories = 0;                    //기본값으로 초기화
        private int fat = 0;    
        private int sodium = 0;
        private int carbohydrate = 0;
 
        public Builder ( int servingSize, int servings ) {
            this.servingSize = servingSize;
            this.servings = servings;
        }
 
        public Builder calories( int val ) { 
            calories = val;
            return this;
        }
 
        public Builder fat( int val ) { 
            fat = val;
            return this;
        }
 
        public Builder sodium( int val ) { 
            sodium = val;
            return this;
        }
 
        public Builder carbohydrate( int val ) { 
            carbohydrate = val;
            return this;
        }
 
        public NutritionFacts build() {
            return new NutritionFacts( this );
        }
    }
 
    private NutritionFacts( Builder builder ) { 
        servingSize = builder.servingSize;
        servings = builder.servings;
        calories = builder.calories;
        fat = builder.fat;
        sodium = builder.sodium;
        carbohydrate = builder.carbohydrate;
    }
}
cs


NutritionFacts  의 객체는 변경불가능 하고 빌더에 정의되어 있는 setter 메소드들은 빌더 객체 자신을 반환하므로, 설정메소드를 호출하는 코드는 죽 이어서 쓸 수 있다.


1
2
3
4
5
6
7
8
 
NutritionFacts cocaCola = 
        new NutritionFacts().Builder( 2408)
                        .calories( 100 )
                        .sodium ( 35 )
                        .carbohydrate( 27 )
                        .build();
 
cs


빌더패턴은 코드의 가독성도 뛰어나고 사용하기도 쉽다.다만 코드 사용량이 점층적 생성자 패턴 등보다는 많으므로 인자가 충분히 많은 상황에서 이용해야하는게 옳다. 물론 새로운 인자가 추가될 수도 있다는 것을 고려해서 사용하는 방법도 괜찮다.


<참고서적 : Effective Java 2/E>

Posted by 미뤽
2015. 1. 26. 22:19



생성자에 전달하는 인자수가 많은 때 점층적 생성자 패턴과 함께 적용가능한 두번째 패턴은 자바빈 패턴이다.인자가 없는 생성자를 통해 객체를 만든 후, 설정 메서드들을 호출하여 필수, 선택 필드들을 채우는 방법이다.


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
public class NutritionFacts {
    private int servingSize = -1;              // 필수
    private int servings = -1;                   // 필수
    private int calories = 0;                     // 선택
    private int fat = 0;                             // 선택
    private int sodium = 0;                      // 선택
    private int carbohydrate = 0;             // 선택
 
    public NutritionFacts() { }
 
    //    setter
    public void setServingSize( int val ) { servingSize = val; }
    public void setServings( int val ) { servings = val; }
    public void setCalories( int val ) { calories = val; }
    public void setFat( int val ) { fat = val; }
    public void setSodium( int val ) { sodium = val; }
    public void setCarbohydrate( int val ) { carbohydrate = val; }
}
cs



위 코드를 통해 생성자 객체를 생성하고 인자를 넣는 방법은


1
2
3
4
5
6
NutritionFacts cocaCola = new NutritionFacts();
cocaCola.setServingSize( 240 );
cocaCola.setServings( 8 );
cocaCola.setCalories( 100 );
cocaCola.setSodium( 35 );
cocaCola.setCarbohydrate( 27 );
cs


이 패턴은 점층적 생성자 패턴과는 다르게 읽기도 쉽고 생성하기도 좋다. 하지만 이 패턴에는 두가지 심각한 단점이 있는데, 첫번째는 1회의 함수 호출로 객체 생성을 끝낼 수 없으므로, 객체 일관성(consistency)이 일시적으로 깨질 수 있다는 점이고 두번재는 자바빈 패턴으로는 변경 불가능(immutable)클래스를 만들 수 없다는 것이다.


<참고서적 : Effective Java 2/E>


Posted by 미뤽
2015. 1. 25. 20:26




카메라를 사용하는 어플을 만들어서 문제 없이 사용하고 있었는데 일부폰에서 카메라를 찍고 돌아왔을때 앱이 죽는 현상이 있었다. 특정 회사, 특정 폰에서 나타나는 현상이었는데 아무리 구글링을 해도 원인을 찾을 수가 없었다. 해결방법은 간단했다.


1
android:configChanges="orientation|screenSize"
cs


위 코드를 AndroidManifest.xml내에서 해당 activity에 추가해주면 된다. 어플리케이션에서 configuration이 바뀌는 경우가 있는데 (언어, 레이아웃방향, 사이즈, 글씨 크기 등등) 그때마다 핸드폰은 해당 activity를 다시 실행한다. 위 코드는 레이아웃 방향의 변화는 스크린 사이즈가 변화가 있어도 activity를 다시 실행하는(다시 그리는) 동작을 하지 말라는 코드다.


원인은 일부 폰에서 카메라 기능을 사용할 때의 레이아웃방향과 내가 만든 어플의 레이아웃방향이 다를때 일어나는 현상이었다. 보통은 카메라 기능을 사용하고 돌아왔을때 결과값만을 가지고 오기때문에 문제가 되지 않지만 일부폰에서는 그때 사용한 레이아웃방향까지 인식하여 자체적으로 configuration change가 일어난 상황으로 인식해 해당 activity를 재실행하다가 생기는 버그였다.(null 포인트가 잡힌다.) 위의 코드를 추가해주면 activity의 재실행을 막아주므로 해당 버그를 막을 수 있다.

Posted by 미뤽
2015. 1. 17. 21:56




 저번 글에서 ViewHolder에 대해서 구글링 하던중 흥미로운 글들을 몇개 발견해서 ViewHolder 2탄을 준비했다. 2탄의 주제는 'ViewHolder보다 더 효과적인 방법' 이다. 세가지 방법에 대해서 살펴볼 생각인데 '사실 확실히 좋다!'는 확신은 없다는 점을 알아주었으면 한다. ViewHolder패턴이 좋다고 생각한 이유도 기실 'findViewById()가 상당히 부담이 되는 작업이다' 라고 전문가가 말한것을 그대로 수용했기 때문이지 내가 이해했던 것이 아니기 때문이다.(그정도의 깊이가 아직은 없다. 아직은) 그럼 하나씩 살펴보도록 하겠다.


관련 글 링크 : http://www.kmshack.kr/android-%EC%9C%A0%EC%97%B0%EC%84%B1-%EC%9E%88%EB%8A%94-viewholder-pattern/


위 글에서 말하는 첫번째 방법은 ViewHolder에 유연성 있는 코딩을 말한다. 기존 ViewHolder패턴에서는 static class로 만들고 해당 아이템(ListView의 한 줄 )에서 사용할 View들을 ViewHolder의 멤버변수로 저장한다. 이렇게 되면 여러아이템이 다른 View들을 가지고 있다면 여러개의 ViewHolder를 만들어야하므로 이럴때 사용할 수 있는 유연성있는 ViewHolder가 필요하다는 말이다.(이런 경우가 많지는 않을거 같지만.) 방법을 살펴보면,


1
2
3
4
5
6
7
8
9
10
11
12
13
14
public static class ViewHolder {
    public static <T extends View> T get( View view , int id ) {
        SparseArray<View> viewHolder = ( SparseArray<View> ) view.getTag();
        if( viewHolder == null) {
            viewHolder = new SparseArray<View>();
            view.setTag( viewHolder );
        }
        View childView = viewHolder.get( id );
        if ( childView == null ) {
            childView = view.findViewById( id );
            viewHolder.put( id, childView );
        }
        return (  T ) childView;
}
cs


위 코드에서 보다시피 더이상 ViewHolder에 맴버변수가 없다. 대신 ViewHolder class내부에 viewHolder SparseArray에 사용할 뷰들을 넣고 나중에 해당 뷰들을 꺼내 쓴다. getView()에서 사용방법은 아래코드와 같다.


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
@Override
public View getView( int position, View convertView, ViewGroup parent ) {
    if ( convertView == null ) {
        convertView = LayoutInflater.from( context ).inflate( R.layout.list_item,
             parent, false );
    }
    ImageView imageView = ViewHolder.get( convertView, R.id.imageview );
    TextView textView = ViewHolder.get( convertView, R.id.textview );
 
    ListItem item = getItem( position );
    
    imageView.setImageResource( item.getImage() );
    textView.setTet( item.getText() ) ;
 
    return convertView;
}
cs





관련글 링크 : http://www.jayway.com/2013/11/06/viewholder-vs-holderview/


두번째 글에서 말하는 방법은, ListView의 각각의 Item에서 하는일을 그 뷰가 알아서 하도록 하는 방법이다. 성능적인 면에서의 차이는 잘 모르겠지만 ListItem에 사용할 각각의 Item들을 Adapter의 getView() 메소드에서 선언, 처리 하던 방식을 사용하지 않고, Adapter에서는 기존처럼 findViewById()의 사용만 피하면서 해당 아이템의 holderViewclass 객체를 불러오면 View의 선언이나 사용은 전부 holderView클래스 내부에서 처리하는 방법이다. 사용법을 살펴보자.


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
@Override
public View getView(int i, View convertView, ViewGroup viewGroup) {
    HolderView holderView;
    // Important to not just null check, but rather to a instanceof
    // since we might get any subclass of view here.
    if (convertView instanceof HolderView) {
        holderView = (HolderView) convertView;
    } else {
        holderView = new HolderView(mContext);
    }
    holderView.bind(new Digit(i));
 
    return holderView;
}
cs


Adapter내의 getView()메소드는 정말 간단하다. holderView객체를 찾거나 생성한후 데이터를 보낸다. 객체 내부를 살펴보면


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
public class HolderView extends GridLayout {
 
    private TextView mDigitDigit;
    private String mDigitText;
 
    public HolderView(Context context, AttributeSet attrs) {
        super(context, attrs);
        View v = LayoutInflater.from(context).inflate(R.layout.list_detail, this);
        mDigitDigit = (TextView) v.findViewById(R.id.list_detail_digit);
        mDigitText = context.getResources().getString(R.string.list_detail_digit);
    }
 
    public void bind(Digit digit) {
        mDigitDigit.setText(String.format(mDigitText, digit));
    }
}
cs


객체가 생성되는 순가 해당아이템에서 사용할 View들을 찾아 연결해주고 bind()메소드를 통해서 들어오는 값을 HolderView내부의 View와 연결해서 Ui에 나타낸다. 직관적인 코드라서 관리가 더 용이하고 코드를 이해하기도 좋다고 한다(?)




관련글 링크 : http://www.slideshare.net/bs_yagi/potato01-no-more-viewholder


위 링크에서 소개하는 마지막 방법은 두번째 방법과 흡사하다. Adapter내부에서 하던 View를 연결하는 작업을 ViewHolder내부에서 객체 생성시에 한다. 비슷한 방법이지만 소개하는 이유는 몇몇 특징 때문인데 한번 살펴보면


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
public class ViewHolder {
    public final ImageView thumbImage;
    public final TextView titleText;
    public final TextView readText;
    public final TextView userText;
    public final View root;
 
    public ViewHolder( View root ) {
        thumbImage = ( ImageView ) root.findViewById( R.id.thumb_image ) ;
        titleText = ( ImageView ) root.findViewById( R.id.title_text ) ;
        readText = ( ImageView ) root.findViewById( R.id.read_text ) ;
        userText = ( ImageView ) root.findViewById( R.id.user_text ) ;
        this.root = root;
    }
}
cs


1
2
3
4
5
6
7
8
@Override
public View getView( int position, View convertView, ViewGroup parent ) {
    if ( convertView == null ) {
        convertView = LayoutInflater.inflate(R.layout.list_view_item, null );
        ViewHolder holder = new ViewHolder ( convertView );
        convertView.setTag( holder );
    }
}
cs


코드를 보면 다른 코드들과는 다른 2가지를 볼 수 있는데 첫번째가 ViewHolder class가 static class가 아니라는 점과 멤버변수들을 final로 선언했다는 점이다. 기존 사용법에서 ViewHolder를 static으로 선언한 이유는 enclosing instance에 연결되는 경우를 막기위해서 인데 내부클래스로 ViewHolder를 하면 enclosing instance에러는 나지 않는다. 두번째 다른점인 final로 선언한 이유는 사실 아직 정확히 이해하지 못했다...(해당사이트 내용들이 일본말인것도 한 이유...) 우선 final에 대해서 다시 한번 처음부터 공부해봐야겠다.

Posted by 미뤽
2015. 1. 13. 00:15

안드로이드 앱을 개발하다보면 다중언어(로컬라이징)를 지원해야 하는 경우가 있다. 그럴경우 안드로이드에서 지원하는 방식으로 resource폴더를 관리하면 예상외로 쉽게 개발할 수 있다. (res/values-ja, res/values-en, res/drawable-ko 등등 )


일단 이렇게 개발하고 나면 앱이 실행될때에 핸드폰의 언어설정에 따른 resource를 자동으로 앱이 파악한 후 적용하게 된다.


하지만 만약 내가 개발하고 있는 앱 내부에서 언어를 바꾸고자 할때(예를 들면 앱 내에 있는 설정부분에서) 굳이 핸드폰 자체의 언어설정을 가지 않고 동적으로 바꿔줄 수 있는 방법이 있었다.


1
2
3
4
5
6
7
 
public void changeConfigulation() {
    Locale mLocale = new Locale("language_code")
    Configuration config = new Configuration();
    config.locale = mLocale;
    getResources().updateConfiguration(config, null);
}
cs



위의 코드에서 new Locale("language_code")의 "language_code"에 내가 바꾸고자 하는 나라의 언어코드를 넣으면 적용이 된다. 

Posted by 미뤽