SwiftUIでSFSafariViewControllerを使う手法の探求 - cockscomblog?
SwiftUIからSFSafariViewControllerを使いたい場面は多い。 SafariView SFSafariViewControllerはビューコントローラーだから、UIViewControllerRepresentableを使ってSwiftUIのビューにしてしまうのが簡単か。 import SwiftUI import SafariServices struct SafariView: UIViewControllerRepresentable { typealias UIViewControllerType = SFSafariViewController typealias Configuration = SFSafariViewController.Configuration private let url: URL private let configuratio
SwiftUIではSingletonの代わりにEnvironmentを使うことができる - cockscomblog?
ここで言うSingletonというのは、ある種のグローバル変数を指している。そもそもクライアントアプリケーションの開発においては、実質的なグローバル変数が出現しやすい。環境にたった一つしか存在しない、存在すべきでない、というものが見出せる。例えばタイムゾーンがそれである。アプリケーション内のタイムゾーンはシステムに合わせるのが自然であり、アプリケーション中で複数存在することはほとんど起こり得ない。 iOSやmacOSでは、タイムゾーンを表すのはFoundation frameworkのTimeZoneである。システムのタイムゾーンはTimeZone.currentで取得できる。これはSingletonパターンのインターフェースに近い（本当にインスタンスが一つであるかどうかをここでは問題にしない）。 このように環境中で存在する個数が限定されるような値を表すのに、Singletonパターンが用
Swift の Nil Coalescing Operator でコンパイルは遅くなるか - cockscomblog?
趣味のウェブブラウジングをしていると、Swift の ?? (nil coalescing operator) がコンパイルを遅くするのではないか、といった話題*1を見かけました。この演算子は、左辺の Optional<Wrapped> 型の値が Optional.none である場合に右辺の値を返すというもので、直感的にはこれがコンパイル時間を悪化させるとは思えません。経験から言えば、このようなケースでは大抵やや複雑な型推論が発生しており、それがコンパイル時間に支配的な影響を与えています。そうであるなら、人間が少し工夫して型のコンテキストを与えてやることで、計算機はずっとよいパフォーマンスを発揮できるはずです。 ごく簡単な例で実験してみましょう。以下のコードは、let view: UIView? があるとき、座標系における view のX座標を得ようとするものです。ただし view が
Swift 2.2 - cockscomblog?
寒さも和らぎ、日によっては春の訪れを感じさせる今日この頃、いかがお過ごしでしょうか。春といえば Swift です。Swift は春と秋に、まるで衣替えのように大きなリリースがあります。2016年の春と予告されていた Swift 2.2 は、おそらく来週には正式にリリースされるものと思われます3月22日にリリースされました。 Swift 2.2 は、バグの修正や警告や診断の改善、コンパイル時間や実行速度の向上が主目的であるとされ、それに加えて Swift 2.0 以来のちょっとした機能向上を図ってのリリースとなります。Swift2.2 は OSS となった Swift の初めてのバージョンアップでもあります。すなわちコミュニティからの直接的なフィードバックを経た、最初の Swift と言えるでしょう。そんな Swift 2.2 の変更から主だった（おもしろい）部分を紹介します。 春に備えて準
watchOS 2のアーキテクチャが意味すること - cockscomblog?
以前に書いたように、watchOS 1.0においてWatchKitアプリはiPhoneの側でそのプロセスが動作する。Apple Watch側にあるのはUIリソースのみであり、実際の処理はiPhone上で行われる。これは非常に高度な仕組みでありながらも、パフォーマンス上の問題を抱えていた。watchOS 2.0からはこれが大きく変化して、いわゆるネイティブ化が行われ、実際の処理もApple Watch側で行われるようになる。とはいってもAPI上の変化は少なく、これまでとおおよそ同じようなインターフェースになっている上、ベースはiOSであるからUIKitの一部やFoundationが利用できる。 watchOS 2.0の正式なリリースは秋を予定しており、Apple Watchの発売からおおよそ半年である。しかしここで大きな疑問が残る。watchOS 1.0のアーキテクチャはいったい何のために用
Swift 1.2 - cockscomblog?
第61回 Cocoa勉強会関西で“Swift 1.2 The long-awaited language updates”と題して発表した、Swift 1.2の主だった（おもしろい）変更点の紹介です。 if let Swift 1.2で最も改善されたのはif文です。if letでOptionalをunwrapできる機能が大きく向上し、複数のOptionalを同時にunwrapできるほか、unwrapされた値について条件を加えることができるようになりました。 例えばcondition: Boolが真でふたつのOptional<Int>がnilではなく、大小関係にも条件がある、という条件を表してみます。 Swift 1.1 let condition = true let aNumber: Int? = 3 let anotherNumber: Int? = 7 if condition {
WatchKitアーキテクチャ概論 - cockscomblog?
来年初めにリリースされるというApple WatchのSDKがプレリリースされた。Appleはこれを WatchKit と呼ぶ。Apple Watchで動作するWatchKitアプリは、いったいどのようなアーキテクチャにより駆動されるのか。この興味深い仕組みについて考察する。 WatchKit - Apple Developer ふたつの予想 Appleがウェアラブルデバイスを開発しているという噂が流れていた頃、そのアプリケーションのアーキテクチャについて異なる二つの予想をしていた。 一つは、ウェアラブル端末本体で動作する通常のアプリを作るというパターン。これはAndroid Wearが採用しており、Androidのアプリを作るのとほとんど同じようにウェアラブル端末で動作するアプリを作ることができる。これが採用されると、UIKitの多くのコンポーネントが利用できることになり、柔軟なアプリを
Android Studio便利テク #3 — メソッドをグルーピングする - cockscomblog?
Javaでクラスの実装を進めていくと、あるメソッドが継承元クラスのメソッドをオーバーライドしているのか、あるいは何らかのinterfaceの実装なのか、だんだん見分けがつかなくなります。一定の規則でメソッドを並べたり様々な工夫があることと思います。 Xcodeのpragma mark #pragma mark - UITableViewDelegate iOSアプリ開発に慣れていれば、上記のような#pragma markを残しておく習慣があることでしょう。ちなみにSwiftでは以下のようになります。 // MARK: - UITableViewDelegate region Android Studioにはpragma markとは少し違いますが、regionというコメントの書き方があります。 //region GoogleApiClient.ConnectionCallbacks @Ov
モバイルアプリのObserverパターン - cockscomblog?
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
iOSアプリ開発における便利OSSライブラリの選定について - cockscomblog?
(Andy Myers and the CocoaPods Dev team. Creative Commons - Attribution-NonCommercial 4.0 International) iOSアプリを作るとき、今日ではCocoaPodsを用いて簡単に便利なライブラリの力を借りることができる。 ライブラリを利用するメリットは多い。自分でメンテナンスする必要がないので、放っておいても勝手に改善されていく。潜在的な問題があったとしても、多くの人が利用しているものなら誰かが気付いて直してくれる可能性も高い。また自分より優れたエンジニアの手によって、優れたインターフェースや実装になっているということも多い。何より、自分で実装する手間が省けるのがよい。 反面、デメリットについても考えなければならない。ライブラリがメンテナンスされなくなったとき、なにか問題が起こったり、あるいはAp
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
