출처 : http://cdkkcdkktoandroid.tistory.com/14

저도 아직 자세히는 파악을 하지 못했지만 WebView.java를 보니깐 WebView로 url를 로드 하면 로드 할때마다 쿠키를 사용하지 못하더군요. 아 사용 못하는게 아니고 대략 테스트를 해보니 로드된 페이지에서 쿠키를 저장하고 있는데 약 5분 정도가 지나야 WebView에서도 적용이 되더군요. 이상해서 WebView를 까보니 WebView로 로드 하게되면 로드 될때마다 쿠키를 초기화 하더군요. 

이를 해결하기 위해서는  CookieSyncManager를 사용해야 합니다.

액티비티를 호출하게 되면 그 생명주기에 맞게 Override한 메소드를 타게 되어있는데 그에 맞게 CookieSyncManager를 사용하면 WebView로 띄운 Url의 쿠키를 어플에 바로 적용이 되더군요

  @Override 

    public void onStart() { 

        super.onStart(); 

        CookieSyncManager.createInstance(this);

    }   

액티비티가 호출되면 onStart 메소드를 타는데 이때  인스턴스를 생성하고

@Override

    public void onResume(){

     super.onResume();

     CookieSyncManager.getInstance().startSync();

    }

액티비티가 상호작용이 이루지면 onResume 메소드를 거칩니다. 이때 생성한 인스턴스를 

startSync() 해줍니다.

그리고 액티비티가 종료될 수 도 있는 상태인 일시정지 상태(종료되는건 아님)에 stopSync() 해줍니다.

 @Override

    public void onPause(){

     super.onPause();

     CookieSyncManager.getInstance().stopSync();

    }

이렇게 해놓으면 액티비티 생명주기에 따라 쿠키를 동기화 시켜주게 됩니다.

그리고 하나더 중요한 부분이

 WebView를 띄울때 브라우저에서 제어권을 넘겨 받는 부분인 setWebViewClient의 페이지 로딩이 끝나면 타는 메소드인 onPageFinished 안에 쿠키를 분석해놔야 합니다.

webView.setWebViewClient(new MyWebClient{

        public boolean shouldOverrideUrlLoading(WebView view, String url){

     view.loadUrl(url);

     return true;

     }

     //WebView가 로딩이 끝나면 시작

     public void onPageFinished(WebView view, String url){

     CookieSyncManager.getInstance().sync();

     }

        });

참고로 말씀들이면 이 방법이 틀렸을 수도 있습니다. 한동안 WebView로 해당 URL의 쿠키를 사용할 수 있게 하기 위해서 별짓을 다 해봤는데 이 방법으로 하니 잘 되더군요.

그리고 구지 이 방법으로 하지 않아도 됩니다. 웹서버에서 쿠키를 저장하게 하지 않고 해당 URL이 로딩하게 되면 비지니스 로직에 맞게 해당 페이지에서 App을 호출해서 값을 넘겨서 App에서 강제로 쿠키매니저로 저장하시면 됩니다. 하지만 별로 권하고 싶지 않군요

이유는 웹에서 이미 쿠키를 저장하고 있는데(하이브리드 App 이니깐용) 구지 그걸 어플에서 다시 getCookie 해서 set을 하던지 해서 조작할 필요없다고 생각합니다. 뭐 물론 특별한 상용에서는 논외로 해야하지만용~ 아무튼 그냥 단순히 모바일 웹에서 잘 되던 쿠키가 WebView로 로딩하니깐 안된다면 위 방법을 한번 사용해 보시기 바랍니다.(거듭강조하지만 이 방법이 정확한건 아닙니다.)

그럼 참고해주시고 혹시 제가 파악한 위 사항이 잘못되었다면 저에게도 좀 알려주시기 바랍니다 ㅜ.ㅜ 그럼 잡스형에게 삿대질 할 그날까지 ~~

https://baepower.wordpress.com/2011/02/17/html5%EC%97%90%EC%84%9C%EB%8A%94/

참고 : http://devian.tistory.com/159

PlayStore 에 등록시 보안이슈 발생 해결방안 보기

로컬 HTML(JavaScript)과 App 영역이 통신(함수호출)을 함으로써 간단한 하이브리드 앱을 만들어볼 수 있다.

1. HTML에서 App 함수 호출
   1) 멤버로 android.os.Handler 를 생성한다. 호출 시 thread 처리를 위해서 이용된다.
        private final Handler handler = new Handler();

   2) App과 Javascript간 Bridge 클래스를 생성하고, 호출될 함수를 implement 한다.
       (이 때 파리메터는 반드시 final로 선언)
       Javascript에서 호출시 별도의 Thread로 구동될 수 있도록 아래와 같이 구현한다.

위의 방법으로 연결된 간단한 하이브리드 어플리케이션이다...

참고 : http://blog.daum.net/gyoju12/49

1. Android에서 Javascript함수 호출하기

 

webView.loadUrl("javascript:callJS('Hello from Android')");

 

다음과 같은 방식으로 javascript:methodname 과 같은 문자열을 넣어 WebView.loadUrl 메소드의 인자로 호출한다.

2. Javascript에서 Android 호출하기

 

/** Object exposed to JavaScript */
    private class AndroidBridge {
       public void callAndroid(final String arg) { // must be final
          handler.post(new Runnable() {
             public void run() {
                Log.d(TAG, "callAndroid(" + arg + ")");
                textView.setText(arg);
             }
          });
       }
    }

 

다음과 같이 브릿지 역활을 할 Class를 만든다.

WebView의 세팅을 바꾸고

           webView.getSettings().setJavaScriptEnabled(true);

WebView에 Javascript Interface를 추가해준다.

           webView.addJavascriptInterface(new AndroidBridge(),"android2");

HTML페이지에서 다음과 같은 방식으로 호출한다.

           window.android2.callAndroid('Hello from Browser')

android2는 addJavascriptInterface의 두번째 인자와 같다.

3. Javascript Listener 걸기

 

 webView.setWebChromeClient(new WebChromeClient() {
           @Override
           public boolean onJsAlert(final WebView view,
                 final String url, final String message,
                 JsResult result) {
              Log.d(TAG, "onJsAlert(!" + view + ", " + url + ", "
                    + message + ", " + result + ")");
              Toast.makeText(LocalBrowser.this, message, 3000).show();
              result.confirm!();
              return true; // I handled it
           }
        });

 

다음과 같이 WebView의 setWebChromeClient를 이용한다.

위 예제는 Javascript의 alert메소드 발생시 이벤트이다.

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

출처 : SHSDOL.COM > 안드로이드 android javascript 연동하기

=== 1일 이내에 수정된 파일

find ./* -mtime -1 (현재 폴더 미포함)
find . -mtime -1 (현재 폴더 포함)

=== 1일 이내에 접근된 파일

find ./* -atime -1

=== 1일 이내에 상태가 변경된 파일

find ./* -ctime -1

=== man 페이지 내용 ===

-atime n

              File  was  last  accessed n*24 hours ago.  When find figures out how many 24-hour periods ago

              the file was last accessed, any fractional part is ignored, so to match -atime +1, a file has

              to have been accessed at least two days ago.

-ctime n

              File's status was last changed n*24 hours ago.  See the comments for -atime to understand how

              rounding affects the interpretation of file status change times.

-mtime n

              File's  data was last modified n*24 hours ago.  See the comments for -atime to understand how

              rounding affects the interpretation of file modification times.

참조
    1. http://sidharthdeshpande.blogspot.kr/2011/08/postgresql-904-streaming-replication.html
    2. http://wiki.postgresql.org/wiki/Streaming_Replication

2번 참조가 공식 사이트의 사용방법이고, 1번 참조가 좀 더 자세하게 나온 것이다.

PostgreSQL은 9.1버전의 deb파일을 구해서 ubuntu 10.0.4에 설치하여 테스트했다.
    - PostgreSQL 9.1 설치 : http://wiki.openscg.com/index.php/Postgres_9.1_DEB
    - PostgreSQL 9.1 deb 및 rpm 파일 : http://www.openscg.com/se/postgresql/packages.jsp

설정은 master를 먼저 하고, slave를 실행한다.
ubuntu 기준으로 설치 시 /opt/postgresql/9.1/ 폴더에 설치가 되었다.
설정 중 경로가 없는것들이 몇 개 있는데 mkdir로 만들어 준다.

=== Master 설치 ===

1. PostgreSQL 9.1 설치 및 초기화
    # dpkg -i postgresql...deb
    # /etc/init.d/postgres-9.1-openscg start

2. 환경설정파일 수정
    # cd /opt/postgres/9.1/data
    - postgresql.conf파일과 pg_hba.conf파일을 수정해야 하는데, 수정하는 내용은 위의 참조 사이트를 참고한다.

3. DB 및 테이블 생성
    - 실제 데이터가 들어갈 DB 및 테이블을 생성
    - DB 생성은 createdb 를 사용하면 된다.

4. DB 데이터 백업
    - 2번 참조 사이트의 How to Use섹션 5번, 6번 항목을 참고한다.
    - rsync는 scp를 내부적으로 사용한다. 따라서 파라미터도 scp에 들어가는 것과 같다.

5. 4번까지 끝나면 slave의 /srv/pgsql/standby 폴더에 /opt/postgres/9.1/data의 파일들이 전부 복사되어 있다.

=== Slave 설치 ===

6. PostgreSQL 9.1 설치
    # dpkg -i postgresql....db
    - slave에서는 초기화를 하지 않는다.

7. DB 데이터 파일 복사
    - 4번에서 복사한 /srv/pgsql/standby의 모든 파일을 /opt/postgres/9.1/data 폴더에 복사한다.
    - 그 후 권한과 사용자를 변경한다.
    # cd /opt/postgres/9.1/data
    # chmod 700 .
    # chown -R postgres:postgres .

8. 환경 설정파일 수정
    - data폴더의 모든 파일을 복사 하였기 때문에 master와 똑같은 설정이 몇가지 있어서 수정한다.
    - postgresql.conf 파일의 master설정 부분을 주석처리한다.
    # vi postgresql.conf
    max_wal_senders = 5 -> #max_wal_senders = 5
    wal_keep_segments = 32 -> #wal_keep_segments = 32
    - slave라는것을 알 수 있도록 hot_standby 항목의 값을 변경한다
    #hot_standby = off -> hot_standby = on

    # vi pg_hba.conf
    - replication으로 설정된 항목 삭제

9. 환경설정 파일 추가
    - 2번 참조 사이트의 How to Use섹션 9번을 참고한다.

10. 마무리
    - 1번 참조 사이트에서 slave의 recovery.conf파일을 생성 한 후 하는 명령어를 실행한다.
        - initdb 실행
        - DB 시작

    - 정상적으로 replication이 설정되었다면 1번 참조 사이트의 로그 내용이 출력된다. 로그는 pg_log 폴더에 있다.

11. 테스트
    - master에서 DB에 아무 값이나 넣어본 후 slave에서 정상적으로 데이터가 복제되나 확인해본다.

※ 에러 사항

1. slave를 시작하는데 시작하는 시간이 오래 걸리고, 로그 내용중 "database system identifier differs between the primary and standby" 이란 에러가 있다면, slave에서 DB초기화를 해서 생긴 에러다.
    ==> data폴더를 삭제 후 다시 slave 설정을 하거나, 그래도 안되면 slave에서 PostgreSQL 9.1을 삭제한 후 다시 설치한다.

2. FATAL:  data directory "/opt/postgres/9.1/data" has group or world access
DETAIL:  Permissions should be u=rwx (0700).
    ==> 말 그대로 data폴더의 권한을 700 으로 주란 소리다.

참조 : http://slony.info/documentation/1.2/firstdb.html

replication의 초기화는 master에서 설정하고, replication 동작은 slave에서 실행한다. 참조의 쉘 스크립트 자체가 master->slave로 되어 있다.

master에서 초기화 쉘 스크립트를 만든다. 파일명은 맘대로....
참조 웹 페이지의 2.3.1 섹션의 쉘 스크립트를 가져다가 적당히 수정한다. 테이블이라던가.... 패스워드라던가...
참조에는 없는 부분인데... store path 아래에 아래 두줄을 넣어준다.

store listen (origin=1, provider = 1, receiver =2);
store listen (origin=2, provider = 2, receiver =1);

만든 쉘 스크립트를 실행 한 후 참조에 있는대로 master와 slave에서 slon데몬을 실행한다.

slon $CLUSTERNAME "dbname=$MASTERDBNAME user=$REPLICATIONUSER host=$MASTERHOST" -> master
slon $CLUSTERNAME "dbname=$SLAVEDBNAME user=$REPLICATIONUSER host=$SLAVEHOST" -> slave

정상적으로 설정이 되었다면 master(node에서 id를 1로 지정)의 로그 중 slave(node에서 id를 2로 지정)와의 싱크중이라는 뜻으로 대략 아래와 같은 메세지가 출력된다. slave의 로그는 id에 해당하는 부분만 1로 출력된다.

remoteListenThread_2: LISTEN
remoteWorkerThread_2: Received event 2,nnn SYNC

만약 db_getLocalNodeId() returned 2 - wrong database? 이런 에러가 뜨면 ip문제일 수도 있다. (테스트 시 localhost로 지정했더니 이같은 에러가 나타나 localhost의 실제 ip주소를 적어주었다. (1) 초기 설정 편의 예시를 보면 된다)

이 에러가 떴다면 master와 slave에서 일단 이전에 만든 정보를 삭제해준다.
psql -h localhost -U postgres -d test_db -c "drop schema _$CLUSTERNAME cascade"

그 후에 다시 초기화 스크립트를 실행해준다.

싱크가 잘 된다면, slave에서 데이터를 받아오도록 하는 스크립트를 실행한다. 역시나 마찬가지로 참조의 스크립트를 가져다가 적당히 수정해서 사용하면 된다.

데이터 가져오는 스크립트를 한번 실행하면 그 후로는 pc가 껐다 켜져도 데몬만 실행하면 된다.

테스트를 해본다. 잘 된다. 끗! 

참고 : http://slony.info/documentation/1.2/firstdb.html

Ubuntu 10.0.4에서 설치하였기 때문에 PostgreSQL 9.0 미만의 버전에서 사용하는 방법이다.
PostgreSQL 9.0 이상은 Streaming Replication이라는 방법을 지원한다.(http://wiki.postgresql.org/wiki/Streaming_Replication)

계정은 기본 계정인 postgres를 그냥 사용했다.
어차피 계정을 새로 만들어도 slave에서 password 설정을 해줘야 한다. (master에서 연결하기 위해서)

계정의 password 설정하는것을 제외한 모든 작업은 master에서 진행한다.

postgres 계정의 비번 변경 방법.

# sudo su - postgres
# psql template1
# alter user postgres with password '1234';

- Replication에 필요한 프로그램 목록
    - postgresql-8.4
    - postgresql-8.4-slony1
    - slony1-bin

- .bashrc 설정(master, slave 전부 설정)

CLUSTERNAME=slony_example
MASTERDBNAME=test_db
SLAVEDBNAME=test_db
MASTERHOST=192.168.0.71
SLAVEHOST=192.168.0.72
REPLICATIONUSER=postgres

- 재부팅 하지 않고 계속 작업할 경우 export로 환경변수 셋팅을 해준다.
- 만약 서로 다른 PC에서 작업할 경우 host의 ip주소 중 localhost가 입력되면 안된다.

밑의 작업은 master에서 postgres 계정으로 전환한 후 작업한다.

- DB 생성

      # createdb -O $REPLICATIONUSER -h $MASTERHOST $MASTERDBNAME
      # createdb -O $REPLICATIONUSER -h $SLAVEHOST $SLAVEDBNAME

- Password 설정 (master, slave 전부 설정한다)

- table 생성
      # psql -U $REPLICATIONUSER -h $MASTERHOST -c "create table history();"
      # psql -U $REPLICATIONUSER -h $MASTERHOST -d $MASTERDBNAME -c "begin; alter table
      history add column id serial; update history set id =
      nextval('history_id_seq'); alter table history add primary key(id); commit"

- pl/pgSQL
    # createlang -h $MASTERHOST plpgsql $MASTERDBNAME

- schema 복제
    # pg_dump -s -U $REPLICATIONUSER -h $MASTERHOST $MASTERDBNAME | psql -U $REPLICATIONUSER -h $SLAVEHOST $SLAVEDBNAME

에러라고 생각할 수도 있고 아닐 수도 있지만...

jsp에서 커넥션을 하나만 생성하고 생성된 커넥션으로만 Read, Write를 했는데...

Write하는동안 read를 할 수 없도록 lock이 걸려 있다..

lock때문에 동시 접속시 tomcat이 뻗어버리는 상황까지 발생...

ab에서 concurrency를 10개 이상을 셋팅하면 무조건 뻗는다... ㅋㅋㅋㅋ

결국 sqlite는 동시접근을 하면 안되는구나 라는 판단이 들고.. 다른 DB로 바꿔 버렸다 ;;

intent filter를 통해 설정.

인터넷 브라우저에서 메뉴-페이지 공유 라던가.... 암튼 메뉴의 공유 라는 명령을 실행할 때 내 앱도 받을 수 있게 해주는 방법이다.

받고자 하는 Activity에 설정한다

<intent-filter>

<action android:name="android.intent.action.SEND" />

<category android:name="android.intent.category.DEFAULT" />

<data android:mimeType="image/*" />

<data android:mimeType="video/*" />

<data android:mimeType="audio/*" />

<data android:mimeType="text/*" />

<data android:mimeType="application/*" />

<data android:mimeType="plain/*" />

</intent-filter>

<intent-filter>

<action android:name="android.intent.action.SEND_MULTIPLE" />

<category android:name="android.intent.category.DEFAULT" />

<data android:mimeType="image/*" />

<data android:mimeType="video/*" />

<data android:mimeType="audio/*" />

<data android:mimeType="text/*" />

<data android:mimeType="application/*" />

<data android:mimeType="plain/*" />

</intent-filter>

android:mimeType이 실제로 내 어플에서 받을 데이터의 유형이다.

예를들어 브라우저에서 페이지 공유를 하면 웹URL을 text형태로 받을 수 있다.

===

반대로 내 앱에서 공유하기 메뉴를 만들어 다른 어플에 데이터를 전송하고자 하려면 startActivity를 사용한다.

Intent i = new Intent(Intent.ACTION_SEND);

i.setType("text/plain");

i.putExtra(android.content.Intent.EXTRA_TEXT, "Share Data");

startActivity(Intent.createChooser(i,"Share using"));

Intent:setType에 설정되는 값에 따라서 받을 수 있는 앱의 목록이 달라진다.

text/plain은 SNS앱에 공유하기가 가능한 타입이다.

intent filter를 설정하여 받을 수 있다.

받고자 하는 Activity에 설정.

<intent-filter>

<action android:name="android.intent.action.VIEW" />

<category android:name="android.intent.category.DEFAULT" />

<category android:name="android.intent.category.BROWSABLE" />

<data android:scheme="myapp"/>

</intent-filter>

<intent-filter>

<action android:name="android.intent.action.VIEW" />

<category android:name="android.intent.category.DEFAULT" />

<category android:name="android.intent.category.BROWSABLE" />

<data android:scheme="http" android:host="www.daum.net" android:pathPrefix="/"/>

</intent-filter>

custom scheme 설정과 http scheme에 대한 intent filter이다.

URL을 받기 위한 intent filter를 설정할 때에는 android.intent.category.BROWSABLE을 필히 설정해야한다.
또 한, 하나의 intent filter에는 1개의 scheme에 대한 정보만 들어가야 된다. (처음에 하나에 두가지를 같이 넣었었는데 이상 동작을 함. 심심하면 테스트 하면서 차이를 아는것도 좋은 방법일듯)

http scheme에 대한 설정을 할 경우 android:pathPrefix를 필히 설정해야 거의 모든 android폰에서 동작한다. android:host는 특정 host에 대한것만 처리하기 위해 넣을때만 필요하다.

http scheme은 삼성폰의 icecream 이상 버전에서는 동작하지 않는다. (현재로선 절대 안되니 굳이 동작하게 하려고 고민할 필요도 없다)