Realm Blog

안드로이드 Realm 설치: 왜 Gradle 플러그인으로 바뀌나요?

Realm의 제약사항

올해 우리는 안드로이드용 Realm을 발표했고 여러 제약에도 불구하고 많은분들이 좋아해주시고 사용하고 계십니다. 많은 피드백 중에 우리는 RealmObject 객체의 상속을 요구하는 것에 대해 많은 불평을 들었는데 이 상속은 아래 제약을 가져옵니다.

  • 퍼블릭 필드는 안됩니다
  • 표준적인 접근자 이름만 허용됩니다
  • 접근자에 로직 추가를 할수 없습니다.
  • 커스텀 메서드도 안됩니다
  • 인터페이스의 구현도 안됩니다

이런 제약들은 공통의 이유가 있습니다. Realm은 하부의 데이터 저장소에서 복제없이 운영하기 위해 프록시 클래스를 사용합니다. 이 제약들을 하나씩 살펴봅시다.

퍼블릭 필드는 안됩니다

자바는 프록시가 필드에 접근하는 것을 허용하지 않습니다. 그래서 Realm 프록시 객체는 이런 필드를 접근할 때 가로챌 수 없습니다. 또 필드는 자바 힙 영역에 정의됩니다. 이것은 Realm에서 Java 메모리로 데이터가 복제되어야 한다는 이야기입니다. 이것은 복제하지 않는 정책에 반하게 됩니다.

표준적인 접근자 이름만 허용됩니다

어노테이션 프로세서는 아주 강력한 도구이지만 몇몇의 제약이 있습니다. 한가지 제약은 프록시될 클래스의 실제 코드를 보는게 불가능하다는 점입니다. 어노테이션 프로세서는 필드와 메서드 이름만 접근할 수 있습니다. 이것은 우리가 예상대로 행동하는 Realm 프록시 객체를 관례대로 만들고 그것에 의존하게 합니다.

접근자에 로직 추가를 할수 없습니다.

이전 제약의 직접적으로 이어집니다. 접근자의 구현에 어노테이션 프로세서가 직접적으로 접근할 수 있는게 없기 때문에 프록시 클래스의 어떤 로직을 복제하는게 불가능합니다. 물론 우리가 단순히 super.getMyField();를 호출할 순 있습니다 하지만 이렇게 하면 프록시 클래스를 이용하지 않고 메모리 내 데이터를 다루게 됩니다.

커스텀 메서드도 안됩니다

다시 말하지만 어노테이션 프로세서가 코드를 볼 수 없기 때문에 커스텀 메서드가 실제로 무엇을 할지 짐작할 수 없습니다. 이런 이유로 Realm은 정확함을 보증하기 위해 이런 메서드를 허용할 수 없습니다.

인터페이스의 구현도 안됩니다

커스텀 메서드가 허용되지 않기 때문에 메서드의 구현을 요구하는 인터페이스를 사용하는 것 역시 허용되지 않습니다.

그래서 이건 고칠 것인가요?

이런 제약을 넘어설 한가지 방법은 바이트코드를 조작하는 것입니다. 이는 컴파일이 끝난 다음에 .class 파일들에 대해 어떤 변경을 한다는 것을 의미합니다. 이러한 조작에 대한 상세한 이야기는 앞으로의 블로그 글에서 다루겠습니다. 여기에서 다룰 중요한 점은 깔끔하게 바이트 코드 조작을 그래들 빌드에서 할 유일한 방법은 플러그인을 쓰는 것이라는 점입니다. 인기있는 라이브러리들 레트로람다휴고가 실제로 이렇게 하고 있습니다. 그리고 우리도 그 중 하나입니다.

우리의 build.gradle 파일

지금까지 Realm을 설치하는 방법은 다음과 같습니다.

repositories {
    jcenter()
}

dependencies {
    compile 'io.realm:realm-android:<version>'
}

그래들 플러그인을 쓰면 다음과 같아집니다.

buildscript {
    repositories {
        jcenter()
    }
    dependencies {
        classpath "io.realm:realm-gradle-plugin:<version>"
    }
}

apply plugin: 'realm-android'

첫번째 코드가 이미 build.gradle 파일에 있다면 다음으로 해야할 일은 classpathapply plugin: 'realm-android'로 시작하는 코드로 바꾸어 주세요.

왜 이렇게 하나요?

우리가 바이트코드 조작 버전을 릴리즈하기 전인 지금 플러그인을 제공하는 이유가 있을까요? 실제로 아래의 이유가 있습니다.

작아진 APK

플러그인을 이용하면서 Realm을 JAR 대신에 AAR로 배포하는게 가능해졌습니다. 우리는 어노테이션 프로세서를 라이브러리에 포함하지 않고 일반적인 패키지로 만들 수 있었습니다. 이는 최종 APK는 어노테이션 프로세서를 가지고 있지 않고 수 킬로바이트를 앱에서 절약할 수 있다는 이야기입니다.

쉬운 ABI 분할!

AAR로 배포하면서 얻은 다음 장점은 이전 블로그 글에서 설명한 것과 같은 우회방법을 쓸 필요없이 깔끔하게 ABI 분리를 할 수 있는 점입니다. 이는 모든 CPU 아키텍쳐를 위한 네이티브 라이브러리를 하나의 APK에 포함할 필요가 없다는 이야기입니다.

이클립스는 어떻게 하나요?

이미 알고 있는 바와 같이, 구글은 이클립스를 위한 ADT를 폐기하였고 올해 말에는 지원을 중단합니다. 우리가 말할 수 있는 것은 대부분의 주요 안드로이드 개발자들은 안드로이드 스튜디오로 전환하였고 우리의 노력도 거기에 초점을 맞추고 있다는 부분입니다. 우리는 여러분의 피드백에 맞추어 우선순위를 정하고 있고 만약 충분히 많은 사람들이 Ant나 Maven 플러그인을 요청한다면 작성할 수도 있을 겁니다.

행복한 코딩을 합시다!

우리는 이 변경점이 여러분에게 유용하길 기대하고 있습니다! 언제든지 저희 한국 Realm 팀에 연락주세요. [email protected]로 한국어 메일 주시거나 Realm 한국 페이스북 페이지, Realm 한국 페이스북 그룹 스택오버플로우, 깃헙, 한국어 트위터에 있습니다.


Realm Team

Realm의 미션은 더 나은 앱을 빠르게 개발할 수 있도록 돕는 것입니다. 이를 위해 저희는 개발자들이 실시간 협업, 가상 현실, 라이브 데이터 동기화, 오프라인 경험, 메시징 등 정교하고 강력한 기능을 쉽게 개발할 수 있도록 하는 개발 도구와 플랫폼을 제공하고 있습니다.

저희는 모바일 인터넷이 수많은 사용자와 보다 많은 디바이스가 속한 개방형 네트워크와 이들 간의 실시간 상호 작용으로 진화할 것이라고 믿으며, 개발자가 이같은 방향으로 발전할 수 있도록 돕기 위해 저희 제품들을 개발하고 있습니다.

이런 개발 뉴스를 더 만나보세요