2010年5月3日月曜日

Byline 3 の新機能まとめ



ちょっとした宣伝ポストになりますが、私が日本語翻訳を手がけてます iPhone の RSS リーダーアプリ Byline のバージョン3が近日リリースされます。すでにリリース候補ビルドが完成しており、特に何の問題もなければ来週月曜日 (5/10) にリリースされる予定です。既存の Byline 2 ユーザーの方はそのまま無料でアップデートすることが出来ます。

バージョン2にくらべて高速で動作し、文字エンコードの取り扱い方法を変更したため以前よりクラッシュしない・・・はずです。少なくとも最新バージョンになってからは私のクライアントでは一度もクラッシュしておらず、安定性は上がっていると思います。

Byline 2 からの変更点とか新機能とかを以下にまとめてみました。


■Google Reader との同期速度向上

Google Reader と同期する際のスピードがさらに高速化しました。特にすべてのフィードのインデックスを生成する速度が劇的に改善されています。具体的にどれぐらい早くなったのか、私の iPhone 3GS 上で実際に測定してみました。

Byline 3


Byline 2


使用したバージョンアイテム件数同期にかかった時間アイテム/秒
Byline 2.5.6511件340.43秒1.50
Byline 3.0f1275件135.99秒2.02

ごらんのように、およそ3割程度速度が向上していることがわかります。アイテム一件一件のキャッシュ速度はそれほど変わりませんが、最初のインデックス取得が劇的に高速化している分だけ全体にかかる時間が短縮されているようです。


■アイテムのキャッシュ機能強化

目玉であるWebページのキャッシュ機能も強化されています。今回のバージョンから、 途中で省略されているアイテムのみをキャッシュする ことが可能になりました。途中で省略されているアイテムというのは、たとえば このような ニュース本文全体を乗せない RSS フィードの記事のことです。 Byline はこのような省略されている記事のみを判定して自動的にキャッシュしてくれます。


■インターフェース変更

はい、 Byline のバージョンアップといえば毎度おなじみのUI変更とアイコンの変更です>< 2までの操作に慣れた方(自分含む)には申し訳ありませんが、また慣れてください・・・その代わり前のインターフェースより優れているところも結構あります。



メイン画面はこんな感じです。フォルダの中の個別のフィードごとに記事を読めるようになりました。



記事一覧。リストの一番下にあった「すべて既読にする」がなくなり、その代わり右上に「編集」ボタンがついてそちらから一度に既読に出来るようになっています。



記事詳細も変わっています。画面左下にあったキャッシュを見るボタンが右上に移動しました。



こんな具合に記事詳細を左右にスワイプすることでつぎつぎと記事をめくっていくことが出来ます。

■Twitter / Instapaper / Read it Later との連携



最近の RSS リーダーではおなじみの外部連携が強化されています。 Twitter / Instapaper / Read it Later と連携することが出来ます。写真は Twitter への投稿画面。結構良くできています。リンクが長すぎる場合には自動的に短くしてくれたりします。


■まとめ

最近は Byline よりも多機能でより多くの外部サービスと連携できる RSS リーダーが登場してきていますが、今回のアップデートで外部連携が強化されたり個別のフィードを読めるようになったりと、それらの最新アプリと対抗できるだけの機能がついてきたかなと思います。目玉の Web ページキャッシュ機能もさらに強化されています。あとは安定動作してくれればまず負けないと思うのですが・・・こればっかりはリリースして皆さんに使っていただかないとわかりません >< とはいえ私の環境では500件以上のフィードを一度に読み込んでも安定しており、前バージョンよりさらに高速化しています。ご期待ください!

UTF-8 の文字列の長さを正確に求めるためには Normalize しましょう

Twitterにメッセージを送信する際に、クライアント側でメッセージの長さを判定して画面に表示したいというような要件があると思います。当然、このような場合には入力されたメッセージを取ってきてその長さを求めてやれば良いのですが、どうやら UTF-8 などのマルチバイトな文字コードを使っていると文字列の長さを正確に求めるのが大変なようです。


■何がどう大変なのか

図を書いてみました。「文」が文字数、「b」がバイト数を表しています。 Objective-C の場合は、「文」が ``[NSString length]`` を、「b」が [NSString lengthOfBytesUsingEncoding:NSUTF8StringEncoding] を表します。ほかの言語の場合もそれぞれ相当するメソッドまたは関数が用意されていると思います。



上のケースが一般的な UTF-8 文字列です。この場合、バイト数はマルチバイトになってしまうため実際の文字数(我々人間が見て自然な文字数)とは一致しませんが、その代わり UTF-8 文字数が実際の文字数と一致するため問題なく長さを求めることができます。

面倒なのが下のケース。ウムラウト記号や濁点・半濁点が一文字として入力されてしまっている場合です。通常滅多にこのような文字列に遭遇することはないのですが、まれにこのような文字列を入力させる処理系があるようです。で、この場合はウムラウト記号や濁点・半濁点も一文字として認識されてしまうため、実際の文字数と文字列長判定メソッドが返す文字数が異なってきます。そこまで厳密にしなくてもよいのでは・・・と思ったのですが、なんと Twitter はきちんとこのような場合も自然な文字列の長さを測定して140文字かどうかを判断しているらしいです。


■対策:Normalizeする

このように実際の文字数と UTF-8 上の文字数が異なっている場合には、 Normalize と呼ばれる処理を行って文字を圧縮する必要があります。 Objective-C の場合には以下のようなメソッドが標準で用意されています。
// NFD
– (NSString *)decomposedStringWithCanonicalMapping

// NFKD
– (NSString *)decomposedStringWithCompatibilityMapping

// NFC
– (NSString *)precomposedStringWithCanonicalMapping

// NFKC
– (NSString *)precomposedStringWithCompatibilityMapping
これらのメソッドは、 Unicode 文字列をそれぞれ NFD, NFC, NFKD, NFKC と呼ばれるフォーマットの文字列に変換してくれます。それぞれの文字列がどのような表現を表しているかは、以下のページを参考にしてみてください。英語ですが図説がついてるので非常にわかりやすいです。
http://unicode.org/reports/tr15/
http://homepage1.nifty.com/nomenclator/unicode/normalization.htm

ほかの言語、たとえばPythonやRubyなどでこの機能が提供されているかどうかはわかりません。あしからず・・・><

2010年4月29日木曜日

Three20 の TTPhotoViewController でローカルファイルを扱う際の注意点

Three20 フレームワークを使ってアプリを作成しているときに、ローカルファイルを TTPhotoViewController に読み込ませようとして一部はまってしまったので共有します。


■結論から
  • TTPhotoViewController の中に一部 NSHTTPURLResponse でないと動かないところがあるため、ファイル読み込みでは動作しない
  • @"bundle://filename.jpg"@"documents://filename.jpg" といった記法を用いることで回避可能
  • またはフレームワーク自体を書き換えてしまう

■問題
以下のコードの様に、ファイルスキームのURLを用いて画像を読み込もうとするとエラーになります。
photos = [[NSMutableArray alloc] init];
PhotoBookPhoto *photo;
NSString *imagesDirectoryPath = [[[NSBundle mainBundle] bundlePath] stringByAppendingPathComponent:@"Images"];
NSArray *imagePathes = [[NSFileManager defaultManager] directoryContentsAtPath:imagesDirectoryPath];

for (int i=0; i<imagePathes.count; i++) {
NSString *imagePath = (NSString *)[imagePathes objectAtIndex:i];
imagePath = [imagesDirectoryPath stringByAppendingPathComponent:imagePath];
LOG(@"%d - %@ %@", i, imagePath, [[NSURL fileURLWithPath:imagePath] absoluteString]);
photo = [[[PhotoBookPhoto alloc] initWithURL:[[NSURL fileURLWithPath:imagePath] absoluteString]
smallURL:[[NSURL fileURLWithPath:imagePath] absoluteString]
size:CGSizeMake(960, 640)] autorelease];
photo.photoSource = self;
photo.index = i;
[photos addObject:photo];
}

■原因
TTRequestLoader 中の以下のコードが直接的な原因です。
///////////////////////////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////////////////////////////
#pragma mark -
#pragma mark NSURLConnectionDelegate


///////////////////////////////////////////////////////////////////////////////////////////////////
- (void)connection:(NSHTTPURLConnection*)connection didReceiveResponse:(NSHTTPURLResponce*)response {
_response = [response retain];
NSDictionary* headers = [_response allHeaderFields];
本来 NSURLConnectionDelegate のデリゲートメソッドである、 connection:didReceiveResponse:NSURLResponce を引数にとるのですが、何故か NSHTTPURLResponce が直接指定されています。通常はこれでも問題ありませんが、fileスキームのURLは当然HTTPではありませんから、 NSHTTPURLResponse を返しません。従って allHeaderFields の呼び出しでエラーになってしまいます。


■対処法
ということで、この部分のコードを一部書き換えてしまい、 NSURLResponce がきても動作する様にしてしまいました。
///////////////////////////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////////////////////////////
#pragma mark -
#pragma mark NSURLConnectionDelegate


///////////////////////////////////////////////////////////////////////////////////////////////////
- (void)connection:(NSURLConnection*)connection didReceiveResponse:(NSURLResponse*)response {
_response = [response retain];
if ([_response isMemberOfClass:NSHTTPURLResponse.class]) {
NSHTTPURLResponse *httpResponse = (NSHTTPURLResponse *)_response;
NSDictionary* headers = [httpResponse allHeaderFields];
int contentLength = [[headers objectForKey:@"Content-Length"] intValue];

// If you hit this assertion it's because a massive file is about to be downloaded.
// If you're sure you want to do this, add the following line to your app delegate startup
// method. Setting the max content length to zero allows anything to go through. If you just
// want to raise the limit, set it to any positive byte size.
// [[TTURLRequestQueue mainQueue] setMaxContentLength:0]
TTDASSERT(0 == _queue.maxContentLength || contentLength <=_queue.maxContentLength);

if (contentLength > _queue.maxContentLength && _queue.maxContentLength) {
TTDCONDITIONLOG(TTDFLAG_URLREQUEST, @"MAX CONTENT LENGTH EXCEEDED (%d) %@",
contentLength, _urlPath);
[self cancel];
}

_responseData = [[NSMutableData alloc] initWithCapacity:contentLength];
} else {
_responseData = [[NSMutableData alloc] initWithCapacity:response.expectedContentLength];
}
}
また、あとから知ったのですが、Three20においては以下のようなURLが使用できるみたいです。 Three20/TTGlobalCorePaths.h にて定義されています。
photo = [[[PhotoBookPhoto alloc] initWithURL:@"bundle://image.png"
smallURL:@"documents://thumbnails/smallImage.png"
size:CGSizeMake(960, 640)] autorelease];
たぶん Three20以外では使用できない記法 なので注意が必要ですが、この方法で読み込むと NSHTTPURLResponce が返却されるためコードを書き換えなくても正常に動作します。 こちらのほうが簡単でThree20の開発チームの人もそうしているのでお勧めです。


■んーでも
そもそもこのThree20、開発者の人(FaceBookアプリを作った人)がiPhoneでのプログラミングを既にやめちゃっていると聞いたのでメンテがどうなるのか不安です。