extension UICollectionView { func register<T: UICollectionViewCell>(cellType: T.Type) { let className = cellType.className let nib = UINib(nibName: className, bundle: nil) register(nib, forCellWithReuseIdentifier: className) } func register<T: UICollectionViewCell>(cellTypes: [T.Type]) { cellTypes.forEach { register(cellType: $0) } } func register<T: UICollectionReusableView>(reusableViewType: T.T

概要 時間という概念は、概念と呼ばれるものの中で最も日常に溶け込んだ存在です。 本投稿では、まずはじめにSwiftでの正しい日付・時刻の扱い方を知るために、その仕組みとなっている時間・時刻の定義についてまとめていき、その後Dateを扱うときのアンチパターンとベストプラクティスについて考え、その対応について紹介していきたいと思います。 GMT / UTC / JST / UNIX TIMEについて SwiftでDateを扱う前に時刻とはなにかについて知る必要があります。ここでは世界で主に使われる時刻の定義の種類について簡単におさらいをします。 GMT GMT(グリニッジ平均時): UTCが現れる以前まで世界共通時として扱われていたものであり、経度0からの平均太陽時を指します。現在ではUTCと同義で扱われることが多いですが、厳密には異なりGMTはうるう秒が考慮されないためUTCとは100年でお

Placeholder(プレースホルダー)： 画像読み込み中に出す画像の機能（インジケーターとはまた違います） ImageTransform(画像加工): 取得した画像を表示するまでに編集できる機能（例 サイズ、まる角など） Animation(アニメーション)： 画像出現の際にアニメーションをつける機能 Prefetch(プリフェッチ)： 表示する画像をあらかじめ読み込んでおく機能 考察 SDWebImageとKingfisherの機能はだいたい同じ NukeはPreheatで拡張すること、PINRemoteImageはデフォルトでプリフェッチ機能が使える。 AlamofireImageは画像出現アニメーションが一番充実している。自分で作らなくてもデフォルトでいくつか用意されている。オプションで自作アニメーションも設定可能。(以下、用意されたアニメーション) crossDissolve

あるプロジェクトで導入しているライブラリを簡単に説明を添えてくれと頼まれたので その内容をQiitaにも投稿します。 iOSプロジェクトで導入しているライブラリの説明 実際にプロジェクトで使っているコードを一部抜粋して載せます。 ※ 長くなってしまうので必要最低限の記述とし、Import等は省きます。 ※ App.XXというのは自前で定義しているstructなのでスルーしてください。 APIKit ishkawa/APIKit: Type-safe networking abstraction layer that associates request type with response type. APIリクエストをする際に使用するネットワークライブラリです。 JSON デコーダのHimotokiと合わせて使っています。 例：お知らせ情報を取得 import APIKit import

Swift のコンパイラの開発に手を出してみたい方向けに、コンパイラの全体構成がどうなっているのかを、大まかに説明します。コードリーディングの参考になればいいなと。 Swift コンパイラの構成 僕はプログラムを把握するときに、エントリポイント（最初に実行される箇所、 main 関数）が分からないとすごく不安になります。逆に言えば、エントリポイントさえ分かれば、そこから処理を追っていけば良いのでその後の理解が非常に楽になります。なので最初は swift コマンドのエントリポイントから。 注意: このエントリで、 GitHub にある実際のコードにリンクを張っていますが、行番号は時と共に変わってしまうので、ファイルまでのリンクになっています。関数名などで検索してください。 ドライバー (Driver) swift コマンドですが、実体は tools/driver です。 tools/driv

はじめに ニュース系アプリのユーザインタフェースの実装で、Objective-C での実現方法について記した。 ようやく Swift を学び始めたので、練習用に先の記事で紹介した PageMenuController を Swift3 で書き直し、PageMenuKit としてフレームワーク化してみた。 PageMenuKit の設計と実装 完成版は github に PageMenuKitSwift として公開中。 すぐに動かしてみたい人は、上記 URL をクリックしてダウンロードするか clone するかして、Xcode でビルドして、 iOS Simulator で実行してね。 メニュー画面の設計 PageMenuController と同じく、画面上部で横スクロールするメニューを実現し、スタイル指定でメニュー部分を切り替え可能な仕組みを採用する。また、メニュー部分は汎用的な親クラス

言語学習をしていると、もっと体系的に学びたい、実際に実務でどんな感じのソースコードが書かれているかみたいなどと思うことがあると思います。その中で自分が体系的に学べたものをいくつか紹介したいと思います。 ※内容は初心者から中級者向けです。 Github Repositories https://github.com/raywenderlich/swift-algorithm-club raywenderlichさんによる、swiftでalgorithmを学べるリポジトリです。 https://github.com/kickstarter/ios-oss Kickstarterさんが実際にリリースしているアプリのオープンソースリポジトリです。 https://github.com/mixi-inc/iOSTraining/blob/master/Swift/README.md mixiさんが公

今更ではありますが、Swift の API Design Guidelinesを訳してみました。 基本 利用者にとっての明確さがもっとも重要な目標です。メソッドやプロパティを宣言するのは一度だけですが、繰り返し 使われます。API を利用するコードが明確で簡潔になるように API を設計しましょう。設計を評価するには宣言を読むだけでは不十分です。API が明瞭なものであることを確かめるため常に利用例を書いてみて検証しましょう。 簡潔さより明確さが重要です。Swift のコードはコンパクトに書くことができますが、出来る限り少ない文字数で出来る限り短いコードを書けるようにすることが 目標ではありません。Swiftにおける簡潔さとは強い型システムとボイラープレートを自然と減らす言語機能の副作用としてもたらされるものです。 全ての宣言にドキュメンテーションコメントを書きましょう。ドキュメントを書く

ほとんどのアプリは以下の方法で分けていると思います。 一つは、User-Definedを使う方法。 一つは、プリプロセッサマクロを使う方法。 これらよりも、自分がベストだと思う方法があるよ。という記事です。 MavenのprofileやGradleのAndroid Pluginのように環境別のファイルを用意して、ビルドにどっちを使うかを判断させる方法です。 やり方 まずは、Environment-Info-develop.plist、 Environment-Info-production.plist のように環境ごとのファイルを作成します。 中身は以下のように環境ごとの違いを記述します。 <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://w

はじめに strongやweakなど所有属性を適当につけると、 メモリリークを起こすと、先輩方によく突っ込まれませんか？ どういうことなのか、整理してみました。 よく言われるケースは、 OutletやDelegate、Closuresなどですかね？ SwiftLintでもワーニングが出ます。 今回は、Delegateを例に説明してみます。 サンプルの説明 1st画面、2nd画面、3rd画面の3画面の構成とします。 1st画面の仕様 ボタンを押下すると、2nd画面へ遷移します。 import UIKit final class FirstViewController: UIViewController { @IBAction func didTap2ndScene(_ sender: UIButton) { let secondVC = UIStoryboard.viewController

それでは、『SwiftのOptionalのベストプラクティス』というタイトルで発表します。 #swtws pic.twitter.com/OJfz2tk4sP — koher (@koher) 2017年4月15日 2 年程前、 Qiita に『SwiftのOptional型を極める』というタイトルで投稿をしました。内容は、 Optional とは何かという説明と、 Optional の使い方を合わせたものでした。 しかし、 Swift 1 だった当時と比べると Optional 周りの状況は大きく変わり、特に使い方の部分が適切ではなくなってきました。また、僕のSwift経験値もたまって、新たな知見も蓄積されてきました。 今回の投稿では、 Swift の Optional 周りを整理し、いつ・どのように Optional を使うべきか、僕の考えるベストプラクティスを紹介します。 全体を通し

Fluxはデータフローを単一方向に限定するのが特徴的な設計パターンです。 SwiftでRxSwiftを利用してFluxを実現する際にに、下記のような問題点があると思います。 Actionからsubscribeしたり、StoreからonNextができてしまう Storeが保持している値をViewからも変えることができてしまう これらの問題を解決するためにはどのような実装にしていくかを解説していきたいと思います。 Actionからsubscribeしたり、StoreからonNextができてしまう RxSwiftでイベントをDispatchするために、下記のようにPublishSubjectとしてPropertyを定義するかと思います。 final class SearchDispatcher { static let shared = SearchDispatcher() let items

はじめに これは Swift Tweets 2017 Spring で発表（ツイート）したものをまとめたものです。 これ以降は基本的にツイートしたものと同じです。 こちらは徳島からTweetしてます、こんばんは。よろしくおねがいします。 今回は、テスト向けにモック（またはスタブ）を差し込む方法について、ぼくが色々と妄想💭を膨らませていきます。 コード多めになったのであとでゆっくり見返してください🙇 まずは、簡単な方法です。対象のクラスのサブクラスを作成してメソッドをオーバーライド🏇するだけでも、動作を差し替えたり、確認用コードを差し込むことができますね。 class UserStatistics { var numberOfYoungUsers: Int { get { return allUsers().filter({ $0.age < 35 }).count } } func