I have an Objective-C framework (framework A) that exposes some public and some private headers. The public headers are also declared in the framework's umbrella header. I have a second Swift framework (framework B) that links with the Objective-C framework. Now, if I want to import the public headers of A in B I simply need to do an import A. But how do I go about importing the private headers? I
I have just started a new Swift project and I would like to use different libraries. In particular, I would like to use Realm.io, an Obj-C library. But, I would also like to use pure Swift libraries such as Alamofire or Dollar. I use Cocoapods for managing my dependencies. I use the latest version (0.37.0) and the new use_frameworks! flag. pod install is successful anytime. Unfortunately, when I t
はじめに こんにちは、GREE Platform部の柳村(@yana_3)です。 iOSエンジニアのみなさまにおかれましてはXcode6以降の使用と64bit対応が必須になりますが、対応すすんでいますか? 64-bit and iOS 8 Requirements for New Apps 64-bit and iOS 8 Requirements for App Updates GREE Platformでは、64bit対応の検証をする中でポインタ周りでJSONKit1がクラッシュするという事態が発生し、そこから64bit時のポインタについて調べたのですが、 あまりこの内容に関して詳しく記載されているところがなかったようなので共有したいと思います。 ただ普通にiOSで開発するぶんには全く役に立たない内容になっておりますのであらかじめご了承くださいmm 調べるきっかけ 64bit環境でのみ
ReactiveCocoa勉強会関西にてObserverパターンについてお話ししましたので、以下にその内容をまとめます。 Observerパターンは、GoFの23のデザインパターンのうちの一つで、モデルが状態の変化をしビューに通知するパターンです。GUIアプリケーションの開発で多用されます。もちろんスマートフォンアプリの開発においても大変役に立つので、いくつかの例を挙げて見ていきます。 Objective-CのKey-Value Observing static void * Context = &Context; - (void)anything { [object addObserver:self forKeyPath:NSStringFromSelector(@selector(property)) options:NSKeyValueObservingOptionNew conte
「そんなん簡単やろ」と思いますよね。 たとえば、「UITextField 文字数制限」でググれば山のようにブログ記事やらコードが出てくるし、Stack Overflow に載ってるコードのコピペ一発で解決しそうに思えませんか? 実は文字数制限をつけたテキストフィールドはそんなに簡単な話ではないのです。 shouldChangeCharactersInRange:replacementString: は使えない子 今回はこれに尽きます。 UITextField や UITextView のデリゲートで呼ばれる textField:shouldChangeCharactersInRange:replacementString: やtextView:shouldChangeCharactersInRange:replacementString: は使ってはいけません。 より正確に言うと、使うとき
Core Audio においてもっとも低レベルに位置する Audio Unit。リアルタイムで高度なオーディオ波形処理を行いたい場合や複雑なルーティングによるオーディオ処理を実現したい場合、これを使用する必要が出てきます。 が、このフレームワーク、個人的には使用頻度があまり高くない *1 ので、ひさびさに触ってみた際にとっつきにくさを感じました。 慣れてしまえば 全体的なコンセプトはシンプル なのですが、関数の引数がやたら多かったり、構造体の要素がやたら多かったり、慣れてないC言語APIだったりするので、久しぶりに触るとそのあたりが複雑に感じてしまうのかなと。 そんなわけで、次に久しぶりに Audio Unit をいじるときに、 そのあたりの「シンプルな全体感」と、「複雑に感じてしまう部分」を切り分けて見ることができるよう、メモっておきます。 基本的な考え方 Audio Unit の基本コ
import JavaScriptCore let ctx = JSContext() let ary = [0, 1, 2, 3] var jsv = ctx.evaluateScript( "\(ary).map(function(n){return n*n})" ) println(jsv) var a = jsv.toArray() println(a) はい。見てのとおり、import JavaScriptCoreして、JSContext()でJSの実行環境をこしらえて、それに.evaluateScript()でString食わせれば、おしまい。 実行結果はJSValueという型で、見ての通りObjective-Cに対応する型へ変更するメソッドもついてます。 JSにSwiftの値を渡すには? しかしこれだけではつまらない。Swiftの値をいちいち文字列化して.evaluateSc
2. Foreword • Don’t make any assumption about imaging on iOS. Why? • Because even if you’re right today, you’ll be wrong next year. • iOS is a moving platform, constantly being optimized versions after versions. • Experiment, and find out the best approach for your app. 3. Understanding • Things to have in mind at all times: execution speed & memory consumption. • How to assess those: Instruments.
Development Apple’s new Objective-C to Javascript Bridge Nigel Brooke • May 13th, 2013 A few month back, Apple quietly slipped a very nice Objective-C to Javascript bridge into WebKit. Since the first commit while we were busy celebrating New Year’s Eve, it has been fairly actively developed and improved. This new API supports straightforward embedding of the JavaScriptCore interpreter into native
Auto Layout Guide.md Auto Layout Guide Auto Layout Concepts Constraintの基本 例えば、buttonの左辺をcontainer viewから20ポイント離す場合 button.left = container.left + 20 と表すことができる。 一般的には、y = m*x + b で表すことができる。ここで y と x はviewの属性 m と b は浮動小数点数 ここで属性は、left、right、top、bottom、leading、trailing、width、height、centerX、centerY、baselineのいずれか。 leadingとtrailingは、英語のように左から右へ書く言語の場合はそれぞれleftとrightと同じだが、ヘブライ語やアラビア語のように右から左へ書く言語の場合は、lea
(Andy Myers and the CocoaPods Dev team. Creative Commons - Attribution-NonCommercial 4.0 International) iOSアプリを作るとき、今日ではCocoaPodsを用いて簡単に便利なライブラリの力を借りることができる。 ライブラリを利用するメリットは多い。自分でメンテナンスする必要がないので、放っておいても勝手に改善されていく。潜在的な問題があったとしても、多くの人が利用しているものなら誰かが気付いて直してくれる可能性も高い。また自分より優れたエンジニアの手によって、優れたインターフェースや実装になっているということも多い。何より、自分で実装する手間が省けるのがよい。 反面、デメリットについても考えなければならない。ライブラリがメンテナンスされなくなったとき、なにか問題が起こったり、あるいはAp
I don’t remember where I first saw this mentioned so I cannot give proper credit but this is an interesting tip to try if you have five minutes. Open Source Builds of the Clang Analyzer The Clang Static Analyzer has long been integrated with Xcode and provides powerful source code analysis to detect bugs in C, C++ and Objective-C code. The analyzer is fully open source and part of the larger Clang
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く