}}配列を渡すこともできるので一度に複数のアイテムを登録することもできる。一致するアイテムはすべて(複数)削除される。渡して結果を取得する。セットすると条件に合うすべてのアイテムを取得することができる。条件はクラスのみを指定している。iOS4.2.1/3GS)。dumpメソッドを用意しておくとデバッグの時に役立つ。})キーは4文字に短縮された文字列が使われている。シンボルとの対応は当投稿の付録を参照のこと。運用するにあたっては次の点に注意する必要がある。登録されたアイテムへはアクセスすることができない。変わると前のバージョンで登録したアイテムが新しいバージョンでは利用できない、といった問題が起こる。iOSデバイスのロックが外れた状態(つまりユーザが操作している時)でしかアイテムへアクセスできないようになっている。kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly)に設定しておく必要がある。概要、サンプルコードなど。ReferenceSecItem系関数リファレンス。Reference(SecItem系関数、SecKeychain系関数のリファレンス)。LoafSecItem系関数の使い方が解説されている。調査した時の記録など(二十数回続く連載)。Services内のデータが読み出すことができるらしい。自身が管理する為、例えばそれが格納された場所が特定できればパスワードを解析することは難しくないかもしれない(そんなすぐに見つかる/アクセスできるような配置はしていないとは思うが。rootが取られればどうだろう。属性キーのシンボルと実際の文字列との対応表。アプリ間の情報共有の用途に使えることに気がついた人がいるかもしれない。答えは半分イエスで半分ノー(制限がある)。次回その方法について解説する。アプリは起動に時間がかかりすぎるとクラッシュする。よって強制終了させられてしまう。events.とある。Watchdog(監視プロセス)がアプリの起動時間を監視していて一定時間を超過するとそのアプリを強制終了する。20秒程度だった(iOS4.2.1/3GS)。経由しての実機デバッグ実行時はこの制限が外れるとのこと。これはアプリ本体の実行時間とは別にデバッガの初期化処理などで時間がかかる為。この為開発中には問題が出なかったに、リリース後に問題が表面化するということもありうる。するコードを書いてみた。YES;}実機で実行させしばらくした後に意図通りアプリが落ちる。時間はほとんど使っていないが、起動時間が長いと強制終了させられる。対策アプリ起動時間を減らすしかない。時間がかかる処理があるとしたらどうするか。マイグレーションが行われる場合、処理件数が多いと数十秒かかるケースがある。使っている限りは避けられない。すると、処理時間がかかる処理の実行タイミングを遅らせるしかない。-applicationDidBecomeActive:に入れみたが駄目。最初に表示されるビューコントローラのメソッドへ移したらどうか。viewDidAppear:結果は×。最初のビューの初期化タイミングはアプリケーション起動時間に含まれてしまう。callStackSymbols]);)。処理内だからまだアプリケーション起動が完了していないということになる。sleep(25)すると問題なく処理できた。やり過ごし、次のイベントループに入ったところで時間のかかる処理を回すことができれば起動時間制限にかからず行けるかもしれない。タイマーをしかけたり遅延実行する方法も考えられるが、それとは別の方法としてメインのビューを表示した後に一旦別のビューを表示してそこで処理させたらどうだろうか。どの道時間がかかる処理なので処理中であることをユーザへ見せる必要もあるので不自然ではない。中からこのビューをモーダル表示させてみた。sleep(25)をかけてみる。@"finished");}さて実行する。起動後一瞬だけメインビューが表示された後、下からサブビューがせり上がってきてモーダル表示される。viewDidAppear:]|finished出た。おけるコールスタックは次の通り。無関係にランループのイベントから処理が始まっている。アプリ起動時間にはカウントされない。この方法を使う場合の流れのイメージは次のとおり。時間のかかる処理が必要か判断する。処理が必要な場合、サブビューを呼び出しそこで時間のかかる処理を行う。この時、ユーザに処理中であることを表示する(ウェイトカーソルなど。終了後は自動もしくはユーザの確認の上、メインビューへ戻る。処理が不要な場合はそのままメインビューで処理を続行する。マイグレーションでまさにこの問題に直面中。上記アプローチでまずは対応する予定だがうまく行ったらその顛末を後ほどブログで紹介する。コメントTweet私はローカル変数をそれを使うコードの直前で定義する派(?)なのだが、switch文のケース内で定義ができなくていつも残念に思っていた。するとコンパイルが通った。#この既述が気持ち悪い人もいるかもね。導入された仕組みで他のアプリのイベントをキャプチャできるらしい。2種類があり、前者はアプリ内のイベント、後者は他のアプリのイベントをキャプチャすることができる。処理を記述するようになっている。message.)使い方は簡単でアプリ起動時などに上記クラスメソッドを呼び出してイベントハンドラを登録するだけ。実は標準では使えない。使ってイベントを受け取るにはユニバーサルアクセスの「補助装置にアクセスできるようにする」にチェックを入れる必要がある。イベントは受け取れない。この設定の有無に関わらわず受け取ることができる。ユニバーサルアクセスの設定が必要なのと、何よりも悪用される可能性が高いことから使い道はかなり限られる。別の言い方をすると非常に簡単にキーロガーやイベントロガーの作成が可能なので、もし「補助装置にアクセスができるようにする」にチェックが入っていると簡単にそういったソフトの標的になりうる。使いこの設定を前提としたアプリケーションの配布は行うべきではないだろう(ユーザが一旦設定してしまうと悪意を持った他のアプリに容易にイベントを盗聴されてしまう可能性が高まる)。便利なんだが....残念。GitHub※「補助装置にアクセスできるようにする」を有効にする場合は考察で述べた危険性があることを十分に理解した上で行って下さい(自己責任です)。