336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.

위치기반 서비스를 구현하기 위해서는 스마트폰 기기내의 GPS, 가속도 센서 등을 이용하여 현재위치정보를 얻습니다.

안드로이드에서는 Google Maps API (구글맵스API)와 안드로이드 위치 기반 관련 라이브러리(android.location.Library)를 이용합니다!

 

 

 

 
  Google Maps Service에 접근하는 인터페이스를 제공하는 패키지로써 주요 클래스는 맵을 표시하는  MapView 클래스와 MapView를 Activity를 관리하는 MapActivity 클래스 등으로 구성되어 있습니다.
 
 
  android.location Package
 
  GPS나 무선랜 등의 정보를 이용하여 휴대전화의 현재 위치 정보(위도,경도)를 얻기 위한 기능을 제공하는 패키지로써 시스템의 위치 서비스(Location Service)의 접근을 제공하는 LocationManager 클래스, 위치정보와 주소정보를 변환하는 Geocoder 클래스, GPS엔진 상태를 표현하는 GpsStatus 클래스 등으로 구성되어 있습니다.
 

 

 

Google Maps (구글맵스)  API Key 발급 받기 :-)

 

Google Maps API 데이터를 받으려면  API Key를 발급받아야합니다. (무료)

 

1) SDK 디버그 서명증명서의 MD5 핑거프린터 확인하기

 

먼저 미리 설치해두신 JDK가 설치된 폴더의 bin폴더에 있는 Keytool를 이용해야합니다.

확인해주세용~

 

 

Keytool를 손쉽게 이용하기 위해서는 path가 등록되어야합니다.

내컴퓨터-속성-고급탭-환경변수-시스템변수의 path 항목에 JDK의 bin폴더가 지정되어있지 않으면, 지정해주세요!

 

지정이 되었으면 이제 keytool을 이용하여 MD5 핑거프린터를 확인해야합니다.

CMD창에서 다음과 같이 입력해주세요'-'

 keytool -list -alias androiddebugkey -keystore debug.keystore -storepass android -keypass android

MD5의 핑거프린터를 확인하셨으면, 복사해서 보관해주세요~

 

 

 

2) Google에서 API Key발급받기

 

 http://code.google.com/android/maps-api-signup.html 로 가셔서

 MD5 핑거프린트를 [My certificate's MD5 fingerprint] 란에입력하시고 구글계정으로 들어가면 API Key를 발급받을수 있습니다.

 

 

<결과 >

 

 

제꺼는 왜 깨져서 나왔는지 -_ㅜ

암튼, 처음에 있는게 사용자 키 API Key입니다!

 

 

3) 안드로이드에서 Google Maps API를 사용하기

 

AndroidManifest.xml

 

 

 

Application에서 com.google.android.maps라이브러리 추가!

 

 

Permission에서 인터넷 추가!!

 

main.xml

 

 

 
<?xml version="1.0" encoding="utf-8"?>
<com.google.android.maps.MapView
    xmlns:android="http://schemas.android.com/apk/res/android"
    android:id="@+id/mapview"
    android:layout_width="fill_parent"
    android:layout_height="fill_parent"
    android:clickable="true" //클릭(터치)으로 맵 이동 가능
    android:apiKey="자신이 발급받은 apikey 입력"
/>

 

HelloMaps.java (메인 엑티비티 )

 

 

package babyjaycee.blog.me;


import com.google.android.maps.MapActivity;
import com.google.android.maps.MapView;
import android.os.Bundle;


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


        MapView mapView = (MapView) findViewById(R.id.mapview);
        mapView.setBuiltInZoomControls(true);  //줌컨트롤을 활성
    }


   @Override
    protected boolean isRouteDisplayed() { //MapAcitivity의 추상메소드 .상속하면 꼭 써줘야함! 라우트정보에 관한것
return false;
    }
}

 

 <결과>

 

 

 

 

블로그 이미지

By훈트

,
336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.
일반적으로 어플리케이션에서 자료를 저장할 때 데이터베이스를 주로 사용합니다. 그런데, 한 어플리케이션 내에 저장되어 있는 데이터베이스에는 해당 어플리케이션 외에 다른 어플리케이션이 접근하는 것이 불가능합니다. 그렇다면, 다른 어플리케이션의 데이터에 접근할 수 있는 방법은 아예 없는 것일까요? 그렇지 않습니다. 만약 이렇게 데이터베이스 공유가 "완전히" 불가능할 경우 엄청난 재앙(?)이 발생합니다.

다른 어플리케이션에서 특정 어플리케이션의 데이터베이스에 직접 접근하는 것은 불가능합니다.


주소록 어플리케이션은 주소록 데이터를 데이터베이스에 저장하게 되는데, 이 주소록 데이터베이스에 주소록 어플리케이션만 접근 가능하고 다른 어플리케이션에서는 접근이 불가능하다면 주소록 정보를 이용하여 다른 서비스를 연동하는 것은 불가능하겠지요? 자칭 "경계가 없는 어플리케이션"을 추구하고 있는 안드로이드에서 기본적인 데이터 공유도 되지 않는다면 그건 말도 안되는 일이겠지요..

이 문제를 종합해보자면, 외부 어플리케이션이 마음대로 내 데이터베이스에 접근하지는 못하게 함과 동시에 내가 가진 데이터베이스 중 원하는 것들만 공유할 수 있도록 해주는 수단이 필요합니다. 안드로이드에서는 이런 역할을 컨텐트 프로바이더(Content Provider)라는 녀석이 해주게 됩니다.

컨텐트 프로바이더는 어플리케이션 내의 데이터베이스를 다른 어플리케이션이 사용할 수 있는 "통로"를 제공해줍니다. 이 과정에서 컨텐트 프로바이더를 통해 외부 어플리케이션이 접근할 수 있는 범위를 정해줄 수 있어, "공유할 것만 공유하는" 것이 가능합니다.

컨텐트 프로바이더와 컨텐트 리졸버

컨텐트 프로바이더를 사용하여 안드로이드 시스템의 각종 설정값이나 SD카드 내의 미디어 등에 접근하는 것이 가능합니다. 컨텐트 프로바이더에 접근하기 위해서는 해당 컨텐트 프로바이더의 주소가 필요합니다. 

컨텐트 프로바이더에 접근할 때는 컨텐트 프로바이더의 주소와 컨텐트 리졸버(Content Resolver)가 필요합니다. 컨텐트 리졸버는 컨텐트 프로바이더의 주소를 통해 해당 컨텐트 프로바이더에 접근하여 컨텐트 프로바이더의 데이터에 접근할 수 있도록 해주는 역할을 합니다.

컨텐트 리졸버는 액티비티 클래스 내의 getContentResolver()메소드를 통해 인스턴스를 받아올 수 있습니다. 일단 컨텐트 리졸버의 인스턴스를 받아온 후에는 query, insert 등의 메소드을 통해 데이터를 받거나 입력, 수정하고 싶은 컨텐트 프로바이더의 URI(Uniform Resource Identifier)를 넘겨주면 해당 컨텐트 프로바이더에 접근하여 요청한 작업을 수행할 수 있습니다. 

컨텐트 리졸버 및 컨텐트 프로바이더를 통한 데이터베이스 접근



컨텐트 프로바이더의 주소 구성

컨텐트 프로바이더의 주소는 컨텐트 프로바이더를 생성할 때 지정하며, URI(Uniform Resource Identifier) 형식으로 구성되어 있습니다. URI라는 단어 자체가 좀 생소할지도 모르겠습니다. 하지만 어렵게 생각할 것은 없습니다. URI는 우리가 인터넷 상의 자원의 주소를 표시할 때 쓰는 URL(Uniform Resource Identifier)의 상위 개념으로, 어떠한 자원의 위치를 표기하기 위한 형식입니다.

컨텐트 프로바이더의 주소(URI)는 일반적으로 아래와 같은 모습을 하고 있습니다.

content://AUTHORITY/PATH

인터넷 주소가 http:// 로 시작하는 것처럼, 컨텐트 프로바이더는 content://로 시작하는 주소를 가지고 있습니다. URI에서 http, content 등을 스키마(Scheme)라 합니다.

다음으로, AUTHORITY 부분입니다. AUTHORITY는 컨텐트 프로바이더의 고유 주소로, 뒤에 붙에 될 PATH와 함께 다른 어플리케이션에서 해당 컨텐트 프로바이더에 접근하기 위한 주소를 구성합니다. AUTHORITY는 다른 어플리케이션과 중복되면 안되므로, 일반적으로 자바 패키지 이름을  짓는 방식을 따라 이름을 지어줍니다. (예 : com.androidhuman.example) 인터넷 주소(URL)으로 치자면 사이트의 주소 (예:www.google.com) 부분이라 보시면 됩니다.

마지막으로 PATH(경로)는 즉 해당 프로바이더에서 제공하는 구체적인 데이터의 위치를 나타냅니다. 인터넷 주소로 치자면 세부 주소 (예: www.google.com/phone에서 phone 부분)라 할 수 있습니다.


컨텐트 프로바이더에서 제공하는 자료의 유형 구분

컨텐트 리졸버와 컨텐트 프로바이더의 주소를 통해 컨텐트 프로바이더에서 제공받는 데이터는 하나의 데이터일 수도 있고, 어떤 유형의 데이터 목록일 수도 있습니다. 이는 일반적으로 컨텐트 프로바이더의 주소를 통해 구분할 수 있지만, 좀 더 명확하게 해주기 위해 타입(MIME Type)을 지정해줍니다.

만약, 아래와 같은 컨텐트 프로바이더의 주소가 있다고 가정해봅시다.

contents://com.androidhuman.phoneprovider/phones

위의 컨텐트 프로바이더는 휴대폰 정보를 제공하는 컨텐트 프로바이더라 가정해보겠습니다. 위의 컨텐트 프로바이더의 AUTHORITY는 com.androidhuman.provider이고, Path는 phones 임을 알 수 있습니다. 위와 같은 형태의 주소는 일반적으로 어떤 항목에 해당하는 모든 데이터를 반환합니다. 위와 같은 경우는 모든 휴대폰 번호를 반환할 것이라 예측할 수 있죠.

Path는 컨텐트 프로바이더에 따라 여러 구조를 가질 수 있습니다. 아래와 같이 제조사별 휴대폰 목록을 제공하는 컨텐트 프로바이더가 있을 수도 있지요.

contents://com.androidhuman.phoneprovider/phones/lg
contents://com.androidhuman.phoneprovider/phones/samsung
contents://com.androidhuman.phoneprovider/phones/htc
contents://com.androidhuman.phoneprovider/phones/motorola

이런 식으로 "여러 개의 데이터"를 반환하는 컨텐트 프로바이더 주소(URI)는 타입으로 아래와 같은 형식을 갖습니다.

vnd.android.cursor.dir/vnd._CUSTOM_NAME_

위의 휴대폰 정보를 제공하는 컨텐트 프로바이더에서 휴대폰 목록을 제공하는 URI의 타임은 아래와 같이 지정할 수 있겠죠.

vnd.android.cursor.dir/vnd.androidhuman.phone

위와 같이 여러 개의 자료가 아닌, 딱 하나의 자료를 가리키는 컨텐트 프로바이더의 주소도 있습니다. 일반적으로 아래와 같은 형태를 하고 있지요.

contents://com.androidhuman.phoneprovider/phones/lg/1
contents://com.androidhuman.phoneprovider/phones/samsung/3

하나의 데이터를 가리키는 컨텐트 프로바이더의 URI는 위와 같이 뒤에 해당 데이터의 ID를 붙인 형태를 띕니다. 이러한 컨텐트 프로바이더 URI는 타입으로 아래와 같은 형태를 갖습니다.

vnd.android.cursor.item/vnd._CUSTOM_NAME

위의 컨텐트 프로바이더에서 휴대폰 하나를 가리키는 URI의 타입은 아래와 같이 표현할 수 있겠죠.

vnd.android.cursor.item/vnd.androidhuman.phone


컨텐트 프로바이더 URI 정리

컨텐트 프로바이더 URI에 대해 다시 한번 정리해보도록 합시다.



1. 컨텐트 프로바이더에 의해 제공되는 데이터임을 알립니다. 이 부분은 변하지 않습니다.
2. 컨텐트 프로바이더의 authority부분입니다. 각 컨텐트 프로바이더의 고유 이름입니다.
3. 컨텐트 프로바이더의 Path 부분이며, 어떤 데이터를 반환할지를 이 부분을 통해 지정합니다. 
4. 3번 부분의 Path 하위의 데이터 중 하나를 가리키는 것으로, 해당 데이터의 ID를 나타냅니다.


컨텐트 프로바이더는 일반적으로 아래와 같은 구조를 가집니다.

  • 어플리케이션의 컨텐트 프로바이더의 고유 주소 (AUTHORITY)
  • URI 필터링을 위한 UriMatcher객체 및 컨텐트 프로바이더가 처리할 수 있는 URI들
  • URI에 따른 Type을 반환하는 메소드
  • insert, update, delete, query 메소드
  • 어플리케이션 데이터베이스 정의부

[출처] http://androidhuman.tistory.com/279

블로그 이미지

By훈트

,
336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.
요즘 Motorola, LG 에서도 안드로이드 폰을 국내에서 출시하며,
IPhone 대항마의 역할로써 안드로이드 폰이 어느 정도 자리를 잡아가고 있는 것 같습니다.
TV만 보고 있어도 하루에도 여러 번씩 SKT 안드로이드 폰 광고를 볼 수도 있기도 하구요.
때문에 오늘은 안드로이드에 대한 재밌는 상식 하나를 소개할까 합니다.

아시는 분도 계시겠지만, Android 플랫폼의 버젼명은 디저트 종류 음식 이름을 애칭으로 가지고 있습니다.
최초 버젼인 1.5 는 Cupcake(컵케익), 1.6 은 Donut(도넛), 최근의 2.0 버젼이후 2.1까지는 Eclair(이클레어) 라고 불리고 있죠.
2010년 5월경 출시될 다음버젼 이름은 Froyo(프로요 : Frozen Yogurt)가 확정된 상태입니다.


Froyo 의 다음 버젼은 Gingerbread(진저브레드)라는 것도 거의 확정인 상태 이지요.

 

딱 보고 감이 오시나요?

Cupcake
Donut
Eclair
Froyo
Gingerbread

Cupcake 을 시작으로 Android Version 닉네임의 제일 첫 글자는 알파벳 순서로 증가하고 있습니다.
아마 Gingerbread 다음 버젼은 H 로 시작하는 디저트 이름이 닉네임으로 붙게 되겠지요? H 로 시작하는 디저트가 뭐가 있을까요? 
H 로 시작하는 음식 이름도 Hotdog, Hamburger 를 제외하면 딱히 생각이 안나는 군요... ^^
여러분들이 한 번 맞춰 보도록 하세요~

아래는 구글의 PM 인 Ryan Gibson 이 라디오 방송에서 얘기한 Andorid Version 에 대한 이야기 입니다.

Q: How did Android versions come to be named after desserts?
A: We wanted an alphabetical naming scheme that would also provide a fun theme for our small release celebrations.  We considered predatory animals, and stomach viruses but they are a lot less fun to have at a party.

Q: What were the "A" and "B" desserts? Apple crumb? Babka?
A: There actually were no "A" and "B" software updates named after a dessert. It just started with Cupcake.

Q: Who determines the dessert names?
A: It's a collaborative effort from the entire team, company, spouses, Google chefs, random passer-bys and the Android development community all throwing out ideas and recipes.  My office door is festooned with suggestions for the future.  It is very motivational to look up from work and see pictures of tasty treats.

Q: Are the desserts actually served at the Google cafeteria at any point?
A: Absolutely!

Q: Have you determined any desserts past "F"?
A: The discussion is as heated as an oven full of cupcakes  We would like to have a Gingerbread House, but that depends a lot on what happens with the housing market by then. 

 

※ 일반적으로 Phone의 버젼명에 의미 없는 숫자나 날짜를 기반으로 한 버젼명을 사용하는데요. 
힘든 개발 환경속에서의 이런 사소한 잔 재미를 찾고 만들어 실행하는 것이 구글의 창의적인 결과물의 원동력의 일부라고 봐도 되겠지요??

※ 이런식의 작명법은 Ubuntu 의 Project가 원조라고 하네요.



블로그 이미지

By훈트

,