Activityのライフサイクル

AndroidアプリはActivityという画面のベースのようなもので構成される。このActivityのプロセスはAndroid OSで管理されており、基本的には「いつ画面が破棄されても大丈夫な仕組み」を前提に設計をしていく必要がある。

IntentとonActivityResult()

他のActivityを表示して処理結果を取得するにはstartActivityForResult()を使用する。処理結果を取得する必要がない場合にはstartActivity()を使用する。

// このコードで処理結果取得モードで他のActivityを開始する
Intent intent = new Intent(activityInstance.getApplicationContext(), TargetActivity.class);
activityInstance.startActivityForResult(intent, 1);

// 開始されたActivity側では処理結果を以下のコードで返す
Intent data = new Intent();
data.putExtra("test", "value");
activityInstance.setResult(RESULT_OK, data);
activityInstance.finish();

// 呼び出し元では下記メソッドをオーバーライドして結果を取得する
protected void onActivityResult(int requestCode, int resultCode, Intent data) {
    if (resultCode == RESULT_OK) {
        switch (requestCode) {
        case 1:
            // resultには"value"が入る
            String result = data.getStringExtra("test");
            break;
        }
    }
}

Androidのスレッドについて

AndroidのUI(View)をコントロールするスレッドは通常のスレッドとは異なり、アプリが起動した段階から専用のスレッドが開始される。すべてのUI(View)の描画処理などはそのスレッドが行うため、他のスレッドからはViewに変更を加える事はできない。

AndroidのUIスレッド以外のスレッドからUIに変更を加えたい場合は、Android.os.Handlerのインスタンスを生成しpostメソッドで実行したいRunnableを渡す。UIスレッドはスケジュールされた順番にRunnableを実行してUIを描画していく。

AndroidのLinearLayoutについて

LinearLayout内に配置した子要素は、そのままの状態でweightを指定しても、正しい描画にならない事がある。heightまたはwidthをwrap_contentから0dpに変更すると正しくweightの指定通り描画される。

Androidアプリ開発でstring.xmlを使用する理由

昔から小規模アプリケーションを開発していると、自然にラベルやボタンのテキストを直打ちしていたので、Androidアプリを初めて作るときはとても戸惑った。直接入力すると警告が出るのです!!

string.xmlに値を登録してから使うのですが、これがまた慣れないと面倒で仕方ない。しかし、多言語対応する場合にはこれがとても大事になるので、しっかりしたいと思う。。。

PostgreSQLストリーミングレプリケーション設定(Windows)

2台構成

host:sv1 ip:192.168.0.100 略称:プライマリ
host:sv2 ip:192.168.0.101 略称:セカンダリ

まずは両ホストにPostgreSQLをインストール。本手順作成時はVer9.2を使用。インストール完了後に両端末で共通の管理者権限を持つアカウントを作成し、サービス実行アカウントをそれに変更する。

プライマリでの作業

コマンドプロンプトを起動し、PostgreSQLのインストールフォルダ内、binフォルダに移動する。

cd "c:\Program Files\PostgreSQL\9.2\bin"

レプリケーション用ユーザーを作成する。

createuser -P -E -U postgres --replication rep_user

作成するユーザーのパスワードを2回入力し、最後にpostgresのパスワードを入力する。コマンドプロンプトの画面は閉じずに次へ。

外部からの通信を許可する。インストールフォルダ内の「data」にある「pg_hba.conf」の最後に下記の行を追加する。

host    replication    rep_user    192.168.0.0/24    md5

postgresql.confの下記8行を編集する。
※synchronous_commitはシステム要件によって変更した方が良い

listen_addresses = '*'
wal_level = hot_standby
fsync = on
synchronous_commit = off
wal_sync_method = fsync
max_wal_senders = 2  ※プライマリを含んだレプリケーションサーバーの数を入れる
wal_keep_segments = 32  ※8~32が目安らしい
synchronous_standby_names = '*'

ついでに下記設定値がシステム要件に合っているか確認する。

max_connections = 300  ※同時接続数
shared_buffers = 1024MB  ※物理メモリの1/4程度
work_mem = 8MB  ※物理メモリの1/500程度だが最大8MB
effective_cache_size = 2048MB  ※物理メモリの1/2程度

postgresqlサービスを再起動。OS再起動でもよい。

セカンダリでの作業

postgresqlサービスを停止した状態で、PostgreSQLのインストールフォルダ内の「data」フォルダ内を空にしておく。

コマンドプロンプトを起動し、PosgreSQLのインストールフォルダ内、binフォルダ内に移動する。

cd "c:\Program Files\PostgreSQL\9.2\bin"

以下のコマンドを実行してプライマリからベースバックアップする。

pg_basebackup -h 192.168.0.100 -p 5432 -U rep_user -D "c:\Program Files\PostgreSQL\9.2\data" -x -c fast -P

インストールフォルダ内の「data」にある「postgresql.conf」を編集する。

hot_standby = on

postgresqlサービスを再起動。OS再起動でもよい。

同じ場所に「recovery.conf」を新規作成、内容は下記の通り。

standby_mode = 'on'
primary_conninfo = 'host=192.168.0.100 port=5432 user=rep_user password=[pass] application_name=sv2'
recovery_target_timeline = 'latest'
trigger_file = 'C:\\\pgsql\\failover-trigger'
recovery_end_command = ''

postgresqlサービスを開始し、ログで正常動作を確認する。