【Swift】UIPresentationControllerを使ってモーダルビューを表示する - Qiita
１．はじめに まずは完成形を。 遷移元の画面上にオーバレイする形でモーダルビューを表示します。 いつもとちょっと違ったモーダルを出したいときに重宝しています。 ２．呼び元の ViewController class PresentationControllerViewController: UIViewController { @IBAction func openButton(_ sender: UIButton) { let modalViewController = ModalViewController() modalViewController.modalPresentationStyle = .custom modalViewController.transitioningDelegate = self present(modalViewController, animated
【Swift】UITableViewのタッチイベントを検知する方法 - mzgkworks
UITableViewController（Static Cells使用）で、テーブルのセル内に入力欄（UITextField）を設置し、入力欄以外をタップした際にキーボードを消したい。 しかし、ViewController側でタッチイベントを検知していない。 どうやらUITableViewはUIScrollView同様に、タッチイベントをViewControllerまでレスポンダーチェーンさせない。 なので、クラス拡張（SwiftでいうExtension。Objective-Cでいうカテゴリ）で対応させる。 こんな画面。 環境 Xcode 6.3.2 Swift 1.2 UITableViewController TableView - Content：Static Cells Extensionの作成 File -> New -> Fileで、.swiftファイルを作成する 名前は任意
Swiftの命名規則を理解する（Swift API Design Guidelines - Naming 日本語まとめ） - Qiita
私は普段Swiftをメインで書いていますが、Namingがとても苦手です。 どうやったらNamingがうまくなるか、考えました、 公式ドキュメントを見つけて、考えるのをやめました。 Namingがうまくなるためには、公式ドキュメントに従うのが一番です。 そこで Swift API Design Guidelines のNamingを読みました。 https://swift.org/documentation/api-design-guidelines/#naming 他の方の翻訳もありますが、当時から公式ドキュメントが更新されていたようですので、 2019/02時点での翻訳をまとめてみました。 翻訳というより、日本語意訳に近いと思います。 構成や日本語表現を独断と偏見で一部編集しています。 忙しい人は、「fuwamakiまとめ」だけ見れば十分かもしれません。 忙しくない人や英語ができる人は
UITextField.rx.textがイベントを発行するタイミング - Qiita
キーボードでリターンキーをタップした時、入力されている文字列が2回ストリームに流れてくるので、UITextField.rx.textをサブスクライブしてAPIリクエストを行うなどの処理をしている場合は余計な通信が発生しないよう注意が必要です。 下記で紹介しているコードを見ていただければと思いますが、こうした余計なイベントへの対応としてUITextField.isEditingプロパティが使えるかもしれません。 また、UITextField.textにコードから文字列を代入した場合、UITextField.sendActions(for: .valueChanged)を実行しないとUITextField.rx.textイベントが流れてこない点も気をつけましょう。 画面とコード テストに使用した画面とコードを以下に載せておきます。 画面は一つのUITextFieldと二つのUIButtonで構
XcodeでDevelop/Staging/Release環境を上手に切り分ける方法 - Qiita
はじめに アプリに限らずだと思いますが、開発・ステージング・本番の３環境で制作が進んでいくケースは多いと思います。 ここでは、私がXcodeでプロジェクトを作成する際に設定する内容をまとめたいと思います。 基本的な設定の流れ 初期状態 Xcodeでプロジェクトを新規作成すると、Build ConfingurationはDebugとReleaseの２種類が作られます。 Build Configrationの設定を好みの形に変更する タイトルの通り、Develop/Staging/Releaseの３つで作成します。 [+]を押して「Debug」を複製する形で「Staging」を作成し、「Debug」はダブルクリックで名称を「Develop」に変更します。 最終的に、このようにします。 PROJECT -> Build Settingsの修正 Apple LLVM 9.0 – Preproces
使うと手放せなくなるSwift Extension集 (Swift 4版) - Qiita
便利で汎用性高めのExtension集です。Protocolやオペレータなども含まれています。 今後も便利なExtensionができ次第、本記事を更新していきます。 手放せなくなるSwift Extension集 (Swift2版)と使うと手放せなくなるSwift Extension集 (Swift3版)のSwift4版です。 記法の最適化や拡張の取捨選択で段々と良くなっています。 今回紹介したExtensionは全て下記のリポジトリに入っています。利用したい方はコピペやCarthageで導入してみてください。 https://github.com/tattn/SwiftExtensions ※ Swift4.2 で動作確認をしています。 ※ コード片ごとに紹介していますが、別のコード片のExtensionに依存している場合がありますので、ご注意ください。 クラス名の取得 public p
【Swift】Extensionの定義の仕方について - Qiita
アプリのような比較的大きなプロジェクトにおけるExtensionの定義の仕方について考えてみました。 まだ実践したわけではないのですが、一旦まとまったので共有してみます。 一つのファイルで拡張する既存型は一つにする。 一つのファイル内でExtensionを複数定義してもよい。 追加される型・メソッドで関連するものは、共通のExtensionのスコープ内でグルーピングする。 ファイル名は <拡張する既存型名>+<分類名>.swift にする。 プロジェクトに<拡張する既存型名>グループを作成してファイルをまとめる。 プロジェクト外で定義された既存型に関するグループはわかりやすい場所にまとめる。 プロジェクト内で定義された既存型に関するグループは、その型が定義されたファイルもその下に置く。 例 プロジェクトの構成例。 Extensionファイル例。特に依存関係にあるメソッドは同じスコープに入れ
SwiftのProtocolExtensionでBaseViewControllerの肥大化を解決！そして、必ず抑えておきたいデメリット - Qiita
ある特定の画面への遷移など、共通の処理を書きたいことはしばしばあります。 下の例はMyViewControllerA及びMyViewControllerBのどちらからもMyViewControllerCへ遷移したい時のコードです。 class MyViewControllerA: UIViewController { // ...省略... func showViewControllerC() { navigationController?.pushViewController(MyViewControllerC(), animated: true) } // ...省略... } class MyViewControllerB: UIViewController { // ...省略... func showViewControllerC() { navigationController
【iOS】【Swift】「RootViewController + Wireframe」で画面遷移での消耗を回避する - ペンギン村 Tech Blog
自己紹介 はじめまして、ペンギン村で一番やかましい住人のナガクラ(@nagakuta)です！ Slackだけでなく、ブログもやかましく更新していきます！！（宣言） TL;DR RootViewControllerをAppDelegate.window.rootViewControllerに指定してから画面遷移するようにすると色々ラクだよ！ Wireframeも一緒に使うとテスト書くときラクだよ！！ RootViewControllerによる画面遷移 RootViewController #とは 自分がRootViewControllerについて知ったのは、ペンギン村に貼られた以下の記事でした。 medium.com その記事のリンクにRootViewControllerについての詳細記事がありました。 medium.com その記事中にて説明されているRootViewControllerに
UIScrollView, UIWebView等のContent Insetを調整する - タコさんブログ
全画面にUIScrollView（UIWebView）を配置すると、ステータスバーを表示している場合、下の図のように、ステータスバーの下にコンテンツが重なって表示されてしまう。 このとき、スクロールヴューの余白、スクロールバーの開始位置を以下のように調整する必要がある。この例ではUIWebViewを使用。 // status bar height:20pt分余白をとる let edgeInsets = UIEdgeInsets(top: 20, left: 0, bottom: 0, right: 0) // 上の余白部分 webView.scrollView.contentInset = edgeInsets // スクロールバーの開始位置をずらす webView.scrollView.scrollIndicatorInsets = edgeInsets これで、ステータスバーの高さだけ
UINavigationControllerと座標ズレの小ネタ - Qiita
画面遷移にUINavigationControllerを使うことは多いと思いますが、少し注意をしないとレイアウトが思い通りにならないことがあります。 自分の経験に基づいて、注意すべき点を2点あげます。 UINavigationController.navigationBar.isTranslucent ナビゲーションバーを透過にするかのフラグです。と共に、ビューの開始位置を決めるフラグでもあります。標準ではtrueになっています。 追記: コメントで指摘をいただきました。@dokubekoさん、ありがとうございます。 バーのisTranslucentがビューの面積をバーの下までのばすトリガーではありません。 ビューの面積をバーの下まで伸ばすかどうかはビューコントローラのedgesForExtendedLayoutプロパティで指定します。これに関連し、バーが不透明な場合にもそうするかどうかを
Carthageを使ってビルド時間を短縮しよう - Qiita
Carthageとは Carthage（カーセッジ）は、Swift製のライブラリ管理ツールです。 Cocoaのライブラリ管理ツールとして有名なCocoaPodsは、自動的にワークスペースの生成と更新を行うなど、多くの機能を搭載していますが、 Carthageはそうでない、シンプルで柔軟性があり、余計なことをしないツールとして作られました。 なぜCarthageを使うのか 先ほどCarthageにはシンプルで余計なことをしないという特徴があると述べましたが、 いま自分としては コンパイル時間が短くなる という点に最も魅力を感じて使用しています。 Carthageはライブラリをインストールすると、そのライブラリを事前にビルドをし、フレームワークを作成してくれるため、 CocoaPodsを使うのに比べ、コンパイル時間を短くすることができるんですね。 実際にメッセージングアプリSync開発の舞台裏
RxSwift UIAlertController を observable で表示 - Qiita
やり方の例です。 UIAlertActionに相当するオブジェクトを定義 UIAlertActionのクロージャ部分は、onNext処理を入れたいので、事前に代わりになるクラスか構造体を定義しておく。 struct AlertAction { var title: String var style: UIAlertActionStyle static func action(title: String, style: UIAlertActionStyle = .default) -> AlertAction { return AlertAction(title: title, style: style) } } 表示部分 上で定義した構造体をUIAlertActionとしてUIAlertControllerにセットする。この時にクロージャ内の処理を定義すること。Observable生成の時
UITableViewの編集モードを使ってCellの削除を実装するまで - Qiita
TableViewのCellの削除の流れ tableViewのdlegateなどは実装してあることを前提としています。 1. 編集ボタンを作ってNavigationBarに追加 2. 編集ボタンを押したらTableViewの編集モードを切り替える 3. 削除の実装 4. バツボタンの背景色を変える 5. 通常時の横にシュッてやるとdeleteが出てしまうのをオフにする 1. 編集ボタンを作ってNavigationBarに追加 まず実装したいViewを選択した状態でxcodeの上のメニューバーからEditor -> Enbed In -> NavigationControllerでNavigationBarを画面に追加する(Viewが二つになるがこれらがうまく重なるイメージ) その後実装したいViewのControllerのviewDidLoad()に次のコードを書き込む self.navi
Storyboard を使わずコードだけで画面を生成、遷移をしてみる - Qiita
Swift時代に悩ましいUIViewControllerをどう扱うか - Qiita 先日の Swift Tweets で UIViewController の初期化とか画面遷移は Swift っぽく書けないからコードで書くのおすすめだよ、ってあったのでコードだけで画面を生成し画面遷移してみる。 AutoLayout の記述には SnapKit を利用するので Cocoapods などで追加しておく。 完成画面 先に作る画面がわかっていた方がわかりやすいので完成画面を先に載せておく、Tab + Navigation の一般的な画面です。 1. 初回起動の Storyboard を削除 Main.storyboard はいらないので削除してしまいましょう。 また、 General > Deployment Info > Main Interface も空欄になるようにしましょう。 2. 各画
programming-beginner-memo.com - programming beginner memo リソースおよび情報
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
XcodeのBuildPhase RunScript でxcfilelistを使う - Qiita
注意 本対応はCarthageのv0.31.1以降でのみ使用可能です。 はじめに Carthageでライブラリ管理を行うような場合、Build Phases に 以下のようなRunScriptを追加する必要があります。 Carthageを例にとりますと、ここでInput FilesにCarthageで導入したライブラリのBuild成果物のPathを記載する必要がありましたが、ライブラリの数が増えると以下のような問題が発生します。 単純に記入が手間 記入漏れ等に気づきにくい、逆に重複があっても気づきにくい 意味のあるまとまり（通信ライブラリ、Alphabet順など）に整理しづらい このあたりの仕組みに関してXcode10で改善があったため共有します。 検証環境 以下の環境を使用しています。 macOS High Sierra Version 10.13.6 Xcode Version 10.
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Swift 4 Attempt to present ViewController whose view is not in the window hierarchy
[Swift] UITableViewの上部にマージン(inset)が自動で設定されてしまうのをstoryboardで解除する。 - Qiita![[Swift] UITableViewの上部にマージン(inset)が自動で設定されてしまうのをstoryboardで解除する。 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/6c70e1a7e9696d7b71e5f30df887cc9ae79b7697/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCU3dpZnQlNUQlMjBVSVRhYmxlVmlldyVFMyU4MSVBRSVFNCVCOCU4QSVFOSU4MyVBOCVFMyU4MSVBQiVFMyU4MyU5RSVFMyU4MyVCQyVFMyU4MiVCOCVFMyU4MyVCMyUyOGluc2V0JTI5JUUzJTgxJThDJUU4JTg3JUFBJUU1JThCJTk1JUUzJTgxJUE3JUU4JUE4JUFEJUU1JUFFJTlBJUUzJTgxJTk1JUUzJTgyJThDJUUzJTgxJUE2JUUzJTgxJTk3JUUzJTgxJUJFJUUzJTgxJTg2JUUzJTgxJUFFJUUzJTgyJTkyc3Rvcnlib2FyZCVFMyU4MSVBNyVFOCVBNyVBMyVFOSU5OSVBNCVFMyU4MSU5OSVFMyU4MiU4QiVFMyU4MCU4MiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTU2JnM9ZWFlMzc0N2I0MmM0YmZhZjgwYzM1MWRkZWVhYzExMTE%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDB0b21vc29vb24mdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPTlkZWY0YmU4ZDJiMDc0ZmE3ODdjOWU3MWYzZjMyOWYx%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3D320d7014d4a29aaca5b580170740c00d)
Swift4でDispatchQueueを使う - Qiita
