import com.google.appengine.api.appidentity.AppIdentityServiceFactory;

public class AppEngineUtils {
	private AppEngineUtils() {
	}
	/**
	 * war/WEB-INF/appengine-web.xmlで設定したアプリケーション名を取得する。
	 * @return アプリケーション名
	 */
	public static String getApplicationName() {
			return AppIdentityServiceFactory.getAppIdentityService()
					.getServiceAccountName().split("@")[0];

	}
}

Python:

from google.appengine.api.app_identity import get_application_id
appname = get_application_id()

ここで取得できるアプリケーション名はwar/WEB-INF/appengine-web.xmlのapplicationタグで指定されているものです。
デプロイ先ごとに設定を切り替える時などにどうぞ。

アクティビティを実装する場合はアクティビティのイベントがいつ発生するか(ライフサイクル)が大事ですし、自分でビューを作る時はビューのイベントを把握しておくとスムーズに実装ができるようになります。

Androidのアクティビティについてはいつどのイベント公式サイトのアクティビティライフサイクルの項目で分かりやすく図示されているのですが、ビューのライフサイクル、イベントの詳細を見つけられなかったため、今回は整理も兼ねてこの記事を公開することにしました。

Android の View は Activity#setContentView() を呼ぶだけでも onFinishInflate(), onAttachedToWindow(),onLayout(),onDraw(),onMeasure()といったイベントが発生するのをご存知でしょうか？

どのタイミングでどのイベントが呼ばれるのか？

カスタムビューを作る時に処理をどのイベントに実装すべきかを悩んでいる方の助けになれれば幸いです。

図:Viewのライフサイクル(View lifecycle: English version)

基本

ビューをアクティビティに割り当てる方法は大きく分けて３通りあります。

• setContentView()を使ったXMLリソースの静的割り当て
  Activity#setContentView(int:レイアウトリソースID)

• inflate() を使ったXMLリソースの静的割り当て
  Inflater#inflate(int:レイアウトリソースID), setContentView()

• 自分でインスタンス化してからの動的割り当て
  Inflater#inflate(int:レイアウトリソースID), setContentView()

基本的にビューのライフサイクルはアクティビティのライフサイクルにほとんど依存しません。

唯一アクティビティの終了する時だけは onDetachedFromWindow()が実行されますが、
その他の画面の切り替えなどの影響を受けることはないようです。

イベント一覧

View#onFinishInflate()イベント

名前の通り、 XMLから展開された直後に呼ばれます。

View#onAttachedToWindow()イベント

ウィンドウへの割り当てが終わった後に非同期で呼ばれます。

特に、アクティビティのライフサイクルに関わるイベント(onCreate(),onResume(),onRestart()など)は、すべて実行が終わってからonAttachedToWindow()が実行されるようです。

View#onMeasure()イベント

ビューのサイズを決定するイベントです。

ビューがウィンドウに割り当てられている間、頻繁に実行されます。

このメソッドはサイズ計算、設定に必要な処理以外を加えるべきではありません。

View#onLayout()イベント

子要素を持つビューなどでレイアウトを更新するためのイベントで、子ビューの情報や構成を更新する場合などに使用できます。

requestLayout()やforceLayout()が呼ばれた後に非同期で発生します。
画面サイズが変わった場合などにもrequestLayout()やforceLayout()を通じて間接的に呼ばれます。

第一引数は画面に変更があったかどうかで、forceLayout()を呼ばれた場合やウィンドウ割り当て時はtrueが入り、requestLayout()を呼ばれた場合はfalseが入ります。

falseでの実行はtrueよりも多くあるので、負荷にコストがかかり頻繁に実行不要なものはtrueのみ実行する、という判定を加えるとよいでしょう。

View#onDraw()イベント

画面の描画を行うイベントです。Canvasを受け取って自身の描画処理(図形や画像の描画)を行うもので、一般的には子ビューを持たないもので使用されるイベントです。

初回割り当て時やrequestLayout(), foreceLayout()で発生し、onLayout()の後に実行されます。

また、onLayout()と異なりinvalidate()でも発生するイベントです。

このメソッドは頻繁に呼ばれるため、負荷がかかる処理には不向きです。onDraw()で遅延が発生するとビューの描画が遅れることになります。

View#onDetachedFromWindow()イベント

アクティビティから割り当てがなくなった時に発生するイベントです。

アクティビティの終了時や、setContentView()で他のビューを割り当てられた時、親のビューに対してremoveAllViews()が呼ばれた時などに発生します。

ライフサイクルに関係するイベントは以上です。
他にもビューサイズの変更で発生するイベント、フォーカスや表示切り替えで発生するイベントなどもありますが、表示が複雑になるため省略しています。その他のイベントについては公式リファレンスが参考になります。

ご覧頂いた通り Androidではビューのイベントはアクティビティのイベントにはあまり関係しません。

このため、たとえば、ActivityのonResume(),onPause()などに合わせた処理を入れたい場合は明示的に開始、中断のメソッドを提供する必要があります。

検証用プロジェクトソースとアプリapkファイル:
アプリ本体(apk) プロジェクトソース(zip)

こういうの。

dk-build clean 
Clean: gnustl_shared [armeabi-v7e] 
/bin/sh: -c: line 0: syntax error near unexpected token `(' 
/bin/sh: -c: line 0: `rm -rf (TARGET_OBJS)' 
make: *** [clean-gnustl_shared-armeabi] Error 1

色々調べたところ、原因は Android NDK r8eの問題のようで
android-ndk/build/core/build-binary.mk

の49行目を次のように修正したらエラーが出なくなった。

変更前:

$(cleantarget): PRIVATE_CLEAN_FILES := ($(my)OBJS)

変更後:

$(cleantarget): PRIVATE_CLEAN_FILES := $($(my)OBJS)

変更後の実行結果:

/Library/android-ndk/ndk-build clean NDK_DEBUG=1 all 
Clean: cvjava [armeabi-v7a]
Clean: gnustl_shared [armeabi-v7a]
Clean: gnustl_static [armeabi-v7a]
Clean: scv [armeabi-v7a]

再現環境はインストールしたバージョンは NDK r8e の OS X 64ビット版(android-ndk-r8e-darwin-x86_64.tar.bz2)
でした。
他の環境で試したわけではないのですが、他の環境ではこれでエラーがでないのでしょうか。

追記

Linux 64bit r8e でも再現するという情報をいただきました。対策も同様でいいそうです。

タイトルは半分冗談です。

Ext JS

JavaScriptで業務システムで使うRIA(リッチインターネットアプリケーション)フレームワークと言えば一番有名なのはExtJSです。

Sencha Ext JS

グラフや表など、ビジネス向けの部品が充実しています。

ExtJSデモ

このように大変便利なライブラリなのですが、ExtJSバージョン3以降は無償版ライセンスがGPLに変わってしまい、実質オープンソースアプリケーションでしか使えなくなってしまいました。

この問題は有料版ライセンスを購入すれば解決可能で、ライセンスがあれば業務向けの非公開アプリケーションももちろん作成可能です。

ただ、予算が少ない場合などライセンス費用が常に出せるとは限らないのが現実ですし、こちら(Sencha Ext JS と Sencha Touch の license について)でまとめられているように、運用会社と開発会社が異なる場合は２重にライセンスを買わないとならないなど、費用面では採用が難しい場合も多いかと思います。

Ext Core

ExtJSのライセンス問題を解決すべくExtJSの派生ライブラリとして生まれたのがExt Coreなのだそうです。

Ext Core

ExtJSコアのライセンス方向転換、GPLからMITへ(マイナビニュース)

Ext CoreはMITライセンスですので、ExtJSと違い無料で安心して利用できます。

ただし、機能面はコア部分だけということでExtJSからかなり制限されています。

用途としては主にExtJSで使っている便利な機能(Ext.extend(),String.format()など)を他でも使いたい、という時に利用するもので、UIについてはあまり期待しないほうがよさそうです。

SmartClient

そこでおすすめなのが SmartClient です。
ExtJSと比べると日本ではあまり知られていませんが、SmartClientもExtJSと同様の機能を備えているRIA開発向けJavaScriptライブラリです(注)。

SmartClientのJavaScriptライブラリは無償でLGPLライセンスとして使用可能なので、ExtJSの対抗として注目されています。

SmartClient

こんなグラフ、表も簡単に表示できます。

何ができるかは、SmartClientデモ
を見て頂くと実際動いているものがあるのでわかりやすいかと思います。

SmartClientも有償版がありますが、こちらはサーバを含めた統合環境(注釈参照)を使うためのもので、
JavaScriptライブラリを使う上ではLGPLライセンスでも無制限に使用可能となっています。

ダウンロードはこちらのダウンロードページから、「Download SmartClient 9.0 LGPL Edition」をクリックして下さい。

使い方はデモサイトにサンプルコードが参考になります。また、ダウンロードしたファイル内のドキュメントには詳しい使い方が書かれていますので、カスタマイズの際はそちらが参考になるでしょう。

ExtJS vs SmartClient

見た目的にはExtJSのほうが可愛いですが、機能面ではSmartClientも負けていません。

ExtJSにはGWT(Google Web Toolkit)と組み合わせられるExtGWTというものがありますが、SmartClientにもちゃんとSmartGWTがあり、こちらもLGPLライセンスで提供されています。

業務向けアプリを作りたいけど、事情がありExtJSのライセンスを購入できない、
というような場合はSmartClientの採用も是非検討してみてはいかがでしょうか。

注: 正確にいうと、本来SmartClientはJavaサーバフレームワークとJavaScriptクライアントで構成されているRIAプラットフォームです。
JavaScriptのクライアント側だけで単独動作可能であり、ExtJSに相当する機能はJavaScriptクライアントだけで実現できるため、記事内では簡単にするため省略しています。

別の方(GAE/JでGson利用時にjava.lang.VerifyErrorが発生する)」もとりあげているのと同じ現象のようですが、一応対応がわかったのでメモしておく。該当のコードを見るとnew Gson()のところで発生しているらしい。

ローカルの開発環境では再現せず、デプロイ先でだけ発生するのが困ったところ。

2013-03-27 15:48:58.984
Error for /main
java.lang.VerifyError: Cannot inherit from final class
	at com.google.appengine.runtime.Request.process-914eb81ff215d801(Request.java)
	at java.lang.ClassLoader.defineClass1(Native Method)
	at java.lang.ClassLoader.defineClass(ClassLoader.java:634)
	at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
	at java.net.URLClassLoader.defineClass(URLClassLoader.java:277)
	at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:616)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:266)
	at jp.co.example.MainServlet(MainServlet.java:82

使っている環境は Google App Engine 1.7.5, Java SDK6、
Slim3 1.0.16, そして Gson 2.2.1。Javaは5も7もだめだった。

何度デプロイし直してもだめで、一時ファイルなどキャッシュになってそうな箇所を
片っ端から一旦クリアしてもやっぱりVerifyError。

色々試行錯誤した結果、原因は不明だけど、
次の方法でエラーなしに動作することがわかった。

• Gson2.2.1のコンパイル済のjarでなく、ソース(gson-2.2.1-source.jar)を展開してプロジェクトソースに組み込む。

• Gsonのバージョン1.7.1を入れる(2.2.1から1.7.1にバージョンを落とす)。

ソースを組み込むのは嫌だったので、後者で対応して解決とすることとした。

そんな時は騒がず慌てず４つのポイントをチェック。

1. ファイルの名前は”〜.9.png”で終わること

9.png で終わるファイルが 9 patch ファイルのしるしです。

jpg はだめ。pngです。banner.9.png のように、ちゃんと「.9.png」という拡張子で終わっているか確認しましょう。

2. 画像のサイズは元画像のサイズ＋２ピクセル

9patch は元の画像の上下左右1ピクセルずつの縁を設用定に使っています。

正しい 9patch 画像なら縁にあるのは黒だけでほかは余白になっているはず。

3. 画像の周りは「黒」だけ

四隅に描いていいのは黒だけです。

ここでいう「黒」は、透過なしの真っ黒(#000000)のこと。
#000001でもいけません。

それから、いくら薄いからといっても、少しでも他の色が隅についてしまうと認識しなくなります。

特にアンチエイリアスには気をつけましょう。

4. 黒い点、ちゃんとつながってる？

上下左右それぞれで、黒い点がつながって１本線になっていないと認識してくれない場合があります。

9patchエディタ(draw9patch ツール)や、Eclipseのレイアウトエディタなんかではちゃんと伸び縮みして見える。

でも実機で見るとばっちり黒いドットが見えてしまう。
そんな場合はこれが原因かもしれません。

最後のチェックポイントは意外とはまりやすいのではないでしょうか。
以上、9-patch のトラブルシューティングでした。

【ピクチャフォルダに保存する】

$ defaults write com.apple.screencapture location ~/Pictures
$ killall SystemUIServer

ピクチャ以外にも好きなディレクトリにすることもできます。

【ScreenShotsフォルダに保存する】

$ mkdir ~/ScreenShots
$ defaults write com.apple.screencapture location ~/ScreenShots
$ killall SystemUIServer

戻したくなったら下のコマンドで戻すこともできます。

【デフォルト(デスクトップ)に戻す】

$ defaults delete com.apple.screencapture location
$ killall SystemUIServer

以上、クリーンショット保存先を変える方法でした。
散らかってしまいがちなデスクトップもこれで綺麗に整理整頓されるかも。

どうやらハニカムで修正されたOSの不具合だそうで…以下対策がわかったのでメモ。

どういう状況？

タイル背景(bg.xml)はこんな感じです。

<!-- res/drawable/bg.xml -->
<?xml version="1.0" encoding="utf-8"?>
<bitmap xmlns:android="http://schemas.android.com/apk/res/android"
    android:antialias="true"
    android:dither="false"
    android:filter="false"
    android:gravity="fill"
    android:src="@drawable/bg_repeat"
    android:tileMode="repeat" />

これを各レイアウトで次のように使っています。

<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:background="@drawable/bg" >

リピートが効く画面もあるのですが、効かない画面では伸びたタイル画像が
１枚だけ表示されてしまいます。これはかっこ悪い。

直し方は？

StackOverFlow(background image not repeating in android layout)に書かれていました。

下のコードを適宜、描画の更新タイミングでリピートを行なっているビューに対して実行するといいようです。

public static void fixBackgroundRepeat(View view) {
      Drawable bg = view.getBackground();
      if(bg != null) {
           if(bg instanceof BitmapDrawable) {
                BitmapDrawable bmp = (BitmapDrawable) bg;
                bmp.mutate(); // make sure that we aren't sharing state anymore
                bmp.setTileModeXY(TileMode.REPEAT, TileMode.REPEAT);
           }
      }
 }

画面背景のリピートを修正するならこのように実行すればいいでしょう。

fixBackgroundRepeat(this.findViewById(android.R.id.content)
				.getRootView());

どうしてこうなった

StackOverFlowのコメントによると、ハニカム(Android 3.0)で修正された不具合のようで、同じ画面でBitmapDrawableが多数使われていると、内部でのBitmap(とBitmapの状態設定)の再利用のタイミングでtileMode設定が簡単に失われてしまうようです。

対策で行っていることは、消えてしまった背景画像のリピート設定を再度設定し直しているのですね。

ひらがなを入力したら変換候補が出てきますが、ここでタブを押して変換候補を切り替えようとしたら、タブキーを押した途端に変換候補の欄が閉じて、入力中の文字が消えてしまう。

カーソルで変換候補を切り替えればいつも通り入力はできます。
でも、つい癖でタブキーを押すたび、入力をやり直すハメになって、手が止まる…。

これじゃいけないとタブ関係のキーバインドを見なおしたら何とかなったので、
修正方法をメモしておきます。

解決方法

メニューからPreferences > Key Bindings – Default を開きます。
すると、下のような怪しい部分があるので…

	{ "keys": ["tab"], "command": "insert_best_completion", "args": {"default": "\t", "exact": true} },
	{ "keys": ["tab"], "command": "insert_best_completion", "args": {"default": "\t", "exact": false},
		"context":
		[
			{ "key": "setting.tab_completion", "operator": "equal", "operand": true }
		]
	},

これをコメントアウトしてしまいます。

/*
	{ "keys": ["tab"], "command": "insert_best_completion", "args": {"default": "\t", "exact": true} },
	{ "keys": ["tab"], "command": "insert_best_completion", "args": {"default": "\t", "exact": false},
		"context":
		[
			{ "key": "setting.tab_completion", "operator": "equal", "operand": true }
		]
	},
*/

あとは保存すればOK。

これで、ストレスなく快適にSublime Text 2を使えるようになりました。

それで原因は？

なんでしょうね…。
色々とプラグインを入れて使っているため、何が原因かは不明なんです。
情報求む。

発生した症状

Homebrew でインストールしたパッケージ(cairo)に依存している箇所でエラーになってしまいました。

具体的には ./configure の実行中に pkg-config で依存しているパッケージの.pc ファイルが存在しないと怒られています。

# config.log
pkg-config --cflags --print-errors cairo 

Package xcb-shm was not found in the pkg-config search path.
Perhaps you should add the directory containing `xcb-shm.pc'
to the PKG_CONFIG_PATH environment variable
Package 'xcb-shm', required by 'cairo', not found

解決するには？

エラーメッセージどおり、環境変数 PKG_CONFIG_PATHの通るところに .pc ファイルを配置するか、環境変数にパスを追加して再実行することで解決しました。

PKG_CONFIG_PATHが空の場合のデフォルトは

/usr/local/lib/pkgconfig

です。

今回は /opt/X11/lib/pkgconfig/ の中に依存している .pcファイルがあったので、パス追加で対応しました。

$ export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:/opt/X11/lib/

再実行し、エラーが出なくなるのを確認します。

$ pkg-config --cflags --print-errors cairo

あとは通常通り、./configure, make などを実行すればOKです。

OS X では(Homebrewでは？) X11 関係の pkgconfigのパッケージ情報ファイル(.pcファイル)は /opt/X11/lib/pkgconfig/ にあるのですね。