Android 설치방법 및 예제실행^#

관련링크 : http://developer.android.com/sdk/1.6_r1/installing.html#installingplugin

• 다운로드 받기 ^#

  • : http://developer.android.com/sdk/1.6_r1/index.html

• 압축풀고 자신이 원하는 위치에 압축풀기^#

• 설정하기(Linux의 경우)^#

  • .bash_profile or .bashrc 파일을 연다.
  • export PATH 항목이 있으면, 끝에 설치경로/tools 를 추가하면 된다.
  • export PATH 항목이 없으면, export PATH=${PATH}:<your_sdk_dir>/tools 를 추가한다.

• 이클립스에 ADT Plugin 설치하기^#

위의 방법을 잘 따라하면 된다. ^^, 이클립스 재시작

• 이클립스 설정하기^#

  01. Preferences -> Android 클릭 : SDK Location 에 Android 설치한 위치를 연다.^#

  02. Apply or OK 를 클릭한다.^#

•  Create an AVD(Android Virtual Device) : 안드로이드용 가상 장치(my_avd)를 생성하는 과정입니다.^#

1. android create avd --target 2 --name my_avd

--target option is required and specifies the deployment target to run on the emulator.
--name option is also required and defines the name for the new AVD.

• Android 입문 따라하기 : Hello, Android 출력하기^#

관련링크 : http://developer.android.com/guide/tutorials/hello-world.html

01. Android Project 생성하기(File -> New -> Project)^#

02. Android -> Android Project 선택^#

• Project name: HelloAndroid
• Application name: Hello, Android
• Package name: com.example.helloandroid (or your own private namespace)
• Create Activity: HelloAndroid
• Min SDK Version: 4

각 항목별 설명 - 해석은 나중에^#

03. Finish 클릭^#

04. 생성된 프로젝트를 열어보면 다음과 같다.^#

04. HelloAndroid.java 내용^#

package com.example.helloandroid;

import android.app.Activity;
import android.os.Bundle;

public class HelloAndroid extends Activity {
    /** Called when the activity is first created. */
    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.main);
    }
}

05. 실행 클릭^#

06. 실행된 모습 - 에뮬레이터 상단에 보면 my_avd 가 보일 것이다. 아까 Create an AVD 에서 생성된 안드로이도 가상 장치 명칭임.^#

- 실행되는데 시간은 컴퓨터 마다 다를 것 같다.

07. Android 실행모습^#

Hello, Android 출력화면.

시스템 종료 모습

이 글은 스프링노트에서 작성되었습니다.

이 글은 스프링노트에서 작성되었습니다.

  잘 만들어진 코드란 요구사항을 정확히 만족하는 코드이다. 그런데 현실에선 요구사항들이 끊임없이 변하기 때문에 만족시키기란 쉽지 않다. 결론적으로 변화하는 요구사항을 안정적으로 잘 동작시키는 코드가 잘 짠 코드라고 말 할 수 있다. 그런 의미에서 객체지향이 관심의 대상이 되고 각광받는 이유는 구조적 프로그래밍으로 대변되는 기존의 방식들에 비해 요구사항을 보다 유연하고 안정적으로 만족시키기 때문이다.

개발하기에 가장 좋은 방법은 수준 높은 개발자들 여럿이서 서로 원하는 수준에서 활발히 커뮤니케이션을 하면서 일하는 것이다. 하지만 우리가 일하는 현실을 돌아보자. 회사 내에서 모든 개발자가 같은 수준에서 개발할 수는 없다. 중급 개발자와 초급 개발자가 똑같은 수준에서 개발을 할 수는 없을 것이다.

통일성이나 수정의 용이성 같은 말은 사실 아주 쉬운 의미이다. 함수들의 공통점을 묶고 나아가 클래스간의 공통점을 묶고 컴포넌트간의 공통점을 묶고 이렇게 잘 묶어서 정리하다보면 그게 바로 객체지향 프로그래밍이고 컴포넌트 프로그래밍이다. 물론 프로그램의 크기가 커질수록 묶는 개념도 커지고 요구사항이나 제품의 방향에 따라 고려해야할 것도 많아지지만 언제나 기본에 충실하라. 공통점 묶기가 객체지향의 초석임을 잊지 말자.

공통점 묶기와 조금만 알기는 객체지향 언어에서 상속, 다형성, 캡슐화보다 더 중요한 개념이다. 공통점을 묶고 조금만 알기 위해 노력하다 보니 상속, 다형성, 캡슐화가 필요하게 되고 더불어 추상화(Abstaction), 일반화(Generalization)라고 세분화(Specialization)도 이루어지는 것이다.

  모든 이론이나 개념은 경험적 발전과 필요에 의해 탄생한 것이고 왜 필요하게 된 것인지를 이해하는 것이 단순히 그 정의와 내용을 공부하는 것보다 훨씬 중요하다. 객체지향의 결정판이라고 알려진 디자인 패턴을 어렵게 느끼는 이유 중 하나는 경험의 산물로 보지 않고 공부해서 익혀야 되는 것으로 인식하기 때문이다. 또 캡슐화에 관해 모든 변수를 반드시 private으로 선언해야 한다는 법이 있는 것은 아니다. 모든 개발자가 어떤 변수는 직접 접근하고 어떤 변수는 접근하면 안된다는 것을 안다면 왜 안되겠는가? 하지만 현실적으로 모두가 똑같은 지식과 레벨에서 개발할 수 없으므로 언어가 이런 점들을 지원해주는 것이다.

  언어는 개발자의 실수를 언어가 최대한 막아주어 생산성을 높이는 방향으로 발전한다는 점을 기억하자.

  모든 클래스는 하나의 책임만을 가진다.

  "이 클래스가 무슨 일을 하는 클래스입니까?" 라는 질문에 "이 클래스는 A라는 일을 합니다." 라고 간단히 대답할 수 있어야 한다. "이 클래스는 맑은 날엔 A라는 일을 하고 비오는 날엔 B라는 일을 하고 안개 낀 날에는 C라는 일을 합니다."라고 대답한다면 클래스의 의미를 정확히 파악할 수 없다. 우리가 클래스를 만드는 이유가 관련된 데이터를 하나로 묶어서 이해하기 쉽도록 하는 것인데 클레스가 너무 많은 책임을 가지면 이해하기가 쉽지 않다. 만약 이렇게 여러가지 책임을 가져야 한다면 클래스를 나눌 것을 강력 추천한다. 객체지향에서 제일 어려운 일 중 하나는 관련된 정보로만 클래스를 구성하는 일이다. 변수 하나, 함수 하나를 넣을 때 "과연 이 기능이 이 클래스에 들어가는 것이 맞을까?"에 대해 고민해야 한다. 클래스 하나가 이일 저일 다하게 되는 신(GOD) 클래스가 된다면 그건 그냥 거대한 코드 덩어리일 뿐 어떠한 방법론의 코드도 아니다.

  클래스는 하나의 책임만을 가진다라는 대명제를 중심에 놓는다면 상속으로 이루어진 클래스 트리 전체는 하나의 책임으로 묶인다고 볼 수 있다. 이런 이유로 Java는 단일 상속만을 지원하지만 부족함이 없는 것이다(Java의 상속은 extends 키워드를 사용한다).

  인터페이스 상속(Java에서는 implements)에 대해 알아보자. 앞서 클래스는 하나의 책임을 가짐과 동시에 상속받는 클래스 트리는 하나의 책임으로 묶여진다고 이야기 했다. 하지만 C++의 다중 상속이나 Java의 인터페이스 구현은 필요하기 때문에 존재하는 것이다. 여기서 혼란이 올 수 있다. 두 클래스에서 상속을 받으면 상속받은 자식 클래스는 두 개의 책임을 지는 것이 되니 하나의 책임을 지는 룰에 위배된다고 생각할 수 있다. 하지만 클래스 상속과 인터페이스 상속은 그 의미가 분명히 다르다. 클래스 상속은 분명 부모와 자식간에 같은 책임을 가지지만 작동하는 형태가 다른 것을 의미한다. 반면 인터페이스 상속은 기능을 추가하거나 클래스 간의 통신을 하기 위한 방법을 제공한다는 의미이다.

  모든 클래스는 하나의 책임만을 가지고 이런 클래스들이 서로 통신하면서 동작하는 것이 객체지향 프로그래밍이다. 이 때 클래스들이 만나는 방법(사전에서 경계면, 접점으로 표현한 부분)을 인터페이스라고 부른다.   Java에서는 모든 함수가 가상 함수(Virtual Function)로 동작하므로 virtual 키워드를 붙이지 않아도 된다. 어쨌든 Java에서는 class 키워드 대신에 더 의미가 분명한 interface 키워드를 제공한다.

  객체지향에서는 클래스 하나를 작성하는 것보다 클래스 사이의 관계를 작성하는 것이 더 중요하다. 클래스 자체가 문제라면 문제 범위를 클래스로 좁힐 수 있지만 클래스 사이의 관계가 문제가 되면 관련된 모든 클래스의 동작 방식이 문제가 되기 때문이다.

  완전한 클래스와 인터페이스 사이에 있는 개념이 추상 클래스이다. 추상 클래스는 인터페이스 개념을 잘 이해하였다면 쉽게 이해할 수 있다. 추상 클래스는 그 이름에서 알 수 있듯이 클래스의 한 종류이다. 하지만 클래스 전체를 다 구현하지 않고 자식 클래스에서 구현의 일부를 위임하기 때문에 실제(Concrete) 클래스라고 부르지 않고 추상(Abstract) 클래스라고 부르는 것이다. Java에서는 추상 클래스를 위한 키워드로 abstract라는 키워드를 지원하여 의미를 더욱 분명히 하였다. 엄밀히 따지면 인터페이스를 작성할 때 구현을 하지 않는 것을 원칙으로 한다. 하지만 인터페이스를 잘 정의하지 못한 상황에서 인터페이스 구현을 하다 보면 자식 클래스들에서 중복으로 구현되는 기능들이 있다. 이런 기능들의 공통점 묶기를 써서 부모 클래스, 즉 인터페이스에 일부 구현하는 경우가 있다. 이 때 java에서는 명백히 인터페이스를 추상 클래스로 변경하도록 컴파일러가 요구한다. 정석대로라면 추상 클래스는 상속 계층에서 책임을 지는 부모 클래스로만 만드는 것이 좋고 인터페이스는 다른 클래스와의 관계만을 기술하므로 구현이 없는 것이 좋다. 하지만 개발을 하다 보면 편의상 인터페이스에 일부 구현을 할 수 있으며 이때는 구현이 있다고 추상 클래스로 보는 것보다는 원래 목적대로 인터페이스로 보는 것이 타당하다.

정리

  객체지향 프로그래밍의 기본 단위는 클래스이다. 모든 클래스는 단 하나의 책임을 가지는 것이 좋다. 레고 부품을 조립하는 것처럼 각자의 책임을 가지는 클래스를 우리가 어떻게 조립하는가에 따라 결과물이 달라진다. 객체지향을 통한 재사용의 강력함은 이 분해와 조립에 있다고 할 수 있다. 클래스를 조립할 때 서로 다른 책임의 클래스를 연결하는 방법은 클래스들을 직접적으로 연관시켜서 할 수 있지만 이 방법은 결합도와 복잡도를 증가시키므로 좋은 방법이 아니다. 결합도와 복잡도는 클래스를 연결시켜주는 인터페이스 사용을 통해 낮출 수 있다. 한편 결합도와 복잡도를 낮춘다는 의미는 확장성을 높인다는 의미로 해석할 수 있다. 인터페이스도 클래스 사이를 연결시켜 주는 책임을 가지는 또 다른 클래스의 형태라고 할 수 있다.

이 글은 스프링노트에서 작성되었습니다.

1. 두 함수(show(), show2()를 비교하라.

1. public class ShowTest {
       public void show(String cmd){
           if ( cmd.equals("Test")){
               System.out.println("cmd is Test");
           }
       }
      
       public void show2(String cmd){
           if( "Test".equals(cmd)) {
               System.out.println("cmd is Test");
           }
       }
   }

1. // 1번 문제는 equals(String cmd)에 null 값이 들어갔을 경우에 대한 질문... ㅡㅅ-)> 그런 경우는 생각을 안해봤어!!
   //그런 경험은 있지만... equals() 안에 들어가는 파라메터가 null 일 때 생기는 경우는 종종 있지.... ㅡㅅ-)>
   public class Main {
       public static void main(String[] args) {
           //String cmd = null;  //이 경우에는 show()에서 NullPointerException을 발생한다. 요게 질문의 핵심인듯.
           //String cmd = "Test"; //이 경우에는 show(), show2() 모두 정상적으로 실행
           String cmd = "test"; // 이건 당연히 둘다 반응 없음.
          
           ShowTest test = new ShowTest();
           test.show(cmd);
           test.show2(cmd);
       }
   }

2.고쳐야 할 부분은 어디!?

1. public class ShowTest2 {
       public void show(String cmd){
           if ( cmd.equals("Test") && cmd != null ){ // 넘겨받은 cmd가 null일 경우에는 NullPointerException이 발생.
               System.out.println("cmd is Test");
           }
       }
   } //cmd.equals("Test") 이 부분을 "Test".equals(cmd) 수정해주면 정상적인 처리가 되겠지요.... ㅡㅅ-)> 잇힝!!!

1. public class Main2 {
       public static void main(String[] args) {
           //String cmd = "Test";
           String cmd = null;
           ShowTest2 test = new ShowTest2();
           test.show(cmd);
       }
   }

3.이 경우에는 어떻게 나올까?

1. public class ShowTest3 {
       public static void main(String[] args) {
           boolean a;
           boolean c;
           a = c = true;
          
           if ( ( a = true ) || ( c = false )){ // true or false ==> true 이니까....
               System.out.println("1:" + a + "   " + c); // 요 녀석이 출력된다. 조건문 안에서 대입하는건 안좋아요...ㅡㅅ-)!!
           }
          
           if ( ( a = true ) && ( c = false)){ //true && false ==> false 이니까.... 다시 물으니까... 당황해서 답을 제대로 못했다. ㅠㅅ-)
               System.out.println("2:" + a + "   " + c);
           }
       }
   }

4.String, StringBuffer, StringBuilder의 차이점(셋다 문자열 객체)

참고 : http://hongsgo.egloos.com/2033998 요 글을 보면, String < StringBuffer < StringBuilder 속도 차이가 있다. 흠... String은 적게 쓰는게 좋군요. ㅡㅅ-);;

참고 : http://cacky.tistory.com/36

• String : 변경되지 않는 Character 문자열 객체
  문자열이 변경되지 않을 경우에는 String 사용
• StringBuffer : 값이 변경 가능 // 동기화 가능 : 다중 스레드 일 경우에 사용
  문자열이 변경되고 다중 스레드에서 사용될 경우 사용
• StringBuilder : 값이 변경 가능 // 동기화 되지 않음 : 단일 스레드일 경우에 사용
  문자열이 변경되고, 단일 스레드에서 사용될 경우 사용

5.가비지 컬렉션을 줄이기 위한 프로그래밍

Java에서는 기본적으로 가비지 컬렉션에 대해서는 JVM에서 처리를 해주기 때문에 크게 신경을 쓰지 않아도 된다고 배웠다. ㅡㅅ-)>

굳이 줄이는 방법을 떠올려보자면,

• open() 했으면 close() 해준다.
• { 열었으면 } 닫아라.
• 가비지 컬렉션 타임을 줄여라. 군요.
• 참고  : http://blog.empas.com/bizk2y/24709240
• http://kr.sun.com/developers/tech_docs/web07/wireless01.html

6.Statement와 PreparedStatement의 차이

이 글은 스프링노트에서 작성되었습니다.