'[+++ JAVA +++]/- - 작성중'에 해당되는 글 28건

  1. 2014.12.24 Robolectric 적용시 NoClassDefFoundError: com/google/android/collect/Maps 날때..
  2. 2014.12.22 AndroidStudio 커서를 이클립스처럼 camelcase 단위로 옮기기 (1)
  3. 2014.12.14 Android wear Watch face Code Sample
  4. 2014.12.14 Android wear Watch face 디자인하기
  5. 2014.12.09 AndroidStudio 1.0 rc4 에서 1.0 릴리즈로 업데이트시 apt 처리 문제 해결방법
  6. 2014.12.08 Mockito 를 이용한 Callback test
  7. 2014.12.07 Testing and Refactoring with legacy code
  8. 2014.12.07 The Art of UNIX Programing (1)
2014.12.24 14:32

예전 맥북에어에서 사용할땐 잘 되던것이 이번에 맥프레로 개발환경을 옮기면서 테스트가 다 깨졌었는데, 그때 에러가 바로

NoClassDefFoundError: com/google/android/collect/Maps#1420


https://github.com/robolectric/robolectric/issues/1420



문제는 버전이었는데 그래들엔 2.4를 쓰고 있었는데 2.4에는 com.google.android 디팬던시가 없어서 클래스를 못찾던것. 그래서 버전을 2.3으로 낮추니 잘 돌아감.


현재 com.google.android 디팬던시를 모두 없애도 있다고 하니 차기 버전에서는 해결될듯


버전을 2.3으로 낮추고 잘 동작하길래 이슈를 닫았더니, 다시 제이크 왓슨님이 손수 오픈하심ㄷㄷ


이런 영광이..ㅋㅋ

저작자 표시 비영리 변경 금지
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
Trackback 0 Comment 0
2014.12.22 11:04

커서를 옮길때 alt+화살표 로 자주 옮기는데, AndroidStudio(intellij 도 마찬가지일듯) 기본값으로 단어 기준을 문법상 단어로 잡혀있어서 매서드 이름, 변수 이름등은 하나의 단어로 생각함.

이클립스의 경우 매서드 이름, 변수 이름등을 또 내부적으로 실제 단어 기준으로(사실은 특문(_)이나 숫자, 카멜케이스단위로)해서 alt+를 이용한 커서 를 옮길때 편리함.



저 옵션을 활성화 하면 이클립스랑 비슷하게 카멜단위로 점프를 할 수 있음

저작자 표시 비영리 변경 금지
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
Trackback 0 Comment 1
  1. Favicon of http://quadflask.tistory.com BlogIcon Flask 2014.12.22 11:20 신고 address edit & del reply

    부작용으로 더블 클릭으로 단어 선택시에도 단어 단위로 선택이 됨....뭐 이런.....

2014.12.14 12:54

Android Wear API 가 새로 공개된 기념으로 코드 샘플을 보고 있는중에 중요한 부분들 기록


1. 퍼미션, 인텐트 필터 등록

일단 패키지 네임은 동일하다.


폰 어플리케이션 AndroidManifest.xml


웨어 AndroidManifest.xml


2. CanvasWatchFaceService 상속 및 Engine 인스턴스 리턴

여기는 폰용 WallpaperService랑 거의 같음.


3. onCreate 매서드를 오버라이딩하고 필요한 초기화 작업 수행

setWatchFaceStyle 에서 몇가지 값들을 셋하는데 Doc 을 참고해야할듯


4. onDraw매서드 오버라이딩하고 시계를 랜더링 한다

이 예제에선 Time 객체를 사용하는데 이게 편할듯(setToNow로 시, 분, 초 다 가져오기 편하다!)


5. onAmbientModeChanged 매소드 오버라이딩하고 앰비언트 모드 전환시 이벤트를 받는다

이 예제에선 단순히 안티 앨리어싱 옵션만 on/off 하고 있다. 여기서 중요한것이 invalidate()를 해준다는점. 그리고 updateTimer()를 호출하고 있는데 이 메소드는 단순히 핸들러에 메시지를 날리는것인데,,,핸들러 내부에서 자기 자신에게 다시 매시지를 날려서 진행하고 있음.(왜 이렇게 하는거지? 그냥 타이머 객체 사용해서 타이머태스크를 구현하면안되나?)

->

여기 핸들러를 보면, 타이머가 동작해야할때에 대해서 메시지를 호출하는데 이때 딜레이를 계산하는 부분이 중요하다. 하지만 이 부분은 굳이 이렇게 까지 복잡하게 할 필요 없이 Timer 클래스와 TimerTask 를 이용하면 자연스레 쉽게 구현이 가능해진다. 하지만 여기서 핸들러를 사용하는 이유는 아마 뷰의 invalidate() 때문인것 같다.


6. onInterruptionFilterChanged 메소드 오버라이딩하고 시계의 뮤트여부에 따라 콘트라스트를 조절한다.

시계에 뮤트 옵션이 있는거 같은데...이 뮤트상태일땐 화면의 콘트라스트를 낮춰야 한다.(밝기를 낮춰야 한다. 그래서 여기선 알파값을 조절해서 100% -> 약 39%로 낮추고 있다)



잘못된 부분은 언제나 피드백 환영합니다.

저작자 표시 비영리 변경 금지
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
Trackback 0 Comment 0
2014.12.14 01:07

Designing Watch Faces:

Watch Faces for Android Wear


원글 : http://developer.android.com/training/wearables/watch-faces/designing.html


간단한 가이드 라인 부분만 발번역해봄


Plan for Square and Round Devices

네모랑 동그란 디바이스를 염두해야 한다는 내용

(갤럭시 기어가 네모, G 와치가 동그라미인데....동그라미가 더 이뻐보임..)


Create flexible concepts

이상적으로 와치페이스의 시각적 기능은 동그라미나 네모 둘다에 대해서 동작해야 합니다. 이 예에서는 와치 페이스는 시각적 기능이 다른 조절 필요 없이 충분히 유연하게 동작합니다. 그러나 다른 디자인 컨셉들은 네모나 동그라미 스크린에 대해서 다른 실행을 필요로 합니다.

-> 네모나 동그라미에 대해서 비슷한 느낌을 줄 수 있도록 해야 한다.


Use a common design language

동그라미나 네모에 대해서 서로 시각적으로 연결하기 위해 흔한 색상, 라인 두께, 쉐이딩, 그외 디자인 요소를 사용하세요. 비슷한 색상 팔레트를 사용하고 약간의 시각적 연관성을 사용함으로써 네모, 동그라미의 전체적인 모습이 조금 커스터마이징 될 수 있지만 여전히 같은 시각 시스템으로 느낄 수 있다.

-> 네모나 동그라미에 대해서 인식한뒤, 그에 맞는 모습을 보여주되 너무 다르게 느끼지 않도록 커스터마이징 해야한다. (그냥 동그라미만 지원한다...를 정할 순 없나..?)


Adjust for analog concepts

몇가지 컨셉들은 자연적으로 시침, 분침이 있는 아날로그 시계의 모습을 가질것입니다. 이 경우 네모로 변환할때  모서리부분을 고려하세요. 다른 여백(?) 공간을 활용하세요.



Plan for All Display Modes

모든 디스플레이 모드에 대해서 계획하세요


안드로이드 웨어 디바이스는 크게 두가지 모드로 동작합니다: 앰비언트(주변광?), 인터렉티브(상호작용?)입니다. 와치 페이스 디자인은 이 두가지 모드에 대해 디자인 되어야 합니다. 보통 와치 페이스 디자인이 앰비언트모드에서 좋게 보인다면, 인터렉티브 모드에선 더 멋지게 보일것입니다.


앰비언트 모드에선 스크린은 매 분마다 업데이트 됩니다. 오직 시, 분만 보여집니다. 이 모드에선 초를 표시하지 마세요.


Interactive mode

유저가 와치를 건들였을때(?) 스크린은 인터렉티브 모드로 전환됩니다. 이 모드에선 모든 색상, 그리고 자연스러운 에니메이션을 사용 할 수 있습니다.


Ambiend mode

(어디서 주워 듣기론 모든 배경은 반드시 검은색이어야 하고 시침, 분침은 흰색으로 표시하되 전체영역에 대해 최대 10? 5?%를 넘지 않아야 한다는....그러니까 최소화 해야함)

앰비언트 모드는 디바이스의 배터리를 오래 유지하게 하는데 도움을 줍니다. 이 모드에선 그림자의 회색, 검은색, 흰색만 표시되어야 합니다. 우리의 와치 페이스는 디바이스가 앰비언트모드로 전환될때 노티를 받고 주의깊게 디자인 해야 합니다.



Optimize for Special Screens 

특수 화면에 대해서 최적화 하세요


안드로이드 웨어 디바이스는 여러가지 스크린 기술들로 되어 있습니다. 각각 장점 그리고 고려할 요소들이 있습니다. 앰비언트 모드에 대해 한가지 중요한 고려 요소로 얼마나 배터리 타임(life)에 영향을 주는가, 그리고 스크린 번인이 있습니다.(번인의 경우 OLED를 이야기 하는듯....)


각각의 스크린 종류에 따라 다른 앰비언트 디자인을 할 수 있습니다. 모든 스크린에 대해서 최선의 디자인을 고려하세요.


Low bit

앰비언트 모드에서 몇몇 스크린의 픽셀들은 on 또는 off됩니다. (이렇게 하는것이 low-bit 라 하는듯) 이땐 그레이스케일된 색생을 피하고 오직 흰색, 검은색만을 사용해야 합니다. 그리고 페인트 스타일에서 안티 앨리어싱 모드를 꺼야 합니다. 반드시 테스트 해보세요.


Burn protection techniques

OLED 스크린에 대해서 디자인할때 전력 효율성과 스크린 번인효과를 고려해야 합니다.(역시 번인이 문제...) 스크린이 앰비언트 모드일땐 특정 몇몇 픽셀들이 번인되는것을 막기 위해 시스템이 스크린의 컨텐츠를 주기적으로 쉬프트합니다.(컨텐츠를 상하좌우 조금씩 옮겨 랜더링 한다는 소리) 앰비언트 모드에선 많은 픽셀 블록들을 사용하지 않아야 하고 95%의 픽셀들을 검은색으로 두어야 합니다. 앰비언트 모드에선 솔리드(내부가 채워진) 쉐이프들은 번인을 막기 위해 외곽선으로 바꾸세요. 또한 채워진 이미지들을 픽셀 패턴으로 바꾸세요. 아날로그 와치 페이스에 대해선 침들이 만나는 픽셀 번인을 막기 위해 중앙부분을 비우세요.



Accomodate System UI Elements

시스템 UI 요소를 수용하세요


와치페이스 디자인은 안드로이드 웨어 Ui 요소를 수용해야 합니다. 이 요소들은 유저에게 웨어러블의 상태와 유저의 폰의 서비스에서 오는 노티들을 보여줍니다. UI요소의 방해로부터 와치페이스의 중요한 요소들을 유지하세요.

(보통 웨어 UI 요소들이 하단에 위치하기때문에 되도록 상단 부분 40% 정도에 중요한 요소들을 위치하도록 하는것이 좋을듯 - 또는 UI 요소가 시계를 덮을땐 그 이벤트를 받아 인터렉티브하게 변경하는것도 좋을듯)


Cards

카드는 노티 시스템











저작자 표시 비영리 변경 금지
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
Trackback 0 Comment 0
2014.12.09 11:00

AndroidAnnotations 사용중, 이번 업데이트로 인해 아래와 같은 오류가 뜬다면,



Error:The project is using an unsupported version of the Android Gradle plug-in (0.14.4). The recommended version is 1.0.0.

<a href="fixGradleElements">Fix plugin version and re-import project</a>



apt {

arguments {

androidManifestFile variant.processResources.manifestFile

resourcePackageName "com.flask.testapp"

}

}


에서


apt {

arguments {

androidManifestFile variant.outputs[0].processResources.manifestFile

resourcePackageName "com.flask.testapp"

}

}


ouputs[0]


을 추가해주면 됨

저작자 표시 비영리 변경 금지
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
Trackback 0 Comment 0
2014.12.08 16:31

Android unit test 를 작성하면서 retrofit 을 사용하는 서비스가 있어 이를 어떻게 해야 할까를 고민하던중 찾은 방법


Retrofit 에서 비동기로 콜을 하기 위해선 파라미터로 콜백을 넣어주면 되는데 기존에 생각했던 방법으론(when-then) 으론 어떻게 테스트를 해야 할지 의문이었음


방법은 간단하게 when 절 앞에 doAnswer를 넣어주면 됨.



MyApi mock = mock(MyApi.class);


doAnswer(new Answer() {

@Override

public Object answer(InvocationOnMock invocation) throws Throwable {

Object[] args = invocation.getArguments();

Callback<MyData> callback = (Callback<MyData>) args[0];

callback.success(dummy.myData, null);

return null;

}

}).when(mock).fetchMyData(any(Callback.class));


final DoneMarker doneMarker = new DoneMarker();

mock.fetchMyData(new Callback<MyData>() {

@Override

public void success(MyData myData, Response response) {

assertThat(myData, notNullValue());

assertThat(myData, is(dummy.myData));

doneMarker.done();

}


@Override

public void failure(RetrofitError error) {

fail();

doneMarker.done();

}

});


await().atMost(1, SECONDS).until(doneMarker);



Retrofit 으로 만든 Api 인터페이스의 클래스를 mock 으로 만들고, doAnswer-when 순으로 테스트 코드를 위한 준비 작업을 함.


doAnswer절에선 callback 을 호출해주면 되고, 우리가 테스트 하고자 하는 매서드의 파라미터로는 콜백을 넣어주면 되는데, 모든 콜백을 받기로 하겠다면(모든 콜백을 파라미터로 넣으면, 어떤 콜백이든, doAnswer 절에 정의한 answer가 실행됨) any 를 써서 넣어주면 됨.


그리고 콜백이 비동기로 이뤄지기 때문에(위 코드에선 그렇진 않지만) assertion 을 콜백 내부에서 해준다. 그리고 매서드 호출 마지막에 await() 으로 최대 1초간 doneMarker 가 true 를 리턴할 때까지 기다린다.

* await 은 awaitility 라이브러리의 매서드



저작자 표시 비영리 변경 금지
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
Trackback 0 Comment 0
2014.12.07 23:38
Testing and Refactoring with legacy code



테스트를 하기 위해서 첫번째로 테스트 해야 할것은 얕은 브랜치부터 깊은 브랜치로 가야 하고, 
리펙토링은 깊은 곳에서 부터 얕은 곳으로,.
start testing from shortest to deepest branch, start refactoring from deeptest to shortest branch.
(단순히 물리적인 인덴트 뿐만 아니라 논리적인 의존성도 생각한 것을 생각해줘야 함)

인젝션이나 등등의 의존성때문에 테스트가 힘들다면, 그 부분을 따로 메소드로 뽑아내고, 테스트 클래스에서 테스트 대상이 되는 클래스를 상속한뒤, 그 인젝션이 되는 메소드를 오버라이드 하고, 목 또는 페이크 오브젝트를 전달하여 비즈니스로직을 테스트 한다. 

코드 커버리지를 확인해 가면서 테스트가 제대로 커버하는지를 확인하는것도 좋은 방법이다.

null 도 또한 의미있는 이름을 지어서 상수로 두는것이 좋다. 테스트를 이해하는데 도움을 주기 때문.

테스트 케이스를 위해 여러가지를 set해야 할땐 빌더 패턴을 적용하면 편리하다. 나중에도 써먹을 일이 생기기 때문, 가독성에도 좋다.

UserBuilder
.aUser()
.friendsWith(ANOTHER_USER, loggedInUser)
.withTrips()
.build();

aUser(){
return new UserBuilder();
}

가변인자로 받으면 편리하다. 

for 로 돌면서 플래스 셋을 위해서(리스트에 포함되 있는지 확인하는, 이런것은 contains를 활용하면 좋지) break 를 하는데 이게 왜 필요할까? 이런것은 물어보지 말고 하라고 시켜야 한다. 

분기에 따라서 어떤 객체를 만들어서 그 리턴할때, 아래에서 두번재 if 블록.
이렇게, 이를 다시
 
이렇게 삼항 연산자로 바꾼다.
물론 이것이 가독성이 나쁠 수 도 있는데, 상황에 따라서 선택하면 좋을듯.
그리고 저 new ArrayList() 를 상수로 만든다. 또는 그냥 메소드 추출.
이때 테스트와 프로덕션 코드와 비슷한 맥락, 으로 이어지면 이해하기 좋다. 물론 영어를 잘한다면.

인덱트를 줄이기 위해 if문 판단을 미리 하거나 나중에 하거나??? 분리를 한다. 이렇게 분리를 하게 되면, 메소드 안에 크게 두가지 블록으로 나눠지게 되고 이를 각각으로 나누면 좋다.

의존성을 줄이기 위해 인자로 받을 수 있는것은 인자로 바꾼다. 

59:22 까지 봄.


저작자 표시 비영리 변경 금지
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

'[+++ JAVA +++] > - - 작성중' 카테고리의 다른 글

Mockito 를 이용한 Callback test  (0) 2014.12.08
Testing and Refactoring with legacy code  (0) 2014.12.07
The Art of UNIX Programing  (1) 2014.12.07
Skip List, Bloom filter  (0) 2014.12.07
Trackback 0 Comment 0
2014.12.07 23:36

The Art of UNIX Programming 


독후감....이랄까
보면, 지금의 OOP 개념과도 비슷한 느낌?인것 같다. 

  1. 철학

1, 모듈화의 법칙
깔끔한 인터페이스들로 연결된 간결한 파트를 작성하라

2, 명확함의 법칙
명확성은 Clever 한것보다 낫다

3, 조합의 법칙
다른 프로그램과 연결될 수 있도록 디자인하라

4, 분리의 법칙
매커니즘(작동방식)으로부터 정책을 분리하라; 엔진으로부터 인터페이스를 분리하라

5, 간결함의 법칙
간결하게 디자인하라; 반드시 필요할때에만 복잡하게 하라

6, 절감의 법칙
큰 프로그램은 오직 한가지일만 한다는것이 분명할때만 작성하라

7, 투명성의 법칙
조사하고 디버깅쉽게하기 위해 디자인을 가시적으로 하라

8, 강건함의 법칙
강건함은 투명성과 간결함의 자식이다....

9, 표현의 법칙
데이터로 지식을 넣어 프로그램 로직을 멍청하고 강건하게 하라

10, 최소한의 놀라움의 법칙(?)
인터페이스를 디자인함에 있어, 항상 최소한으로 놀라게 하라

11, 침묵의 법칙
프로그램이 놀라게 할만한것이 없다면 아무것도 말하지 말아야 한다.(입닥쳐!)

12, 수리의 법칙
만약 반드시 실패해야 한다면, 시끄럽게 그리고 가능한 빨리 실패하라

13, 경제의 법칙
프로그래머의 시간은 비싸다; 머신의 시간을 사용함을 통해 절약하라

14, 세대(생성?)의 법칙
핸드-해킹을 피하라; 프로그램을 작성하기 위한 프로그램을 작성할 수 있을때 작성하라
(코드 생성을 하는 프로그램을 작성하라 라는 뜻?)

15, 최적화의 법칙
연마 하기 전에 프로토타입을 하라; 최적화 하기 전에 동작되게 하라

16, 다양성의 법칙
한가지 진실된 방법에 대한 클레임은 모두 무시하라

17, 확장성의 법칙
미래를 위해 디자인하라, 왜냐면 당신이 생각하는것보다 금방 도달하기때문






저작자 표시 비영리 변경 금지
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
Trackback 0 Comment 1
  1. 2015.06.20 01:04 address edit & del reply

    비밀댓글입니다



티스토리 툴바