Swiftのエラー4分類が素晴らしすぎるのでみんなに知ってほしい - Qiita
これは Swift Tweets の発表をまとめたものです（次回開催はこちら）。イベントのスポンサーとして Qiita に許可をいただいた上で投稿しています。 ありがとうございました！Q&Aは他の人の発表中でも構わないのでリプを飛ばして下さい。 続いては僕 @koher の発表で、タイトルは "Swiftのエラー4分類が素晴らしすぎるのでみんなに知ってほしい" です。 #swtws — koher (@koher) 2017年1月14日 第 1 部: Swift の 4 種類のエラーについて あまり知られてませんが、エラー処理について、 Swift 2.0 設計時に Core Team がまとめた "Error Handling Rationale and Proposal" というドキュメントがあります。このドキュメントは、僕が去年 try! Swift で発表した際にも参考文献にしまし
今から新規でiOSアプリを書き始めるなら。2016年冬 - Qiita
こんにちは @yimajo です。この記事は今から新規でAndroidアプリを書き始めるなら。に大きく影響されています。主な内容として次のような事柄を取り扱っています。 今から書くならこんな設計 こんなライブラリがあるが使ってみた感想 ただ、結論として大して深い内容は書けませんでしたので、がっかりせず、みなさん思い思いにやればいいよっていうことに終着しています。アドベントカレンダーのネタにみなさんも書いてみてはどうでしょう。 言語について Objective-C か Swift か まず最初に言っておくとObjective-CやSwift以外にもiOSアプリを始める方法はあります。例えばObjective-C++とかRubyMotionとか。まあそれはそれで良いところもあると思いますが、複数人でiOSアプリ開発を行いそれを保守したり機能追加したりすることを考えるとObjective-CかS
Swift のコードカバレッジ - Qiita
Swift2.0 になって、コードカバレッジが測定できるようになった。 C0 カバレッジしかとれないけど、それでも無いよりははるかにマシ。 コードカバレッジがないと、ユニットテストでどこまでカバーできているか分からないし、テストケースを書くモチベーションもなかなか上がらない。 以下は Xcode7.1 で確認した。 1. テスト対象 サンプルプロジェクトとして、SwiftCoverage を作る。テンプレートはなんでもいいけど、とりあえず iOS - Single View Application ということにしておく。 これに User.swift を追加して、これをテスト対象とする。 import Foundation class User { var lastName: String = "" var firstName: String = "" init() { self.last
RxSwift, ObjectMapper, APIKit で作る使いやすい API クライアント - Qiita
1.b. Linked Frameworks and Libraries に framework ファイルを追加 Xcode 上での作業になります。 プロジェクトファイルを開く 左にある TARGETS で APISample を選択 上部の General タブを選択 Linked Frameworks and Libraries の + ボタンを選択 Add Other... ボタンを選択 {RepoRoot}/Carthage/Build/iOS/ 以下の .framework ファイルを選択する 以下の様になります。 1.c. Build Phases に framework ファイルを追加 引き続き Xcode 上での作業です。 プロジェクトファイルを開く 左にある TARGETS で APISample を選択 上部の Build Phases タブを選択 左上の + ボタンを
#potatotips でAPIKitを紹介してきた
Mar 13, 2015 資料 内容 Appleが出しているThe Swift Programming Languageに”Swift is a type safe language.”書かれているように、 SwiftをSwiftらしく書くには型を意識したコードを書くのが良いと思っています。 型を意識する前は以下のようなAPIクライアントを使ってきたのですが、 let parameters = [ "q": "APIKit", "sort": "stars", "order": "asc", ] GitHub.call(.GET, "/search/repositories", parameters) { JSON, error in if error != nil { println("error: \(error!.localizedDescription)”) } else { se
Dependency Injection Framework for Swift - Swinjectの紹介 - Qiita
以下のブログ記事の翻訳です1。 Dependency Injection Framework for Swift - Introduction to Swinject このブログでは、Swift 用の dependency injection (依存性の注入) フレームワークである Swinject を紹介します。Swift 2 では protocol extension が登場し、protocol oriented programming が推奨されるようになりました。さらに、Xcode 7 では UI testing ができるようになります。この状況の中で、アプリのコンポーネントをプロトコルによって疎結合にすることがより重要になってきます。疎結合にする方法で代表的なものが dependency injection です。 Dependency Injection (依存性の注入) まず
[Swift] タイプセーフな軽量HTTPクライアント「APIKit」を試してみた | DevelopersIO
1 APIKitとは Yosuke Ishikawa氏 作成のAPIKitは、比較的新しいHTTPクライアントです。 https://github.com/ishkawa/APIKit Swiftは、タイプセーフな言語ですが、APIKitは、このタイプセーフの利点を最大限に発揮していると思います。 動作条件は次のとおりです。 Swift 2.1 Mac OS 10.9 or later iOS 8.0 or later watchOS 2.0 or later tvOS 9.0 or later また、特徴としては、次のようなものが挙げられます。 エンドポイントごとにクラスを定義 パラメータなどを型で明確に制限できる（Enumも利用可能） レスポンスが、成功・失敗の２値となる レスポンスの型を定義することができ、アンラップが不要（エラー時はNSError) それでは、実際に使用してみたよう
![[Swift] タイプセーフな軽量HTTPクライアント「APIKit」を試してみた | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/4b9b98d8423d1943cae402d21764bf51589e811b/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2014%2F11%2Flogo_swift_400x400.png)
[Swift] タイプセーフなJSONデコーダ「Himotoki」を試してみた | DevelopersIO
1 はじめに (1) Himotokiとは Himotokiは（紐解き）は、Syo Ikeda氏によって作成されたタイプセーフなJSONのデコードライブラリです。 https://github.com/ikesyo/Himotoki 特徴として、以下のようなものが挙げられます。 Swiftのみで書かれている 依存ライブラリがない JSONのデコードに特化されている 簡潔にモデル定義が可能 タイプセーフ 非常に軽量（Sourceの下で21,487byte） 国産 動作環境は、次のとおりとなっています。 Swift 2.1 / Xcode 7.2 OS X 10.9 or later iOS 8.0 or later (by Carthage or CocoaPods) / iOS 7 (by copying the source files directly) tvOS 9.0 or lat
Xcode 7 の新しいところ #cm_ios9
2015-11-05 に開催された『iOS 9 週連続 Bootcamp!』の第６回目で Xcode 7 の新機能について紹介してきました。ざっくりとじっくり含めて、目に止まった新機能を網羅的に扱っています。Read less
Swift2で作るコマンドラインツール - クックパッド開発者ブログ
会員事業部の三木(@giginet)です。 この記事では、業務改善のために開発者向けのツールをSwiftで開発してみたため、その知見についてお伝えしたいと思います。 なお、この記事はXcode7.1上でSwift2.1を使った開発を前提としています。 作ったもの クックパッドiOSアプリでは開発の際に、新しい機能を実装したり、インターフェイスを改善したあとにiOSシミュレーターの動画を撮影しPull Requestに貼り付けています。 動画を撮影する際には、汎用的にスクリーンキャストを撮影する社内ツールを使っていたのですが、使いづらい面も多かったため、 簡単にiOSシミュレーターの操作をアニメーションgifとして記録したいという需要がありました。 そのため、空き時間を使って、簡単なユーティリティを実装しました。 なぜSwiftで作るのか 今回は、OS Xの開発用SDKであるCocoaを使い
WWDC 2015 で Swift 2 が発表されました。 | DevelopersIO
Swift 2が発表されました 2015/6/8 アメリカはサンフランシスコで開催された WWDC2015 にてプログラミング言語Swiftの新バージョンであるSwift 2が発表されました。 私もTwitterのタイムラインを尻目に生中継を視聴していましたが、その中でとりわけ注目を集めていたのはなんといってもSwiftがオープンソース化し、将来的にはLinuxの上でも動くようになるという発表でした。 Appleの公式ブログによればSwiftは標準ライブラリ、コンパイラも合わせて今年の遅くにオープンソース化されるとのことです。OSSコミュニティからのコントリビューションも積極的に取り入れられるとのことで、バグの原因もOSSコミュニティの寄与によってパッチ等があてられて、目に見える形で言語開発が進むことが期待されます。 ドキュメント Pre-release版としてドキュメントがWWDC201
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 {
ObjectMapperでJSONマッピング
（概要） 第10回Swiftビギナーズ勉強会での発表資料になります。 AppleWatch対応アプリでの実装に関するTipsとiPhoneとAppleWatch間でのデータのやりとりに関する例をまとめました。 （サンプルはこちら） https://github.com/fumiyasac/goCoworkingSpaceReport/tree/for_swift_study ※追記10/14：記述ミスがありましたので訂正＆追加版をUPしました。
Swift - また言語仕様が変わっていやがる 2015春 - euphonictechnologies’s diary
You have been warned! Swiftは開発途上の言語です というわけで、またSwiftの言語仕様がガラリと変わりまして、さっぱりビルドを通りません。ぱっと見ると17個ものビルドエラー。なーんかC->C++->Ocamlあがりの私としては言語仕様というのはバックワーズコンパチブルでなんぼやというところなのですが、Swiftはそうではないようです。未来の開発者がクリーンな言語仕様で働けるようにがしがし後方互換性を殺すというのはまあ、いいのかも。 ですが、私はいましこしこビルドエラーを直さないといけないので、晒しておこうと思います。 変わったところ as of 9 Apr 2015 オーバーフロー演算子のうち(&%)がなくなったっぽい まあ、当たり前なんですが、&%がなくなりました。オーバーフローモジュロというのは意味わからないからだと思いますが、直交性のない演算子の組み合わせ
Swiftのmanual mocking
Mar 20, 2015 Objective-Cではテストケース毎にオブジェクトの一部だけ挙動を変えたい場合に、OCMockなどのライブラリを使うのが普通でした。 それらのライブラリはNSInvocationやMethod Swizzlingなどを使ったいわゆる魔術的なコードで実現されていることが多く、 “テストコードを書いているのによくわからんコードが動いてる！”ってなってモヤモヤしたりします。 一方、Swiftではmanual mockingという手法が取られたりするみたいです。 例えば、 class Object { var foo: String { return "foo" } var bar: String { return "bar" } } class ObjectTests: XCTestCase { func testFoo() { class ObjectMock:
SwiftTask、PromiseKit、Boltsを比較する（2015年3月版） | TOKOROM BLOG
※2015/3/11時点での比較結果ですので、今後、各ライブラリともにパワーアップしていくと思われます ※いまはできないことでも各ライブラリのIssuesでは実装の検討が進んでいるものも多くあるようです 次の案件で（Swiftで）Promiseライクなフロー制御を実現するために利用するライブラリを選定するため、2015/3/11時点の SwiftTask PromiseKit Bolts-iOS を（表面だけ）使って比較してみました。 なお、昨年の７月時点では（Swiftで使うぶんには）PromiseKitが将来性があると判断し、しばらくはPromiseKitを使っていました。 その後、SwiftTaskも登場して気になっていたので、今回改めて新案件で採用するライブラリを選定したという経緯になります。 以下にそれぞれ使ってみた結果を紹介させていただきます。 更新頻度 この３つのライブラリは
Swiftで使いやすいAPIを書くために気をつけていること - 24/7 twenty-four seven
先日iOSオールスターズ勉強会でSwiftでライブラリを書く際に良いと思ってることについて話しました。そこで好評だったり同意してもらえた何点かについてあらためてまとめます。 オーバーロードを積極的に活用しよう Swiftではメソッドのオーバーロード（引数の数、型、および戻り値の型が異なる同じ名前のメソッドが定義できる）が言語仕様としてサポートされています。これは上手に使うと利用する側にとってとても書きやすくなるので積極的に使っていきましょう。 例えば下記のような例では、Objective-Cではデータ型によって複数のメソッドを使い分ける必要がありました。 （引数の型がNSStringかNSDataかでメソッドの名前が異なる） - (BOOL)setString:(NSString *)string forKey:(NSString *)key; - (BOOL)setData:(NSDat
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
CCL 〜仮想通貨研究所〜 – Just another WordPress site
Swift 2.0 で変わったところ「後編」 #cswift
Swift 2.0 で変わったところ「前編」 #cswift
