SwiftUI はWWDC 2019のキーノートで発表された iOS/MacアプリなどのUIを構築するためのフレームワーク です。デベロッパーフレンドリーなコーディング＆直感的なデザインツールの組み合わせで、超簡単にUIを構築できる特長があります。例えばこんな感じです。 import SwiftUI struct ContentView: View { var body: some View { Text("Turtle Rock") .font(.title) .color(.green) } } struct ContentView_Preview: PreviewProvider { static var previews: some View { ContentView() } } これまで以上に簡単にUIが構築できることから、発表後iOSエンジニア界隈ではバズワードになっています
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? iOSアプリ開発のライブラリ選定時に、定番ライブラリが沢山乗っている記事があったら嬉しいな〜と思い、調べて書いてみました。 「他にもこんな良いライブラリがあるよ！」等ありましたら、教えていただけると嬉しいです！ GitHubでstarが多かったり、よく名前を耳にするライブラリを集めました ライブラリ名の横にライセンス種別を記載しています。 最新のライセンスではない可能性があるので導入の際は実際にリポジトリのライセンスページをご確認ください。 [2020/03/01 いくつかライブラリを追加しました] [2023/05/16 古い情報を修
私は普段Swiftをメインで書いていますが、Namingがとても苦手です。 どうやったらNamingがうまくなるか、考えました、 公式ドキュメントを見つけて、考えるのをやめました。 Namingがうまくなるためには、公式ドキュメントに従うのが一番です。 そこで Swift API Design Guidelines のNamingを読みました。 https://swift.org/documentation/api-design-guidelines/#naming 他の方の翻訳もありますが、当時から公式ドキュメントが更新されていたようですので、 2019/02時点での翻訳をまとめてみました。 翻訳というより、日本語意訳に近いと思います。 構成や日本語表現を独断と偏見で一部編集しています。 忙しい人は、「fuwamakiまとめ」だけ見れば十分かもしれません。 忙しくない人や英語ができる人は
import SQLite // Wrap everything in a do...catch to handle errors do { let db = try Connection("path/to/db.sqlite3") let users = Table("users") let id = SQLite.Expression<Int64>("id") let name = SQLite.Expression<String?>("name") let email = SQLite.Expression<String>("email") try db.run(users.create { t in t.column(id, primaryKey: true) t.column(name) t.column(email, unique: true) }) // CREATE TAB
To facilitate use as a quick reference, the details of many guidelines can be expanded individually. Details are never hidden when this page is printed. Table of Contents Introduction Fundamentals Naming Promote Clear Usage Strive for Fluent Usage Use Terminology Well Conventions General Conventions Parameters Argument Labels Special Instructions Introduction Delivering a clear, consistent develop
こんにちは、サービス開発部の氏です。 主にiOSのクックパッドアプリの開発を担当しています。 UICollectionViewLayout みなさん使ってますか？ UICollectionView でレイアウトを組む際、実際触り始めると実装するための選択肢が複数あり、どれが最適なのか悩ましい場面に遭遇する人もいるのではないかと思います。 今回は、自分が業務で触れた際に得た知見について軽くお話したいと思います。 UICollectionVIewLayout とは UICollectionView は Cellのサイズや余白等のレイアウトを管理するため、プロパティとして、 UICollectionViewLayout を所持しています。 この UICollectionViewLayout に手をいれることによって、レイアウトを好きな形に変更することができます。 レイアウトを組み立てるときの複数
If we have an enum wih associated types, the compiler can't automatically generate Codable conformance yet. For example, let's create an enum that can be one of two values: enum Either<A,B> { case left(A) case right(B) } If we use the latest Swift toolchain, we can conditionally make it conform to Codable (see this gist), but even in the current Swift release we can make it work by adding Codable
概要 エンドユーザーが通知（特にRemote Push Notification）を許可してくれたかどうかはサービスにとって死活問題 それなのに通知の許可ダイアログでの選択を素直にハンドリングする方法がこれまでなかった iOS 10でそれを簡単にハンドリングできるようになったよ！ 2016/6/28 追記 コメントで @mono0926 さんからいただいたとおり、じつはiOS 8/9でもdelegateでハンドリング可能ということが発覚しました。 http://qiita.com/tokorom/items/6c6864fa8e841e50e37b#comment-b07920917a7edfb87775 iOS 8/9 でのハンドリングについては別途まとめさせていただきますが、取り急ぎ、こちらで訂正させていただきます。 iOS 9 以前 let notificationSettings
DOCUMENT.md How to save data in iOS この投稿では、iOSのファイルシステムについて理解し、データを永続化(iCloud含む)する方法を紹介する。尚、サンプルコードは動かない可能性もあるので参考程度にして下さい。 iOS File System アプリがファイルシステムとやり取り出来る場所は、ほぼアプリのサンドボックス内のディレクトリに制限されている。新しいアプリがインストールされる際、インストーラーはサンドボックス内に複数のコンテナを作成し、図1に示す構成をとる。各コンテナには役割があり、Bundle Containerはアプリのバンドルを保持し、Data Containerはアプリとユーザ両方のデータを保持する。Data Containerは用途毎に、さらに複数のディレクトリに分けられる。アプリは、例えばiCloud Containerのように、実行時
高性能なMacマシンを確保まず、技術的なこと抜きに一定以上の性能のMacマシンを用意するのが良いです。取っ掛かりの勉強目的などならともかく、中規模以上のアプリを作る場合低スペックマシンでは著しく非効率です。 大体以下のようなイメージで、これ未満だと早めにマシン変えた方が幸せになれると思っています。 2–3年以内に買った20万円以上程度のMacBook Pro: 許容範囲iMac 5K: 良い感じiMac Pro: 一般的なiOSアプリ開発ではオーバースペック気味でコスパは微妙かも🤔会社で、交渉しても低スペック環境を強いられるのならば転職した方が良い気がしています🤔ちなみに転職ドラフトでSWHGという招待コードで登録するとお互いプロテインゲットできるので、気が向いたらお願いします( ´･‿･｀) Continuous Integration(CI)環境次に、CI環境について触れます。CI
こんにちは @yimajo です。この記事は今から新規でAndroidアプリを書き始めるなら。に大きく影響されています。主な内容として次のような事柄を取り扱っています。 今から書くならこんな設計 こんなライブラリがあるが使ってみた感想 ただ、結論として大して深い内容は書けませんでしたので、がっかりせず、みなさん思い思いにやればいいよっていうことに終着しています。アドベントカレンダーのネタにみなさんも書いてみてはどうでしょう。 言語について Objective-C か Swift か まず最初に言っておくとObjective-CやSwift以外にもiOSアプリを始める方法はあります。例えばObjective-C++とかRubyMotionとか。まあそれはそれで良いところもあると思いますが、複数人でiOSアプリ開発を行いそれを保守したり機能追加したりすることを考えるとObjective-CかS
こんにちは、技術部モバイル基盤グループの茂呂(@slightair)です。 クックパッドは Garage という RESTful Web API 開発を楽にする Rails のためのライブラリを作り、内部通信やモバイルアプリケーションのためのAPIサーバの開発に利用しています。 過去の Garage の紹介記事はこちらです。 RESTful Web API 開発をささえる Garage - http://techlife.cookpad.com/entry/2014/11/06/100000 RESTful Web API 開発をささえる Garage (client 編) - http://techlife.cookpad.com/entry/2014/12/26/193802 この Garage を使って実装された Web API を iOS アプリから気軽に呼べるように、 Swift
おはようございます。シニアアプリケーションエンジニアの id:cockscomb です。WWDC が目前に迫ったいま、今秋にリリースが予定されている Swift 3.0 について、Swift OSS コミュニティの中心である Swift Evolution から読み取っていきたいと思います。 [PR] 本記事は、筆者が株式会社はてなの協賛を得て主催した「関西モバイルアプリ研究会 #14」において、“Swift Otaku — Nerdy Swift-Evolution Watching” と題して発表したものをブログの記事として再構成したものである。 関西モバイルアプリ研究会は、毎月一度、平日夜に京都や大阪で開催される、モバイルアプリ関連の勉強会である。次回の「関西モバイルアプリ研究会 #15」は6月22日水曜日に開催予定だ。 目次 Focus Winding Down Complete
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? TL;DR 複雑になりがちな構造やコードをシンプルで把握しやすいコードで記述したい MVVMを用いて責務を明確にし関心事を分離した構造にする ViewDataBindingとFRPを用いて時間とともに変化するデータやステートに伴う処理を宣言的に記述し、Viewとデータの動的な変化を相互的に連動させる 上記をSwiftとそのパラダイムを活かしたライブラリ（SwiftBond)を中心に実現する はじめに Swiftで新規のアプリを開発することになり、MVVM、FRP、ViewDataBindingの要素技術を活用して開発を行いました。設計や
海外事業向けのiOSアプリケーション開発を担当している西山(@yuseinishiyama)です。クックパッドは現在、海外複数カ国に向けてサービスを展開しています。 XcodeにはInterface Builderと呼ばれる、リッチなGUIを持ったデザインツールが付属しており、これを用いて画面のレイアウトを構成することが主流となっています。弊社ブログでも、iOS開発でstoryboardとxibをうまく使い分けるプラクティス等の記事で、GUIベースのレイアウトについて触れています。しかし、現在私が担当しているプロジェクトでは、Interface Builderを用いずに、レイアウトの大半をコードで記述しています。 今回は、コードベースのレイアウトを実装していく中で得た知見を、以下の3つの部分に分けて共有したいと思います。 Interface Builderを用いたレイアウトとコードベースの
self.view iOS 開発において、UIViewController の view の振る舞いは一番理解しておきたい点の一つです。 今回はその view に対して、メモリ管理とレイアウトの2つの視点を交えてアプローチを行い、 UIViewController の subclass を作成する上で、 UIViewController の各メソッドにどんな処理を書くべきか、そして何を書くべきでないか を説明出来ればなと思っています。 iOS 6 以降からを対象として考えていますので、 iOS 5 以前は取り扱いません。 self.view の振る舞い 扱いを学ぶには、まず対象の振る舞いを把握する事からです。 ライフサイクルとレイアウトサイクルの2点から簡単に復習します。 self.view のライフサイクル UIViewController の view がどのようなタイミングで生成され
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
