iOS2013. 7. 15. 14:40


출처 : http://nickeys.tistory.com/archive/201108


SQL DB 엔진의 주 목적은 SQL문장을 평가 하는 것이다. 그걸 위해서, 개발자는 두 개의 객체에 대해 알 필요가 있다:

1) The database connection object: sqlite3
2) The prepared statement object: sqlite3_stmt

엄격히 따지자면, prepared_statement 객체는 꼭 필요한건 아니긴 하지만 편의를 위해서 wrapper 인터페이스들(sqlite3_exec 또는 sqlite3_get_table등)이 사용될 수 있다. 그래도, prepared statements에 대한 이해는 SQLite를 잘 사용하기 위해선 필수적이다.

The database connection과 prepared statement 객체들은 아래에 나열된 C/C++ 인터페이스 루틴의 소 집합에 의해 조작된다.

● sqlite3_open()
● sqlite3_prepare()
● sqlite3_step()
● sqlite3_column()
● sqlite3_finalize()
● sqlite3_close()

위의 루틴들의 리스트는 실재 존재하는 것이 아닌(actual) 개념적이라는 것을 알아 두자. 이 루틴들은 다양한 버전이 존재한다. 예를 들면, 사실 약간 다르긴 하지만 같은 용도의, 세 개의 분리된 루틴들(sqlite3_open(), sqlite3_open16(), sqlite3_open_v2())이 있고 위의 리스트 에서는 sqlite3_open()이라는 싱글 루틴을 보여준다. 위의 리스트에서 보여지는 "sqlite_column()"은 다양한 타입의 열 데이터를 추출하는데 사용되는 루틴들의 전체 군에 대한 place holder이다.

각각의 코어 인터페이스들의 요약이 있다:

sqlite3_open()   이 루틴은 SQLite DB파일을 열고 DB 연결 객체를 반환 한다. 이 루틴은 응용프로그램이 빈번하게 제일 먼저 호출 하는데, 대부분의 SQLite API들의 선행 조건이기 때문이다. 많은 SQLite 인터페이스들은 첫 번째 인자로 DB 연결에 대한 포인터를 요구한다. 이 루틴은 DB 객체의 생성자 역할을 한다고 할 수 있겠다.

sqlite3_prepare()  이 루틴은 SQL 문장을 prepared statement 객체로 전환하고 그 객체에 대한 포인터를 반환한다. 이 인터페이스는 앞에서 sqlite3_open()을 호출해서 만들어진 DB 연결 객체의 포인터와 SQL 문장을 포함한 문자열을 인자로 받는다. 이 API는 실재로 SQL 문장을 평가하는 것이 아니고 단지, SQL 문장에 대한 평가를 준비하는 단계이다.
새로운 응용 프로그램에서 sqlite3_prepare()의 사용은 추천되지 않는다는 것을 알아두라. 대신 sqlite3_prepare_v2()를 사용하는 게 낫다.

sqlite3_step()  이 루틴은 sqlite3_prepare() 인터페이스에서 생성된 prepared statement를 평가한다. 해당 문장은 결과의 첫 번째 행에 대한 포인터에 대해 평가 된다. 다음 열에 대해 계속해서 진행하려면, sqlite3_step()을 다시 호출하라. 해당 문장이 끝날 때까지sqlite3_step()을 계속 수행하라. 결과를 반환하지 않는 문장들(INSERT, UPDATE, DELETE)은 sqlite3_step()을 한번 호출해도 완료 된다.

sqlite3_column()  이 루틴은 sqlite3_step()에 의해 평가되고 있는 prepared statement에 대한 결과 집합의 현재 튜플로 부터 한 열을 반환한다. sqlite3_step()은 매번 새로운 결과 집합 튜플에서 멈추는데, 이 루틴은 해당 튜플에서 모든 열들의 값을 찾기 위해 여러번 호출 될 수 있다(한 튜플은 여러 열로 이뤄 지므로). 위에서 명시 된 것 처럼, SQLite API에는 "sqlite3_column()" 함수와 같은 것은 정말로 없다. 대신, 여기서 sqlite3_column()을 호출하는 것은 다양한 타입의 결과 집합으로 부터 한 값을 반환하는 함수들의 전체 집합에 대한 place holder라는 것이다. 그 결과(문자열이나 BLOB데이터일 경우)의 사이즈와 결과 집합에 있어 열의 수를 반환하는 함수 군에는 여러 루틴들이 있다.


● sqlite3_column_blob()
● sqlite3_column_bytes()
● sqlite3_column_bytes16()
● sqlite3_column_count()
● sqlite3_column_double()
● sqlite3_column_int()
● sqlite3_column_int64()
● sqlite3_column_text()
● sqlite3_column_text16()
● sqlite3_column_type()
● sqlite3_column_value()

sqlite3_finalize()  이 루틴은 sqlite3_prepare()의 호출로 부터 만들어진 prepared statement를 파괴한다. 모든 prepared statement는 메모리 누수를 막기 위해서 이 루틴을 호출해서 파괴되어야 한다.

sqlite3_close()  이 루틴은 이전에 sqlite3_open()을 호출함으로써 만들어진 DB연결을 닫는다. 모든 해당 연결에 관련된 prepared statement들은 해당 연결이 닫히기 전에 종결 되어야 한다.


Posted by 삼스
Android/App개발2013. 7. 11. 19:13



private void getMusicMetaInfo(String fileStr) {

Uri fileUri = Uri.parse(fileStr);

String filePath = fileUri.getPath();

Cursor c = getContentResolver().query(MediaStore.Audio.Media.EXTERNAL_CONTENT_URI,null,"_data ='" + filePath + "'",null,null);

c.moveToNext();

if(c.getCount()>0) {

int id = c.getInt(0);

Uri uri = ContentUris.withAppendedId(MediaStore.Audio.Media.EXTERNAL_CONTENT_URI,id);

Log.d(LOG_TAG, fileStr + "'s uri : " + uri.toString());

Cursor cur = managedQuery(uri, null, null, null, null);

if(cur.moveToFirst()) {

Log.d(LOG_TAG, "==============================");


// int artistColumn = cur.getColumnIndex(MediaStore.Audio.AlbumColumns.ARTIST);

Log.d(LOG_TAG, "타이틀 : " + cur.getString(cur.getColumnIndex(MediaStore.Audio.AudioColumns.TITLE)));

Log.d(LOG_TAG, "아티스트 : " + cur.getString(cur.getColumnIndex(MediaStore.Audio.AlbumColumns.ARTIST)));

Log.d(LOG_TAG, "앨범 : " + cur.getString(cur.getColumnIndex(MediaStore.Audio.AlbumColumns.ALBUM)));

Log.d(LOG_TAG, "재생시간 : " + cur.getString(cur.getColumnIndex(MediaStore.Audio.AudioColumns.DURATION)));


Log.d(LOG_TAG, "==============================");

}

}

c.close();

Log.d(LOG_TAG, "");

}

Posted by 삼스
iOS2013. 6. 28. 19:35


iOS UIWebView Page loading flow 테스트 결과

didStartLoad delegate에서 webVIew.request.URL은 이전 페이지의 URL이거나 비어있다.

페이지로딩이 리다이렉트될때

 1. shouldStartLoading (requestURL is target page)

 2. didStartLoading

 3. shouldStartLoading (requestURL is redirect target)

 4. didFinishLoad (request.URL is redirect target)

 Note : 두번째 didStartLoading이 호출되지 않는다.


iframe을 포함한 페이지의 로딩시

 1. shouldStartLoading (requestURL is main page)

 2. didStartLoading

 3. shouldStartLoading (requestURL is one of the iframes)

 4. didStartLoading

 5. didFinishLoad

 6. didFinishLoad

Note didFinishLoad가 어떤 didStartLoad에 대응되는지 알 방법이 없음.


window.history.go(-1)가 호출될때

 1. didStartLoading

 2. didFinishLoad

 Note shouldStartLoading가 호출되지 않는다.  iOS6에서는 호출된다.


location.reload()호출시

 1. shouldStartLoading

 2. didStartLoading

 3. didFinishLoad


iframe페이지 로딩이 실패한 경우:

 1. shouldStart (main page)

 2. didStart

 3. shouldStart (iframe)

 4. didStart

 5. didFailWithError

 6. didFinish


잘못된 URL로 인해 iframe로딩이 실패한 경우

 1. shouldStart (main page)

 2. didStart

 3. shouldStart (iframe)

 5. didFailWithError

 6. didFinish

didStart가 누락된다. 해결하려면 shouldStart에서 URL을 체크하고 문제가 있으면 NO를 리턴하면 된다.


잘못된 URL접근인 경우

 1. shouldStart (main page)

 2. didFailWithError


Posted by 삼스