2016년 12월 25일 일요일

Spring Security Login Error 메시지 처리

Spring Security 인증 방법에 대한 글을 쓴 적이 있다.

그런데 Login Fail의 경우 Error 메세지 처리를 해야할 것이 아닌가?

provider나 userDetailService의 경우
각 케이스 별로 UsernameException, BadCredentialException등의 예외를 던지면

Exception error = (Exception) session.getAttribute("SPRING_SECURITY_LAST_EXCEPTION");if (error != null) {
    model.addAttribute("error", error.getMessage());
}

session에서 `SPRING_SECURITY_LAST_EXCEPTION`이라는 키로 해당 예외에서 생성한 exception object를 가져올 수 있다.

처리방법은 여러가지가 있겠지만, 단순히 메세지만 처리하기 위함이라면
Exception으로 캐스팅한 후에 getMessage() 메서드로 해당 메시지를 가져 올 수 있다.


2016년 12월 18일 일요일

오늘도 고민한다. - jHipster에 붙여 -

pro우려er는 아니지만 오늘도 고민한다.

그동안 작업하던거 그냥 접고 jHipster로 새로 생성하는게 훨씬 낫겠는데?
이러려고 개발자 했나 자괴감 들고 괴로워...
진짜 그냥 AngularJS로 frontend 수정하는게 훨씬 여러모로 나은거 아닐까?

내가 작업하던건 그냥 쓰레기가 아니었을까...?

그래서 고민한다.
괴롭다 ㅠ.ㅠ

Spring AspectJ와 java beans getter&setter로 삽질하던 이야기

java beans의 field값을 상황에 따라 조작해줘야 할 필요가 생겼다.
AES로 encrypt/decrpyt 해 줘야 하는 문제인데,
상황에 따라 몇 가지 변수가 있다.

때문에 일반적인 business layer <> persistence layer 계층으로 처리하기에는 일이 복잡해진다.

이럴 때 빛을 발하는게 AOP인데.
테스트케이스로 개발하면서 테스트해보니 JPA와 함께 잘 해결한 것처럼 "보였다."

실제 코드에 반영해보니 아뿔사.
생성된 instance가 가지고 있는 전역변수가 다른 객체의 instance인 경우에 문제가 발생하는 것이었다. 상세한 내용은 생략하지만, 의도치 않은 동작이 발생했다.


해결할 방법을 두 가지 시나리오로 정리했다.
  1. AOP로 decrypt된 instance에 field method를 부가해서 한번만 decrypt 처리를 한다.
  2. instance의 변수는 immutable로 다루고 getter를 조작해서 상황에 맞게 처리를 한다.
이리저리 검토해봤을 때, 2번 케이스가 가장 적합하다고 판단해서
domain model class의 getter들을 pointcut으로 접근하도록 advice를 만들었다.

그런데 왠걸? 아무리해도 advised methods에 getter들이 나타나지 않는게 아닌가?!

가능성을 몇 가지 생각해봤다.
  1. lombok이 문제인가?
  2. interface를 구현한 것 때문에 외부에 method signature가 노출이 안되나?
  3. pointcut advice를 잘못 작성했나?
도대체 내가 무얼 잘못 했나를 검증하며 몇 시간 씨름을 했다.

그리고 도무지 답을 찾지 못하고 stackoverflow든 어디든 도움을 요청하기 위해 케이스를 일반화시키고 있었다.

그리고는 불현듯 깨달았다.

domain model class는 spring bean이 아니며, spring bean이 되어서도 안되며 그렇기 때문에 advised methods에 getter가 나타날 수 없었다는 것.

간단한 문제(?)였다.

그나저나 이걸 어떻게 해결한다...

2016년 12월 14일 수요일

github은 정말...


재미있는 장난감이다.

각종 open source도 open source지만,
jekyll로 제공하는 static site의 재미도 쏠쏠하다.

markdown으로 작성하는 문서도 나름 괜찮다.

매번 github private 결제에 대해 고민한다.
...하지만 현실은 bitbucket private ㅋㅋ


2016년 12월 9일 금요일

android webView에 관한 이슈 몇 가지

android에서 webview는 사실 꽤 한계가 많아보인다. 가장 큰 단점으로는 javascript 처리 속도가 늦다는 점을 들 수 있다. 경쟁사(?)에 비해서 싱글코어의 성능이 낮다보니 구조상 어쩔 수 없는 문제라고 한다. ionic, cordova 등의 hybrid app등의 발목을 잡는 문제도 바로 이 성능문제에 기인한다.

때문에 webview 관련 이슈를 정리해 보려고 한다.

상세 내용은 링크

2016년 12월 8일 목요일

android context에 대해

android에서 context는, 사실 android가 제공하는 서비스를 사용하거나 화면에 뷰를 그려야 할때 가장 많이 접근하게 된다.

한편 adapterView를 상속하고 있는 listView, gridView등은 adapter 패턴을 사용해서 adapter를 통해 화면에 그리질 childView 및 데이터를 관리하게 된다.

listView와 adapter 관련된 예제들을 보면 adapter의 instance를 생성할때 context를 주입해주는 것이 대부분이다.
사실 매우 귀찮다. 저 context를 외부에서 주입해줘야만 뷰를 그릴 수 있는 것인가?

나머지는 아래 링크에서 ^.^



2016년 11월 17일 목요일

react 공부를 시작하며

react? angular?
고민하다가 둘다 해보기로 하고 우선 react 공부를 시작했ㄷ...

npm?
babel?
typescript?
redux?
jsx?
grunt?
gulp?
bower?



일단 개념 정리부터 해야할 필요성을 뼈저리게 느꼈다. -_-;

1. npm
maven이나 gradle같은 dependency 관리 툴.
자세한건 패스

2. babel
ES6 코드등을 알아서 컴파일(?)해서 vanila javascript로 변환해주는 툴.
주로 react 진영에서 쓰이는거 같다.

3. typescript
정적 언어 특징중의 하나가 타입추론 일텐데, 대규모(?)로 가면 헷갈리나 보다. type을 강제하는(?) javascipt 컴파일러(?). babel과 영역이 겹치는듯 한데, MS가 든든한 후원자로 있다보니 왠지(?) 꺼리는가 보다.
어쨌거나 angular 진영에서 쓴다는 듯.


추가예정


4. redux
5. jsx
6. grunt
7. gulp
8. bower






2016년 11월 10일 목요일

Scaffold 서비스들을 둘러보고

시작은 AXBoot이라는 녀석이었다.

그런데 어쩌다보니 yeoman에 굴러들어가게 되었고
JHipster까지 둘러봤다.

중간에 nodeJS 버전때문에 골머리 썩기도 했지만 6.9.1버전을 설치하는 걸로 해결을 했고.

둘러본 소감은.

와우.
세상은 넓고 정말 고수들을 많다는 것이다.
Spring boot는 그냥 빈 캔버스에 불과했다...

JHipster는 그 깔끔함에 더 손을 댈게 없는거 같다.
사실 둘러보면서 배우는게 엄청 많다.
이렇게도 할 수 있구나 부터 시작해서,
이건 이렇게 하는 거였군 하는 등.

한편으로는,
Entity 모델링이 끝나면
backend는 사실상 더 이상 할게 없는거 아냐?! 뭐 이런 생각마저 든다.

뭐 언제나 문제(...)는 frontend쪽이 손댈게 많다는 것?

angular vs react의 큰 양대축(?)도 문제고
엄청난 속도로 쏟아지는 javascript framework들을 보면서
특정 framework에 종속되는건 아무래도 큰 리스크를 져야 한다는 점에서
주저하게 된다.

2016년 10월 26일 수요일

xamarin - Xamarin.forms는 버려라

진심으로.

visual studio에서 New project로 생성한 프로젝트가 빌드조차 안된다.
이유도 모르겠다.

그나마 빌드되는게 Native정도.

이건 android 각종 resource를 포팅해야 하는데,
intelliSense가 구려서인지 정보가 다 없어서 그런지 모르겠지만
타이핑할 양이 훨씬 많다 -_-;

layout 폴더 아래 있는 xaml 파일들 내용 자체는
android에서 생성한 xml 파일들과 내용이 같다.

그러니까 그냥 layout은 android studio에서 그린 담에 복사해 넣자.그게 속편하다, 진심으로.


그리고 각종 리소스들은 Build 하기 전에는 인식을 못한다.
이것때문에도 며칠 삽질을

이쯤에서 이걸 도대체 왜 xamarin으로 만들고 있어야 하지 하는 생각이 뇌리를 스치운다.
iOS 앱 만들려면 결국 또 Storyboard로 그려야 하겠구만.


2016년 10월 24일 월요일

Springboot Template engine. JSP vs Velocity vs Thymeleaf (1)

스프링부트와 템플릿 엔진 이야기

1. JSP
jsp를 쓰려니까 뭔가 추가해야할 것이 많더라. 그래서 그냥 패스.

2. Velocity
그래서 velocity를 썼는데, 1.4.0Release 버전부터 deprecated 된것이 아닌가.
이미 적용한 데는 놔두고, 다음 작업할 곳은 다른 엔진을 찾아 보기로 했다.

3. Thymeleaf
여러가지가 있었던것 같지만, freemaker, thymeleaf 정도 손에 꼽혔다.

구글 트렌드를 한번 검색해보니 대충 이렇더라.


그래서 왠지 스프링에서도 밀고 있는 것 같은 thymeleaf를 써보기로 했다.
(react 등 client-side rendering 등은 일단 다음 기회에...)



3.1. 첫인상

뭐 특별한 것은 없었다. velocity engine을 ViewResolver로 사용하기 위해 만들었던 javaConfig 파일을 주석처리 하고 application.properties 몇 줄 수정하는 것으로 thymeleaf가 동작한다.

3.2 첫 난관

template layout을 만들 때 고생을 조금 했다.
html tag를 적극적으로 활용하다 보니,
'어떤 부분이 replace 되는 건가?' 하는 부분들이 직관적으로 보이지가 않았다.

웹브라우져에서도 본래 레이아웃을 확인 할 수 있는게 장점이라는데(?)
그렇게 하기 위해서는 각 페이지 레이아웃을 반복적으로? 사용해줘야 한다.
굳이 그럴 필요가 있나???

한편, thymeleaf를 좀 쉽게 사용하려면 `thymeleaf-layout-dialect` 이걸 활용할 필요가 있는 것 같다.

스프링부트 dependency에서 spring-boot-starter-thymeleaf을 포함하면 해당 패키지에 같이 포함되어 있다. - 다행이다 -


3.3 그 이후

그렇게 Velocity로 만들었던 폼들을 thymeleaf로 변환하고 보니,
뭐 딱히 템플릿 엔진의 기능을 많이 안써서 그런지 별 차이를 못 느끼겠다.

아무래도 html tag 형식을 빌려쓰고 있는 thymeleaf는 표현의 제약이 느껴진다.
마법의 태그(?)로 보이는 `th:block`과 `th:remove="tag"`를 잘 활용하는 방법 밖에는 없는 것 같다.


EDIT:
그런데 또 막상 쓰다보니 표현의 제약 그런거 별로 없더라.
어떻게 풀어서 쓰면 다 된다;;;

2016년 10월 11일 화요일

Builder 시리즈 - Biz PPurio SMS Builder


서비스 제공업체들이 준 API들 쓰기가 너무 귀찮고 복잡해서
builder pattern으로 만들었다. 시리즈 첫번째.

android만 봐도 클래스에 옵션이 많다 싶으면 builder를 제공하는데, 몇개 안보긴 했지만 제대로 된 example이나 builder를 제공하는게 별로 없는 것 같다.

이번에 만든 것은 bizPurio builder 이다.

하나는 SMS message builder.
property 마다 주석 달아놔서 좀 읽기 쉬울거라고 생각한다.

다른 하나는 실제 메세지를 보내는 class builder.
인라인 주석으로 되어 있는거 보기가 싫어서 마찬가지로 builder pattern으로 작업.

작업하면서 method chaining이 되도록 하는 방법을 알게된게 소득이랄까.

EDIT:
...purio가 아니라 [ppurio 뿌리오]였구나. sms를 뿌리오? 이런건가 보다;;

2016년 9월 26일 월요일

xamarin 첫걸음

사내 프로젝트가 시작되었다.

'같은 작업 2번 하기 싫다'는 지극히 개발자지향적인 마인드가 공감을 얻어 xarmarin이 플랫폼(?)으로 선택되었다.

뭔가 재미있을거 같다(?)


EDIT:

일단 2가지 난관이 있었다.
첫번째는 C#에 적응하는 것,
두번째는 VisualStudio에 적응하는 것.

C#은, java랑 생김새가 비슷하다보니
C# 코드를 java로 바꿔보기도 했는데, 코드차원에서 읽어내리는건 그렇게 어렵지 않았다.

그러나 C#으로 코드를 짜려고 하니 손이 움직이질 않더라.
java로 프로그램을 짜려고 해도, 목적에 맞게 spring 혹은 android 등의 환경을 갖추는게 더 귀찮고 어려웠듯(?) C#과 닷넷 자체에 대한 이해 없이 뭔가 시작을 할 수 없었다.

이는 VisualStudio 적응과도 문제가 이어졌는데,
Eclipse의 workspace - project 관계가
intelliJ에서는 project - module이고,
VisualStudio에서는 solution - project로 관계가 매핑되더라.

그런데 그냥 파일을 해당(?) 위치에 넣으니까 인식을 못하는게 아닌가?
파일기반이 아니라 뭔가 database로 관리된다는 소리가 되겠지.

... 그리고 새로운 클래스 파일을 생성하기 위해 어떻게 해야 하는가?를 두고도 삽을 펐는데, 결국 이런 문제들을 해결하기 위해 책을 보기로 했다.

그랬더니 역시 책에 나오더라 -_-...

아무튼 VisualStudio와 intelliJ에서 나온 C# IDE인 rider를 어느정도 병행해서 사용하게 될거 같다.

2016년 9월 12일 월요일

왜 C/C++에 관심을 가지게 되었을까.

갑자기 C/C++ 에 대한 관심이 생겼다.

왤까.

지금으로서는 그 이유를 모르겠다.

한번 찾아봐야 겠다.

C/C++


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를 도입해서 생명주기를 관리를 해야 한다.


2016년 9월 1일 목요일

Maven으로 특정 유닛테스트만 실행하기

서버에서 테스트 케이스를 실행하고 싶을 때가 있다.

어떻게 하면 될까?


maven test로 특정 testClass 만 실행할 수 있다. 참고사이트

2016년 8월 30일 화요일

Spring Security 인증방법 4가지.

JavaConfig 방식 기준으로 이야기를 하면 다음과 같다.
.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으로 작성하지 않아도 될거 같다는 결론이다.


2016년 6월 3일 금요일

oneDrive에 바라는 점

.ignore를 지원해달라!

제발!
너무 절실함!

동기화 안하겠다고 체크 해제했는데 기어이 동기화하는 통에 질렸다!

2016년 5월 27일 금요일

docker 첫 걸음


왜 도커를 사용해야 하는가? - 혹은 왜 다들 도커도커 하는가?

그 이유를 python을 사용하면서 알게 되었다.
python은 버전2와 3이 차이가 제법 있다.

처음 python을 설치하면서 3.5.1 버전을 설치했고,
거기서 첫 코드를 작성했던 것이 문제였다.

나중에 프로젝트에 사용될 기술들을 정했는데,
mac el capitan에 기본적으로 설치되어 있는 녀석이 2.7이고,
그냥 그 2.7 버전을 쓰기로 합의가 된 것이었다.

아무튼 2.7이 설치되어 있는 mac에다가 3.5.1을
virtualenv를 사용해서 설치해보려고 하다가 주화입마에 빠져버렸다.
아직 python에 대한 이해도가 낮은게 문제이겠지만
2.7, 3.5.1이 짬뽕이 되어서 library가 날 뛰는 것이 아닌가.

하물며 개발 환경에서도 이런데,
실제 운영 환경에서는 또 얼마만한 삽질을 해야 할 것인가?

아 이래서 개발 환경과 운영 환경을 통합해버릴 수 있는 도커가 각광을 받게 된 것이구나.
클라우드 환경에서 서버 가상화로 관리가 편해지는 이점도 있고!

그래서 또 이틀간에 걸친 삽질 끝에
원하는 docker 이미지를 만들어 내는데 성공했다.

알고보니 간단한데사실 알고나면 다 간단하지만
이걸 통해 더 간단히(?) 서버 설정을 할 수 있을 거라 생각하니 기쁘기 한량없더라.

운영 환경일때 삽질은 뭐 나중에 해보면 될것이고,
어쨌거나 지금 시점에서는 만족함.





2016년 5월 18일 수요일

2016년 5월 11일 수요일

android gradle buildtime 줄이기

프로젝트 빌드 타임이 4분 30초가 넘어가면서 인내심도 바닥나 버렸다.

만사를 제쳐놓고 빌드 타임을 줄이기 위한 방법을 찾아봤는데,
3가지가 해법인 것 같다.

gradle daemon, parallel, large heap

mac이나 unix 라면 ~/.gradle,
윈도우라면 /Users/%user%/,gradle

아래에 다음과 같은 파일을 만든다.



그다음, android studio 에서
Settings / Build, Execution, Deployment / Build Tools / Compiler에서

Compile independent modules in parallel (may require larger heap size)
을 체크하고

Command-line Options에

--offline

을 추가한다.


이렇게 하고 4분 30초 정도 걸리던 빌드타임이 6초로 줄었다?
잘못쟀나...
잘못 잰게 맞는 것 같다. ㅜㅜ

2016년 4월 27일 수요일

android versionCode, versionName은 어디에 위치해야 하는가


android studio를 활용해서 새로운 프로젝트를 생성했을 경우에,
이녀석은 너무나 당연하게 app/build.gradle 안에 groovy code로 versionCode, versionName을 생성한다.

그래서 당연히 build.gradle 안에 저 녀석들이 있어야 하는 걸로 알고 있었고, 버전 관리할때마다 반겨주는 메세지를 만나야 했다.

Gradle files have changed since last project sync. A project sync may be necessary for the IDE to work properly.  Sync Now

그런데 문제는 저 gradle build가 매우 느리다는 것이다 :(

덕분에 릴리즈 버전별로 브랜치를 관리하다 보면, 브랜치 스위칭하면서 빌드빌드빌드빌드를 하게 되는데 아. 쓰기만 해도 괴롭다. 아무튼 저 versionCode, versionName을 AndroidManifests.xml로 옮길 수 있다는 사실을 알게 되었다.

!!!!!!!!!!!!!!!!!!!!!

그리고 AndroidManifests.xml은 수정해봐야 재빌드 안한다!

왜 이걸 이제 알았을까.

아무튼 versionCode, versionName은 AndroidManifests.xml로 옮깁시다!

2016년 4월 12일 화요일

ormlite foreigncollectionfield에 대해

1 to many 관계에서 눈여겨 볼 일 없이 그냥 가져다가 썼었다.

그러다가 queryBuilder로 join을 했는데,
limit
orderBy
등이 전혀 먹히지 않는 것이 아닌가.

왜 이런 일이 벌어지는것인가! 나는 햄보칼수가 없어!


하루종일 삽질하다가
생성된 테이블 구조를 살펴보고야 이유를 짐작해냈다.

SomeEntity database table에 DetailEntity table에 대한 참조키가 생성되지 않는 거였다.
ormlite가 lazyForeignCollection으로 Set을 모조리 갖다 붙이는 거였음.

그래서 그냥 java code로 2차 가공하기로 했다.

profit(?)

2016년 3월 31일 목요일

Windows10 Bash shell 포팅 소식을 들으며

윈도우 노트북 SSD가 달랑 128GB라 늘 하드가 부족한데 이놈의 윈도우는 뭐가 윈도우만 용량이 25GB를 잡아먹고 있더라. (안드로이드 SDK가 25GB인것도 함정. 슬프다) 그 덕분에 git command 쓸 일이 있을 때마다 cd 로 폴더명 일일이 치고 있을 때마다 게이지가 차오르는 것을 느낀다. 어쨌거나 적어도 좀 터미널은 편하게 쓸 수 있게 되는가 보다. --------------------------------------------------- 헐. 윈도우에도 powershell이라는 녀석이 내장되어 있었다니! 전혀 몰랐다 -_-;... 그동안 cd 명령어로 삽질을 하고 있었구나 ㅠㅠ...

2016년 2월 26일 금요일

android studio에서 jar 만들기

android studio에서 module들을 jar 파일로 export 해보자.


towwaygridview를 jar로 만들 예정이다


jar로 만들 module의 build.gradle 파일을 열어서 다음을 입력하자.

task deleteOldJar(type: Delete) {
    delete 'libs/{moduleName}.jar'
}

//task to export contents as jar
task exportJar(type: Copy) {
    from('build/intermediates/bundles/release/')
    into('libs/')
    include('classes.jar')
    ///Give whatever name you want to give
    rename('classes.jar', '{moduleName}.jar')
}

exportJar.dependsOn(deleteOldJar, build)


그 이후에 Gradle 탭을 열어보자.

Gradle 탭을 열면...

jar로 만들 module을 연다

Tasks > other > ...

exportJar를 실행


위 gradle code로 task를 만든 exportJar 메뉴가 있다.
이 녀석을 실행하면



뭐 이런 녀석이 나오고

towwaygridview / libs / towwaygridview.jar 파일이 생성된다.

이 녀석을 복사해서 사용하면 되겠다.


** android resource 를 사용한 경우에는 jar 대신 aar을 사용해야 한다.

2016년 2월 24일 수요일

simple ONLINE relationship database design tool

http://aquerytool.com/aquerymain/index/

관계형 데이터베이스 디자인툴 괜찮은 것은 역시 erwin일것이다.
윈도우용이고 비싸다는 점만 제외하면.

db 설계할때 일반적으로는 복잡한 기능을 사용하지 않고
구조도(?)와 DDL 생성 기능을 주로 사용한다고 하면
위 사이트는 매우 좋은 선택이 될 것이다.

2016년 2월 15일 월요일

ormlite 첫인상

바쁘다는 핑계로 ORM 책 페이지가 넘어가지 않고 있었다.

그러다가 새로운 프로젝트를 하나 만들게 생겼는데,
android에서 local db를 사용해야 할 일이 생겼다.

해본 사람들이라면 알겠지만
...저거 테이블 또... 하다가 신음소리가 절로 나오는 그런 순간이 아닐 수 없다.
그냥 막 하기 싫고, 누가 좀 대신 타이핑 해줬으면 싶은 마음이 굴뚝같고,
그런 일이 일어날리는 없고.

그래서 검색잠시 해본 결과 ormlite가 android도 지원한다는게 아닌가.

나무 위에 올라가 있는데 하늘에서 동아줄이 내려온 기분이 이럴까?
몇 챕터 읽지는 못했지만 ormlite로 냅다 달려봤다.

erd로 그려진 테이블과 칼럼들을 바탕으로
model 클래스들을 만들었다.

그리고 어노테이션으로 관계들을 매핑해주고, OrmLiteSqliteOpenHelper를 상속해서 sqliteDatabaseHelper 클래스를 만들어서 onCreate, onUpgrade 메서드를 구현해주면 끝!

테이블 생성은 메서드 단 하나,  TableUtils.createTable()로 끝!

기본적인 CRUD는 문제없었다.
칼럼 join 테스트만 한번 해보면 어쨌거나 android에서 db로 머리 썩힐 일은 이제 없을 것이다!

행복하다.
Thank You, ORM!

2016년 1월 22일 금요일

Java에서 Unchecked cast warning 제거하기

Map<String, Object>을 이용해서 여러 개의 ArrayList<MyObject>들을 넘겨주게 된 경우가 있었다.

지금 다시 작업한다면 그럴 여지를 만들지 않겠지만,
value = map.get(key) 같은 형태로 map의 value를 가져오면 Unchecked cast warning이 발생한다.

@SuppressWarnings("unchecked")를 추가해주면 warning은 무시되지만
뭔가 찝찝하다고 생각되면 번거롭지만 다음과 같이 하면 된다.



java스럽게 복잡한데 속은 시원하다.

2016년 1월 12일 화요일

android logcat 필터링하기 - 원치 않는 로그 제거하기

logcat 로그 메시지를 원하는 것만 추려보려면?
정규식을 이용해야 한다.

Android Studio에서 logcat - Edit Filter Configuration을 실행하자.

Log Tag, Log Message, Package Name은 정규식을 적용할 수 있는데,

Log Tag에서 dalvikvm이 뿌리는 로그를 제거해보자.



^(?!(dalvikvm))


다른 것들을 추가하려면 아래와 같이 적용할 수 있다.


2016년 1월 8일 금요일

유틸리티 클래스 대신 객채지향!

객체지향에 대해 다시 한번 생각을 해보게 되었다.

데이터는 없고,
객체와 행위만 있다는 말이 의미 심장하다.