왤까.
지금으로서는 그 이유를 모르겠다.
한번 찾아봐야 겠다.
C/C++
2016년 9월 12일 월요일
2016년 9월 6일 화요일
이놈들연구소 - Sgnl!
대박 괜찮은 느낌적인 느낌의 제품이 출시될 것 같다.
한국에서 흔하지 않은 하드웨어 벤처이기도 하고
늘 스팸전화에 시달리는 통에 전화받는게 귀찮았는데
그 과정이 조금은 편해지지 않을까 생각한다.
Take my money!
Dagger2를 사용해보자!
Spring framework를 사용해봤다면, framework가 instance를 관리하는 Dependency Injection: Inversion of Control 의 편리함(?)을 느껴봤을 것이다.
android도 규모가 좀 되는 것을 개발하다보면 필요성을 뼈저리게 느끼게 되는데, 가장 유명한 툴이 Dagger가 되겠다.
Dagger는 본래 Retrofit, okhttp 등으로 유명한 Square에서 공개한 라이브러리인데 google에서 fork한후 손을 봐서 Dagger2를 공개했다. dagger는 보다가 이해가 안되서 접었고 상대적으로 dagger2가 사용하기 쉬워서(?) 사용하고 있다.
instance를 constructor를 통해서 주입해주는 것이 기본인데,
android의 경우 constructor를 사용할 수 없는 경우가 있다.
바로 activity, fragment가 그 범인인데,
이경우에는 수동 inject를 해야 한다. 아래가 수많은 삽질 끝에 정리한, 그 수동 inject를 하는 Best Practice라고 생각한다.
사실은 조금 더 dagger2를 제대로 사용하려면, activity 혹은 fragment 단위에서 생성되는 instance들은 ActivityComponent와 Activity 단위의 scope를 도입해서 생명주기를 관리를 해야 한다.
android도 규모가 좀 되는 것을 개발하다보면 필요성을 뼈저리게 느끼게 되는데, 가장 유명한 툴이 Dagger가 되겠다.
Dagger는 본래 Retrofit, okhttp 등으로 유명한 Square에서 공개한 라이브러리인데 google에서 fork한후 손을 봐서 Dagger2를 공개했다. dagger는 보다가 이해가 안되서 접었고 상대적으로 dagger2가 사용하기 쉬워서(?) 사용하고 있다.
instance를 constructor를 통해서 주입해주는 것이 기본인데,
android의 경우 constructor를 사용할 수 없는 경우가 있다.
바로 activity, fragment가 그 범인인데,
이경우에는 수동 inject를 해야 한다. 아래가 수많은 삽질 끝에 정리한, 그 수동 inject를 하는 Best Practice라고 생각한다.
사실은 조금 더 dagger2를 제대로 사용하려면, activity 혹은 fragment 단위에서 생성되는 instance들은 ActivityComponent와 Activity 단위의 scope를 도입해서 생명주기를 관리를 해야 한다.
2016년 9월 1일 목요일
2016년 8월 30일 화요일
Spring Security 인증방법 4가지.
JavaConfig 방식 기준으로 이야기를 하면 다음과 같다.
.xml 설정은 찾아보면 많이들 있더라.
1. in-memory
2. jdbc database
3. UserDetailsService
4. AuthenticationProvider
.xml 설정은 찾아보면 많이들 있더라.
1. in-memory
2. jdbc database
3. UserDetailsService
4. AuthenticationProvider
샘플 코드는 아래를 참조.
2016년 8월 25일 목요일
kotlin을 포기하다
순수한 호기심으로 kotlin으로 앱을 만들어 보려고 했으나...
지극히 현실적인 문제로 포기하게 되었다.
androidStudio 버전업과 gradle2.14로 업데이트 하면서
빌드 에러가 속출하는 것이 아닌가.
매번 Clean & Run을 해야 하는데 kotlin 빌드가 그렇게 빠른것도 아니고
instant run도 포기해 가면서 이 짓을 해야 하는 생각이 많이 들었다.
비지니스 로직이나 모델 객체 등은 kotlin으로 만들어도 나쁘지 않은 것 같지만,
dagger2나 butterKnife등의 DI 라이브러리를 사용하기에 충돌도 많은 것 같고
어차피 안드로이드에 귀속되는 View나 API등은 굳이 kotlin으로 작성하지 않아도 될거 같다는 결론이다.
지극히 현실적인 문제로 포기하게 되었다.
androidStudio 버전업과 gradle2.14로 업데이트 하면서
빌드 에러가 속출하는 것이 아닌가.
매번 Clean & Run을 해야 하는데 kotlin 빌드가 그렇게 빠른것도 아니고
instant run도 포기해 가면서 이 짓을 해야 하는 생각이 많이 들었다.
비지니스 로직이나 모델 객체 등은 kotlin으로 만들어도 나쁘지 않은 것 같지만,
dagger2나 butterKnife등의 DI 라이브러리를 사용하기에 충돌도 많은 것 같고
어차피 안드로이드에 귀속되는 View나 API등은 굳이 kotlin으로 작성하지 않아도 될거 같다는 결론이다.
2016년 6월 3일 금요일
피드 구독하기:
글 (Atom)