Build better apps, faster.Realm is a fast, scalable alternative to SQLite with mobile to cloud data sync that makes building real-time, reactive mobile apps easy.
NSCacheというキャッシュモジュールについて第43回Cocoa関西で発表してきました。 NSCacheの特徴 スレッドセーフ NSDictionaryのように手動でロックする必要がない 格納オブジェクトの上限を決められる 溢れたら自動破棄 iOSのようなメモリ制約の厳しい環境に最適 NSDictionaryに似たインターフェイス Mac OS 10.6 / iOS 4.0以上で使える 具体例としては、ダウンロードした画像をオンメモリにキャッシュする際等にとても有用だと思います。同じような機能を提供してくれるOSSのモジュールは見たことがあるのですが(例えばnimbusに含まれているNIMemoryCache)こちらはOS組み込みなので手軽に使えます。 発表資料 サンプルコード Twitter及びInstagramの画像をロードしてデモするサンプルコードは以下です。それぞれの機能を動かす
こんにちは。開発担当の福井です。 突然ですが、みなさん NSProxy をご存じでしょうか? NSProxy は Foundation の中で唯一 NSObject を継承しないクラスです(NSProxy のサブクラスを除く)。 また、その実装はほとんどありません。 今回はその NSProxy を使って view に対するメソッド呼び出しをフックしてみようというお話です。 NSProxy の使い方 名前からも推測できるように、NSProxy は Proxy パターンを実現するためのクラスです。 メッセージの呼び出しが動的に解決される Objective-C において Proxy オブジェクトを実現するのは実に簡単です。 NSProxy は、ただ自身に送られたメッセージを、そのまま別のオブジェクトに受け流すことで Proxy としての機能を実現します。 Proxy オブジェクトを作ってみる
Objective-C唯一のiOSファイルパスライブラリ、YKFileとは まず唯一かどうかは定かではない。 もしかしたら嘘をついていたら本当にすまない。 しかし自分が探す限り、現在Cocoapods内では他に同等なライブラリは見つからなかった。 YKFileとはYKFileという名のクラスのインスタンス1つが、iOSアプリが生成するファイル(Documents以下など)の1つをピックアップするためのライブラリである。 https://github.com/GeneralD/YKFile 早速使い方を説明する。 インストール をPodfileに記述しインストールするのが最も手っ取り早い。 Cocoapodsの基本的な使い方については割愛したいのでQiita内の他の方の記事のリンクを貼っておく。 http://qiita.com/yaakaito@github/items/66457a0d5
NSArrayでfor(; ;)とかfor-inを使うのをやめて、enumerateObjectsUsingBlock:を使うObjective-CiOS
鸟归巢:夜趣福利导第一导航|性交描述小说|男人插曲女视频40分钟|影音先峰男人资源,一部不行就来两部,身体要紧且看且珍惜。
UIScrollViewDelegate has got two delegate methods scrollViewDidScroll: and scrollViewDidEndScrollingAnimation: but neither of these tell you when scrolling has completed. scrollViewDidScroll only notifies you that the scroll view did scroll not that it has finished scrolling. The other method scrollViewDidEndScrollingAnimation only seems to fire if you programmatically move the scroll view not if
//自前コンテナ(self)にchildViewControllerを追加 [self addChildViewController:childViewController]; //その後didMoveToParentViewControllerを実行しなければいけない [childViewController didMoveToParentViewController:self]; この追加(add)したあとになぜ完了(didMove)を明示的に知らせないといけないのか謎という感覚。また、これがなくてもこちらの想定通り動くのでずっと疑問だった。 結論としては 自前コンテナでaddChildViewController:を実行した後は、やはり必ずdidMoveToParentViewController:を呼ぶ。これはUIViewController自身が他のコンテナに追加(もしくは削除)
XAML と C# を使った Windows ストアアプリ(LOB)構築のためのtips Prism 4.5 & Kona project 等のご紹介Shotaro Suzuki
getter/setter, init, dealloc 以外でivarにアクセスしない¶ インスタンス変数にアクセスする時は、基本的にgetter/setter(アクセッサメソッド、プロパティ)を経由してアクセスすべきです。 インスタンス変数を直接使わない理由としては、 インスタンス変数を直接使う場合は不必要なretain等、参照カウントを操作するコードが必要になり見通しが悪くなる事や、 KVO(Key-Value Observing)が使えない事や、アクセッサメソッドを経由しないため変更に弱い部分があることなどがあげられます。 以下の条件を満たしているならインスタンス変数を直接使っても問題は無いですが、統一性という観点から インスタンス変数を直接参照するのは -init と -dealloc 以外では避けるべきです: 1.Is declared in a class using ARC
基本的に、 getter/setter/init/deallocメソッドの中でだけ_propertyを使い、 それ以外のときはすべて、self.propertyを使う のが良いでしょう。 (以下、uasiさんのアドバイスです) getter/setter の呼び出しコストは微々たるものですので、コストと副作用を考えて _property と self.property を使い分けるより、一律で self.property を使った方が楽です。 _propertyは、値を直接割り当てたり取得することしかできません。 これに対し、self.propertyは[self property]を呼ぶことと同じです。このやり方だと、独自のgetterやsetterをつくることができます。 (以下、uasiさんのアドバイスです) 独自の getter/setter を作ることで、あるプロパティを読み書き
Objective-C のプロパティの属性を指定するとき従うべきガイドラインをまとめた。 できる限り nonatomic を指定する atomic にしてもパフォーマンスが悪化するだけでほとんどメリットがない(参考:StackOverflow - Atomic vs nonatomic properties)。 nonatomic と atomic の使い分けの指針は次のとおり: 参照型: メモリアドレスのみの書き込みなので、常にnonatomicでよい プリミティブ型: int, BOOL等ワンステップでの書き込みが可能: 常にnonatomicでよい 単一のスレッドからしかアクセスされない: 設計に気をつけつつnonatomic推奨 複数のスレッドからのアクセスがあり、long,構造体などサイズの大きい値: atomic推奨 (thx to @takasek) 複数のスレッドから同時に
HOME » Natsu note » 古い投稿 » Core Data 勉強日記 (11):More iPhone 3 Development / chapter 7 (関連/Relationship) Core Data 勉強日記 (11):More iPhone 3 Development / chapter 7 (関連/Relationship) 2010/02/24/|古い投稿|Core Data More iPhone 3 Development: Tackling iPhone SDK 3 (Beginning) Chapter 7 のまとめ。 最終章は、関連(Relationship)、取得済みプロパティ(Fetched property)について。さらに、流用がしやすいように汎用的なViewControllerの設計について考える。内容が多いので、まずはRelations
Objective-Cの @dynamic はお好きですか? ぼくはけっこう好きです。 @synthesizeのほうは昔はほぼ必須で書かないといけなかったり Xcode4.4で省略できるようになった ことで有名ですが、いっぽうで@dynamicのほうはあまり日の目を浴びていない気がします。 そこで、今日は@dynamicについて再考してみることにしました。 以下、ぼくが思い返してみて@dynamicがこんなときに便利だったと感じたところを2点挙げさせていただきます。 みなさまのほうでも「こんなとき便利だよ」というのがありましたら是非ご教示ください。 クラスの内部実装が適当なのを隠すときに そもそもこの実装自体がどうかという話もあるのですが、リファクタリング前にひとまず雑な実装をしてしまうことはままあります。 例えば、ゲームスコアを管理するGameScoreクラスを作ったとして、その中で ハ
今更なんだよ?って気がしますが、うちのブログにAFNetworkingについての記事が無いので軽く書いてみます。 2.x系になって変わったこと まず、一番の変更点はAFHTTPClientがいなくなったことでしょうか。変わりにAFHTTPOperationManagerやAFHTTPSessionManagerなるものや、AFXxxRequestSerializer、AFXxxResponseSerializerなどが追加になりました。また、動作可能なiOSのバージョンは6.0以降になってました。 なんだこれ?ってわけで早速触ってみます。 AFXxxManager AFHTTPOperationManagerとAFHTTPSessionManagerがありますが、どうやらiOS 6.xに対応するのであればAFHTTPOperationManagerを、iOS 7.x以降であればAFHTTP
非同期処理のテストってどう書いてますか? 標準のXCTest自体がサポートしていれば良いのですがそうではないので、非同期処理のテストを書きたい場合には、その仕組みを自作するか出来合いのライブラリを利用する必要があります。現実的な選択肢としては、 GHUnitやKiwiなど非同期処理をサポートしたテストフレームワークを利用する GHunitの非同期処理のテストの仕組みを真似て抜粋したライブラリを利用する(意外とこれが多いかも?) expectaなどのマッチャーライブラリに付属の非同期処理の仕組みを使う となるかと思います。 ただ、私が調べた時点だとどれもしっくりきませんでした。 まず、GHUnitやKiwiなどを採択している場合には良いのですが、非同期処理のテストを書くという目的だけのためにそれらのフレームワークを使うというのは冗長すぎます。 また、GHUnitの非同期処理の仕組みだけを抜き
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く