【iOS】Swiftコーティング規約について
お久しぶりです。 ブログ久しく書いてなかったのですが、 ぼちぼち書いていこうかと思います。 サーバサイド、フロント、Androidアプリ開発も一通りやって 最近iOSアプリの開発やってます。 そろそろ本格的にSwiftで開発はじめます。 SwiftはLLなみに自由に書けるので チーム開発はコーディング規約が必須でしょう。 とりあえず文法も軽く押さえたので参考になりそうなものを あさってみました。 チュートリアルサイトで有名なhttp://www.raywenderlich.com/ の公式コーディング規約がけっこう良さげです。 https://github.com/raywenderlich/swift-style-guide 上記swift-style-guideを適当に和訳しましたので参考にどうぞ。 https://github.com/dekatotoro/swift-style-g
Swift学習のため、Qiita API v2を使いQiitaのクライアントアプリ作りました。 - Qiita
概要 きっかけとしては swiftがっつり書いてみたい QiitaをiPhoneで閲覧したい 社内でiOSのライブラリ開発してるが、「お前実際のアプリ知らないだろ」って舐められてる感があるから「いやー、少しは知ってるお。(・ω・)」ってとこを見せるため という感じです。 アプリのことと、1.5ヶ月ぐらい開発してて思ったことをツラツラ書いていきたいと思います。 作ったアプリ「Miita」 Qiita APIを使って「Miita」というQiitaのクライアントアプリ開発しました。 https://itunes.apple.com/jp/app/miita-browsing-article-for/id1030691396 アプリ名の由来 モバイルのm iPhoneでQiita(iita)を見(m)るのm 山口のm などなど、ゴロがいいので当てて見ましたよ 機能 すべての記事、ストックした記事、
iOS アプリの UI でこれだけはおさえたい細部のインタラクション3つ - クックパッド開発者ブログ
Holiday 事業室の多田です。先日 Elasticsearch の記事を書いた内藤と共に Holiday ( https://haveagood.holiday ) の開発を行っています。 Holiday は、去年9月に Web 版をリリースしましたが、よりおでかけを楽しくするために今年3月に iPhone アプリをリリースしました（ダウンロードはこちら）。 アプリの開発過程ではコンセプトや仮説を立て、その検証や実現のために作っては壊すことを何度も繰り返し行いますが、実現したい価値を提供するためには、出来上がったプロダクトの細部のインタラクションも重要になってきます。細かい部分に気を配り使い心地を良くしてこそ、本当に提供したい価値をまっすぐに届けることができるためです。逆に言えば、最後の最後で細かい部分がちゃんとしていないばかりにそれまでの過程が無駄になったらもったいないですよね。 今
既存のObjective-CアプリケーションをSwiftで書き換えた話 - クックパッド開発者ブログ
海外事業向けのiOSアプリケーション開発を担当している西山(@yuseinishiyama)です。クックパッドは現在、海外複数カ国に向けてサービスを展開しています。 主にObjective-Cで記述されたアプリケーションを全面的にSwiftに書き換える機会があったので、その際に得た知見や書き換えるに至った動機を共有します。 書き換えに至るまでの経緯 この項では、書き換えに至るまでの経緯について説明します。 Objective-C期 アプリケーションの開発は2014年7月頃にスタートしました。Swiftの発表直後でしたが、時期尚早ということもあり、Objective-Cで実装することになりました。 Objective-C、Swift混在期 2014年10月頃から、Swiftへの段階的な移行のために、新規のコードをSwiftで書くようになりました。Swiftの記述力や、ヘッダと実装を行き来しな
どこよりも分かりやすいSwiftの"?"と"!" - Qiita
swiftはオプショナルが便利！ と、swiftがリリースされてから言われてますがswift初心者からすると厄介極まりないです。 ?と!の使い分けが分からずとりあえず"?"をつける、ソースコードを書いていたら急にXcodeに怒られ、エラーに導かれるままに"!"をつける... こんな経験がある方がいるのではないでしょうか。 この記事はそんなオプショナルがフワフワした状態を脱却することを目的としています。 (そのため、あまり深い部分は扱いません...) 細かく項目を区切っているため多く見えますが、サクサク読めるはずです。頑張って読んでいただければオプショナル型を理解できると約束します。 時間のない人はまとめだけ見ていただければと思います。 ◼︎ 読了時間 オプショナル型と非オプショナル型 (4分) オプショナル型と非オプショナル型の違いを示します オプショナル型 (6分) オプショナル型"?"
iOS AutoLayoutのデバッグテクニック(Xcode 7で導入されたIdentifierなど) - Qiita
先々週あたり、この2件のAutoLayoutのデバッグテクニック系記事が海外で話題になっていてPocketで積ん読状態になっていたので、掘り出しつつ試してみました。 Using Identifiers to Debug Autolayout - Use Your Loaf Autolayout breakpoints - NSHint UIViewAlertForUnsatisfiableConstraintsのシンボリックブレークポイントを設定 このブレークポイントを設定することで、文字通りAutoLayoutの制約矛盾が発生した時にブレークしてくれます。 さらに、Actionも設定するのが肝で、この場合は次の設定をするとブレーク時に見やすいログが自動出力されるようになります。 関連: Objective-C - Xcodeでデバッグ実行中にクラッシュした時に捗るブレークポイント設定 -
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Kodeco
GitHub - ishkawa/APIKit: Type-safe networking abstraction layer that associates request type with response type.
