iOS のアプリケーションでハイライト状態などを示すため、生成した画像イメージに対して色付けしたいときがあります。

UIView には tintColor というプロパティがあって、色付けが簡単にできそうなのですが、イメージを表示する UIImageView に tintColor を設定しても何も変わりません。

そこで以下のようなヘルパークラスを用意して利用しています。

@interface SBLImageHelper
/**
 *  Generates an image which is tinted with a given color.
 *  @param image - an image to be tinted
 *  @param color - tint color
 *  @return an instance of UIImage
 */
+ (UIImage *)tintedImageFromImage:(UIImage *)image
                        withColor:(UIColor *)color;
@end


@implementation SBLImageHelper

+ (UIImage *)tintedImageFromImage:(UIImage *)image
                        withColor:(UIColor *)color
{
  UIImage *output = nil;
  CGRect rect = CGRectMake(0, 0, image.size.width, image.size.height);

  if (UIGraphicsBeginImageContextWithOptions != NULL)
  {
    UIGraphicsBeginImageContextWithOptions(image.size,
                                           NO,
                                           image.scale);
  }
  else
  {
    UIGraphicsBeginImageContext(image.size);
  }

  CGContextRef context = UIGraphicsGetCurrentContext();

  // -- flipping geometry
  CGContextTranslateCTM(context, 0, image.size.height);
  CGContextScaleCTM(context, 1.0, -1.0);

  // -- setting up blend mode
  CGContextSetBlendMode(context, kCGBlendModeNormal);

  // -- first drawing the image
  CGContextDrawImage(context, rect, image.CGImage);

  // -- then setting up mask and fill the color
  CGContextClipToMask(context, rect, image.CGImage);
  CGContextSetFillColorWithColor(context, color.CGColor);
  CGContextFillRect(context, rect);

  output = UIGraphicsGetImageFromCurrentImageContext();
  UIGraphicsEndImageContext();

  return output;
}

@end

次のように使います。

UIColor *tintColor = [[UIColor redColor] colorWithAlphaComponent:0.5];
UIImage *originalImage = [UIImage imageNamed:@"sample"];
UIImage *tintedImage = [SBLImageHelper tintedImageFromImage:originalImage
                                                  withColor:tintColor];

Objective-C にはカテゴリーという既存のクラスを拡張するための仕組みがありますが、すでにあるメソッドと同じ名前のメソッドを追加すると、どっちのメソッドが利用されるか分からなくなってしまうという強烈な副作用があります。

ですので、個人的にはあまりオススメしませんが、UIImage のカテゴリーとして拡張するバージョンだと以下のようになるでしょうか。

@interface UIImage (SBLImageHelper)
/**
 *  Generates an image which is tinted with a given color.
 *  @param color - tint color
 *  @return an instance of UIImage
 */
- (UIImage *)imageWithTintColor:(UIColor *)color;

@end


@implementation UIImage (SBLImageHelper)

- (UIImage *)imageWithTintColor:(UIColor *)color
{
  UIImage *output = nil;
  CGRect rect = CGRectMake(0, 0, self.size.width, self.size.height);

  if (UIGraphicsBeginImageContextWithOptions != NULL)
  {
    UIGraphicsBeginImageContextWithOptions(self.size,
                                           NO,
                                           self.scale);
  }
  else
  {
    UIGraphicsBeginImageContext(self.size);
  }

  CGContextRef context = UIGraphicsGetCurrentContext();

  // -- flipping geometry
  CGContextTranslateCTM(context, 0, self.size.height);
  CGContextScaleCTM(context, 1.0, -1.0);

  // -- setting up blend mode
  CGContextSetBlendMode(context, kCGBlendModeNormal);

  // -- first drawing the image
  CGContextDrawImage(context, rect, self.CGImage);

  // -- then setting up mask and fill the color
  CGContextClipToMask(context, rect, self.CGImage);
  CGContextSetFillColorWithColor(context, color.CGColor);
  CGContextFillRect(context, rect);

  output = UIGraphicsGetImageFromCurrentImageContext();
  UIGraphicsEndImageContext();

  return output;
}

@end

この記事は qiita.com の内容を再掲載したものです。

知っている人もいると思いますが、およそ十年間暮らしたニュージーランドを離れ、今年 7 月よりスイス・チューリッヒにて生活を始めました。

カリフォルニア、いわゆるシリコンバレー、を拠点とするクラウド系サービスを提供している IT 企業のチューリッヒオフィスで、ソフトウェアエンジニアとして働いています。

「ニュージーランドからスイスに引っ越します」と言うと驚く人が多いんですが、場所はどちらかと言うと付随的なもので、やってみたいお仕事を選んだら、働く場所がたまたまスイスだったという感覚が近い感じがします。

もちろん、そこで生活していく以上、もっとも影響のある要素のひとつなので、考えられる可能性などを家族と相談した上で決めました。

スイスで働くためには就労ビザが必要なります。今回、ビザの申請から最終的な承認が下りるまでにおよそ三ヶ月かかりました。

ビザ申請は採用決定後に行われます。採用の決定を受けたものの、スイス行きが確定しない (それもいつ確定するか分からない) という宙ぶらりんな状態が続きました。

いつ確定するか分からないので、準備や告知をどのタイミングで始めるか決めかね、正直辛かったです。

ビザが下りて、スイス行きが確定してからは、前職にて退職願提出から始まり、引っ越しの手配、各所へのお知らせ、日頃よりお世話になっている友人などにご挨拶、ニュージーランドの持ち家に関しての諸手続き、……などなど、とにかくやることが盛り沢山。

娘や嫁さんの頑張りのお陰でどうにかこうにかスイス入りにこぎつけたという感じです。

参考になるか分かりませんが、スイス行きが確定するまでの流れを軽くまとめると……

2012.09 上旬

申し込み。 CV (職務経歴書) の送付

2012.10 中旬

スイスでの就労ビザ取得困難との判断で一度断られる

2012.12 中旬

先方より再連絡

2013.01 上旬

Skype で技術面接 (一次)

2013.01 中旬

Skype で技術面接 (二次)

2013.01 下旬

Skype で技術面接 (三次)

2013.01 下旬

人事の方と電話面接

2013.02 中旬

Skype にて面接。正式にオファーを受ける

2013.02 下旬

オファーにサイン

2013.03 上旬

就労ビザ申請手続き開始

2013.03 下旬

ビザに必要な書類の送付

2013.04 上旬

スイス連邦当局よりビザ承認

2013.04 下旬

申請者の就労ビザの最終承認

2013.05 下旬

申請者の家族のビザ最終承認

2013.07 中旬

スイス入り

2013.08 上旬

ネコ・家族のスイス入り

就職応募先がスイス、本社はカルフォルニアで、私自身はニュージーランド。面接は基本的に Skype を通して行いました。

2 月頃、こちらのネットワークの調子が非常に悪い時期があって、その時だけ電話での面接でしたが。

これまでにも何度か Skype を通して面接を行ったことはありますが、これほど立て続けに面接をしたのは初めての経験でした。

技術面接では Google ドキュメントのような共同編集できるオンラインツールを使って、コーディングの問題に回答したりもしました。

ビザ最終承認の後、スイス入りまで飛ばしていますが、前述のとおり、怒涛の勢いで色んな行事やら手続きが詰まっています。

スイスにはこの先、どのぐらい滞在することになるかは分かりませんが、とりあえずしばらくはこの新しい場所で生活していくことになります。

十年間暮らしたニュージーランドは、素晴らしい友人にも恵まれ、とても快適に過ごすことができました。お世話になった方々、ありがとうございました。スイスに移ってもよろしくお願いします。

salchuさんの「今日のiPhoneホーム画面」に触発されて、私もホームスクリーン晒し。

この間、日本でお会いした時には iPhone 持っていなかったので、お見せできなかったですものね。多分、iOS6 でのホーム画面はこれが最終形になるかと。五つの画面をひとまとめにしてしまったので、見づらくてごめんなさい。

スクリーン 1

Apple 標準アプリのみ。"Podcast" は、半標準ということで。

スクリーン 2

ソーシャル系・日常で利用するアプリ。左に赤系・右に青系を置いてます。

スクリーン 3

Apple, Google, Evernote を順に並べて、自作アプリもここに。

スクリーン 4

辞書系・読書系のアプリ。

スクリーン 5

銀行関連・乗り換え案内関連。あといくつか普段あまり利用しないやつも。

傾向として……

• フォルダはあまり使わない。
• 同系色はまとめたい。
• よく利用するアプリほど下に配置したい。

といった感じでしょうか。

地図は標準 Map と Google Map を半々で利用する感じ。これまでのところ、標準の Map で使いづらいとか困ったとかあまり感じたことがないので、特に Google Map じゃないとダメという感じではないです。

二ページ目は左側の赤系・右側に青系と決めているんですけど、そのせいであまり使わない mixi とか Foursquare が入ってしまっているのはご愛嬌。Gmail, ATOK Pad, Facebook, Dropbox は、ビューワとしてほぼ毎日使ってます。

iOS7 になると、おそらくまた構成が変わると思うので、この状態があと何日もつかは不明ですけれども。

あ、ちなみに iOS で最も頻繁に使っていると思われるアプリは Settings (設定) です。カメラはもっぱらロックスクリーンからアクセスするのでどこに置いても変わらないという。

多機能エディタ mi の新バージョン ver 3 の最初のベータ版が公開されました。

ver 3 になって Cocoa フレームワークを利用したアプリケーションとして作り直されています。

そのため Maximizer のような Cocoa アプリケーションにしか効かない SIMBL プラグインも利用できるようになっています。フルスクリーンで mi が利用できるように。

UI のアピアランスが大きく変更されました。Cocoa フレームワークを利用したこと影響も大きいのでしょう、全体的にモダンな UI に変わっています。

アウトラインは「見出しリスト」という形で従来からサポートされていましたが、それが強化されて、セクション毎に折畳みができるようになっています。

モダンなエディタらしく (?) 選択されたテキストなどに対して、同一ファイル内に存在する同じワードが全てハイライト表示されたりします。

モードや設定などは ver 2 から引き継がれますが、設定ファイルは別に保存されているので併用も可能です。

私の環境ではモード毎に設定されているツールに割り当てていたキーバインドの一部が引き継がれませんでしたが (一部、新規追加されたデフォルトのキーバインドと被っていたせいかもしれません)、概ね以前のままの状態でそのまま利用できる印象です。

英語リソースの対応はまだのようで、英語環境で立ち上げると英語と日本語が交じったインタフェースになってしまうのはご愛嬌。…… ver 2 から引き継がれたメニューやインタフェースは英語化されていて、新規に追加された分が英語化されていないという感じの状態になっています。

アプリケーション設定・モード設定が大幅に見直されてとても分かりやすくなっています。

特にカラー設定は「カラースキーム」という csv ファイルで定義されるようになり、インポート・エクスポートが簡単にできて管理しやすくなっています。インタフェースも分かりやすい。

ver 2 では subversion などバージョン管理システムで管理されたファイルに対して差分表示を行う機能がありましたが、ver 3 では、差分表示機能そのものが大幅に強化されて、自動保存による履歴差分や他のファイルの差分表示などもサポートするようになっています。

私の環境では Retina ディスプレイでの表示を確認することはできませんが、アプリケーション内のリソースを見ると一部アイコンなどはベクター画像が利用されたりしていて、Retina 表示にも対応しているようです。

アプリケーションアイコンも前掲の通り刷新されました。「ミミカキ」がなくなっていますが、最大サイズ (1024 x 1024) で見るとハイライトペンのところに、さりげなく「MI3」の文字が……。細かい。

アイコンでキャプチャされている書類は、なんらかのソースコードに見えます。なんだろう……。コードスタイルから見ると c++ っぽい感じのコード。

まだざっとしか利用していませんが、安定して動作しています。パフォーマンスに関しては今のところ従来と同等な印象ですが、大きなファイルを開いたり、マルチファイル検索などの比較的重めな処理は行っていないので、これから確認という感じです。

ver 3 ではフリー版・有料版・AppStore 版とリリースされる予定ですが、今回ざっと紹介した機能のどこまでフリー版のものか、有料版のものかなどの詳細はまだ分かりません。ともあれ今後の展開にとっても楽しみです。

いくつかの iOS アプリケーションを開発していると、自然と共有できるコードが増えてきます。

そうした共有可能な汎用コードを複数のアプリケーションのプロジェクトで利用する方法はいくつか考えられます。

アプリケーションのプロジェクトに組み込む

別リポジトリで管理している汎用コードを svn externals や git submodule などを使ってリンクして、それをそのままアプリケーションのプロジェクトに組み込みます。

svn や git などバージョン管理ソフトウェアの機能だけを利用しているので、仕組み自体はとてもシンプルになります。

構成はシンプルになりますが、その分運用でカバーしなくてはいけない点があります。

• 汎用コード部分のビルドがアプリケーションのプロジェクトに依存するので、汎用コード部分の独立性を保つのに注意が必要。

• 汎用コード部分でファイルの追加・削除があった場合、それを参照している全てのアプリケーションプロジェクトを逐次変更しなくてはならない。

• 汎用コードを利用する新規アプリケーションプロジェクトを作成して、リンクしたリポジトリを取り込む際、ターゲットに含めるファイルとそうでないファイルの切り分けが必要。

総じて独立性が乏しい分、手順が増える傾向があります。

静的ライブラリとして生成する

汎用コード部分を静的ライブラリとして作成して、アプリケーションのプロジェクトにライブラリとして登録します。

静的ライブラリを作成するプロジェクトファイルがアプリケーションのプロジェクトとは独立した形で作成されるので、アプリケーションのプロジェクトに依存することなく、ビルド・ユニットテストを行うことができます。

Xcode は外部プロジェクトもプロジェクトに組み込めるので、アプリケーションをビルドする際に都度静的ライブラリを生成するような形で運用することも可能です。

Xcode の基本機能だけで完結しますし、手順もそれほど難しくはないのですが、イメージや xib などのバイナリリソースが静的ライブラリには、そのまま組み込めないという制約があります。

イメージなどのバイナリリソースは静的ライブラリとは別にアプリケーションのプロジェクトに組み込む必要があります。

その場合、汎用コード部分で利用されるリソースファイルの追加・削除の手間は前述の組み込み型と同等になります。

フレームワークとして生成する

静的ライブラリではリソースは組み込めないのですが、フレームワークという仕組みを利用するとリソースも込みでライブラリを生成することができます。

UIKit などはフレームワークの形で配布されて、ほぼ全てのネイティブ iOS アプリケーションで利用されています。

汎用コード・リソースの共有化という点では最適な方法なのですが、Xcode の標準な方法ではサポートされないという欠点があります。

Mac OS X 向けアプリケーションに対してはフレームワーク生成がサポートされていますが、iOS プラットフォームではサポートされていません。

iOS ユニバーサルフレームワークなどを利用すると iOS プラットフォーム向けフレームワークを作成することができます。

github での説明を見ても分かる通り、現状ではややハック的な運用にならざる得ないようです。Fake Framework という仕組みではバンドルを利用していたりするみたい。

静的ライブラリをリソース込みで生成する

拙作 SBPullToRefreshHeaderView のようにリソース込みな汎用コードがある場合、リソースがあるのでやはりフレームワークを使う方法になると思います。

ハック的な運用を避けて、Xcode 標準な機能だけでなんとかならないか、と探していたところ、Compiling Image Resources into a Static Library という記事を見つけました。

静的ライブラリにはバイナリリソースは組み込ませんが、バイナリを C コードの形でダンプしてコンパイルしてしまえば、データとして組み込むことが可能になります。

1. イメージなどのバイナリを xxd -i コマンドを使って C コードに変換
2. コード化されたデータを UIImage など Objective-C クラスに変換するローダーを生成
3. リソースはローダーを介して読み込む

Compiling Image Resources into a Static Library では、イメージだけ処理していますが、同様に nib ファイルも処理できます。具体的な手順については後日改めて。

iOS 版 Facebook の実装が HTML5 アプリケーションからネイティブアプリケーション (CocoaTouch フレームワークを使ったアプリケーション) に変更されたのは記憶に新しいところ。

それに対して「Facebookのモバイルアプリが失敗した理由は HTML5 のせいじゃない。HTML5 でサクサク動く Facebook アプリを作って見せた Sencha Touch 開発チーム」という記事がありました。

元ネタは The Making of Fastbook: An HTML5 Love Story (以下、元記事) です。

簡単に言うと、「HTML5 だから遅いんじゃないよ、デモアプリケーション Fastbook のようにネイティブアプリケーション同等な (むしろそれを上回る) パフォーマンスでるよ」ということになるでしょうか。

動画も挙がっていて、自信の程が伺えます。

これに対して、いくつか指摘が挙がっています。

え？これSafariじゃね？WebViewとSafariじゃあスピード全然違うよ

[→はてなブックマーク - hazisarashi のブックマーク - 2012年12月20日]

Safariとかずるすぎワロタ。WebviewはSafariの約3.3倍遅いんですが、Webviewで動かすとどうなるんでしょうね（ゲス顔

[→はてなブックマーク - fikah のブックマーク]

同様に元記事のコメントでも……

The demo is really promising, but it is in MobileSafari. When you make an iOS app, you can only use WebView, which is a second-class and slower browser.

[意訳] デモはとても前途有望だけれど、MobileSafari で動いているね。iOS アプリを作る時には WebView しか使えなくて、それは遅いブラウザになってしまうよ。

[→元記事コメント @hlb]

A sticking point with iOS is that embedded WebKit (in Facebook’s old native app) performs horribly compared to Mobile Safari (what Sencha used here) due to Apple's selfish hoarding of the Nitro JavaScript engine.

[意訳] 問題は Facebook の前バージョンでも利用されてた組み込み WebKit で、このデモで使っている Mobile Safari よりもひどく遅いけど。Apple の勝手な囲い込みで Nitro JavaScript エンジンは使えないから。

[→元記事コメント @Ron Waldon]

Mobile Safari では Nitro と呼ばれる JavaScript エンジンでスクリプトが処理されるのですが、CocoaTouch フレームで利用できる UIWebView ではその高速な JavaScript エンジンが (セキュリティ上の理由から) 使われません。

私もこの点 (デモが Safari 上で動いている) は少し気になっていました。

それに対して、Sencha Team のメンバーの何人かが答えています。

@hlb the issue is NOT JavaScript. It's the DOM. The DOM engine is the *same* for both use cases.

[意訳] @hlb JavaScript が問題ではないんだ。DOM が問題で、DOM エンジンは (Safari も UIWebView も) 同じなんだよね。

[→元記事コメント @Jay Garcia]

@hlb Simply save the app to your homescreen to force it to use a WebView.

[意訳] @hlb ホームに置くと、WebView を使うようになると思う (iOS 5.1 以降では Mobile Safari を利用するようになったという指摘あり)。

[→元記事コメント @Jamie Avins]

@Ron Waldon It doesn't matter for such apps like this. Again as we mentioned the bottleneck is never JavaScript execution. We wrapped the app in native webviews for you to try it out yourself: github.com/extjs/fastbook

[意訳] @Ron Waldon このアプリではそこは問題にならないんだ。(これまで) 指摘している通り、ボトルネックは JavaScript の実行にあるわけではないから。ネイティブな webview で実装した例を github に挙げたので、試してみてね。

[→元記事コメント @Jacky Nguyen]

Jacky Nguyen さんと Jamie Avins さんは動画にも登場されています。

コメント受けて、WebView を使った利用例が github に公開されました。

コードは実にシンプルで、

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
    self.window = [[UIWindow alloc] initWithFrame:[[UIScreen mainScreen] bounds]];
    // Override point for customization after application launch.
    self.window.backgroundColor = [UIColor whiteColor];
    
    UIWebView* view = [[UIWebView alloc] initWithFrame:[UIScreen mainScreen].applicationFrame];
    [self.window addSubview:view];
    [view loadRequest:[NSURLRequest requestWithURL:[NSURL URLWithString:@"http://fb.html5isready.com/"]]];
    [self.window makeKeyAndVisible];
    return YES;
}

メインのコードはこれだけ。UIWebView を作って http://fb.html5isready.com/ を開いているだけです。

動作させてみると、私が思っていた以上に速い。iPhone 4S / iOS 6.x で確認。確か iOS6 から WebView に対して動作割当メモリが増えたので、それも影響している可能性あり。

UIWebView 上の WebKit でも、スクロールとかきびきびと軽快に動作します。

iOS のアプリケーションとしては、ステータスバーをタップしてもトップにスクロールバックしない、ローディングアニメーションが表示されるべきところで表示されない、未実装な機能 (例えば検索機能) がある、などブラッシュアップが必要な部分はありますが、デモアプリケーションとしてはなかなか興味深い。

もっともこれでもって「HTML5 使うべき」とも言えない部分もあって、

スクロール速度だけを取り上げても。Facebookのエンジニアが指摘した第一の問題はそこじゃないですよね。クラッシュの原因が解らない等 http://lists.w3.org/Archives/Public/public-coremob/2012Sep/0021.html

[→はてなブックマーク - Teshのブックマーク]

という Tesh さんのブックマークコメントや

The premise of this argument is wrong. It's not a simple question of "slow" versus "fast." Application performance is only one factor in building an HTML5 app. Device support, engineer productivity, testability, measurement, tooling/debugging, and native integration are all points that should be factored in. Anyone who has burnt the hours trying to debug a perf issue on a device that doesn't support Webinspector knows this pain. As does anyone who has gotten the bug report about the keyboard not popping up correctly on insert random Android 2.X no one has ever heard of here. As does anyone who has gotten the layout performance awesome in one test environment only to test another and find it terrible. The argument that HTML is ready while the device landscape is not is pretty fraught.

As far as fast goes, even as well done as this demo is, the scrolling framerate is noticeably slower on the Nexus 4 compared against the native application. I feel like all the demo is proving is what we already knew - somethings can be done reasonably well in HTML while many other can't. I'm a person who would rather have the web win. I'm pretty sure it will win in time. It's a pretty clear fact that until the browsers/webviews get faster and/or the device's have faster hardware, HTML is the second best option for smartphones.

[意訳] 議論の前提が違っているよね。単に「遅い」か「速い」という問題じゃない。アプリケーション性能は HTML5 アプリを構築するひとつファクタに過ぎないよ。どのデバイスをサポートするか、エンジニアの生産性、テストのしやすさや計測しやすさ、ツールの使い勝手、デバッグのしやすさ、ネイティブなサポート、など全てのファクタを考える必要がある。ウェブインスペクタをサポートしないデバイスでパフォーマンスをデバッグするのがどんなに大変か知っている人はいる？Android 2.X でキーボードが正しく表示されずにランダムな文字が入力されてしまうというバグレポートを見たことがある人は？あるテスト環境では素晴らしく性能がいいのに、別の環境ではめちゃくちゃだというのを経験したことがある人は？この議論を実際デバイスを横向きにして見ると見づらいという事実についてはどう？

[意訳] 速さという点に関しては、このデモはとても良くできている。スクロールのフレームレートは Nexus 4 で見るとネイティブアプリに比べて遅いけど。このデモは Sencha Team が HTML に関して深く理解している (そしてそれは他の多くの人はできない) こと証明しているに過ぎないと思うんだ。私個人的にはむしろ web が勝って欲しいし、いつかその日がくると信じているけれども、それはブラウザとデバイスが十分に速いというの明快になった時で、HTML はスマートフォンに対して二番目にベストなオプションだと思う。

[→元記事コメント @Jackson Gabbard]

元記事に寄せられた Jackson Gabbard さんのコメントのご指摘の通り、単純に速い・遅いという問題ではなくて、もちろんそれはとても重要な部分ではあるけれども、あくまでも全体の一部の問題でしかありません。

ツールの使いやすさ、デバッグのしやすさ、習得に対する敷居の低さ、などはソフトウェアを恒常的にメンテナンスする上で、重要なポイントになってきます。

Objective-C が習得に対して敷居が低いかどうかはまた別の議論になってしまいそうですが、ネイティブサポートのため、ハック的な知識がなくてもある程度の性能はいけるという印象はあります。もちろん実装次第ですけれども。

これは Sencha や Titanium だけでなく、他のクロスプラットフォームなフレームワークでも大きな課題になっているポイントのような気がします。

Visual Studio 2010 Express for Windows Phone を Windows 8 にインストールする手順について、備忘録

元記事 に全ての手順ならびに要因が詳しく説明してあります。

1. Windows Phone SDK 7.1 をダウンロード・インストール
2. Games for Windows Marketplace Client をダウンロードして・インストール
3. 1. でダウンロードしたインストーラを再度起動して、修復 (repair) を選択
4. Windows Phone SDK 7.1.1 Update をダウンロードして、SDK 7.1.1 にアップグレード

3. のステップが終了した段階で、Visual Studio 2010 Express は起動できるようになりますが、エミュレータが正しく起動しません。SDK 7.1.1 にアップグレードすることでエミュレータも動作するようになります。

iOS デバイスの一覧表を自分用に作成 (2014/11 現在)。

デバイス	発売年	CPU	解像度	iOS
				バージョン	2	3	4	5	6	7	8
iPhone	2007	armv6	320 x 480	1.0 - 3.1.3	◎	◎	×	×	×	×	×
iPhone 3G	2008	armv6	320 x 480	2.0 - 4.2.1	◎	◎	◎	×	×	×	×
iPhone 3GS	2009	armv7	320 x 480	3.0 - 6.1.4	×	◎	◎	◎	◎	×	×
iPhone 4 (GSM)	2010	armv7	640 x 960 *	4.0 - 7.1.2	×	×	◎	◎	◎	◎	×
iPhone 4 (CDMA)	2011	armv7	640 x 960 *	4.2.5 - 7.1.2	×	×	◎	◎	◎	◎	×
iPhone 4S	2011	armv7	640 x 960 *	5.0 -	×	×	×	◎	◎	◎	◎
iPhone 5	2012	armv7s	640 x 1136 *	6.0 -	×	×	×	×	◎	◎	◎
iPhone 5c	2013	armv7s	640 x 1136 *	7.0 -	×	×	×	×	×	◎	◎
iPhone 5s	2013	arm64	640 x 1136 *	7.0 -	×	×	×	×	×	◎	◎
iPhone 6	2014	arm64	750 x 1334 *	8.0 -	×	×	×	×	×	×	◎
iPhone 6 plus	2014	arm64	1242 x 2208 **	8.0 -	×	×	×	×	×	×	◎
iPod touch	2007	armv6	320 x 480	1.1 - 3.1.3	◎	◎	×	×	×	×	×
iPod touch (2nd)	2008	armv6	320 x 480	2.1.1 - 4.2.1	×	◎	◎	×	×	×	×
iPod touch (3rd)	2009	armv7	320 x 480	3.1 - 5.1.1	×	◎	◎	◎	×	×	×
iPod touch (4th)	2010	armv7	640 x 960 *	4.1 - 6.1.4	×	×	◎	◎	◎	×	×
iPod touch (5th)	2012	armv7	640 x 1136 *	6.0 -	×	×	×	×	◎	◎	◎
iPad	2010	armv7	768 x 1024	3.2 - 5.1.1	×	◎	◎	◎	×	×	×
iPad 2	2011	armv7	768 x 1024	4.3 -	×	×	◎	◎	◎	◎	◎
iPad (3rd)	2012	armv7	1536 x 2048 *	5.1 -	×	×	×	◎	◎	◎	◎
iPad (4th)	2012	armv7s	1536 x 2048 *	6.0 -	×	×	×	×	◎	◎	◎
iPad Air	2013	arm64	1536 x 2048 *	7.0 -	×	×	×	×	×	◎	◎
iPad Air 2	2014	arm64	1536 x 2048 *	8.1 -	×	×	×	×	×	×	◎
iPad mini	2012	armv7	768 x 1024	6.0 -	×	×	×	×	◎	◎	◎
iPad mini Retina	2013	arm64	1536 x 2048 *	7.0 -	×	×	×	×	×	◎	◎
iPad mini 3	2014	arm64	1536 x 2048 *	8.1 -	×	×	×	×	×	×	◎

"CPU" とあるのは対応する CPU アーキテクチャを示しています。解像度で強調表記されているのは Retina ディスプレイを示しています。** は 3x 解像度です。

以下の iOS は特定のデバイスにのみ対応したバージョンになります。

3.2.*	iPad (初代) 専用バージョン。
4.0 - 4.1	iPad 未対応バージョン。
4.2.5 - 4.2.10	iPhone 4 (CDMA) 専用バージョン。

参考

• iOS - Wikipedia
• Tech Specs - Apple support

reeder は Google Reader を快適に利用できるアプリケーションです。

その reeder からインスパイアされて、似たルック & フィールを Chrome 上で実現する機能拡張が Reeder for Chrome (Unofficial) (以下、RFC) です。

残念ながら RFC の開発は継続されないことになりましたが、ソースは公開されています。

RFC の最も肝となるルック & フィールは基本 css のみで実現されていて、Stylish を使えば、他のブラウザでも利用できそうです。

他に fork している人がいたので、その内容を確認しようと思っただけだったんですが、間違えて自ら fork してしまい、それをきっかけに中身を確認することに……。

1. Stylish for Safari より Stylish の機能拡張をダウンロード・インストールします。
2. ツールバー上にある「Stylish」ボタンから管理画面 (Manage) を開きます。
3. 「Edit」を選ぶと新規スタイル編集画面が開きます。

   Title

   RFC

   CSS

   GitHub から CSS の内容をコピー

   Applies to

   "Regexp" を選択して、https?://www.google.*/reader/.*

   

その後、Google Reader を見ると Reeder のようなインタフェースに変わっていると思います。オススメは 3 カラム表示。

(Webkit に特化したスタイルを利用しているため) CSS の一部変更が必要になりますが、Firefox でもほぼ同様に Stylish から利用できます。

先日、娘が誕生日を迎えました。

一応毎年カードみたいなものを用意していて、去年はカードの代わりに iPad で動く「誕生日アプリ」……マイクを使って息を吹きかけるとロウソクが消えるエフェクト付き……を作りました。

今年はどーしよーかなぁと思っていたんですが、なにやら最近少しだけ「ペーパークラフト」に興味を持っているようなので、ちょっとした工作をしてみることに……。

ざっと調べると、ペーパークラフトで文字が浮き出るような効果を出すために使える POPUP フォントなるものがいくつか見つかりました (Balloon Tales | Articles | Tutorial: Pop-Up Letters、Pop-Up Font | dafont.com)。

フォントを見てみると、専用フォントを使わなくても、ある程度線が太ければ利用できそうな感じだったので、自作してみることに。

ポイントは文字が浮き出たときに補助となる出っ張り部分。切り抜きのひな形を作るのはそれほど難しくありません。

まず、紙の半分、(印刷したときに) 折り目にあたる部分に直線を引きます。

折り目をまたがるように文字を置きます。今回使ったのは Optima の Extra Bold 。個人的に気に入っているフォントで FloatyMemo のロゴにも使っています。

折り目から文字の底にあたる部分の長さが、文字が浮き出てくる長さに相当します。

先に測った「折り目から文字底までの長さ」の分だけ文字の上に補助部をつけます。

他の文字にも同じようにして補助線を付けていきます。今回は文字を反転させています。これはカードの裏面に作ったひな形を印刷するためで、そうすることによって印刷した線が見えなくなります。

印刷した線は折り目以外は切り取ります。

• 一番最初に引いた直線 (紙半分、カード自身の折り目にあたる)
• 文字の底 (文字下部の折り目)
• 文字の天で補助部と接する線 (文字上部の折り目)
• 補助部の天 (出っ張りの折り目)

がそれぞれ折り目になります。このうち、「文字の天で補助部と接する線」以外は同じ方向に折ります。裏面に印刷するので、印刷面から見て「山折り」になって、「文字の天で補助部と接する線」だけは「谷折り」になります。

少し厚手の紙に印刷します。印刷面がカードの裏面になります。

定規とカッターで丁寧に切っていきます。曲線部分はやや慎重に。折り目にあたる部分は山側になる方に軽く切れ込みを入れます。「文字の天で補助部と接する線」は表面が山側なので、そこだけは印刷面とは反対側から切り込みを入れます。

実のところ、折る作業が一番気を使うところかもしれません。写真だと分かりづらいですが、今回「T」の文字がやや失敗してしまって、横棒と縦棒のつなぎの部分が少し折れてしまいました。