There will be case that your custom list item doesn’t respond when you click…so what’s the reason and what’s the solution?

Here several problems and solutions:


1. Scenario: list item layout contains CheckBox

Problem: OnItemClickListener doesn’t respond.

Reason: CheckBox is also having its own click listener by default to change its state, and it overrides the container ListView.

Solution: remove focus on CheckBox by setting these attributes to “false”

1
2
android:focusable="false"
android:focusableInTouchMode="false"



2. Scenario: random

ProblemOnItemClickListener just doesn’t repond any at all!!!!

Reason: No idea..

Solution: in code, just set OnItemClickListener before setting Adapter. It works randomly @@!



3. Scenario: list item contains ImageButton

ProblemOnItemClickListener just doesn’t repond any at all!!!!

Reason: No idea!!!

Solution: in code, set ImageButton focus to “false”

1
2
ImageButton button = (ImageButton) convertView.findViewById(R.id.imageButton);
button.setFocusable(false);



4. Scenario: list item contain TextView

ProblemOnItemClickListener just doesn’t repond.

Reason: I think you have set this attribute to TextView: android:inputType=”textMultiLine”

Solution: just remove that attribute, using android:minLines/android:maxLines instead.



5. Scenario: list item contain a TextView that is linked to website URL or whatever “mailto:” things

ProblemOnItemClickListener just doesn’t repond.

Reason: the TextView overrides focus of list item.

Solution: just remove attribute “android:autoLink” on TextView.

 

Hope you solve your problems!

Cheers,

Pete Houston


출처 http://xjaphx.wordpress.com/2011/07/14/listview-doesnt-respond-to-onitemclicklistener/

저작자 표시 비영리 동일 조건 변경 허락
신고
Posted by 우너효

■ 주석의 개념

    - 코드에 대한 개요와 코드 자체만 가지고 이용할 수 없는 추가적인 정보 제공

    - 프로그램을 읽는 것과 이해하는 것에 관계된 정보만을 포함하고 있어야 한다.

    - 중복된 주석은 피해야 한다.

    - 주석을 추가해야만 할 정도의 프로그램이라면 재작성을 고려해야 한다.

    - 특수문자(Form feed, backspace 등)를 포함하면 안된다.


■ 주석의 종류 

    - 문서주석 : '/**      */'에 의해 경계가 결정, javadoc 툴을 사용하여 HTML 파일로 축출

    - 구현주석 : '/*      */'과 '//'에 의해 경계가 결정, 개별적 구현에 대한 주석, 코드와는 상관없는 주석


■ 문서주석

    - 자바 클래스, 인터페이스, 생성자, 메서드, 필드 들을 성명

    - 주석 경계기호인 '/**  */' 안에 들어감

    - 클래스, 인터페이스, 맴버 당 하나씩 들어감

    - 선언 바로 전에 나와야 함.

    - 최 상위 레벨의 클래스와 인터페이스들은 열여쓰기를 하지 않고 멤버들(변수, 메서드)은 들여쓰기를 한다.

    - 클래스에 대한 문서주석의 첫 번째 줄은 들여쓰기를 하지 않고 그 다음에 나오는 문서주석은 별표를 수직으로 맞춘다(1개의 스페이스 포함)

    - 생성자를 포함한 멤버들은 문서주석 첫 줄에서 4개의 스페이스로 들여쓰기를 하고 그 이후는 5개의 스페이스 들여쓰기를 한다.

    - 문서주석에 적절하지 않은 클래스, 인터페이스, 변수, 메서드에 대한 정보를 제공하려면 선언 바로 후에 block 주석이나 single line 주석을 사용한다.(클래스의 구현에 대한 세부사항은 class 선언 다음에 block 주석을 사용)

    - Java는 문서주석을 주석 이후 처음 나오는 선언문과 연결시키므로 문서주석은 메서드, 생성자 정의 블록 내부에 위치하면 안된다.


○ 클래스 설명 주석(Document comments)

    - import 문 다음에 기술

    - 블록주석을 사용

    - 각 라인은 *로 시작

    - 해당 클래스에 대한 기능과 용도 기술

    - <pre>...</pre>내용은 수정하지 않음

    - Serialize 기능이 뭔지 모르겠음.(버전관리 프로그램 관련?)

 

/**

 * Serialize 기능을 사용하여 file에 object를 저장

 * <pre>

 * input : input.txt   - 입력데이터 파일

 * output : output.txt - 출력데이터 파일

 * Table : none 

 * </pre>

 *

 * <pre>

 * <b>History:</b>

 *    작성자, 1.0, 2007.3.9 초기작성

 * </pre>

 *

 * @author 최종 수정자

 * @version 1.0, 2007.5.5 메서드 추가

 * @see    None

 */



○ 맴버변수 설명 주석

    - 변수 상단에 위치

    - 블록주석을 사용

    - 용도, 제한사항 등을 기술

    ※ 맴버변수의 기술 순서 : constant - static - primitive - reference


○ 맴버함수 설명 주석

    - 함수의 상단에 위치

    - 블록주석을 사용

    - 메서드 기능설명은 한 두줄로 간결하게 기술

    - 메서드의 파라미터를 type명과 변수명을 적고 간략하게 설명

    - 리턴변수, 예외사항 설명

 

/**

 * 메서드의 기능설명은 한 두줄로 간결하게..

 *

 * @param int list1 메서드의 파라미터 설명, type명과 변수명을 적고 간략하게 설명

 * @return

 * @exception 예외사항한 라인에 하나씩

 */



○ 기타 주석처리

    - 코드 내부의 짧은 statement 뒤의 주석은 //로

    - 맴버변수 정의시 인자가 많으면 각 인자를 한행에 하나씩 기술, 같은 행에 주석 기재

    - 코드가 산만하지 않게 주석을 멀리 사용

    - /*.........*/는 테스트 목적으로 활용했던 부분을 남김

    - 주석의 시작은 항상 라인의 처음에서 시작하며 각 라인은 *로 시작

    - 블럭내 주석은 사용하지 않는다(특별한 경우 제외)

    - 의문점이나 해결못한 것은 임시주석으로 사용(/*-  ..............*/)



■ 구현주석 : block, single-line, trailing, end of line


○ block 주석

    - 파일, 메서드, 자료구조, 알고리즘의 설명 제공

    - 각각의 파일이 시작될 때와 메서드 전에 사용

    - 메서드 안에 존재하는 block 주석은 설명하는 코드와 같은 레벨로 들여쓰기

    - block 주석의 형식을 고치는 일이 일어나지 않는 특별한 block 주석은 /*- 으로 시작

    - 코드의 나머지로부터 분리하기 위해 처음 한줄은 비워둔다.

 

/*

 * 여기에 block comment 작성

 */

 

/*-

 * 형식을 고치지 않는 특별한 block 주석

 * 들여쓰기가 무시되는 특별한 주석

 * :

 * :

 */



○ single line 주석

    - 짧은 주석은 뒤에 따라오는 코드와 같은 레벨의 들여쓰기를 하는 한줄로 나타남

    - 한 줄로 써지지 않는다면 block 주석 형식을 따라야 함


 if(condition) {

/* single line 주석 */

:

}

    if(condition2){

    */ single line 주석 */

    ....

    }



○ trailing 주석

    - 매우 잛은 주석의 경우 코드와 같은 줄에 나타난다.

    - 코드와의 확실한 구별을 위해 충분히 멀리 떨어뜨림.


if(condition) {                              /* trailing 주석 */

return TRUE ;

}

else {

    return expressionReturn();               /* trailing 주석 */

}



○ end of line 주석

    - 한 줄 모두를 주석처리 하거나 한 줄의 일부분을 주석처리

    - 본문 주석을 위하여 여러 줄에 연속되어 사용하면 안됨

    - 코드섹션을 주석처리 하기 위하여 여러 줄을 연속하여 사용 가능


if(condition) {                          // end of line 주석

    expression1 ;

    expression2 ;

}

else {                                   // end of line 주석

    expression3 ;

    expression4 ;

}

 

// 블럭을 통째로 주석처리 할 경우

// if(condition2) {

//     expression5 ;

//     expression6 ;

// }

// else {

//     expression7 ;

//     expression8 ;

// }

 


■ javadoc로 HTML 문서 생성

    - 개발한 클래스의 모든 설명주석(/* ,.......*/)은 javadoc을 이용하여 HTML 문서 형태로 클래스의 API를 문서화 한다.

    - javadoc은 jdk를 이용한다.


javadoc verbos author version d <대상 디렉토리> <java 소스 파일명>



■ HTML / JavaScript 주석

    - 설명주석 : 블록주석(<!--  ......  // -->)을 사용하며 각 라인은 '*'로 시작한다.


<!

 

* 사용자 정보 조회

*

* history :

*           작성자, 1.0, 2006.3.9 초기 작성

* author : 최종수정자

* version : 1.1 2007.3.10 - javascript 함수 추가

* see : 관련된 모듈 기술

*

//-->



출처 : Tong - NetSET님의 틀이부#프로그래밍언어통


저작자 표시 비영리 동일 조건 변경 허락
신고
Posted by 우너효

#자바를 이용한 웹 서버 개발 환경 이해하기.

이번 ‘휴먼디자인프로젝트'를 하면서 가장 먼저 해야 하는 것은 바로 Github를 통한 협업이 가능한 로컬 개발 환경 구축이었다. 3명의 팀원이 동시에 개발을 진행해야 했기 때문이다.


일단 웹 서버는 자바를 기반으로 만들기로 했다. 배경 지식이 전무한 상태에서 제대로 될 리는 없었다. 일단 이전처럼 개발환경 세팅과 관련한 책을 찾았고 그렇게 발견한 책이 ‘Head First Servlet & JSP”였다. 일단 이 책을 적어도 1주일동안 읽고 공부하기로 팀원들과 계획을 세웠다.


하지만 그 계획은 제대로 이루어지지 않았다. 어느 정도 책을 읽고나면 로컬 개발 환경을 구축할 수 있을 거라는 막연한 생각을 했었지만, 책을 아무리 읽어도 도저히 감은 잡히지 않았다.


결국 NEXT의 조영호 교수님께 로컬 개발 환경과 관련하여 도움을 받기로 했다. 


스터디가 시작되면서 교수님의 자바 웹 서버와 Servlet, JSP에 대한 관계는 다음과 같은 한 문장이었다.


자바를 통해 웹 서버를 개발하려면 정해진 룰에 따라야 한다는 것이다. 


그에 관련한 룰에 대한 스펙이 바로 서블릿과 JSP였다. 우리 팀은 마치 서블릿과 JSP만 알면 다 될 거라 생각하고 ‘Head First’만 매달리고 있었으니 로컬 개발 환경 설정이 막연하게 느껴진 것은 당연했다.


무언가를 공부해야 한다면, 정말 그에 알맞은 자료나 책을 조사하고 선택하는 것이 가장 중요한 일인데도 불구하고 이를 잊고 너무 태만하게 공부한 탓에 팀 전체에 아까운 시간을 날리게 된 셈이다.


구체적인 서블릿이나, JSP의 스펙을 이번 포스트에서는 다루지 않는다. 어차피 ‘Head First Servlet & JSP’에서 매우 상세하게 다루고 있기 때문이다. 기타 디렉토리 구조 가이드도 역시 마찬가지이다.


# 로컬 개발 환경에 대한 메이븐의 필요성

각각의 로컬 개발 환경을 가지게 될 개발자들의 컴퓨터에는 컨테이너라고 부르는 Apache tomcat을 설치하게 된다. 그러다 보니, 컴퓨터 별로 개발 환경의 상세 디렉토리 구조는 달라지기 마련이다. 하지만, 매우 기본적인 뼈대 디렉토리는 (webapps나  sample과 같은) 기본적으로 같다. 약속이기 때문이다.


그리고 각각의 페이지(login이나 logout)에 대해 해당하는 기능을 구현하는 자바로 구현한, 즉 서블릿을 갖게 된다. 그러한 서블릿들을 컴파일하여 생성된 클래스 파일들은 tomcat 내의 디렉토리로 옮겨주면 된다. (이것이 바로 흔히 개발 서버에서 불리는 ‘배포’라는 작업이다.) 하지만, 매번 컴파일을 할 때마다 생성된 클래스 파일들은 새로이 tomcat에 복사하는 것은 매우 귀찮은 과정이다. 이러한 과정을 자동화 한 도구들은 여러가지가 있지만 이번 프로젝트에 주로 사용하는 것은 ‘이클립스’와 ‘메이븐’이다.


조금 더 자세히 설명해보자.


한 개발자가 자신의 랩탑에 자바 프로젝트를 생성한다. 이 프로젝트 내에는 servlet.java 라는 식의 서블릿을 다수 가지고 있게 될 것이다. 그리고, 필요한 라이브러리 (*.jar)들도 프로젝트 내에 보유하게 된다. 또, WEB-INF라는 디렉토리 내에 web.xml 등의 파일을 만든다.

그리고 컴파일 된 클래스들을 보관하기 위한 임의의 B라는 디렉토리를 생성한다. 이 때, tomcat에 테스트를 하기 위해서는 생성된 클래스 파일들을  tomcat에 복사하기만 하면 된다. 


이렇듯 프로젝트 별로 디렉토리의 구조는 달라질 수 밖에 없게 된다. 이러한 차이점은 협업이나 공유가 이루어지는 환경에서는 큰 단점으로 작용했고, 이로 인해 ‘표준 디렉토리 구조’라는 것을 제정하게 된다.

이러한 표준 디렉토리 구조를 바로 ‘메이븐’이라고 부른다.


메이븐은 빌드 도구이다. 특별한 점이 있다면, 표준 구조가 있다는 점이다. 즉, 메이븐을 통해 빌드를 하게 되면 소스 구조는 모두 같아지게 된다. 메이븐 이전에는 라이브러리를 사용하려면 프로젝트 내에 달아야 했지만, 메이븐을 사용하면 pom.xml의 설정을 통해 필요한 라이브러리도 ‘Maven Repository’에서 자동으로 다운 받아서 사용할 수 있게 된다.


메이븐에는 ‘아르케타입’이라는 것이 존재한다. 자바를 이용해 자주 작업하는 전형적인 프로젝트에 알맞게 디렉토리의 표준 구조를 뜻한다. 

이클립스와 메이븐을 동시에 사용 할 경우, 메이븐에서 이루어지는 각종 빌드 작업들은 이클립스가 자동으로 처리하게 된다. 기본적으로 메이븐을 통해 빌드를 하게 되면 war 파일이 생성이 되고, 이를 tomcat에 설치하는 게 일반적인 과정이었다. 하지만 이클립스의 도입 이후 위의 과정은 전부 자동화되었다. 


pom.xml에는 메이븐 자체의 빌드에 대한 상세 설정이 들어 있지 않다. 왜냐하면, 메이븐 내부적으로 빌드와 관련된 상세 순서나 설정이 이미 내장되어 있기 때문이다. 


기본적으로 메이븐을 통한 프로젝트는 이클립스에서 인식하지 못한다. 이 때, 메이븐 빌드 시, goal로 eclipse:eclipse를 설정하여 이클립스에서도 인식이 되게끔 할 수 있다. 이렇게 된 이유는, 이클립스는 ‘도구’에 불과하기 때문이다. 도구 별로 프로젝트를 인식하는 방법은 달라지기 마련이므로, 메이븐에서 일괄적으로 환경을 설정하여 빌드 할 수 없는 것은 당연하다.


즉, 메이븐이 하는 역할을 요약하면 다음과 같다.


표준적인 디렉토리 구조를 생성한다.

표준적인 빌드 절차(프로세스)를 가지고, 빌드를 수행한다.


개발자가 해야 할 일은 코딩과, 빌드에 필요한 리소스들만 명시해주면 된다.


# 배포와 출시

휴디처럼 여러 명이 팀을 이루어 개발이 이루어지게 될 경우 전체적인 개발 환경은 다음과 같다.


(다수의 개발자(로컬)) — 버전관리시스템(gitHub, svn) — 개발 서버 — 라이브 서버


다수의 개발자들이 개발 및 push한 코드는 gitHub에 쌓이게 된다. 그렇게 쌓인 코드에 대한 테스트나 데모 등은 개발 서버에서 이루어지고, 그러한 작업을 마친 프로젝트는 사용자가 이용할 수 있는 라이브 서버로 이동하게 된다.

이 때, gitHub에 있는 코드를 개발 서버에 전송한 뒤 메이븐으로 빌드를 해서 개발 서버 내의 tomcat에 올리는 작업이 필요하다. 조금 생각해 보면 이러한 작업은 매우 반복적인 작업임을 알 수 있다. 즉, 이러한 작업 또한 자동화 해주는 도구가 필요하다. 이러한 도구를 ‘지속적 통합 툴’, CI라고 부르며 대표적으로 jenkins라는 도구가 있다. 


이전에 박재성 교수님이 메이븐 강의 시간에 말씀 하셨던, 서버에서 빌드가 실패했을 때 알림이 가는 그 빌드의 순간이 바로 이 곳에서 이루어지는 빌드이다.

이러한 도구의 필요성은 협업 환경에서 매우 중요해진다. 다수의 개발자가 코드를 수정하는 만큼, 빌드 실패가 일어났을 때와 그 실패 여부가 개발자에게 알려질 때 까지의 기간은 짧을 수록 팀에게 유리해지기 때문이다.


gitHub에서 개발 서버로 코드를 가져온 뒤, 메이븐을 통해 빌드를 하고, 생성된 war 파일을 tomcat에 올리는 작업을 ‘배포’라고 부른다.

이렇게 배포된 버전 중, 충분한 테스트를 거친 버전은 라이브 서버로 옮겨서 (빌드를 마친 뒤 클래스 파일들을) 라이브 서버 내의 tomcat에 복사하게 된다. 이를 ‘출시’라고 부른다.



개발이라는 과정에는 사람의 노력이 매우 필요한 부분도 많지만, 컴퓨터를 통해 충분히 자동화 할 수 있는 부분들이 있다. 저러한 도구들을 왜, 어떻게 사용되는 지를 이해하면 개발 환경 설정에 대해 좀 더 빠른 이해를 할 수 있지 않을까 하는 생각이 든다.


 #번외: fabric

규모가 큰 서비스의 경우, 라이브 서버가 2대 이상으로 구성되기 마련이다. 이 경우, 각 라이브 서버 간의 통합을 유지하기 위한 도구가 바로 fabric이다.

저작자 표시 비영리 동일 조건 변경 허락
신고
Posted by 우너효