Action intent

화면 위에 항상 떠있는 FAB를 만들어보도록 하겠습니다. 

www.youtube.com/watch?v=umCX1-Tq25k

* 아이콘 색 변경시 android가 아닌 app:tint="@android:color/white"를 쓰자

- to_bottom_anim.xml에서 scale(from,to)을 잡아주지 않으면 접힐때 아이콘 크기가 1로 다시 설정 됨

- 다이나믹하게 생성되는 버튼의 clickable을 설정 해주지 않으면 visibility가 false여도 클릭이 된다.

- BindingAdapter를 추가하여 isclick 변수에 따라 visibility와 clickable 설정하도록 했다.

Activity 등에 클래스 데이터를 전달하기위해 Serialization, Deserialization하는 코드로 화면 간 데이터는 최소화하여 전달하도록 권장하고 있으므로 그냥 방법만 알아두자

@Entity(tableName = "card_table")
data class Card(
        @PrimaryKey(autoGenerate = true) val id: Long?,
        @ColumnInfo(name = "card_name") val cardName: String?,
        @ColumnInfo(name = "card_number") val cardNumber: String?,
        @ColumnInfo(name = "limit_amount") val limitAmount: Long = 0,
        @ColumnInfo(name = "description") val description: String?
): Parcelable {
    constructor(name: String, number: String, limit: Long, desc: String): this(null, name, number, limit, desc)

    constructor(parcel: Parcel) : this(null, parcel.readString(), parcel.readString(), parcel.readLong(), parcel.readString())

    override fun describeContents(): Int {
        return 0
    }

    override fun writeToParcel(parcel: Parcel, flags: Int) {
        parcel.writeString(cardName)
        parcel.writeString(cardNumber)
        parcel.writeLong(limitAmount)
        parcel.writeString(description)
    }

    companion object CREATOR : Parcelable.Creator<Card> {
        override fun createFromParcel(parcel: Parcel): Card {
            return Card(parcel)
        }

        override fun newArray(size: Int): Array<Card?> {
            return arrayOfNulls(size)
        }
    }
}

위와 같이 boilerplate 코드와 override 함수들로인해 data class의 코드가 많이 복잡해지고 attribute의 non-null 속성도 보장하지 못하게 된다.

Firebase란 쉽게 클라이언트 개발자가 직접 서버를 만들필요 없도록 상용화 서버 플렛폼을 제공하는 서비스입니다. 

node.js 등으로 직접 서버를 개발하여 클라이언트의 데이터를 백업하거나 서버기반 클라이언트를 개발 할 수 있으나 특별한 기능을 요하지 않는 서버라면

Firebase로 충분히 커버가 가능합니다. 기본적으로 인증(구글 로그인 등) 그 외 사용자 로그, 분석, 서버DB, 저장소.. 기본적인 기능은 너무나 잘 구성되어 있

을뿐더러 초기 배포선에서 '무료'로 사용할 수 있다는 점이 매력적입니다. 

https://firebase.google.com/docs/android/setup?authuser=0

잘 정리되어 있는 공식 가이드를 참고합니다. 

1. 프로젝트 레벨의 build.gradle에 아래 내용을 추가합니다. 

buildscript {
    // ...
    dependencies {
        // ...
        classpath 'com.google.gms:google-services:4.2.0' // google-services plugin
    }
}

2. 앱 레벨의 build.gradle에 아래 내용을 추가합니다. 

dependencies {
  // ...
  implementation 'com.google.firebase:firebase-core:16.0.6'

  // Getting a "Could not find" error? Make sure you have
  // added the Google maven respository to your root build.gradle
}

// ADD THIS AT THE BOTTOM
apply plugin: 'com.google.gms.google-services'

3. build.gradle 오른쪽 구석에 sync버튼을 눌러 추가한 라이브러리를 다운로드 받습니다. 

개발중인 앱에 기본 Firebase SDK를 추가하였습니다. 

그럼 Firebase에 개발중인 앱을 등록하겠습니다. 

https://console.firebase.google.com/

1. Firebase 콘솔로 이동하여 '프로젝트 추가'를 합니다. 

프로젝트 이름 등 필요한 정보를 입력합니다.(패키지 이름은 개발중인 앱의 AndroidManifest.xml 에서 가져옵니다.)

google-service.json 파일을 개발중인 앱의 app폴더 아래에 넣습니다. 

SHA 인증서 지문까지 입력하고 완료합니다.(SHA는 선택적인데 입력하지 않으면 google로그인 등 인증 기능을 사용할 수 없습니다.)

* SHA 개발중인 프로젝트 마다 고유의 Signing key가 존재합니다. 

2. 생성된 프로젝트를 눌러보면 Firebase에서 지원하는 기능들이 나열된 메뉴와 현황판이 있습니다. 

앞으로 인증, Analytics등 개발중인 프로젝트에 기능을 추가하면 해당 콘솔에서 클라이언트에서 서버로 전송된 기록을 확인할 수 있습니다. 

public class MyApplication extends android.app.Application {
    public static boolean DEBUG; //현재 DEBUG 모드로 앱이 실행중인가?

    @Override
    public void onCreate() {
        super.onCreate();
    }
}

<1. Application class>

안드로이드의 Application class는 앱의 실행과 동시에 생성되는 객체로 대표적인 Singleton(앱 실행 시 오직 하나의 객체만 유지)

구조를 반영한 class 입니다. 

앱의 Main activity를 띄우기 전에 사용자 로그인 상태를 확인 한다거나 다수의 하위 객체(Activity 나 Viewmodel 등)에서 

참고할 데이터를 미리 셋팅해 두는 등 갖가지 전처리 기능을 수행 할 수 있는 class입니다. 

위 예제에서는 현재 앱이 DEBUG 모드인지 확인하는 static 변수를 가지고 있습니다. 

이는 모든 하위 객체에서 현재 DEBUG 모드로 작동중인지 확인하여 출력 log의 레벨을 결정할 수 있습니다. 

public class MainViewModel extends AndroidViewModel {
    private MyApplication myApp;
 
    public MainViewModel(Application application) {
        super(application);
        myApp = (MyApplication)getApplication();
    }
}

<2. 하위 객체에서의 사용 예>

Application을 사용하는 하위 class입니다. Activity 나 ViewModel이나 getApplication으로 언제 어디서든 Application 객체를 사용할 수 있습니다.

주의! 

찾기 쉽고 편하다고 해서 고민없이 Application class에 attribute나 method를 밀어 넣으면 앱의 실행 시간도 길어지고

앱이 종료 될 때까지 class가 메모리에 상주하고 있기 때문에 메모리 점유율도 높아집니다. 

Application에는 충분한 검토 후 코드를 추가하세요.

안드로이드 개발 기본을 떼고 본격적으로 개발을 해보려는 분들이라면 참고하실 좋은 레퍼런스가 있어 공유드립니다.

철 없던 시절 처음 안드로이드 개발을 하면서 저는 구조 따위가 뭐가 중요한가.. 나는 코딩의 신이다. 개발자는 구현만해주면 된다.라는 

우를 범하게 됩니다. 이 글을 보시는 분들은 그런 우를 범하지 마시길..

https://android.jlelse.eu/android-architecture-components-room-livedata-and-viewmodel-fca5da39e26b

MVVM 구조의 스켈레톤 예제라고 생각하시면 되겠습니다. 

아키텍쳐라는 영역이 그러하듯 위와 같은 구조는 안드로이드에서만 사용되는 것이 아닙니다. 

서버 등 다른 플렛폼에서도 개발의 효율성과 탄탄한 솔루션을 만들기위해 허들이 있더라도 당연히 적용해야 하는 부분입니다.

간단히 설명드리는 아래 내용을 참고하시고 위 예제 코드를 보시면 좀 더 이해가 쉬울 것 같습니다?

Model : 모델 레이어로 내 솔루션에서 필요한 기본 클래스 예를들어 사용자 정보, 일정 클래스 등 입니다. 이는 곧 DB의 entity로 연결됩니다. 

View : 뷰 레이어로 실제 사용자가 보게되는 화면에 대한 UI 구현입니다. 각종 위젯(버튼, 텍스트뷰 등)을 정의하는 코드들이 들어갑니다.

ViewModel : 모델과 뷰를 연결해주는 레이어입니다. 아키텍쳐의 기둥이 되는 부분으로 DB에서 Model을 꺼내와 가공 후 View레이어로 전달합니다.

하나의 View에는 하나의 ViewModel이 존재합니다.(Bind) 하나의 ViewModel은 여러 Model을 필요로 할 수 있습니다. 

예를들어 일정관리 솔루션에서 사용자에게 저장된 일정을 보여주고자 한다면 View는 ViewModel에 기 입력된 오늘 일정을 요청합니다. 

ViewModel은 DB에 오늘 일정 데이터 좀 꺼내달라고 요청합니다. Model은 오늘의 일정 객체들을 ViewModel에 리턴하고 ViewModel은 

만약 특정 일정을 상단에 보여줘야 한다는 요구사항이 있다면 오늘의 일정 리스트를 다시 정렬해서 View로 전달하게 됩니다. 

그럼 View는 ViewModel에서 전달 받은 리스트를 그대로 뿌려주기만 하면 됩니다. 

한마디로 출력 전 데이터를 가지고 특별한 연산이 필요한 부분은 ViewModel이 전담하게 됩니다.

모든 아키텍쳐 가이드의 시작과 모든 아키텍쳐 교수님들도 첫강의에 말씀 하시듯이 이로인해 View 코드가 간결해지고 

개발 시 UI개발자 등 각 레이어 담당의 역할 분담이 확실해지며 단위 테스트를 하기 용이해집니다.

예제 코드에서 나오는 LiveData나 Room등은 다른 포스팅을 통해 설명 드리도록 하겠습니다. 

이해가 잘 안되더라도 꼭 이해를 하시고 개발하시면서 적용해보세요.

개발을 하다보면 로컬데이터(preference, DB 등)를 초기화 해야 하는 일이 자주 있습니다. 

그럴때마다 단말의 '설정 -> 애플리케이션 -> 패키지선택 -> 데이터 삭제'를 하는 일은 너무 번거롭죠.

ADB 커맨드 하나면 한번에 패키지의 로컬 데이터를 날려줍니다. 

adb shell pm clear [패키지 이름 ex) com.android...]

개꿀..