ReactNative: onHost 생명주기 메소드가 없을 때



(글 작성한 시점의 최신 ReactNative ver: 0.40)


기존 Android 네이티브 앱에 ReactNative를 이식하기 위해서 ReactNative 공식 doc에서 가이드해주는 Integration With Existing Apps를 따라하고 있었다.



 1. 이슈 내용

하라는대로 제대로 잘 따라한 것 같은데, 일단 첫번째 문제는 doc에서 사용하라는 onHost... 로 시작하는 생명주기 메소드들을 찾을 수가 없었다. (아래 스크린샷의 메소드)



일단 뭐 대충 보니 메소드 이름과 파라미터들은 달랐지만 onPause(), onResume(), onDestroy() 라는 메소드들이 있어서 '뭐 아직 문서가 업데이트 되지 않았나보다' 하고 대수롭지 않게 넘기고 onPause(), onResume(), onDestroy() 메소드들을 사용했다.


그러고나서 빌드하니 발생하는 RuntimeException:
IllegalAccessError??



2. 이슈 원인

 일단 원인은 프로젝트 루트의 build.gradle 에서 maven 코드 블럭 추가시 잘못된 경로를 추가한 문제였다.


doc에 나오는 정확히 $rootDir/../node_modules/react-native/android 이 부분이다.

일반적으로 이 doc 문서를 보면서 차근차근 따라했다면, 프로젝트 루트안에 node_modules 폴더가 만들어졌으므로 node_modules 폴더가 저 경로 안에 위치할리가 없다.



3. 해결방법

해당 url을 $rootDir/node_modules/react-native/android 로 수정하면 앞에서 언급한 onHostPause(), onHostResume(), onHostDestroy() 메소드들을 사용할 수도 있고 RuntimeException도 당연히 해결할 수 있다. (또한 같은 이름의 class라 몰랐겠지만, 잘못 import 되었던 LifecycleState 클래스도 제대로 된 경로의 클래스를 import 될 것이다.)

댓글

댓글 쓰기

이 블로그의 인기 게시물

5년차의 슬럼프

이미지
2-3년 전까지만해도 꿈을 이뤘다고 생각했다. 매 해 더 어렵고 까다로운 일들을 맡게되고, 또 그것을 잘 해내면서 인정을 받을 때 마다 내가 성장하고 있다고 믿었다. 내가 성장할 때마다 인정을 받았고, 인정 받을 때마다 난 성장했다. 쌓이는 신뢰도와 높은 인사평가의 점수가 곧 나의 자질이며 실력이라고도 생각했다. 내 목표의식은 항상 successful result에 있었기 때문에 그에 따르는 성취감과 업무 만족도는 비례했으며, 따라서 회사의 발전이 곧 나의 발전이었다. 덕분에 프로젝트들을 주도할 기회가 점차 많이 주어지게 되었고, 그 과정 속에서 솔직히 만족스러웠다기보단 회사의 비전을 고민하게 되는 계기가 되었다. 두세개의 프로젝트를 병행하면서도 나은 결과를 위해 신체적으로나 심리적으로 많이 무리했었고, 물리적으로 불가능한 일정을 해보겠다고 사무실에 남아 새벽까지 일하다보면 어떤 날들에는 막역한 부담감이 너무 무거워 하염없이 눈물이 나기도 했다. 같이 일하는 팀원들은 다들 이미 힘들고 지친 나머지 프로젝트의 완성도를 높이는 작업에는 여력이 없는 모습들을 보며, 나도 점차 지쳐갔다. 내 열성을 다른 사람에게까지 강요할 수는 없는 노릇이었으니까. 개발 과정에서 아무리 time complexity와 design에 대해서 이야기해도, 반론을 제기하며 논쟁 했던 사람이 없다. 심지어 이미 개발을 다 끝낸 코드에 이슈를 제기했을 때도 상대방은 바로 수긍하며 다시 짜겠다고했다. 이상하게도 그 모습을 보며 화가 났다. 고민하지 않고 작성한 덕분에 쉽게 지워버릴 수 있는, 자존감이 없는 코드에 화가 났고, 그렇게 짜올 동안 누가 지적 한번 해준 적 없다는 상황이 화가 났다. 무엇보다 더 나은 방법이 있는지 찾아보지 않고 내 말 곧이 곧대로 수정하는 모습이 결국 등을 돌리는 계기가 되었다. 내게 필요했던건 워라밸도, 높은 연봉도 아니라 최소한 나와 비슷한 열정을 가진 사람들이었다. 내가 더 이상 이 회사에 남아 있어야 할 이유가 없었다. 남아서 더 배워야할 우리...
자세한 내용 보기

멀티 스레딩 환경에서의 Singleton 사용 및 견고한 Singleton 구현 방법 (Enum Singleton)

이미지
Singleton? Singleton pattern은 특정 인스턴스에 대하여 단일 인스턴스만 만들어질 수 있도록 제한하는 패턴이다. 스레드 풀이나 캐시, 네트워크 모듈 등등에서 같은 객체를 여러개 만드는 것은 불필요한 자원을 할당하며 예기치 않은 오류를 불러올 수 있는데, 이런 상황에서 singleton을 사용하여 하나의 인스턴스만을 생성하여 사용하도록 관리를 해주면 불필요한 메모리 낭비를 줄일 수 있고 사용성 측면에서도 효율적이라 자주 쓰이는 패턴중에 하나이다. 자주 사용하던 방식은 이런 방식이다. 이렇게 되면 생성자가 private이라 무조건  getInstance() 를 통해서만 인스턴스에 접근할 수 있기 때문에  mInstance == null 인 최초 상황에서만 초기화가 되며 그 이후에는 생성된 기존의 인스턴스를 사용하게 된다. 그러나 과연 'Singleton'을 보장할 수 있을까? 일단 기본적으로 Android는 멀티 스레딩 환경이다. 만약 A thread와 B thread에서 동시에 이 인스턴스에 접근하려고할 때 마침 mInstance 가 null이였다면, A thread에서도  mInstance == null 를 타기 때문에  mInstance 를 새로 할당할거고 B thread에서도  mInstance == null 를 타며 새로 할당하게 될 것이다. 그렇게 되면 예상했던 것과는 달리 mInstance 가 2개 이상의 중복 생성이 되며 예상하지 못한 오류를 만들어낼 수도 있다. 일단 해결책으로, Main thread에서만 접근하도록 제어할 수도 있을 것이다. 다른 스레드에서 접근하면 Exception을 날린다던가 하는 식으로 예외처리를 할 수 있지만, 만약 이 singleton 객체가 꼭 멀티 스레딩 환경에서도 사용가능하게끔 해야 한다면?? 그래서 나온 해결책이  getInstance() 를  synchronized ...
자세한 내용 보기

RxAndroid: 비동기 및 이벤트 기반 프로그래밍을 위한 라이브러리

이미지
RxAndroid: 비동기 및 이벤트 기반 프로그래밍을 위한 라이브러리 from Stella Kim 2017년 1월 24일, 사내에서 진행한 RxAndroid 주제의 세미나 발표 자료이다. ReactiveX를 알게 되고 RxJava를 공부하며, 다음으로 착수하게 될 프로젝트에 RxJava를 도입하기로 결심을 했다. 같이 프로젝트 개발을 진행할 개발자들과 PL, PM에게는 간략한 기술검토 내용을 설명하여 설득을 했지만, 단순히 특정 프로젝트에 그치는 것이 아니라 향후에도 Rx 개념을 지속적으로 사용하고 싶었다. 또한 내가 투입되지 않는 프로젝트에서도 Rx를 사용하기를 원했다. 그렇게 되기 위해서는 최소 사내 개발자들은 Rx의 개념을 알고 사용법을 알아야하는데, 사실 누군가가(심지어 말단사원이) 제안했다고해서 가뜩이나 바쁜 연구원들이 바로 Rx를 공부하며 실무에 적용해볼리가 만무했다. 사내에는 2-3명 정도가 Rx에 대해 관심을 가지고 공부했을 뿐, 그 외에는 모두 Rx에 대해 잠시 들어만 봤거나 아예 모르는 연구원들이 대다수였다. 어떻게 해야 타 연구원들이 Rx에 대해 관심을 가지고 공부를 할 수 있을까 생각하다가, 최소한 'Rx가 뭔지 들어는 개발자'로 만들기 위해 아예 전사 세미나를 주최하기로 했다. (PL이 먼저 세미나 주최를 제안했던 것이 가장 큰 계기가 되었다.) 그리고 나름 성공적으로 마쳤다. '생산성이 좋습니다.' 한마디를 이야기하기 위해서는, 왜 좋은지, 어떻게 좋은지, 기존의 방법보다 어떤 것이 나으며 어떤 것이 부족한지에 대한 설명과 근거 자료들이 준비가 되어있어야 했고, 예상치 못한 질문에도 최대한 사실에 근거하며 잘 대답할 수 있게끔 전반적인 이해가 완전히 되어야 했기 때문에 공부와 세미나 자료 준비를 거의 동시에 진행했다. 공부도 공부 나름인게 Rx를 설명하기 위해서는 멀티코어 프로세서가 등장한 환경부터 동시성 프로그래밍, 반응성 프로그래밍 등...
자세한 내용 보기