Eclipse (Europa 3.4.0)에서 구글(Google) 안드로이드(Android) 개발환경 구축하기
Eclipse (Europa 3.4.0)에서 구글(Google) 안드로이드(Android) 개발환경 구축하기 -- Ko,jinhyuk
뜨겁게 달아오르고 있는 오픈 모바일 OS 인 Android 개발환경을 만들어 보자. 현재의 Eclipse Europa 최신버전 (3.4.0)에 맞춰져 있어.. Google 에서 Install Guide와 일부 용어에서 다른부분이 있을수있다.
1. Eclipse 는 이미 설치되어있다고 가정하고 진행한다.
2. Android SDK를 다운로드 한다. 다운로드 링크 -> android_sdk_windows_m3-rc22a.zip (59 MB, checksum aa3dee05a9872752a3bc4efd0f93e98b)
3. tools 디렉토리를 환경변수 PATH 에 등록 한다. C:/android_sdk_windows_m3-rc22atools 를 환경변수에 등록한다. (내 컴퓨터 속성->고급->환경변수 메뉴에서 추가)
4. ADT (Android Development Tools ) Eclipse plug-in 설치
ADT는 Eclipse에서 Android 개발 프로젝트 보다 편리하게 할수있도록 지원하는 플러그인 이다. 다른 일반적인 Eclipse 플러그인 처럼 설치해주면된다.
온라인 설치를 해주면 되는데 업데이트 링크는 https://dl-ssl.google.com/android/eclipse/ 이다.
그림-2) 재시작시 위처럼 메시지가 표시된다.
그림-3) Windows -> Preference 에서 좌측에 Android 선택 SDK Location 에 앞서 압축을 풀어준 경로를 선택해준다.
여기까지 하면 Plug-in 까지 설치는 완료된것이고 이후 새로운 버전이 나오면 Help > Software Updates > Find and Install.... 실행 해서 업데이트를 해주면된다.
5. Android Project 생성하고 빌드하기
그림-4) File -> New -> Project... 을 선택한다.
그림-5) 프로젝트 Package name, Activity name, Application name 과 Project name 을 넣고 Finish
그림-6) 생성된 프로젝트 트리 구성이다. 좌측은 Navigator에서 우측은 Package Explorer 에서 펼쳐진 모양
생성된 프로젝트는 src/ , bin/ 디렉토리와 res/, assets/ 디렉토리를 만들고 기본적인 파일들도 자동으로 생성되어져 있다. 각각의 디렉토리와 파일에 대한 설명은 이후에 다시 알아보기로 하고...
그림-7) 메뉴 Run 에서 Debug Configurations... 나 Run Configurations... 를 선택해준다.
그림-8)
아이콘을 선택하면 신규 실행 설정을추가하게 된다.
그림-9) Configuration의 이름 (예: FirstConfigruation)을 입력하고 디버깅 또는 실행할 프로젝트를 선택해주고 Apply 를 누르면 Launch 가 생성된다. 바로 Debug버튼을 클릭해주면 디버깅이 시작된다.
그림-10) Debug를 실행하면 구글폰 모양의 Emulator 와 디버깅창그리고 (처음 설치후 실행시) 감사의 메시지가 나타난다.
그림-11) SDK개발에 도움일 될수있도록 사용 통계정보를 전송에 협조할것인지를 묻는다. 이후 설정은 변경할수있다.
![]()
그림-12) 실행화면과 Application 메뉴에 추가된 HelloWorld App 아이콘
여기까지 기본 개발환경설치를 해서 실행까지 해봤다.. 추가적으로 개발관련된 글도 .. 기회가되면 슬슬 올려볼까한다.
뜨겁게 달아오르고 있는 오픈 모바일 OS 인 Android 개발환경을 만들어 보자. 현재의 Eclipse Europa 최신버전 (3.4.0)에 맞춰져 있어.. Google 에서 Install Guide와 일부 용어에서 다른부분이 있을수있다.
1. Eclipse 는 이미 설치되어있다고 가정하고 진행한다.
2. Android SDK를 다운로드 한다. 다운로드 링크 -> android_sdk_windows_m3-rc22a.zip (59 MB, checksum aa3dee05a9872752a3bc4efd0f93e98b)
2.1 압축을 푼다. C:/android_sdk_windows_m3-rc22a 에 압축을 푼것으로 가정한다. ( 백슬레쉬를 슬레쉬로 표시하더라도... 이해해주길..)
서브디렉토리에 docs,tools,samples 를 포함하고 있다.
서브디렉토리에 docs,tools,samples 를 포함하고 있다.
3. tools 디렉토리를 환경변수 PATH 에 등록 한다. C:/android_sdk_windows_m3-rc22atools 를 환경변수에 등록한다. (내 컴퓨터 속성->고급->환경변수 메뉴에서 추가)
4. ADT (Android Development Tools ) Eclipse plug-in 설치
ADT는 Eclipse에서 Android 개발 프로젝트 보다 편리하게 할수있도록 지원하는 플러그인 이다. 다른 일반적인 Eclipse 플러그인 처럼 설치해주면된다.
온라인 설치를 해주면 되는데 업데이트 링크는 https://dl-ssl.google.com/android/eclipse/ 이다.
그림-1) ADT 설치를 위한 경로 추가
OK -> Finish 를 클릭해주면 사이트추가가 되고 설치에 들어갈 plug-in을 다운로드 한다. 동의 여부를 묻는화면에서 agree 해주고 나서 Install All 을 클릭해주면 된다. 그리고 나서 Eclipse 재시작.
OK -> Finish 를 클릭해주면 사이트추가가 되고 설치에 들어갈 plug-in을 다운로드 한다. 동의 여부를 묻는화면에서 agree 해주고 나서 Install All 을 클릭해주면 된다. 그리고 나서 Eclipse 재시작.
그림-2) 재시작시 위처럼 메시지가 표시된다.
그림-3) Windows -> Preference 에서 좌측에 Android 선택 SDK Location 에 앞서 압축을 풀어준 경로를 선택해준다.
여기까지 하면 Plug-in 까지 설치는 완료된것이고 이후 새로운 버전이 나오면 Help > Software Updates > Find and Install.... 실행 해서 업데이트를 해주면된다.
5. Android Project 생성하고 빌드하기
5.1. 프로젝트 생성
그림-4) File -> New -> Project... 을 선택한다.
그림-5) 프로젝트 Package name, Activity name, Application name 과 Project name 을 넣고 Finish
그림-6) 생성된 프로젝트 트리 구성이다. 좌측은 Navigator에서 우측은 Package Explorer 에서 펼쳐진 모양
5.2. Launch 설정하기, Eclipse 내에서 개발된 프로그램을 바로 실행하기 위해서는 Run/Debug 실행설정을 해주어야 한다.
그림-7) 메뉴 Run 에서 Debug Configurations... 나 Run Configurations... 를 선택해준다.
그림-8)
그림-9) Configuration의 이름 (예: FirstConfigruation)을 입력하고 디버깅 또는 실행할 프로젝트를 선택해주고 Apply 를 누르면 Launch 가 생성된다. 바로 Debug버튼을 클릭해주면 디버깅이 시작된다.
그림-10) Debug를 실행하면 구글폰 모양의 Emulator 와 디버깅창그리고 (처음 설치후 실행시) 감사의 메시지가 나타난다.
그림-11) SDK개발에 도움일 될수있도록 사용 통계정보를 전송에 협조할것인지를 묻는다. 이후 설정은 변경할수있다.
그림-12) 실행화면과 Application 메뉴에 추가된 HelloWorld App 아이콘
Java 프로젝트를 빠른 분산소스관리도구 Mercurial를 이용해 버전 관리 하기 간단버전- Windows 버전
Java 프로젝트를 빠른 분산소스관리도구 Mercurial를 이용해 버전 관리 하기 간단버전- Windows 버전 by Ko,jinhuyk
0) 환경
1) 설치하기
2) 기존에 있던 (Java) 프로젝트를 Mercurial 프로젝트로 만들기
이렇게 한뒤 다른곳에 사본을 만들거나 중앙서버로 만들곳에 사본을 만들어주는 것이 서버에 import 해주는것과 같게된다. 기존에는 서버/클라이언트 관계가 분명해서 중앙서버에만 실제리파지토리 파일이 올라가고 관련 entry 정보만 클라이언트에 있는 구조였다면 Mercurial을 각 관리위치별 클라이언트 하나하나가 바로 리파지토리 하나가 되고 이 리파지토리는 다른 곳에 http나 ssh로 공유 되는 구조로 관리되는 것이다. 특별히 서버 클라이언트가 정해지는 구조가 아니라는 점이다. 여러 리파지토리(클라이언트들)들중 하나(또는 여러개)를 서버라고 생각하면 되는 것이다.
실제로 서버 리파지토리를 구성할때 현재 내가 만든 로컬리파지토리에서 http 서버를 띄워 이곳에서 부터 clone을 만드는 방식으로 하게될 것이다.
3) 서버실행과 클라이언트 작업
4) 서버쪽에 실제 작업소스에 반영하기
5) 끝으로
간단히 PC 2대에서 각각 서버 , 클라이언트로 가상해서 기존의 소스리파지토리를 구성해서 변경된 소스의 반영을 해볼수있는 테스트수준으로 정리해보았다.
Mercurial을 분산소스관리를 지원하는 개념이라 실제 각 작업환경에 리파지토리를 갖고 있는 형태로 각 로컬내에서 commit/update를 하고 다른 서버나 pc 와는 push/pull 을 통해 동기화를 해주는 형태라고 보면된다.
이것은 본사에서 작업하던 프로그램을 (네트워크 단절, 보안, 성능 등의 이유로) 외부프로젝트로에서 분리하여 버전관리를 진행하고 다시 본사로 push해주는 것 (실제로는 변경된 부분을 뜻하는 tip 이라는 개념을 이용한 변경의 동기화를 하는 방법등도 활용하여)도 손쉽게 가능하게 해줄수있는 솔루션이 될것으로 보인다.
---------------참고자료------------------------------------
또다른 분산 소스관리도구 Arch 라고..
http://www.gnuarch.org/revc/index.html
분산소스관리에 대한 소개
http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/
버전관리에 대한 이해
http://betterexplained.com/articles/a-visual-guide-to-version-control/
http://www.selenic.com/mercurial/wiki/
0) 환경
1) 설치하기
윈도우즈 버전은 간단히 사이트에서 윈도우용 바이너리를 설치하면된다. 바이너리 다운로드 하기 http://mercurial.berkwood.com/
설치가 끝나면 (다른경로를 선택하지 않았다면) C:Mercurial에 설치가 되고 (path에 추가되어)cmd 화면에서 hg 명령이 실행가능해진다.
여기까지 설치끝이고
가) 사용자 명 설정
기본적으로 Mercurial에 접속하는 사용자 정보를 %USERPROFILE%Mercurial.ini 에 넣어준다.
============ 파일 - 1) %USERPROFILE%Mercurial.ini ================
===========================================================
이렇게 넣어준 파일은 commit 에 대한 기록과 Repository 로 접근 하는데 기본적인 접속 정보로 사용된다.
설치가 끝나면 (다른경로를 선택하지 않았다면) C:Mercurial에 설치가 되고 (path에 추가되어)cmd 화면에서 hg 명령이 실행가능해진다.
여기까지 설치끝이고
가) 사용자 명 설정
기본적으로 Mercurial에 접속하는 사용자 정보를 %USERPROFILE%Mercurial.ini 에 넣어준다.
============ 파일 - 1) %USERPROFILE%Mercurial.ini ================
[ui] |
이렇게 넣어준 파일은 commit 에 대한 기록과 Repository 로 접근 하는데 기본적인 접속 정보로 사용된다.
2) 기존에 있던 (Java) 프로젝트를 Mercurial 프로젝트로 만들기
가) 리파지토리준비
cvs 에 init 명령을 수행하는 것과 같은 작업이라고 보면된다. Mercurial 는 간단히 해당위치에서 'init' 명령을 실행해주면 되고 초기화된 디렉토리에 .hg 라는 디렉토리를 생성하고 메타파일들을 준비하게 된다.
============ 실행 - 1) ================
===========================================================
이렇게 해주면 기존 프로젝트 디렉토리내에 .hg 라는 간단히 리파지토리영역이 (메타정보및 commit된 파일들 보관소) 마련된다.
| pc1>cd ProjectMyProject pc1>hg init |
이렇게 해주면 기존 프로젝트 디렉토리내에 .hg 라는 간단히 리파지토리영역이 (메타정보및 commit된 파일들 보관소) 마련된다.
나) 버전관리 제외 파일 설정하기
프로젝트 소스를 관리하는 경우 해당 경로에는 바이너리나 특정 자동 생성 파일들과 같이 버전관리가 필요없는 파일또는 경로가 있게 된다. 이러한 파일을 설정하기위해서는 프로젝트의 루트 디렉토리 (.hg 디렉토리가 보이는)에 .hgignore파일을 생성해주면된다.
java 프로젝트 같은 경우 build나 bin 같은 바이너리 디렉토리가 여기에 해당 되는 경우이다.
java 프로젝트 같은 경우 build나 bin 같은 바이너리 디렉토리가 여기에 해당 되는 경우이다.
============ 파일 - 2) projectRoot.hgignore ================
===========================================================
위 파일을 만들어 넣어주면 파일에 있는 패턴에 해당되는 영역이나 파일은 add 대상에서 제외 된다.
| syntax: glob *.orig *.rej *~ *.o build/* syntax: regexp .*#.*#$ |
위 파일을 만들어 넣어주면 파일에 있는 패턴에 해당되는 영역이나 파일은 add 대상에서 제외 된다.
다) 파일들 최초 리파지토리에 저장하기
============ 실행 - 2) ================
===========================================================
============ 실행 - 2) ================
| pc1>hg add pc1>hg commit |
.hg 디렉토리안에 store 밑으로 파일들이 저장된다.
이렇게 한뒤 다른곳에 사본을 만들거나 중앙서버로 만들곳에 사본을 만들어주는 것이 서버에 import 해주는것과 같게된다. 기존에는 서버/클라이언트 관계가 분명해서 중앙서버에만 실제리파지토리 파일이 올라가고 관련 entry 정보만 클라이언트에 있는 구조였다면 Mercurial을 각 관리위치별 클라이언트 하나하나가 바로 리파지토리 하나가 되고 이 리파지토리는 다른 곳에 http나 ssh로 공유 되는 구조로 관리되는 것이다. 특별히 서버 클라이언트가 정해지는 구조가 아니라는 점이다. 여러 리파지토리(클라이언트들)들중 하나(또는 여러개)를 서버라고 생각하면 되는 것이다.
실제로 서버 리파지토리를 구성할때 현재 내가 만든 로컬리파지토리에서 http 서버를 띄워 이곳에서 부터 clone을 만드는 방식으로 하게될 것이다.
3) 서버실행과 클라이언트 작업
가) 다음은 방금 만든 리파지토리를 웹서버로 제공하기
============ 실행 - 3) ================
===========================================================
나) 다른 PC 또는 리파지토리에서 로컬 리파지토리 구성하기
============ 실행 - 3) ================
===========================================================
위는 pc1 을 서버로 하여 실행하고 pc2에서 클라이언트가 되어 서버쪽의 리파지토리에 대한 clone을 구성하게 된다. 이후 pc1 에서 작업을 하고 난뒤 pc1으로 push 해주면된다. (pc1에서 pull로 pc2의 것을 가져올수도 있다.)
다) pc2에서 소스 변경된 뒤에 서버에 반영하기
============ 실행 - 4.1) ================
===========================================================
위의 경우는 정상적인 경우이고 처음에 실행하면 다음과 같은 에러가 발생할것이다.
============ 실행 - 3) ================
| pc1>hg serve -n "MyLocalRep" -p 8001 |
나) 다른 PC 또는 리파지토리에서 로컬 리파지토리 구성하기
============ 실행 - 3) ================
| pc2>hg clone http://pc1:8001/path/ newname pc2>cd newname |
위는 pc1 을 서버로 하여 실행하고 pc2에서 클라이언트가 되어 서버쪽의 리파지토리에 대한 clone을 구성하게 된다. 이후 pc1 에서 작업을 하고 난뒤 pc1으로 push 해주면된다. (pc1에서 pull로 pc2의 것을 가져올수도 있다.)
다) pc2에서 소스 변경된 뒤에 서버에 반영하기
============ 실행 - 4.1) ================
| pc2>hg commit pc2>hg push http://pc1:8001/path/ pushing to http://pc1:8001/path searching for changes adding changesets adding manifests adding file changes added 1 changesets with 1 changes to 1 files |
위의 경우는 정상적인 경우이고 처음에 실행하면 다음과 같은 에러가 발생할것이다.
============ 실행 - 4.2) ssl required error 발생의 경우 ================
===========================================================
이것은 기본적으로는 ssl을 사용하는 프로토콜을 이용하도록 하고 있어서 발생하는 문제 이다. 파일3) 처럼 보면 push_ssl = false 해서 무시하게 할 수 도있다.
============ 실행 - 4.3) 사용자 에러 ================
===========================================================
이 에러는 사용자 인증 실패 인경우 나타나게 되는데 실제 사용자관리를 서버쪽에서 해주거나 간단하게 실험적형태로 사용해보려는 경우에는 allow_push = * 를 해주면된다.
| pc2>hg commit pc2>hg push http://pc1:8001/path/ pushing to http://pc1:8001/path searching for changes ssl required |
이것은 기본적으로는 ssl을 사용하는 프로토콜을 이용하도록 하고 있어서 발생하는 문제 이다. 파일3) 처럼 보면 push_ssl = false 해서 무시하게 할 수 도있다.
============ 실행 - 4.3) 사용자 에러 ================
| pc2>hg push http://pc1:8001/path/ pushing to http://pc1:8001/path searching for changes push not authorized |
이 에러는 사용자 인증 실패 인경우 나타나게 되는데 실제 사용자관리를 서버쪽에서 해주거나 간단하게 실험적형태로 사용해보려는 경우에는 allow_push = * 를 해주면된다.
============ 파일 - 3) projectRoot.hghgrc ================
간단하게 서버구성을 해보려는 경우에는 아래처럼 해주면된다. 실제 운영환경에서 허락된 사용자의 접근만을 허용하려는 경우에는 allow_push = 사용자명1,사용자명2 형태로 넣어주면된다.
간단하게 서버구성을 해보려는 경우에는 아래처럼 해주면된다. 실제 운영환경에서 허락된 사용자의 접근만을 허용하려는 경우에는 allow_push = 사용자명1,사용자명2 형태로 넣어주면된다.
[web] |
===========================================================
4) 서버쪽에 실제 작업소스에 반영하기
============ 실행 - 5) pc1 작업영역 소스에 반영하기 ================
| pc1>update 1 files updated, 0 files merged, 0 files removed, 0 files unresolved |
===========================================================
pc2에서 pc2로 push 해준내용은 pc2의 .hg영역에 저장되어있다. 이를 실제 작업소스에 반영하기 위해서는 다시 update를 해주어야한다.
pc2에서 pc2로 push 해준내용은 pc2의 .hg영역에 저장되어있다. 이를 실제 작업소스에 반영하기 위해서는 다시 update를 해주어야한다.
5) 끝으로
간단히 PC 2대에서 각각 서버 , 클라이언트로 가상해서 기존의 소스리파지토리를 구성해서 변경된 소스의 반영을 해볼수있는 테스트수준으로 정리해보았다.
Mercurial을 분산소스관리를 지원하는 개념이라 실제 각 작업환경에 리파지토리를 갖고 있는 형태로 각 로컬내에서 commit/update를 하고 다른 서버나 pc 와는 push/pull 을 통해 동기화를 해주는 형태라고 보면된다.
이것은 본사에서 작업하던 프로그램을 (네트워크 단절, 보안, 성능 등의 이유로) 외부프로젝트로에서 분리하여 버전관리를 진행하고 다시 본사로 push해주는 것 (실제로는 변경된 부분을 뜻하는 tip 이라는 개념을 이용한 변경의 동기화를 하는 방법등도 활용하여)도 손쉽게 가능하게 해줄수있는 솔루션이 될것으로 보인다.
---------------참고자료------------------------------------
또다른 분산 소스관리도구 Arch 라고..
http://www.gnuarch.org/revc/index.html
분산소스관리에 대한 소개
http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/
버전관리에 대한 이해
http://betterexplained.com/articles/a-visual-guide-to-version-control/
http://www.selenic.com/mercurial/wiki/