Search Results for 'Development'

ATOM Icon

3 POSTS

  1. 2011/04/21 안드로이드 커스텀 컴포넌트 구현 시 주의사항 by joshy21
  2. 2011/04/21 앙드레 미셸 이후 처음으로... by joshy21
  3. 2011/04/18 합성(Composition)에 대해... by joshy21
« Previous : 1 : Next »

안드로이드 커스텀 컴포넌트 구현 시 주의사항

안드로이드 커스텀 컴포넌트를 만들 때는

Context context를 매개변수로 받는 기본 생성자 이외에

xml에서 태그로 정의해 컴포넌트를 선언할 수 있게

<ClassName>(Context context, AttributSet attrs) 생성자 또한 구현해야 한다.

아이폰 프로그래밍에서 nib 파일에 아카이빙된 객체가 초기화될 때 별도 메서드를 호출하는 것처럼

안드로이드에서도 Inflater를 통해 초기화되는 클래스는 이 클래스 생성자를 통해서만 초기화되고

이 클래스 생성자를 명시적으로 구현하지 않으면 예외가 발생한다.

물론 커스텀 컴포넌트를 직접 코드로 초기화한다면 저 생성자를 호출하지 않겠지만

컴포넌트를 어떻게 사용할지 모르므로 항상 두 생성자 메서드를 명시적으로 구현하는

습관을 들이는 게 좋다.

이런 식으로 커스텀 컴포넌트를 레이아웃 xml에서 사용하면 컴포넌트를 매번 재사용하기가 쉽고

고유 아이디를 매번 일일이 생각하지 않아도 되므로 편하며

컴포넌트 단위로 기능을 캡슐화할 수 있어서 좋다.

이 경우 커스텀 컴포넌트가 컨테이너라면 내부에 있는 컴포넌트의 참조는

커스텀 컨테이너의 공개 API를 통해 (필요한 것들만) 접근할 수 있게 해주면 된다.

크리에이티브 커먼즈 라이센스
Creative Commons License

Posted by joshy21

2011/04/21 03:24 2011/04/21 03:24
Tag
, ,
Response
0 Trackbacks , 0 Comments
RSS :
http://joshy21.com/weblog/rss/response/25

Trackback URL : 이 글에는 트랙백을 보낼 수 없습니다

앙드레 미셸 이후 처음으로...

예전에, 그러니까 한 2001년 쯤일 테니 한 10년쯤 됐을 것이다.

앙드레 미셸이 작성한 코드의 프랑스어 주석을 본 이래 처음으로

이곳에서 프랑스어로 된 코드 관련 설명을 본 것 같다.

내용은 AIR에서 SQLite를 조회할 때 테이블 조인을 할 경우

VO로 어떻게 매핑할지에 대한 건데

해결책은 VO 안에 또 다른 VO를 속성으로 정의한 후

조인한 키에 따라 describeType을 통해 클래스 정보를 추출하고 데이터를 매핑한 후

라벨 함수를 활용해 내부 VO의 값을 반환하는 것이다.

(이해는 되지만... 이게 최선이라는 생각은 안 든다. 유감스럽게도...)

그러고 보니 나도 안드로이드 SQL 자동 매핑 툴을 만들면서 테이블 조인 조건을

생각하지 않은 게 문뜩 떠올랐다. 하지만 아직은 테이블 조인을 할 일도 없고

한다 하더라도 어차피 커스텀 VO를 UI에 매핑하는 곳이 아닌 이상 모두 인터페이스 타입으로

받고 있으므로 아직까지는 현 상태대로 써도 될 것 같다.
크리에이티브 커먼즈 라이센스
Creative Commons License

Posted by joshy21

2011/04/21 01:08 2011/04/21 01:08
Tag
, ,
Response
0 Trackbacks , 0 Comments
RSS :
http://joshy21.com/weblog/rss/response/24

Trackback URL : 이 글에는 트랙백을 보낼 수 없습니다

합성(Composition)에 대해...

사람들은 합성이 더 좋은 거라는 걸

잘 이해하지 못한다.

난 합성이 왜 더 좋은지 이해하지 못하는 사람들을

이해하지 못하겠다.

합성은 상속으로부터 자유롭기 때문에

OOP 원칙에 더 잘 부합된다.

상속은 상속하는 순간

제명이 됐어요


상속 계층구조에 묶여버리기 때문에

아무리 상위 클래스의 메서드를 스텁 함수로 만든다 하더라도

상위 클래스의 로직으로부터 완전히 자유로울 수 없다.

하지만 합성은 설령 상위 클래스가 바뀌더라도

얼마든지 자유롭게 구현할 수 있다.


사실 플렉스 개발자 중에 TextInput 컴포넌트가 실제로는

상속이 아니라 합성으로 구현한 것임을 제대로 알고 있는 개발자가 얼마나 될까?

사실 상속으로 치자면 TextInput 컴포넌트는 그냥 UIComponent다.

그런데 합성을 통해 마치, "훗, 난 처음부터 텍스트 인풋이었다고"라고 말하는 것처럼

누가 보기에도 텍스트 인풋처럼 돼 버렸다(심지어 클래스명까지...)

이처럼 합성은 마법 같은 힘이 있다.

원하는 요소를 모아서 내가 원하는 대로 버무릴 수 있고

내부에서 사용(합성)할 다른 컴포넌트의 속성을 커스텀 컴포넌트에 정의하고

커스텀 컴포넌트에서 내부 클래스 인스턴스로 속성을 잘 전달해주기만 하면

내부 컴포넌트를 얼마든지 부려 쓸 수 있다.

이렇게 되면 상속으로 인한 상위 클래스와의 결합도를 줄일 수 있고

필요한 로직을 언제든 추가하거나 뺄 수 있다.

또 DI나 ioC를 통해 특정 기능을 수행하는 컴포넌트를 동적으로 주입해

기능을 추가하기도 훨씬 쉽다.

예를 들어 안드로이드의 DatePickerDialog도 사실은 상속으로 치자면 AlertDialog지만

내부적으로 private final DatePicker mDatePicker;를 선언해


"내가 바로 데이트피커 다이알로그다"하고 광고하고 있다.


이는 마치 인터페이스와도 닮아 있다.


한 클래스가 다중 클래스를 상속할 수는 없지만 다중 인터페이스를 구현할 수는


있는 것처럼 한 클래스는 여러 내부 클래스 인스턴스를 합성해


마치 여러 기능을 갖춘 클래스마냥 (마치 여러 클래스를 상속한 것처럼)


행동할 수 있다.


이런 사실을 잘 이해하면 얼마든지 AlertDialog를 상속해 또 다른 컴포넌트를


합성할 수 있다. 하지만 이런 사실이 잘 이해되지 않는다면


이해될 때까지 좀 더 공부할 것을 권장한다.
크리에이티브 커먼즈 라이센스
Creative Commons License

Posted by joshy21

2011/04/18 13:03 2011/04/18 13:03
Tag
,
Response
0 Trackbacks , 0 Comments
RSS :
http://joshy21.com/weblog/rss/response/21

Trackback URL : 이 글에는 트랙백을 보낼 수 없습니다

« Previous : 1 : Next »
블로그 이미지

- joshy21

Notices

  1. 안녕하세요 유윤선입니...

Archives

Authors

  1. joshy21

Recent Trackbacks

Calendar

«   2012/02   »
일 월 화 수 목 금 토
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29      

Site Stats

Total hits:
3498
Today:
0
Yesterday:
7