Blocksを使ったHTTPリクエスト - mixi engineer blog
聖闘士星矢Ωが、思ったより面白くて小宇宙が軽く爆発しそうなk_kinukawaです。 今回は、iOSアプリでHTTP通信を行うときの話です。 2012年4月27日 「メインスレッド上で処理している」について一部修正 従来のNSURLConnectionは、レスポンスをdelegateでハンドリングしていました。 そのため、リクエストを投げる箇所とレスポンスを受ける箇所がコード上で離れてしまい、可読性がよくありませんでした。 また、レスポンスを受け取ったあとの処理についても、delegate内で条件分けをして処理をしているうちに分岐/ネスト地獄になりがちでした。 一方、iOS5からNSURLConnectionにsendAsynchronousRequest:queue:completionHandler:というメソッドが誕生しました。 引数を見る限り、GCDを使って非同期リクエストをする系
UIAlertView の delegate 束縛を解放しよう - mixi engineer blog
どうも、佐野です。今回は UIAlertView の拡張カテゴリを作って、delegate ではなく Block でコールバック処理を記述するための拡張カテゴリの作り方を紹介します。 iOS4 から Objective-C では Blocks という独自のクロージャ機能が搭載されました。これによってアニメーションの記述やコールバック処理などグッと直観的・効率的に記述できるようになったのですが、残念ながら UIKit によって提供されているクラスの多くはまだ Blocks に最適化された作りになっていません。UIAlertView もそのひとつです。 UIAlertView は、その delegate を実装することでユーザアクションに対する処理を記述する訳ですが、どうも使い勝手が悪い。例えば、同じで画面内で2通りの UIAlertView を表示するような UIViewController
background処理＆delegate通知でのEXE BAD ACCESS対処法 | エンジニア開発記
background処理＆delegate通知はサクサク動かすために結構よく使いますが、一歩間違えるとEXE BAD ACCESSだらけになってしまいます。(経験談) どうやったらEXE BAD ACCESSを防げるのか、なんとなくわかったのでメモってみます。 おおまかな問題点 基本的にはbackgroundの処理が終わる前にdelegate先のオブジェクトが解放されてしまうのが問題です。 しかし、これは単純にオブジェクトが解放されるときにdelegateをnilにするだけでは解決できません。 delegateで呼び出されたメソッドを実行中にオブジェクトが解放される可能性もあるのです。 この場合、delegate先のメソッドが呼ばれてるのでdelegateをnilにしても意味がなく、その後selfやメンバ変数を呼び出してしまうとエラーが出てくるわけです。 回避法 まず、よく使っていたbac
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
