바쁜척쟁이 개발자의 블로그

http://www.enjoydev.co.kr 도메인이 놀고 있어서 현재 서버에 임시페이지를 만들어 연결시키고 있다. 

이 페이지는 나를 표현하는 각 사이트들을 한데에 모아놓고 사용할 계획이다. 

Flickr에 올려진 사진들을 이용해 갤러리 형태로 보여주고 싶었다. 

Flickr에도 Open API가 존재하긴 하지만, 이걸 언제 다 만드니 -_-;

구글링을 잠깐 해보았더니, 역시나 누군가가 이미 만들어놓은 페이지가 있었다. 

방법은 간단했다. 일단 아래의 가이드문서 페이지로 가보자. 

가이드문서 : http://net.tutsplus.com/tutorials/php/how-to-create-a-photo-gallery-using-the-flickr-api/

영어라고 당황하지 말자. 

소스 다운로드 버튼을 눌러 필요한 소스들을 다운로드 받는다. 

다운로드 받은 소스에서 config.php 파일을 에디터로 열어서 API Key와 UserName 항목을 입력해 준다. 

API Key가 없다면 Flickr 사이트에서 발급받으면 된다. 

그 다음으로는 Flickr 사이트와 Auth연동 처리를 담당해주는 모듈을 다운로드 받아야 하는데.

다운로드 페이지 : http://code.google.com/p/phpflickr/downloads/list

위 페이지에서 쉽게 다운로드 받는다. 

아까 다운로드 받은 UI 파일들과 방금 받아놓은 연동모듈 파일들을 모두 서버의 한 디렉토리에 놓고 테스트를 위해 브라우저로 경로를 입력해보자. Flickr에 올려놓은 이미지들이 잘 보여진다면 성공한 것이다. 

그런데 썸네일의 크기와 보여지는 갯수등을 수정하고 싶을 수도 있다. 

갯수를 수정하려면 index.php 파일을 에디터로 열어 아래의 주석부분의 설정값을 변경하면 된다. 

// Get the user's public photos and show 21 per page

크기를 수정하려면 마찬가지로 index.php 파일의 foreach 구문의 width=\"95\" height=\"95\" 부분을 수정하면 된다. 크기는 커졌는데 화면에 보여지는 갯수가 줄어들었다면 style.css 파일을 열어 아래의 구문에 너비값을 수정해주자. 

#thumbs {width:950px}

그런데 내 티스토리에서는 왜 이미지가 안 올라가는 것일까.

보통의 안드로이드 어플들 내부적으로 검색기능이 존재하지 않는 경우가 많기도 하며, 정말 좋은 효과를 얻을 수 있는 QSB라는 프레임워크가 내장되어 있음에도 활용하지 아니하는 경우가 많다. 아래의 QSB 프레임워크를 적극 활용하여 어플 외부에 있는 사용자들은 우리의 어플 내부로 끌어들이는 방안에 대해 알아보자. 

Adding Custom Suggestions 
http://developer.android.com/guide/topics/search/adding-custom-suggestions.html

When using the Android search dialog or search widget, you can provide custom search suggestions that are created from data in your application.

안드로이드 검색 다이얼로그나 검색위젯을 사용할때에, 당신은 당신의 어플리케이션 내의 데이터로부터 만들어진 커스텀 검색제안을 제공할 수 있습니다.

For example, if your application is a word dictionary, you can suggest words from the dictionary that match the text entered so far.

예를들어 당신의 어플리케이션이 단어사전이라면, 당신은 입력된 글자와 매칭하여 사전으로부터 단어들을 제안할 수 있습니다.

These are the most valuable suggestions, because you can effectively predict what the user wants and provide instant access to it.

여기에 가장 값진 제안들이 있습니다. 왜냐하면 당신은 사용자가 원하는 것을 효과적으로 예측할 수 있으며 즉각 그것을 처리하여 제공할 수 있기 때문입니다.

(스크린샷 생략)

Figure 1. Screenshot of a search dialog with custom search suggestions.

보기 1. 커스텀 검색 제안을 이용한 검색 다이얼로그의 스크린샷

Figure 1 shows an example of a search dialog with custom suggestions.

보기 1은 검색 커스텀 제안을 이용한 다이얼로그의 예를 보여줍니다.

Once you provide custom suggestions, you can also make them available to the system-wide Quick Search Box, providing access to your content from outside your application.

일단 커스텀 제안을 제공하면, 또한 당신은 당신의 어플리케이션 외부에서 당신의 컨텐츠에 접근할 수 있도록 하는 시스템 전역적인 QSB에도 그것을 사용가능하도록 만들 수 있습니다.

Before you begin with this guide to add custom suggestions, you need to have implemented the Android search dialog or a search widget for searches in your application.

커스텀 제안을 추가하는 방법에 대한 가이드를 시작하기에 앞서, 당신은 어플리케이션 내에서의 검색을 위한 안드로이드 검색 다이얼로그나 검색 위젯의 구현이 반드시 필요합니다.

If you haven't, see Creating a Search Interface.

만약 아직 구현하지 않으셨다면, 검색 인터페이스를 생성하는 방법을 읽어보세요.

The Basics

When the user selects a custom suggestion, the Android system sends an Intent to your searchable activity.

사용자들이 커스텀 제안을 선택할때에, 안드로이드 시스템은 당신의 검색가능한 액티비티에게 인텐트를 보냅니다.

Whereas a normal search query sends an intent with the ACTION_SEARCH action, you can instead define your custom suggestions to use ACTION_VIEW (or any other intent action), and also include data that's relevant to the selected suggestion.

일반적인 검색 쿼리가 ACTION_SEARCH 액션을 이용해 인텐트를 전송하는 것과는 달리, 당신의 커스텀 제안을 선언하는 것을 대신하여 ACTION_VIEW(또는 어떠한 다른 인텐트 액션)를 사용할 수 있고 또한 선택된 제안과 관련된 데이터를 포함할 수 있습니다.

Continuing the dictionary example, when the user selects a suggestion, your application can immediately open the definition for that word, instead of searching the dictionary for matches.

계속해서 이전 예제를 보면, 사용자가 제안을 선택하였을 때에 어플리케이션은 매칭을 위해 사전을 찾는 것 대신에 즉각적으로 그 단어의 뜻을 오픈할 수 있습니다.

To provide custom suggestions, do the following:

커스텀 제안기능을 제공하려면, 다음과 같이 하시면 됩니다.

  - Implement a basic searchable activity, as described in Creating a Search Interface.

     검색 인터페이스를 생성하는 것을 담고있는 기본 searchable 액티비티를 구현하십시오.

  - Modify the searchable configuration with information about the content provider that provides custom suggestions.

     커스텀 제안기능을 제공할 컨텐츠 프로바이더에 대한 정보를 가진 searchable 설정파일을 수정하십시오.

  - Build a table (such as in an SQLiteDatabase) for your suggestions and format the table with required columns.

     당신의 제안기능을 위한 (SQLite 데이터베이스와 같은) 테이블을 생성하고 필요한 열을 테이블에 구성하십시오.

  - Create a Content Provider that has access to your suggestions table and declare the provider in your manifest.

     당신의 제안기능 테이블에 접근가능하고 매니페스트 설정파일에 프로바이더로 선언한 컨텐츠 프로바이더를 생성하십시오.

  - Declare the type of Intent to be sent when the user selects a suggestion (including a custom action and custom data).

     사용자가 제안기능의 항목을 선택(커스텀 액션과 커스텀 데이터를 포함함) 하였을때에 보내어질 인텐트의 형식을 설정하십시오.

Just as the Android system displays the search dialog, it also displays your search suggestions.

안드로이드 시스템이 검색 다이얼로그를 출력하는 것처럼, 그것은 또한 당신의 검색 제안들을 출력합니다.

All you need is a content provider from which the system can retrieve your suggestions.

당신의 제안을 검색하는데에 필요한 모든 것은 컨텐츠 프로바이더 입니다.

If you're not familiar with creating content providers, read the Content Providers developer guide before you continue.

컨텐츠 프로바이더의 생성에 익숙하지 않은 경우에는 진행에 앞서  Content Providers 개발가이드를 먼저 참조하십시오.

When the system identifies that your activity is searchable and provides search suggestions, the following procedure takes place when the user types a query:

당신의 액티비티가 검색가능하며 검색제안 기능을 제공할 수 있다는것을 시스템이 인식할때에, 사용자의 쿼리 입력시 다음과 같은 일련의 절차가 이루어집니다.

  1. The system takes the search query text (whatever has been typed so far) and performs a query to your content provider that manages your suggestions.

      (현재까지 입력되어진) 검색 쿼리 문장을 시스템이 인식하고 당신의 컨텐츠 프로바이더를 이용하여 당신의 제안기능을 관리하기 위한 검색을 수행합니다.

  2. Your content provider returns a Cursor that points to all suggestions that are relevant to the search query text.

      당신의  컨텐츠 프로바이더는 검색쿼리 텍스트와 관련된 모든 제안항목들을 가리키는 커서를 반환합니다.

  3. The system displays the list of suggestions provided by the Cursor.

      시스템은 커서에 의해 제공된 제안항목 리스트를 출력합니다.

Once the custom suggestions are displayed, the following might happen:

커스텀 제안항목들이 출력되면, 다음과 같은 일들이 일어납니다.

  - If the user types another key, or changes the query in any way, the above steps are repeated and the suggestion list is updated as appropriate.

    사용자가 다른 어떠한 키를 누르는 경우이거나 어떠한 방법으로든 쿼리를 변경하게되면, 위에 언급된 과정이 반복되며 적절하게 업데이트된 제안항목을 리스팅합니다.

  - If the user executes the search, the suggestions are ignored and the search is delivered to your searchable activity using the normal ACTION_SEARCH intent.

     사용자가 검색을 실행하는 경우, 제안항목은 무시되고 일반적인 ACTION_SEARCH 인텐트를 사용하는 당신의 검색가능한 액티비티에게 검색기능을 위임합니다. 

  - If the user selects a suggestion, an intent is sent to your searchable activity, carrying a custom action and custom data so that your application can open the suggested content.

     사용자가 제안항목을 선택하면 어플리케이션이 제안된 콘텐츠를 열 수 있도록 인텐트는 사용자 커스텀 액션과 사용자 정의 데이터를 운반하여 검색 액티비티로 전송됩니다.

Modifying the searchable configuration

To add support for custom suggestions, add the android:searchSuggestAuthority attribute to the <searchable> element in your searchable configuration file. For example:

커스텀 제안기능을 위한 지원을 추가하려면,  android:searchSuggestAuthority 속성을 검색을 위한 설정파일의 <searchable> 항목에 추가하십시오. 예를 들면...

<?xml version="1.0" encoding="utf-8"?>

<searchable xmlns:android="http://schemas.android.com/apk/res/android"

    android:label="@string/app_label"

    android:hint="@string/search_hint"

    android:searchSuggestAuthority="com.example.MyCustomSuggestionProvider">

</searchable>

You might need some additional attributes, depending on the type of intent you attach to each suggestion and how you want to format queries to your content provider.

당신은 각 제안에 첨부하는 인텐트의 유형과 컨텐츠 공급자에게 쿼리를 지정하는 방법에 따라 몇 가지 추가 속성을 해야 할 수 있습니다.

The other optional attributes are discussed in the following sections.

기타 추가적인 속성에 대해서는 다음의 섹션에서 논의하겠습니다.

Creating a Content Provider

Creating a content provider for custom suggestions requires previous knowledge about content providers that's covered in the Content Provider developer guide.

커스텀 제안기능을 위한 컨텐츠 프로바이더를 생성하는 것은 Content Provider 개발가이드에 수록된 컨텐츠 프로바이더에 대한 사전지식을 필요로 합니다.

For the most part, a content provider for custom suggestions is the same as any other content provider.

대부분의 경우, 커스텀 제안기능을 위한 컨텐츠 프로바이더는 일반적인 컨텐츠 프로바이더와 동일합니다.

However, for each suggestion you provide, the respective row in the Cursor must include specific columns that the system understands and uses to format the suggestions.

그러나 당신이 제공하는 각 제안항목에 대해, 커서의 각 행은 시스템이 이해할수 있는 내용 및 제안사항을 양식을 사용하는 특정 열을 포함해야합니다.

When the user starts typing into the search dialog or search widget, the system queries your content provider for suggestions by calling query() each time a letter is typed.

사용자가 검색 다이얼로그나 검색 위젯에 타이핑을 시작할때에, 시스템은 글자가 타이핑 될때마다 query()를 호출함으로서 제안기능을 위한 당신의 컨텐츠 프로바이더를 조회합니다.

In your implementation of query(), your content provider must search your suggestion data and return a Cursor that points to the rows you have determined to be good suggestions.

당신의 query() 구현모듈에서 당신의 컨텐츠 프로바이더는 반드시 제안기능 데이터를 검색해야하며, 좋은 제안항목으로 선별된 행들을 가리키는 커서객체를 반환해야 합니다.

Details about creating a content provider for custom suggestions are discussed in the following two sections:

커스텀 제안기능을 위한 컨텐츠 프로바이더를 생성하는 것에 대한 상세한 내용은 다음 두개의 섹션에서 논의하겠습니다.

Handling the suggestion query

제안 쿼리를 핸들링 하는 방법

  - How the system sends requests to your content provider and how to handle them

     시스템이 당신의 컨텐츠 프로바이더에게 요청을 전달하는 방법과 그것들을 다루는 방법

Building a suggestion table

제안항목 테이블을 생성하는 방법

  - How to define the columns that the system expects in the Cursor returned with each query

     각 쿼리에 의해 반환된 커서내에서 시스템이 이해할 수 있는 열을 정의하는 방법

Handling the suggestion query

When the system requests suggestions from your content provider, it calls your content provider's query() method.

시스템이 당신의 컨텐츠 프로바이더에서 발생한 제안항목을 요청할때에, 시스템은 당신의 컨텐츠 프로바이더의 query() 메서드를 호출합니다.

You must implement this method to search your suggestion data and return a Cursor pointing to the suggestions you deem relevant.

반드시 당신의 검색항목 데이터를 검색할 수 있는 이 메서드를 구현해야하며, 적합한 제안항목을 가리키고 있는 커서 객체를 반환해야 합니다.

Here's a summary of the parameters that the system passes to your query() method (listed in order):

다음은 시스템에서 당신의 query() 메서드로 전달하는 매개변수에 대한 요약내용입니다. (순서대로 나열됨)

uri

   Always a content Uri, formatted as:

   항상 컨텐츠 Uri이며, 형식은 이렇습니다.

   content://your.authority/optional.suggest.path/SUGGEST_URI_PATH_QUERY

   The default behavior is for system to pass this URI and append it with the query text. For example:

   시스템이 이 URI를 통해 쿼리문장을 추가하는 것이 기본동작입니다. 예를들면 다음과 같습니다.

   content://your.authority/optional.suggest.path/SUGGEST_URI_PATH_QUERY/puppies

   The query text on the end is encoded using URI encoding rules, so you might need to decode it before performing a search.

    마지막부분의 쿼리문장은 URI 인코딩 규칙을 이용하여 인코딩 되어 있습니다. 그렇기에 검색을 수행하기 전에 그것을 디코딩 할 수도 있습니다.

   The optional.suggest.path portion is only included in the URI if you have set such a path in your searchable configuration file with the android:searchSuggestPath attribute.

    당신의 searchable 설정파일내의 android:searchSuggestPath 속성을 이용하여 이러한 경로를 설정하였다면 optional.suggest.path의 위치는 단지 URI 내에 포함되어진 것 입니다.

   This is only needed if you use the same content provider for multiple searchable activities, in which case, you need to disambiguate the source of the suggestion query.

    이것은 당신이 다수의 검색가능한 액티비티를 위해 동일한 컨텐츠 프로바이더를 사용하는 경우에만 필요합니다. 그러한 경우에 당신은 제안쿼리의 소스를 하나하나 구분할 필요가 있습니다.

   Note: SUGGEST_URI_PATH_QUERY is not the literal string provided in the URI, but a constant that you should use if you need to refer to this path.

   주의 : SUGGEST_URI_PATH_QUERY는 URI내에서 제공되는 리터럴 문자열이 아니지만, 당신이 이 경로를 참조할 필요가 있는경우 사용하게 될 상수입니다.

projection

   Always null

   항상 null 입니다.

selection

   The value provided in the android:searchSuggestSelection attribute of your searchable configuration file, or null if you have not declared the android:searchSuggestSelection attribute.

   당신의 searchable 설정 파일에서의 android:searchSuggestSelection 속성내에서 제공되는 값이지만, android:searchSuggestSelection 속성을 선언하지 않았다면 null 입니다.

   More about using this to get the query below.

   이것을 사용하는 것에 대한 상세한 내용은 'get the query'를 참조하세요.

selectionArgs

   Contains the search query as the first (and only) element of the array if you have declared the android:searchSuggestSelection attribute in your searchable configuration.

   당신의 searchable 설정내의 android:searchSuggestSelection 속성을 선언한 경우, 배열의 첫번째 (그리고 유일하게) 항목으로서의 검색 쿼리를 포함합니다.

   If you have not declared android:searchSuggestSelection, then this parameter is null. More about using this to get the query below.

   만일 android:searchSuggestSelection 항목을 선언하지 않았다면, 이 파라메타는 null 입니다. 이것에 대한 상세한 내용은 'get the query'를 참조하십시오.

sortOrder

   Always null

   항상 null 입니다.

The system can send you the search query text in two ways.

시스템이 당신에게 검색쿼리를 전송하는 방식에는 두 가지 방식이 존재합니다.

The default manner is for the query text to be included as the last path of the content URI passed in the uri parameter.

기본방식은 uri 파라메타에 전달되어진 컨텐츠 URI의 마지막 경로가 포함되는 쿼리문장입니다.

However, if you include a selection value in your searchable configuration's android:searchSuggestSelection attribute, then the query text is instead passed as the first element of the selectionArgs string array.

당신의 searchable 속성의 android:searchSuggestSelection 속성에서의 선택값을 포함하는 경우에는 selectionArgs 문자열 배열의 첫 번째 항목으로 전달되는 것 대신에 다음의 쿼리문장이 위치합니다.

Both options are summarized next.

두개의 옵션 모두 다음번에 요약됩니다.

Get the query in the Uri

By default, the query is appended as the last segment of the uri parameter (a Uri object).

기본적으로 쿼리는 uri 파라메타의 마지막 부분으로 추가됩니다. (Uri 객체)

To retrieve the query text in this case, simply use getLastPathSegment(). For example:

이러한 경우 쿼리문장을 검색하려면 getLastPathSegment()를 사용합니다. 예를 들면...

String query = uri.getLastPathSegment().toLowerCase();

This returns the last segment of the Uri, which is the query text entered by the user.

이것은 사용자에 의해 입력된 쿼리문인 Uri의 마지막 부분을 반환합니다.

Get the query in the selection arguments

Instead of using the URI, you might decide it makes more sense for your query() method to receive everything it needs to perform the look-up and you want the selection and selectionArgs parameters to carry the appropriate values.

URI를 사용하는 것 대신, 룩업 수행에 필요하며 selection과 적절한 값들을 이동시키기 위한 selectionArgs 파라메타 을 원하므로 모든것을 전달받는 것이 query() 메서드를 위해 보다 효율적이라고 결정할지도 모른다.

In such a case, add the android:searchSuggestSelection attribute to your searchable configuration with your SQLite selection string.

이러한 경우 SQLite selection 문자열과 함께 android:searchSuggestSelection 속성을 당신의 searchable 설정에 추가하십시오.

In the selection string, include a question mark ("?") as a placeholder for the actual search query.

selection 문자열 내에서는 실제검색쿼리를 위한 위치지정자로서 물음표("?")를 포함합니다.

The system calls query() with the selection string as the selection parameter and the search query as the first element in the selectionArgs array.

시스템은 selection 파라메타로서 selection 문자열을 이용하여 query()를 호출하며, selectionArgs 배열의 첫번째 항목으로서 검색을 조회합니다.

For example, here's how you might form the android:searchSuggestSelection attribute to create a full-text search statement:

여기에서는 전체 텍스트 검색 구문을 만들 android:searchSuggestSelection 속성을 구성하는 방법에 대한 예제가 있습니다.

<?xml version="1.0" encoding="utf-8"?>

<searchable xmlns:android="http://schemas.android.com/apk/res/android"

    android:label="@string/app_label"

    android:hint="@string/search_hint"

    android:searchSuggestAuthority="com.example.MyCustomSuggestionProvider"

    android:searchSuggestIntentAction="android.intent.action.VIEW"

    android:searchSuggestSelection="word MATCH ?">

</searchable>

With this configuration, your query() method delivers the selection parameter as "word MATCH ?" and the selectionArgs parameter as the search query.

이 설정에서 query() 메서드는 "word MATCH?"로 selection 파라메타를 전달하고 검색쿼리로서 selectionArgs가 전달됩니다.

When you pass these to an SQLite query() method, as their respective arguments, they are synthesized together (the question mark is replaced with the query text).

SQLite query() 메서드로 이것을 전달할때에, 각각의 인자로, 그들은 함께 동기화(합성) 됩니다. (물음표 표시는 퀴리문장으로 대체 됩니다.)

If you chose to receive suggestion queries this way and need to add wildcards to the query text, append (and/or prefix) them to the selectionArgs parameter, because this value is wrapped in quotes and inserted in place of the question mark.

당신이 제안 쿼리들을 전달받기 위해 이방식을 선택하고 쿼리문장에 와일드카드를 추가하는 것이 필요하다면, selectionArgs 파라메타에 그것들을 추가(and/or prefix)하십시오. 왜냐하면 이 값은 따옴표로 둘러쌓여 물음표의 위치에 삽입되어 있기 때문입니다.

Another new attribute in the example above is android:searchSuggestIntentAction, which defines the intent action sent with each intent when the user selects a suggestion.

위의 예제 내에서의 또다른 새로운 속성은 사용자가 제안항목을 선택할때에 각 인텐트를 이용해 보내어질 인텐트 액션을 정의한 android:searchSuggestIntentAction 입니다.

It is discussed further in the section about Declaring an Intent for Suggestions.

이것은 "Declaring an Intent for Suggestions" 에 대한 섹션에 추가적인 설명이 있습니다.

Building a suggestion table

When you return suggestions to the system with a Cursor, the system expects specific columns in each row.

당신이 커서와 함께 시스템에 제안항목을 반환할때에, 시스템은 각 행에서 특정 열을 전달받기를 원합니다.

So, regardless of whether you decide to store your suggestion data in an SQLite database on the device, a database on a web server, or another format on the device or web, you must format the suggestions as rows in a table and present them with a Cursor.

그래서 당신이 장치상의 SQLite 데이터베이스 내부, 웹서버상의 데이터베이스 또는 장치나 웹상의 또다른 형식으로든 관계없이 반드시 테이블내의 행으로서의 제안항목의 형식을 지정해야 하며, 커서객체 형식으로 그것들을 제공합니다.

=============================================================

- 부가내용 -

Creating a Cursor without a table

테이블 없이 커서객체 생성하기

If your search suggestions are not stored in a table format (such as an SQLite table) using the columns required by the system, then you can search your suggestion data for matches and then format them into the necessary table on each request.

만약 당신의 검색제안항목들이 시스템으로부터 요구되는 열들로 구성된 (SQLite 테이블과 같은) 테이블 형식으로 저장되어 있지 않다면, 당신은 매치할 당신의 제안기능 데이터를 검색할 수 있으며 각 요청에서의 필수 테이블 내의 형식을 지정할 수 있습니다.

To do so, create a MatrixCursor using the required column names and then add a row for each suggestion using addRow(Object[]).

그렇게 하려면 필수 열이 지정된 Matrixcursor를 생성하고 addRow(Object[])를 이용하여 각 제안항목을 위한 행을 추가하십시오.

Return the final product from your Content Provider's query() method.

마지막으로 당신의 컨텐츠 프로바이더의 query() 메서드로부터의 결과를 리턴하십시오.

==============================================================================================================================================

The system understands several columns, but only two are required:

시스템은 몇몇 열들을 이해할 수 있지만, 딱 두가지 열은 필수항목입니다.

_ID

   A unique integer row ID for each suggestion. The system requires this in order to present suggestions in a ListView.

   각 제안항목을 위한 유니크한 integer 행 ID. 시스템은 리스트뷰에 제안항목들을 제공하기 위한 목적으로 이 열을 필수사항으로 여깁니다.

SUGGEST_COLUMN_TEXT_1

   The string that is presented as a suggestion.

   제안항목으로서 제공되어질 문자열

   The following columns are all optional (and most are discussed further in the following sections):

   이하의 열들은 모두 부가적인 항목입니다. (그리고 대부분은 다음의 섹션에서 부가설명되어 있습니다.)

SUGGEST_COLUMN_TEXT_2

   A string. If your Cursor includes this column, then all suggestions are provided in a two-line format.

   문자열입니다. 만약 당신의 커서가 이 열을 포함한다면, 모든 제안항목은 두줄의 형태로 제공됩니다.

   The string in this column is displayed as a second, smaller line of text below the primary suggestion text.

   두번째로서 보여지는 이 열의 문자열은 주 제안항목 문자열의 아랫줄에 작게 표시되는 항목입니다.

   It can be null or empty to indicate no secondary text.

   null 일수도 있고 부가적인 텍스트가 불필요하다면 비워두어도 됩니다.

SUGGEST_COLUMN_ICON_1

   A drawable resource, content, or file URI string.

   drawable 리소스, 컨텐츠 또는 파일의 URI 문자열입니다.

   If your Cursor includes this column, then all suggestions are provided in an icon-plus-text format with the drawable icon on the left side.

   당신의 커서가 이 열을 포함한다면, 모든 제안항목들은 좌측면에 drawable 아이콘이 보이는 형태로 아이콘과 텍스트가 결합되어 제공됩니다.

   This can be null or zero to indicate no icon in this row.

   이것은 널일수도 있고 이 행내의 아이콘이 불필요하다면 0을 넣을 수 있습니다.

SUGGEST_COLUMN_ICON_2

   A drawable resource, content, or file URI string.

   drawable 리소스, 컨텐츠 또는 파일의 URI 문자열 입니다. 

   If your Cursor includes this column, then all suggestions are provided in an icon-plus-text format with the icon on the right side.

   만약 당신의 커서가 이 열을 포함한다면, 모든 제안항목들은 우측면에 아이콘이 보이는 형태로 아이콘과 텍스트가 결합되어 제공됩니다.

   This can be null or zero to indicate no icon in this row.

   이것은 널일수도 있고 이 행내의 아이콘이 불필요하다면 0을 넣을 수 있습니다.

SUGGEST_COLUMN_INTENT_ACTION

   An intent action string.

   인텐트 액션 문자열 입니다.

   If this column exists and contains a value at the given row, the action defined here is used when forming the suggestion's intent.

   이 열이 존재하고 주어진 행에 이 값이 포함되어 있다면, 제안항목의 인텐트를 형성할때에 여기에 액션이 정의된 액션이 사용됩니다.

   If the element is not provided, the action is taken from the android:searchSuggestIntentAction field in your searchable configuration.

   이 항목이 제공되지 않는다면, 액션은 searchable 설정파일내의 android:searchSuggestIntentAction 필드로부터 얻어야 합니다.

   If your action is the same for all suggestions, it is more efficient to specify the action using android:searchSuggestIntentAction and omit this column.

   모든 제안항목을 위해 당신의 액션이 동일하다면, 그것은 android:searchSuggestIntentAction을 사용하여 액션을 지정하고 이 칼럼을 생략하는 것보다 효율적입니다.

SUGGEST_COLUMN_INTENT_DATA

   A data URI string.

   데이터 URI 문자열 입니다.

   If this column exists and contains a value at the given row, this is the data that is used when forming the suggestion's intent.

   이 열이 존재하고 주어진 행에 값이 포함되어 있다면, 이것은 제안항목들의 인텐트를 형성할때에 사용될 데이터 입니다.

   If the element is not provided, the data is taken from the android:searchSuggestIntentData field in your searchable configuration.

   이 항목이 제공되어지지 않는다면, 데이터는 searchable 설정파일내의 android:searchSuggestIntentData 필드로부터 얻어야 합니다.

   If neither source is provided, the intent's data field is null.

   소스또한 제공되어지지 않는다면, 인텐트의 데이터필드는 널입니다.

   If your data is the same for all suggestions, or can be described using a constant part and a specific ID, it is more efficient to specify it using android:searchSuggestIntentData and omit this column.

   모든 제안항목들을 위한 데이터가 동일하거나 상수나 특정 ID를 이용하여 설명되어진다면, android:searchSuggestIntentData를 사용하며 이 칼럼을 생략하는 것보다 효율적입니다.

SUGGEST_COLUMN_INTENT_DATA_ID

   A URI path string.

   URI 경로의 문자열 입니다.

   If this column exists and contains a value at the given row, then "/" and this value is appended to the data field in the intent.

   이 열이 존재하고 주어진 행에 값이 포함되어져 있다면, 인텐트 내의 데이터 필드에 "/"와 이 값이 추가되어 집니다.

   This should only be used if the data field specified by the android:searchSuggestIntentData attribute in the searchable configuration has already been set to an appropriate base string.

   searchable 설정파일내의 android:searchSuggestIntentData 속성에 의해 지정된 데이터 필드가 이미 적절한 기본 문자열로 설정된 경우에만 사용해야 합니다.

SUGGEST_COLUMN_INTENT_EXTRA_DATA

   Arbitrary data.

   임의의 데이터 입니다.

   If this column exists and contains a value at a given row, this is the extra data used when forming the suggestion's intent.

   이 열이 존재하고 주어진 행에 값이 포함되어 있다면, 이것은 제안항목의 인텐트를 형성할때에 사용되어질 여분의 데이터 항목입니다.

   If not provided, the intent's extra data field is null.

   만약 제공되어지지 않았다면, 인텐트츼 여분의 데이터 필드는 null 입니다.

   This column allows suggestions to provide additional data that is included as an extra in the intent's EXTRA_DATA_KEY key.

   이 열은 제안항목이  인텐트의 EXTRA_DATA_KEY키내의 여분으로서 부가적인 데이터를 제공하는 것을 허락합니다.

SUGGEST_COLUMN_QUERY

   If this column exists and this element exists at the given row, this is the data that is used when forming the suggestion's query, included as an extra in the intent's QUERY key.

   이 열이 존재하고 주어진 행에 이 항목이 존재한다면, 이것은 제안항목 쿼리를 형성할때에 사용되어질 인텐트의 QUERY 키내의 여분으로서 포함된 데이터 입니다.

   Required if suggestion's action is ACTION_SEARCH, optional otherwise.

   만일 제안항목의 액션이 ACTION_SEARCH 라면 필수항목이며, 그밖에는 부가항목입니다.

SUGGEST_COLUMN_SHORTCUT_ID

   Only used when providing suggestions for Quick Search Box.

   QSB를 위한 제안항목들이 제공되어지는 경우에만 사용됩니다.

   This column indicates whether a search suggestion should be stored as a shortcut and whether it should be validated.

   이 열은 검색 제안항목을 바로가기로서 저장해야 하는지 여부와 그것의 유효성을 검사할지 여부를 나타냅니다.

   Shortcuts are usually formed when the user clicks a suggestion from Quick Search Box.

   바로가기는 대게 사용자가 QSB내의 제안항목을 선택할때에 형성됩니다.

   If missing, the result is stored as a shortcut and never refreshed.

   없는 경우, 결과는 숏컷으로 저장되고 새로고침되지 않습니다.

   If set to SUGGEST_NEVER_MAKE_SHORTCUT, the result is not stored as a shortcut.

   SUGGEST_NEVER_MAKE_SHORTCUT로 설정되면, 결과는 숏컷형태로 저장되지 않습니다.

   Otherwise, the shortcut ID is used to check back for an up to date suggestion using SUGGEST_URI_PATH_SHORTCUT.

   그렇지 않으면, 숏컷  ID가 SUGGEST_URI_PATH_SHORTCUT을 사용하여 최신의 제안항목으로까지 다시 확인하는데 사용됩니다.

SUGGEST_COLUMN_SPINNER_WHILE_REFRESHING

   Only used when providing suggestions for Quick Search Box.

   오직 QSB를 위해 제안항목이 제공되어질때에 사용됩니다.

   This column specifies that a spinner should be shown instead of an icon from SUGGEST_COLUMN_ICON_2 while the shortcut of this suggestion is being refreshed in Quick Search Box.

   이 열은 QSB에서 제안항목의 바로가기가 새로고침 되는 동안 SUGGEST_COLUMN_ICON_2 부터의 아이콘 대신 출력되어질 스피너를 지정합니다.

Some of these columns are discussed more in the following sections.

이러한 열들의 일부에 대한 자세한 설명은 다음의 섹션에서 다루어집니다.

원본 : http://goo.gl/S9Fem

Say Goodbye to the Menu Button(Posted by Tim Bray on 26 January 2012 at 12:10 PM)

[This post is by Scott Main, lead tech writer for developer.android.com. — Tim Bray]

Before Android 3.0 (Honeycomb), all Android-powered devices included a dedicated Menu button. As a developer, you could use the Menu button to display whatever options were relevant to the user, often using the activity’s built-in options menu. Honeycomb removed the reliance on physical buttons, and introduced the ActionBar class as the standard solution to make actions from the user options immediately visible and quick to invoke. In order to provide the most intuitive and consistent user experience in your apps, you should migrate your designs away from using the Menu button and toward using the action bar. This isn’t a new concept — the action bar pattern has been around on Android even before Honeycomb — but as Ice Cream Sandwich rolls out to more devices, it's important that you begin to migrate your designs to the action bar in order to promote a consistent Android user experience.

안드로이드 3.0이전에 출시된 모든 안드로이드 기반의 디바이스들은 전용 메뉴버튼을 포함하였습니다. 개발자로서 당신은 자주 사용되는 액티비티에 종속적인 옵션메뉴와 관련있는 옵션들을 출력하기 위해 메뉴버튼을 사용할 수 있습니다. 허니컴은 물리적인 버튼에 대한 의존성을 제거하였고 사용자의 옵션들을 즉시 보여주고 빠르게 사용할 수 있는 표준 솔루션으로서 액션바 클래스를 소개하였습니다. 이해하기 쉽고 어플리케이션에서의 사용자 경험이 극대화 될수 있도록 당신은 액션바를 사용하여 메뉴버튼의 사용과 방향에 대한 설계적인 측면을 마이그레이션 해야 합니다. 이것은 새로운 컨셉트가 아닙니다 - 액션바 패턴은 허니컴 이전부터 계속 안드로이드에 있어왔습니다. - 그러나 ICS에 와서 더 많은 디바이스에 적용되게 되었습니다. 당신이 일관된 안드로이드 사용자 경험을 촉진하기 위해 액션바 설계를 마이그레이션하기 시작하는 것은 중요합니다.

You might worry that it’s too much work to begin using the action bar, because you need to support versions of Android older than Honeycomb. However, it’s quite simple for most apps because you can continue to support the Menu button on pre-Honeycomb devices, but also provide the action bar on newer devices with only a few lines of code changes.

당신은 아마도 액션바를 사용하는 것을 시작함에있어 너무 많은 작업량이 있을까 걱정할지 모릅니다. 왜냐하면 당신은 허니컴보다 오래된 안드로이드 버전에 대한 지원이 필요하기 때문이죠. 당신은 허니컴 이전의 디바이스에 대한 메뉴버튼에 대해 지속적인 지원할 수 있기때문에 대부분의 어플리케이션에서는 꽤나 간단합니다.

If I had to put this whole post into one sentence, it’d be: Set targetSdkVersion to 14 and, if you use the options menu, surface a few actions in the action bar with showAsAction="ifRoom".

이 모든 포스트를 한줄요약해보면 targetSdkVersion을 14로 맞추고, 만약에 당신이 옵션메뉴를 사용한다면 showAsAction="ifRoom"을 잉요해 액션바에서의 몇개의 액션들은 나타내세요.

Don’t call it a menu

Not only should your apps stop relying on the hardware Menu button, but you should stop thinking about your activities using a “menu button” at all. Your activities should provide buttons for important user actions directly in the action bar (or elsewhere on screen). Those that can’t fit in the action bar end up in the action overflow.

하드웨어 메뉴버튼에 의존하는 것을 중지해야 할뿐 아니라, "메뉴버튼"을 사용하는 당신의 액티비티들에 대해서 아무런 생각을 하지 말아야 합니다. 당신의 액티비티들은 액션바에서의(또는 다른 곳에서의) 중요한 사용자 액션들을 직접적으로 버튼으로 제공해야 합니다. 액션바에 알맞지 않는 것들은 액션 오버플로우에서 이루어져야 합니다.

(스크린샷 생략)

In the screenshot here, you can see an action button for Search and the action overflow on the right side of the action bar.

여기 스크린샷이 있는데, 당신은 검색을 위한액션 버튼과 액션바 우측의 액션오버플로우를 보실 수 있습니다.

Even if your app is built to support versions of Android older than 3.0 (in which apps traditionally use the options menu panel to display user options/actions), when it runs on Android 3.0 and beyond, there’s no Menu button. The button that appears in the system/navigation bar represents the action overflow for legacy apps, which reveals actions and user options that have “overflowed off the screen.”

당신의 어플리케이션이 3.0 보다 오래된 버전의 안드로이드(사용자의 옵션/액션들은 메뉴패널을 이용하여 전통적으로 출력하는)를 지원하여 만들어졌다고 하더라도, 그것이 안드로이드 3.0과 그 이후버전에서 실행될때 그곳에는 어떠한 메뉴버튼도 없습니다. 시스템/네비게이션바 상에서 나타나는 버튼은 대대로 내려오는 어플리케이션들을 위한 액션 오버플로우를 대표합니다. 이것들은 액션들과 "화면에서 넘치는" 사용자 옵션을 나타냅니다.

This might seem like splitting hairs over terminology, but the name action overflow promotes a different way of thinking. Instead of thinking about a menu that serves as a catch-all for various user options, you should think more about which user options you want to display on the screen as actions. Those that don't need to be on the screen can overflow off the screen. Users can reveal the overflow and other options by touching an overflow button that appears alongside the on-screen action buttons.

이것은 마치 전문용어를 시시콜콜 따지는 것 같지만, 액션 오버플로우라는 이름은 생각의 방향을 다르게 촉진시킵니다. 사용자 옵션들을 위한 잡동사니 바구니처럼 제공되는 메뉴에 대한 생각과는 반대로 당신은 액션으로서 화면상에 나타낼 사용자 옵션들에 대해 더 많이 생각해야 합니다. 화면상에 나타나지 않아도 되는것들은 화면상에서 숨길 수 있습니다. 사용자는 화면상의 액션 버튼과 나란히 나타나는 오버플로우 버튼을 눌러 오버플로우 메뉴 및 기타 옵션들을 확인 할 수 있습니다.

Action overflow button for legacy apps

If you’ve already developed an app to support Android 2.3 and lower, then you might have noticed that when it runs on a device without a hardware Menu button (such as a Honeycomb tablet or Galaxy Nexus), the system adds the action overflow button beside the system navigation.

만약 당신이 이미 안드로이드 2.3 과 그 이하 버전을 지원하는 어플리케이션의 개발이 완료되었다면, 그렇다면 당신은 하드웨어 메뉴버튼이 없는 디바이스(예를들면 허니컴 태블릿이나 갤럭시 넥서스)에서 그것이 동작하는 경우에 대해서 눈치챘을 겁니다. 시스템은 시스템 네비게이션 옆으로 액션 오버플로우 버튼을 추가하게 됩니다.

(스크린샷 생략) 

This is a compatibility behavior for legacy apps designed to ensure that apps built to expect a Menu button remain functional. However, this button doesn’t provide an ideal user experience. In fact, in apps that don’t use an options menu anyway, this action overflow button does nothing and creates user confusion. So you should update your legacy apps to remove the action overflow from the navigation bar when running on Android 3.0+ and begin using the action bar if necessary. You can do so all while remaining backward compatible with the devices your apps currently support.

이것은 메뉴버튼을 기능적으로 남겨 사용되도록 설계된 전통적인 어플리케이션에서도 동작이 가능하도록 합니다. 그러나 이 버튼은 완벽한 사용자 경험을 제공하지 않습니다. 사실 어찌되었든 옵션메뉴를 사용하지 않고, 이 액션 오버플로우 버튼이 아무런 동작도 하지 않는 어플리케이션이라면 사용자에게 혼란만 가져올 것 입니다.

If your app runs on a device without a dedicated Menu button, the system decides whether to add the action overflow to the navigation bar based on which API levels you declare to support in the <uses-sdk> manifest element. The logic boils down to:

전용 메뉴버튼이 없는 디바이스에서 당신이 어플리케이션이 실행되고 있다면, 시스템은 매니페스트 항목에 당신이 선언한 <uses-sdk> 지원 API 레벨에 근거하여 액션 오버플로우를 네비게이션바에 추가할지 결정하게 됩니다. 이 토픽은 아래를 참고하세요.

   - If you set either minSdkVersion or targetSdkVersion to 11 or higher, the system will not add the legacy overflow button.

   - Otherwise, the system will add the legacy overflow button when running on Android 3.0 or higher.

   - The only exception is that if you set minSdkVersion to 10 or lower, set targetSdkVersion to 11, 12, or 13, and you do not use ActionBar, the system will add the legacy overflow button when running your app on a handset with Android 4.0 or higher.

   - 당신이 minSdkVerion 이나 targetSdkVersion을 11 또는 그 이상으로 설정한다면, 시스템은 기존의 오버플로우 버튼을 추가하지 않습니다.

   - 그렇지 않으면 시스템은 안드로이드 3.0이나 그 이상의 장치에서 실행될때에 기존의 오버플로우 버튼을 추가할 것 입니다.

   - 단 한가지 예외사항으로는 minSdkVersion을 10이나 그 이하로 설정하는 경우, targetSdkVerion을 11/12/또는 13으로 설정하는 경우, 그리고 액션바를 사용하지 않는 경우이며 시스템은 안드로이드 4.0 또는 그 이상의 단말장치에서 당신의 어플리케이션이 실행될 때에 기존의 오버플로우 버튼을 추가할 것 입니다.

That exception might be a bit confusing, but it’s based on the belief that if you designed your app to support pre-Honeycomb handsets and Honeycomb tablets, it probably expects handset devices to include a Menu button (but it supports tablets that don’t have one).

이러한 예외는 아마도 약간 혼란스러울 수 있겠지만, 허니컴 이전과 허니컴 태블릿을 지원하는 당신의 어플의 결정에 따르는 것입니다. 그것은 아마도 메뉴버튼이 존재하는 단말장치를 기대할 것 입니다. (그러나 그것은 메뉴버튼이 없는 태블릿을 지원합니다.)

So, to ensure that the overflow action button never appears beside the system navigation, you should set the targetSdkVersion to 14. (You can leave minSdkVersion at something much lower to continue supporting older devices.)

그래서 오버플로우 액션 버튼이 시스템 네비게이션 옆에 나타나는지를 확인하려면, 당신은 targetSdkVersion을 14로 설정해야 합니다.

Migrating to the action bar

If you have activities that use the options menu (they implement onCreateOptionsMenu()), then once the legacy overflow button disappears from the system/navigation bar (because you’ve set targetSdkVersion to 14), you need to provide an alternative means for the user to access the activity’s actions and other options. Fortunately, the system provides such a means by default: the action bar.

당신이 만일 옵션메뉴를 사용하는 액티비티(onCreateOptionMenu()를 구현하는)가 있다면, 다시한번 기존의 오버플로우 버튼이 시스템/네비게이션 바에서 사라집니다. (왜냐하면 당신이 targetSdkVersion을 14로 설정했기 때문입니다.) 당신은 액티비티의 액션과 기타 옵션들에 엑세스하려는 사용자를 위한 대체수단을 제공해야 합니다. 다행스럽게도 시스템은 기본적으로 그러한 수단을 액션바를 이용해 제공합니다.

Add showAsAction="ifRoom" to the <item> elements representing the activity’s most important actions to show them in the action bar when space is available. For help deciding how to prioritize which actions should appear in the action bar, see Android Design’s Action Bar guide.

공간을 사용할 수 있는 경우 액션바에 그것들을 보여주려는 작업에서 가장 중요한 행동을 나타내는 showAsAction="ifRoom"을 <item> 항목에 추가하십시오. 액션들이 액션바에서 표시되어야 하는 우선순위를 결정하는 방법에 도움을 줍니다. 안드로이드 설계의 액션바 가이드를 보십시오.

(스크린샷 생략)

To further provide a consistent user experience in the action bar, we suggest that you use action icons designed by the Android UX Team where appropriate. The available icons support common user actions such as Refresh, Delete, Attach, Star, Share and more, and are designed for the light and dark Holo themes. Here they are!

액션바에서의 일관된 사용자 경험을 추가적으로 제공하기 위해, 우리는 당신이 안드로이드 UX팀에의해 적절히 디자인된 액션 아이콘들은 사용하는 것을 제안합니다. 사용가능한 아이콘들은 새로고임, 삭제, 첨부, 별점, 공유 그리고 기타와 같은 일반적인 사용자의 액션들을 제공하며 밝고 어두운 홀로테마들고 디자인되어 있습니다. 여기에 있습니다! (첨부파일 참고)

If these icons don’t accommodate your needs and you need to create your own, you should follow the Iconography design guide.

이 아이콘들이 당신의 요구에 알맞지 않고, 직접 생성해야 하는 경우에는 도해법 디자인 가이드를 준수해야 합니다.

Removing the action bar

If you don’t need the action bar, you can remove it from your entire app or from individual activities. This is appropriate for apps that never used the options menu or for apps in which the action bar doesn’t meet design needs (such as games). You can remove the action bar using a theme such as Theme.Holo.NoActionBar or Theme.DeviceDefault.NoActionBar.

액션바가 필요없으시면, 당신은 전체 어플리케이션이나 각 액티비티에서 제거 할 수 있습니다. 이것은 옵션메뉴의 사용이 일어나지 않을만한 어플리케이션이거나 액션바가 설계요구사항에 불필요한 경우(예를들면 게임과 같은)에 적합합니다. 당신은 Theme.Holo.NoActionBar 또는 Theme.DeviceDefault.NoActionBar와 같은 테마를 이용하여 액션바를 제거할 수 있습니다.

In order to use such a theme and remain backward compatible, you can use Android’s resource system to define different themes for different platform versions, as described by Adam Powell’s post, Holo Everywhere. All you need is your own theme, which you define to inherit different platform themes depending on the current platform version.

이러한 테마를 사용하면서 이전 버전과의 호환성을 유지하기 위해서, Adam Powell의 'Holo Everyshere(http://android-developers.blogspot.com/2012/01/holo-everywhere.html)'포스트에서 설명된 것 처럼 당신은 다른 플랫폼 버전에 대해 서로 다른 테마를 정의하는 안드로이드의 리소스 시스템을 사용할 수 있습니다. 당신이 필요로 하는 것은 현재의 플랫폼 버전에 따라 서로 다른 플랫폼 테마가 정의된 자신의 테마입니다.

For example, here’s how you can declare a custom theme for your application:

예를들면, 여기에 당신의 어플리케이션을 위해 어떻게 커스텀 테마를 정의하는지 답이 있습니다.

    <application android:theme="@style/NoActionBar">

Or you can instead declare the theme for individual <activity> elements.

아니면 개별적인 <activity> 항목들을 위한 테마를 대신 선언할 수 있습니다.

For pre-Honeycomb devices, include the following theme in res/values/themes.xml that inherits the standard platform theme:

허니컴 이전의 디바이스인 경우, 표준 플랫폼 테마를 상속한 res/values/themes.xml 내에 다음의 테마를 포함합니다.

     <resources>

         <style name="NoActionBar" parent="@android:style/Theme">

             <!-- Inherits the default theme for pre-HC (no action bar) -->

         </style>

     </resources>

For Honeycomb and beyond, include the following theme in res/values-v11/themes.xml that inherits a NoActionBar theme:

허니컴 또는 그 이상의 경우, NoActionBar를 상속하는 res/values-v11/themes.xml 내에 다음의 테마를 포함합니다.

     <resources>

         <style name="NoActionBar" parent="@android:style/Theme.Holo.NoActionBar">

             <!-- Inherits the Holo theme with no action bar; no other styles needed. -->

         </style>

     </resources>

At runtime, the system applies the appropriate version of the NoActionBar theme based on the system’s API version.

실행시에 시스템은 시스템의 API 버전에 따라 NoActionBar 테마의 해당 버전을 적용합니다.

Summary

- Android no longer requires a dedicated Menu button, some devices don’t have one, and you should migrate away from using it.

- Set targetSdkVersion to 14, then test your app on Android 4.0.

- Add showAsAction="ifRoom" to menu items you’d like to surface in the action bar.

- If the ActionBar doesn’t work for your app, you can remove it with Theme.Holo.NoActionBar or Theme.DeviceDefault.NoActionBar.

- 안드로이드가 몇몇 디바이스들과 같이 더 이상 전용 메뉴버튼을 요구하지 않으면,  당신은 그것을 사용하여 마이그레이션 해야 합니다.

- targetSdkVersion을 14로 설정하시고, 안드로이드 4.0에서 당신의 어플리케이션을 테스트 하십시오.

- 액션바의 표면에 나타내고 싶은 항목에 showAsAction="ifRoom"을 메뉴아이템에 추가합니다.

- 당신의 어플리케이션에서 액션바가 동작하지 않는 경우, Theme.Holo.NoActionBar 또는 Theme.DeviceDafault.NoActionBar를 사용하여 그것을 제거할 수 있습니다.

For information about how you should design your action bar, see Android Design’s Action Bar guide. More information about implementing the action bar is also available in the Action Bar developer guide.

당신의 액션바를 어떻게 설계해야 하는지에 대한 정보는 안드로이드 설계의 액션바 가이드를 참조하십시오. 액션바의 구현에 대한 더 자세한 정보는 또한 액션바 개발 가이드문서를 참조하실 수 있습니다. 

FTP 서버 설치하기

     - apt-get install vsftpd

FTP 설정파일 내용변경하기

     - vi /etc/vsftpd.conf 명령으로 설정파일 열자. 

     - local_umask 주석풀어줌 (로컬계정사용자의 umask (default = 077)

     - chroot_list_enable=YES 주석풀어줌

     - chroot_list_file=/etc/vsftpd.chroot_list 주석풀어줌

     - vsftpd.chroot_list 파일에 abcdedfg라고 계정 적어주고 저장함

     - restart vsftpd 명령으로 서버 재시작

     - Filezilla로 연결테스트 완료함 

FTP 서버에 대한 자세한 참고자료

http://www.linux.co.kr/home/lecture/index.php?cateNo=1&secNo=294

FTP 서버설정 파일 내용수정함 (2011.10.20 PM21:35)

     FTP 서버설정을 변경했음에도 불구하고, 수정된 내역들이 반영되지 않고있다

     서버 재부팅 이후 다시 눈여겨봐야 할 내용이다. 

     익명사용자의 접속허용 여부

     anonymous_enable=NO

     로컬계정 사용자의 접속허용 여부

     local_enable=YES

     write명령어 허용여부

     write_enable=YES

     로컬계정 사용자용 umask (기본값 : 077)

     local_umask=022

     익명사용자의 업로드 가능여부

     anon_upload_enable=YES를 주석처리함

     익명사용자의 디렉토리생성 가능여부

     anon_mkdir_write_enable=YES를 주석처리함

     파일전송 로그에 대한 기록허용여부

     xferlog_enable=YES

     파일전송로그 파일명

     xferlog_file=/var/log/vsftpd.log

     FTP서버 접속시, 환영메시지 설정

     ftpd_banner=위트가이즈 FTP 서버에 오신것을 환영합니다!

     사용자가 자신의 홈디렉토리 외에는 접근하지 못하도록 설정

     chroot_local_user=YES

     특정사용자들만 모든 디렉토리에 접근 가능하도록 설정

     chroot_list_enable=YES

     위 내용처럼 특정사용자들만 모든 디렉토리에 접근 가능하도록, 특정사용자 리스트를 생성

     chroot_list_file=/etc/vsftpd.chroot_list

     wtmp에 등록하여 로그를 남기기 위한 설정 (last 명령으로 로그확인 가능하도록)

     session_support=YES

     수정 후 서버 재시작

     restart vsftpd

ssh server 설치를 위해 아래 명령 수행

     - 참고경로 : http://zodiac12k.egloos.com/964697

     - sudo apt-get install ssh

설치과정 중에 한글폰트가 깨지므로 아래 명령 수행

     - 참고경로 : http://kldp.org/node/82891

     - sudo apt-get install ttf-unfonts

ssh 서버 포트변경하고자 할때에는

     - vi /etc/ssh/sshd_config 설정파일 내용 수정하면 되지만, 필요없으므로 쌩깜

     - 설정파일 변경시에는 데몬재시작이 필요함 (아래명령)

            - /etc/init.d/ssh restart

ssh 서버 동작확인

     - netstat -ntl

     - 어떻게 보는건지 모르겠음 -_- 추후 수정하기로 하자. 

맥에서 SSH 정상동작 확인하기

     - 맥 터미널 열고 아래 명령수행

          - ssh (괄호빼고 계정명)@192.168.0.x

          - 정상동작 확인완료

단, 포트가 22번이 아닌 경우

     - 맥에서 접속할때에 아래 명령처럼 포트를 기재한다. 

            ssh (괄호빼고 계정명)@192.168.0.x -p 20000

설치가 완료되면 putty나 터미널 등을 이용해서 원격접속을 자유롭게 해보자!