今回の出張では会いたかった開発者が来れてなかったり、 前回のようにプレゼンもなく、予定していたデモは機材の関係でできなかったりと、 ちょっと微妙だったが、
バルセロナは良かった。物価も安く、美味かった。 これまでも、パリ、バンクーバー、オースチン、バルセロナと半年おきで出張があったわけだが、 これでもしかすると終わりかもしれぬと思うと感慨深い。特に役得的に。
]]>
今回の出張では会いたかった開発者が来れてなかったり、 前回のようにプレゼンもなく、予定していたデモは機材の関係でできなかったりと、 ちょっと微妙だったが、
バルセロナは良かった。物価も安く、美味かった。 これまでも、パリ、バンクーバー、オースチン、バルセロナと半年おきで出張があったわけだが、 これでもしかすると終わりかもしれぬと思うと感慨深い。特に役得的に。
]]>まず、DEBUGというプリプロセッサマクロが定義されていた場合のみ、
ログを出力する、DEBUG_NSLog というプリプロセッサマクロを仕込む。
(プリプロセッサマクロ、という単語で良いんだよね？？)
#ifdef DEBUG
#define DEBUG_NSLog NSLog
#else
#define DEBUG_NSLog
#endif
そして、デバッグビルド時のみに出力してほしい場合には、DEBUG_NSLogを使う。
Debugビルド時のターゲットの設定に、プリプロセッサマクロ「DEBUG」を追加する。
Releaseビルド時の設定には何もなし。
これで Debugビルド時のみ、DEBUG_NSLogはログを出力するようになる。
]]>ほんと死んじまえ！って感じでブログを書くならFC2はやめてほしいけど、 そんな非現実的なことを呻いていても仕方ないので Safari のリファラをなんとかいじってみようと調べてみる。
ってか Firefox 使いなら RefControl :: Firefox Add-ons があるので Firefox にしとけばいいじゃんって話なんだけど。ここは Safariで。
HMDTの本、
とか読む限り、WebKit はリソースのリクエストに NSURLRequest を使うらしい。
それならば話は簡単だ！と思ったのはちょっと軽率だったが、まあとりあえずこんな努力をしてみた。
@implementation NSURLRequest (SRHSwizzle)
-(NSDictionary *) _srh_allHTTPHeaderFields
{
NSMutableDictionary* headers = [NSMutableDictionary
dictionaryWithDictionary:[self _srh_allHTTPHeaderFields]
];
[headers setValue:@"http://www.google.com/" forKey:@"Referer"];
return headers;
}
@end
@implementation SRHSafariReferrerHack
+ (void) load
{
BOOL rc;
rc = MethodSwizzle(
[NSURLRequest class],
@selector(allHTTPHeaderFields),
@selector(_srh_allHTTPHeaderFields)
);
}
@end
Referrer として必ず "http://www.google.com/" を返す _srh_allHTTPHeaderFields というメソッドを NSURLRequestに用意してやって、 allHTTPHeaderFields と MethodSwizzling。
これを SIMBL プラグインとして Safari に読み込ませてやった。
が、駄目。
自分の鯖にアクセスしてみたらこんなログを残した。
0.238.74.67 - - [16/Jun/2008:12:11:40 +0900] "GET / HTTP/1.1" 200 27161 "http://www.google.com/" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_3; en-us) AppleWebKit/525.18 (KHTML, like Gecko)"
60.238.74.67 - - [16/Jun/2008:12:11:41 +0900] "GET /images/banner.png?1208240823 HTTP/1.1" 200 2192 "http://yuanying.oeilvert.org/" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_3; en-us) AppleWebKit/525.18 (KHTML, like Gecko)"
直のアクセスのリファラは変わったんだけど、そのHTMLから読み込まれる画像とかのリファラは変わってない。
webView:resource:willSendRequest:redirectResponse:fromDataSource: が送られてくる時点のヘッダはちゃんと置き換わってるから、 実際にリソースをダウンロードする時点でリファラをちゃんと直してるっぽい。
こうなったらもう絶対ハックしてやる！っていう勢いで、 WebKit のソースをダウンロードして読み始める。
WebFrame.mm の 1196行目あたりにドキュメント中のリソースを読み込んでるらしきソースを発見する。
- (void)loadRequest:(NSURLRequest *)request
{
_private->coreFrame->loader()->load(request);
}
えーっと。。。WebCore に潜れとおっしゃりますか？
WebCore 読んでたら、結局のところリソースのダウンロードは NSURLConnection を使うってところに行き着いた。
とりあえず簡単に試してみようと、NSURLConnection をポージング。
@implementation SRHNSURLConnection
+ (void)load
{
[self poseAsClass:[NSURLConnection class]];
NSLog(@"NSURLConnection is overridded.");
}
- (id)initWithRequest:(NSURLRequest *)request delegate:(id)delegate
{
NSMutableURLRequest* newRequest = [NSMutableURLRequest requestWithURL:[request URL]];
[newRequest setCachePolicy:[request cachePolicy]];
[newRequest setTimeoutInterval:[request timeoutInterval]];
[newRequest setAllHTTPHeaderFields:[request allHTTPHeaderFields]];
[newRequest setHTTPMethod:[request HTTPMethod]];
[newRequest setValue:@"http://www.bonnoh.org/" forHTTPHeaderField:@"Referer"];
self = [super initWithRequest:newRequest delegate:delegate];
return self;
}
- (id)initWithRequest:(NSURLRequest *)request delegate:(id)delegate startImmediately:(BOOL)startImmediately
{
NSMutableURLRequest* newRequest = [NSMutableURLRequest requestWithURL:[request URL]];
[newRequest setCachePolicy:[request cachePolicy]];
[newRequest setTimeoutInterval:[request timeoutInterval]];
[newRequest setAllHTTPHeaderFields:[request allHTTPHeaderFields]];
[newRequest setHTTPMethod:[request HTTPMethod]];
[newRequest setValue:@"http://www.bonnoh.org/" forHTTPHeaderField:@"Referer"];
self =[super initWithRequest:newRequest delegate:delegate startImmediately:startImmediately];
return self;
}
@end
うまくいきましたよ、奥さん！
Safari でリファラをいじるSIMBLプラグインをリリースしました。
]]>
long NSHostByteOrder (
void
);
実行時のバイトオーダーを返す。
返り値は以下の定数。
enum _NSByteOrder {
NS_UnknownByteOrder = CFByteOrderUnknown,
NS_LittleEndian = CFByteOrderLittleEndian,
NS_BigEndian = CFByteOrderBigEndian
};
Rosettaで動作していればBigEndianを返すのかな？
コンパイル時にバイトオーダーによって以下のどちらかの定数が定義される。
それぞれのバイトオーダー特有の処理を書きたい場合は、
#if __LITTLE_ENDIAN__
// リトルエンディアンの場合の処理
#else
// その他の場合の処理
#endif
こんな感じ。
NSSwap* という関数がshort, int, long, long long, float, double 型についてそれぞれ用意されている。
例えばint型については、
unsigned int NSSwapInt (
unsigned int inv
);
unsigned int NSSwapLittleIntToHost (
unsigned int x
);
unsigned int NSSwapHostIntToLittle (
unsigned int x
);
unsigned int NSSwapBigIntToHost (
unsigned int x
);
unsigned int NSSwapHostIntToBig (
unsigned int x
);
という感じで関数がそろっている。
]]>Cocoaアプリをローカライズする一番簡単な方法は、Xcode上からnibファイルのローカリゼーションを追加する方法だ。
まず、ローカライズしたいnibファイルを選択し、
「ローカリゼーションを追加」を選択する。
そして最後に、できあがったnibファイルを、その言語用に編集する。
ただ、この方法にはとても気持ち悪い問題がある。
例えば、元のnibファイルを編集してユーザインタフェースを変更した場合、同じ修正を別言語のnibファイルに行うか、一旦、別言語のnibファイルを削除して、もう一度ローカライズを行わなければならない。
これはひどい。
Subversionとの相性も最悪で、どうしようかと悩んでいるところにibtoolを知った。
ibtoolを使うと以下の流れでローカライズを行うことができる。
以下のコマンドをプロジェクトのルートディレクトリで行うことでnibファイルから文字列を取り出すことができる。
[yuanying@Magnus test]$ ibtool --generate-stringsfile English.lproj/MainMenu.nib.strings English.lproj/MainMenu.nib
出来上がったMainMenu.nib.stringsファイルはXcodeのResourceグループにドラッグアンドドロップして、プロジェクトに追加しておく。
生成されたMainMenu.nib.stringsのエンコードは Unicode (UTF-16LE) なので、Xcodeで開いて文字化けする場合は、文字コードを設定する。
生成されたMainMenu.nib.stringsを通常の方法と同様に、ローカリゼーションを追加する。
追加された言語環境(この場合は日本語)に翻訳する。
翻訳した文字列から、その言語用のnibファイルを生成する。
[yuanying@Magnus test]$ ibtool --write Japanese.lproj/MainMenu.nib -d Japanese.lproj/MainMenu.nib.strings English.lproj/MainMenu.nib
この例だと、English.lproj/MainMenu.nibを利用して、Japanese.lproj/MainMenu.nib.stringsからJapanese.lproj/MainMenu.nibを生成してる。
インタフェース(English.lproj/MainMenu.nib)を変更するたびにibtoolを使って日本語用のnibファイルを生成し直すのは面倒なので、最後のステップを自動化する。
まず、プロジェクトのターゲットを選択し、新規スクリプトを実行を追加する。
追加したビルドフェーズを、ビルドの一番最初に持ってくる。
スクリプトの編集を行い、以下のスクリプトを追加する。
ibtool --write Japanese.lproj/MainMenu.nib -d Japanese.lproj/MainMenu.nib.strings English.lproj/MainMenu.nib
以上でビルドを行うたびにEnglish.lproj/MainMenu.nibからJapanese.lproj/MainMenu.nibが生成されるようになった。
iLingualっていうソフトが使いやすそう。シェアウェアなのでまだ使ったこと無いけど。
よくある翻訳を、Appleの純正ソフトウェアから学習できるってのがいいかも。これがあるだけで一般的なメニューの翻訳はだいぶ楽になるなー。3000円か…。同じようなツールを自分で作る？
]]>ファイルの読み書きの話が書いてないのでもしやCのライブラリを使うのかなーと思いながら嫌々Cの入門本をめくってたのですが、全然関係ないところでCocoaの該当クラスを見つけました。
にも、// #1 パスをフルパスに
NSString* outputFilePath = [outputFilePath stringByExpandingTildeInPath];
// #2 出力するファイルを生成
[[NSFileManager defaultManager] createFileAtPath:outputFilePath contents:nil attributes:nil];
NSFileHandle* input = [NSFileHandle fileHandleForReadingAtPath:inputFilePath];
NSFileHandle* output = [NSFileHandle fileHandleForWritingAtPath:ouputFilePath];
// #3 ループ
@try {
NSData* data
while (data = [input readDataOfLength:1]) {
[output writeData:data];
}
} @finally {
[input closeFile];
[output closeFile];
}一応解説すると、
stringByExpandingTildeInPathを使ってチルダ付きのパスをフルパスにしてます。
NSFileHandleで書き込むファイルは存在してないと駄目っぽい。最初これではまった、fileHandleForWritingAtPathでnilしか返ってこないんだもんね…。ということで、createFileAtPathを使ってファイル生成。
実を言うとこのメソッドでついでに書き込むデータも一緒に指定できるんだけど、今日はまあ練習ということで…。
inputから1バイト読み込んでoutputに書き込んでます。なんて無駄な処理。今日はまあ練習ということで…。
ファイルIOの学習にこんな時間かかるなんて、なんて新鮮！
たまには違う言語もやってみるものですな。
]]>最新版のソースコードをsubversionからチェックアウト。これまたなんのひねりもなく、Getting the Codeに書いてあるそのまんま。
おもむろにCygwinのシェルを立ち上げ、ソースコードをチェックアウトしたいディレクトリに移動してチェックアウト。
私は特に何も考えずそのままホームにチェックアウトしてしまったけど結構な量なので気になる人は別にパーティションつくってそこにチェックアウトとかしてる模様。
$ svn checkout http://svn.webkit.org/repository/webkit/trunk WebKit
WebKit Support Librariesをダウンロードして「WebKitSupportLibrary.zip」という名前のまま解凍せずにソースコードをチェックアウトしてきたディレクトリのルートにコピーする。
$ /cygdrive/c/Documents\ and\ Settings/Administrator/My\ Documents/Downloads/WebKitSupportLibrary.zip ./WebKit/
さらに追加のライブラリをインストールするために以下のコマンドを実行する。
$ WebKit/WebKitTools/Scripts/update-webkit
本来はソースコードを最新にアップデートするコマンドらしいが、Windowsの場合は初回時に必ず実行しておかないと依存するライブラリが解決しないらしい。
これで準備は終わり。あとはビルドを実行するだけ！
$ WebKit/WebKitTools/Scripts/build-webkit
この手順でやれば特に何の問題もエラーもなくビルドが終了する。何も失敗がないとドキュメント通りになってまったく面白みがないですね！
WindowsにSafariがインストールされている場合は以下のコマンドで自分でビルドしたWebKitを使ってSafariが起動する。
$ WebKit/WebKitTools/Scripts/run-safari
さて、一通りビルドが終わって確認したのでソースコードを色々見てみますか…。
上記の環境を VMware Fusion 上に構築してビルド。えらい時間かかって死ぬかと思った。
最近はハマりポイントがつぶされているのかどうかわかりませんが一発でビルド成功、WebKit起動した。先人様々ですな。
特に変なことをせずInstalling the Developer Tools通りに。安上がりにやるためにVisual C++ 2005 Express Editionを使いますよ。
C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\Include\mfcを追加。最後のステップはVisual C++を起動した後にメニューのツール - オプション - プロジェクトおよびソリューション - VC++ ディレクトリから以下のように設定。
SubversionやPerlやらビルドに必要なツールをCygwinを利用してインストールする模様。WebKitのビルドに必要なパッケージを揃えた自動インストーラが webkit.org で配布されているのでそれを使ってインストールすると簡単。
すでにCygwinがインストールされている場合は、いくつかのパッケージをインストールしておく必要がある模様。
まず、最初からつまづく。なんといってもNew Projectに「Java Swing Application」が見当たらない。出来上がりのアプリケーションから察するにXcode 3.0では単純に「Java Application」と名前を変えているらしい。
そして一番の問題がプロジェクトがほとんどAnt-basedになっちゃってること。
そのせいで新規にビルドフェーズをXcode上から追加できない。全部自分でbuild.xmlをいじらなくちゃいけない模様。
まあJava開発者ならAntの方が使いやすいだろうという配慮なんだけど私には余計なお世話でした…。
まあとりあえずBuilding a JNI Universal Application with Xcode通りにnativeメソッドをJavaのソースコードに追加して、ライブラリをロードするところまで進める。
public native String getMyFullName();
static { System.loadLibrary( "MyFirstJNILib" ); }
さて、ここら辺からドキュメントが役立たずになってきますよ。
今回はヘッダファイルを作るのに(ドキュメントにあるJavaHeadersターゲットは作成せずに、)antタスクのjavahを使います。javahでヘッダファイルを作るためにいくつかの変数をbuild.xmlに追加します。
initターゲットとjarターゲットを修正。
<!-- Initialization target, for any prelimary setup needed to build -->
<target name="init" description="Preparation">
<!-- Get properties from environment -->
<property environment="env"/>
<property name="curr_build_dir" location="build/${env.CONFIGURATION}"/>
<property name="curr_header_dir" location="build/${env.CONFIGURATION}/Headers"/>
<mkdir dir="${curr_build_dir}"/>
<mkdir dir="${curr_header_dir}"/>
<mkdir dir="${src}"/>
<mkdir dir="${lib}"/>
</target>
<target name="jar" depends="compile" description="Build jar">
<mkdir dir="${jars}"/>
<jar jarfile="${jars}/${ant.project.name}.jar" basedir="${bin}" manifest="${resources}/Manifest">
<!-- Inject resources -->
<fileset dir="${resources}/"
excludes="${resources}/Manifest"
/>
<!-- Merge library jars into final jar file -->
<zipgroupfileset refid="lib.jars"/>
</jar>
<!-- generate the header files -->
<javah classpath=""${jars}/${ant.project.name}.jar" outputfile="${curr_header_dir}/MyFirstJNILib.h">
<class name="MyLeopardJNIProject"/>
</javah>
</target>propertyとjavacタスクを追加したよ。
とりあえずここまででビルドしてみると、うまくいってればbuild/${env.CONFIGURATION}/HeadersフォルダにMyFirstJNIProject.hができているはず。
ここのセクションはいくつかの相違点以外は基本的にそのまま。
ドキュメントではヘッダ検索パスとして$(SDKROOT)/System/Library/Frameworks/JavaVM.framework/Headersを追加していたが、さらに"${TARGET_BUILD_DIR}/Headers"も追加する。
MyFirstJNILib.cはMyFirstJNILib.hをincludeするが、MyFirstJNILib.hはヘッダ検索パスを前項で追加したため、#include "MyFirstJNILib.h"ではなく、以下のように指定する。
#include <MyFirstJNILib.h>
追加したMyFirstJNILibターゲットをAntからコンパイルするようにbuild.xmlを編集する。
まず、build.xmlの最初の方にネイティブコードをコンパイルするための変数を追加。
...
<property name="application.resources" location="${dist}/${ant.project.name}.app/Contents/Resources"/>
<property name="application.resources.java" location="${dist}/${ant.project.name}.app/Contents/Resources/Java"/>
<property name="native.target" value="MyFirstJNILib"/>
<property name="native.project" value="MyLeopardJNIProject.xcodeproj"/>
<property name="native.library" value="libMyFirstJNILib.jnilib"/>
<property name="env.CONFIGURATION" value="Release"/>
<!-- lib directory should contain any pre-built jar files needed to build the project
AppleJavaExtensions.jar is included to allow the built jars to run cross-platform if you depend on Apple eAWT or eIO classes.
See http://developer.apple.com/samplecode/AppleJavaExtensions/index.html for more information -->
...ネイティブコードをXcodeを利用してコンパイルするターゲットを追加。
<!-- Note: this target requires that Xcode Tools be installed -->
<target name="nativelib" depends="jar">
<exec executable="/usr/bin/xcodebuild">
<arg line="-project ${native.project}"/>
<arg line="-target ${native.target}"/>
<arg line="-configuration ${env.CONFIGURATION}"/>
</exec>
<copy file="${curr_build_dir}/${native.library}" toDir="${jars}" failonerror="true" verbose="true"/>
</target> packageターゲットの依存関係にnativelibターゲットを追加し、*.jnilibをリソースとして追加するタスクを追加する。
<target name="package" depends="nativelib" description="Make a double-clickable Mac OS X application">
<mkdir dir="${dist}"/>
<mkdir dir="${application.resources.java}"/>
<mkdir dir="${application.macos}"/>
<!-- copy jars -->
<copy toDir="${application.resources.java}">
<fileset dir="${jars}">
<include name="*.jar"/>
<include name="*.jnilib" />
</fileset>
</copy>以上で設定終わり。「ビルドして進行」ボタンを押せばJNIを利用したSwingアプリケーションができあがってるはず。
LeopardになってからJavaが蔑ろにされてる気が…。
ところでJavaでJNI使ってる人ってまだいるのかしらん？
念のため今回作ってみたプロジェクト。
]]>