タグ

Swiftに関するyoshukiのブックマーク (74)

  • 🐧🐧🐧iOS開発で誰も教えてくれなかったけど当たり前にやっているSwiftの書き方🐧🐧🐧 - Qiita

    「誰も教えてくれなかった」ってタイトルですが、僕iOS開発に関しては独学でしかやってないので、よく考えたら誰にも教わってないですね🐧🐧🐧 まあなんか、読んでもあんまり明示的には書いてないけど、「皆当たり前にやってるやん!」と思ったことを書いていきます。 (どこかに書いてあるのを見落としただけかもしれませんが) delegateで要求されているprotocolはextensionで書く ルールではないですが、慣習的にextensionで各protocolごとに分離して書いた方がきれいです。 extension SampleMapViewController: MKMapViewDelegate { func mapView(_ mapView: MKMapView, regionWillChangeAnimated animated: Bool) { //do something }

    🐧🐧🐧iOS開発で誰も教えてくれなかったけど当たり前にやっているSwiftの書き方🐧🐧🐧 - Qiita
  • RealmSwift入門 – 覚えておきたい、リレーションの定義からクエリ、マイグレーションまで – | DevelopersIO

    今回のテーマはモバイルデータベースの Realm です。 この記事では基的なCRUD以外の、実際にアプリケーションを開発していく中で必要になるリレーションの定義やマイグレーションなどを取り上げていきたいと思います。 こんにちは。モバイルアプリサービス部で iOS アプリエンジニアとして働き始めた田辺です。現在研修で大阪に来ていますが研修が終わるまでに一記事書きたいと考えていたので、その目標が達成できそうで嬉しいです。 今回のテーマはモバイルデータベースの Realm です。 業務で Realm を使っていること、今までの開発ではかなり単純なデータ(参照も更新も限定的)の保存に Realm を扱っていたため、実案件に入るまでにきちんと準備をしておきたいということで、今回 Realm をテーマにした記事を書くことにしました。 Developers.IO では 2 年程前に Realm の基

    RealmSwift入門 – 覚えておきたい、リレーションの定義からクエリ、マイグレーションまで – | DevelopersIO
  • Objective-CからSwiftへ、4つの移行ポイント~メルカリの実践例から最適な手法を学ぶ - エンジニアHub|Webエンジニアのキャリアを考える!

    Objective-CからSwiftへ、4つの移行ポイント~メルカリの実践例から最適な手法を学ぶ 多くの企業でObjective-CからSwiftへの移行が行われていますが、どのような戦略、手順が必要になるのでしょうか。実践に基づくノウハウを、メルカリの小林晋士さんが解説します。 2014年にSwiftが登場して以来、その利便性の高さから多くのiOSエンジニアがこの言語を用いるようになりました。それに伴い、Objective-Cで書かれたアプリケーションをSwiftに移行する企業も増えています。フリマアプリ「メルカリ」の開発・運営で知られる株式会社メルカリも、そのひとつです。稿では、TOPLOG株式会社と株式会社メルカリの2社でObjective-CからSwiftへの移行を経験した小林晋士さんに、移行にあたり策定すべき戦略とポイントについて解説していただきました。 なぜSwiftで作るの

    Objective-CからSwiftへ、4つの移行ポイント~メルカリの実践例から最適な手法を学ぶ - エンジニアHub|Webエンジニアのキャリアを考える!
  • はてなブックマーク - Swiftのエラーハンドリングはなぜ最先端なのか - Qiita

    ブックマークしました ここにツイート内容が記載されます https://b.hatena.ne.jp/URLはspanで囲んでください Twitterで共有

    はてなブックマーク - Swiftのエラーハンドリングはなぜ最先端なのか - Qiita
  • What’s New in Swift4.2 まとめ - Qiita

    Swift4.2で新しく追加されたものをざっくりまとめました。これからSwift4.2対応するプロジェクトなどがある時に参考程度になれば良いかなと思います。 実施環境 Conditional conformances SE-0143 みなさんSwift4.1で大喜びしたstruct, enum, classへの条件付きプロトコル適合(ある条件下の時のみプロトコルに準拠させる方法)ですが、下記のような動的なキャストやチェックを行うことはできませんでした。Swift4.2ではその実装が完了し、条件付きプロトコル適合が完成したみたいです。 // Swift4.1 protocol Bachelor { func givesRose() } extension Array: Bachelor where Element: Bachelor { func givesRose() { forEach

    What’s New in Swift4.2 まとめ - Qiita
  • ObjC, Swiftが混在している環境で使える小技など - Qiita

    ex-mixi Advent Calendar 2017 17日目の記事になります。 株式会社ミクシィには2009年に新卒で入社し、2014年の2月に転職しました。 同期は私含めて10人でしたが、転職したり、起業したり、ミクシィに出戻ったり、海外で生活してまた日に帰ってきていたりとそれぞれ元気にやっているようで何よりです。 私の近況としては転職後、子供が生まれて現在3歳です。来年の頭にもう1人生まれる予定です。 子供を育てるのは大変ですが、日々の成長が著しく人間ってスゲー!と感じる日々を送っています。 つい先日も出張で3日ほど家を空けていたのですが帰宅後の翌朝に子供と話すと、最後に話した時よりも流暢にお話出来る様になっていて感動しました。 現職ではiOSアプリの開発やiOSアプリ向けのCI環境のメンテナンスなどをしています。 残念なことに他の記事の様なエモいこと1が思いつかなかったのでO

    ObjC, Swiftが混在している環境で使える小技など - Qiita
  • Swift 4.1+ - LINE ENGINEERING

    こんにちは、AIプラットフォームClova開発チームのezuraです。この記事はLINE Advent Calendar 2017の14日目の記事です。 みなさん、今年のSwiftマイグレーション祭りは無事に終わりましたか。例年よりも穏やかなエラーを味わえたのではないでしょうか。 さて、マイグレーションといえば、みなさんの行ったマイグレーションは「普通の」マイグレーションですか?それとも「スーパー」マイグレーションですか? ここでいう「スーパーマイグレーション」とは、エラー・警告部分を修正するだけでなく、Swiftの改善によって効率的に書けるようになった部分の変更を含めたマイグレーションです。 スーパーマイグレーションの対象箇所はエラー等が出ない部分も含むため、いざマイグレーションを始めると見つけにくいですよね。効率良く移行するには、今のうちから、新しいバージョンに移行しやすいような設計や

    Swift 4.1+ - LINE ENGINEERING
  • 【小ネタ】Swift で Objective-C 側用の API を指定する仕方 - Qiita

    class SomeClass: NSObject { var id: String? func updateID(from dictionary: [String: String]) { // self.id = ... } } これらは Swift で呼び出す場合は someClass.id や someClass.updateID(from: someDictionary) で呼び出せるので何も困ることはないです。 ところが Obj-C がまだ混在しているプロジェクトの場合、これらはそのまま Obj-C で呼び出すと:

    【小ネタ】Swift で Objective-C 側用の API を指定する仕方 - Qiita
  • 【Swift4】iOSアプリ開発で使える(使いたい)Swiftライブラリー - Qiita

    iOSアプリ開発で(自分が)使えるなあ、使いたいなあと思ったライブラリーをリストアップします。Swiftのみとして、Objective-Cは載せていません。 Reactive Extensions RxSwift Combine Frameworkの登場で自分にとってのRxSwiftは終焉を迎えそうです AppleがWWDC19で発表したCombine Frameworkは、私がアーキテクチャー上最も重要だと考えるRxSwiftの主機能(Publish/Subscribeによる)Observer(パターン)を完全に置き換えます。 RxはReactive Extensionsの略です。もともとはC#が発祥ですが、javaを始めとしてswiftにも実装されています。swiftには独自の拡張として、RxCocoaがあり、iOSのUIKitReactive Extensionsのパーツとして使う

    【Swift4】iOSアプリ開発で使える(使いたい)Swiftライブラリー - Qiita
  • どうしてその機能/仕様はSwiftにないのか - Qiita

    この記事は Swift Advent Calendar 2017 の 3 日目の記事です。 記事では、よく提案されるけれど採用されなかった仕様とその理由、そして、そこから読み取れる Swift の設計方針を紹介します。 主なソースはapple/swift-evolution 内の Commonly Rejected Changes とswift-evolution のメーリングリストのログです。 リジェクトされた提案 Array の範囲外にアクセスした際に nil を返す 前提 Swift では配列(Array)の範囲外に添え字でアクセスすると実行時エラーになります。 リジェクト理由 理由は 2 点挙げられています。 1. 範囲外アクセスはロジックエラーである 「subscript は入力に前提条件があり、それが満たされていない場合の回復処理を動的にさせるべきではない」という考えのようで

    どうしてその機能/仕様はSwiftにないのか - Qiita
  • Swiftとイニシャライザ - Qiita

    はじめに Swiftの型(クラス、構造体、列挙体)とイニシャライザの関係を整理します。 以下のキーワードがモヤっとしている方におすすめです。 Failable Initilizer|失敗可能イニシャライザ Default Initializer|既定イニシャライザ Memberwise Initilaizer|全項目イニシャライザ Designated Initializer|指定イニシャライザ Convenience Initializer|簡易イニシャライザ Required Initializer|必須イニシャライザ イニシャライザとは 型(クラス、構造体、列挙体)のインスタンスを初期化(initialize)する特殊なメソッドのこと Apple公式リファレンス|Initialization イニシャライザの記法 通常のメソッドの記法に近いですが、イニシャライザは特殊なメソッドのため

    Swiftとイニシャライザ - Qiita
  • なぜ多くの開発者が今なお Swift よりも Objective-C を好むのか - Frasco

    iOS SDK がアナウンスされてから数年間、アプリ開発ゴールドラッシュの恩恵を得ようと、開発者たちは Objective-C の世界に群がっていました。しかしその時代は去りました。Swift が我々の前に現れて3年以上、それは古い同種の言語を主役の座から押しやりました。 Objective-C - かつてはアプリ開発の世界で人気急上昇のスター的存在でしたが - は、Apple の開発環境の中では2級の扱いになっていきました。そうです、それは時おり WWDC にて1枚か2枚のスライドに引っ張り出されることはあるかもしれませんが、カンファレンスの大部分は Swift に関してです。AppleSwift教育を推進しており、主要な言語の機能はまず Swift に対応するようになっています。 しかし、まだ Objective-C を使ってるなら、あなたは一人ではありません。たくさんの開発

    なぜ多くの開発者が今なお Swift よりも Objective-C を好むのか - Frasco
  • やさしいSwift単体テスト~テスト可能なクラス設計・後編~ - Qiita

    概要 前編: テスト対象と、テストが書きづらいコードはなぜ書きづらいのかを説明します。 やさしいSwift単体テスト~テスト可能なクラス設計・前編~ 後編(この記事): テストが書きづらいコードを書きやすいコードへ変更する方法、実際のテストコードを説明します。 テストが書けない/書きづらいコードの原因と回避策 前編のまとめから話を続けます。 クラス外の値を内部で利用している場合 テストを行うための値を準備できない クラス外の値 = どんなものが返ってくるか分からない = テストできない → テスト時のみ、返ってくる値を固定値にする(= 返ってくる値が明確) ことで回避します。 テスト失敗時に、原因がクラス内/外どちらなのか明確にできない クラス外の値 = どんな実装になっているかわからない = テスト失敗時に原因が明確にできない → クラス外とのやりとりはProtocolを通すことで、実際

    やさしいSwift単体テスト~テスト可能なクラス設計・後編~ - Qiita
  • Swift の文字列の長さ - Qiita

    length プロパティが無い!? たいていのプログラミング言語の文字列には length というプロパティやメンバ関数があって文字列の長さを取得できます。ところが驚くことに Swift の文字列には length プロパティがありません。Objective-C 由来の NSString にだってあるのにこれはどういうことでしょう? これは真面目に向き合うと、とても複雑な Unicode に Swift が真面目に向き合っていることに起因します。 Unicode 昔々、コンピュータは地域ごとに、酷いとメーカーごとに異なる文字コードを使っていました。これでは地域やメーカーを超えた文章ファイルのやりとりは色々と面倒なことになります。また、欧米の文字は 1 文字 1 バイトなのに対し日をはじめとした東アジアの文字は 1 文字 2 バイトで表すことが多く文字列処理が煩雑という問題もありました。こ

    Swift の文字列の長さ - Qiita
  • トレタのiPadアプリをSwift 3 対応しました - トレタ開発者ブログ

    iOSエンジニアの高(@y_koh)です。 この度トレタではiPadアプリのSwift 3対応を行いました。どんな感じで進めたのかと、ハマったところなど共有できればなと思います。 対応自体は去年末には終えていましたが、年が明けて1/10にリリースしました。 年末は飲店さま繁忙期のため、トレタではこの時期のアプリアップデートは控えています。例年このタイミングでリファクタリングやKaizenタスクなどを行っています。今回はSwift 3対応をメインに行いました。 先日サーバサイドもRailsを4.2にバージョンアップしています。言語やフレームワークのバージョンアップは機能改善に直接つながるものではないので後回しにしがちですが、将来的に負債になってしまうだけなので出来る限り時間を作って適宜アップデートするようにしています。 今回のSwift 3対応については、昨年のpotatotips#35で

    トレタのiPadアプリをSwift 3 対応しました - トレタ開発者ブログ
  • 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 で発表した際にも参考文献にしまし

    Swiftのエラー4分類が素晴らしすぎるのでみんなに知ってほしい - Qiita
  • HTTP Request in Swift 3.0 - Qiita

    思いの外、昔書いたHTTP Request in Swift 2.0が閲覧されているので、続編としてSwift 3.0版を書いた。一部のクラス名からPrefix(NS)が取り除かれたり、プロパティ名がLower Camel Caseになったりと、個人的にコードがすっきり見えるようになり嬉しく感じた。 Request.swift //: Playground - noun: a place where people can play import Foundation class Request { let session: URLSession = URLSession.shared // GET METHOD func get(url: URL, completionHandler: @escaping (Data?, URLResponse?, Error?) -> Void) { v

    HTTP Request in Swift 3.0 - Qiita
  • Swift.org

    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

    Swift.org
  • Swift 3.0 Coding Standard - Qiita

    About this Standard このドキュメントは Swift でのコーディングを効率よく行うために作成したもので、以下の項目を方針としています。 プログラマによる記述のブレが少ないこと コードの意図が明確であること 可読性をできるだけ落とさずに、少ない記述量でコーディングできること このドキュメント自体の読みやすさ、把握しやすさが保たれること なお原則として、Xcode上でエラーになる、または警告が出る書き方については記述しません。 Gratitude ドキュメントの作成にあたり、複数の他社様規約を参考にさせていただきました。 参考にさせていただいた規約については項番 14. に記載しています。 この場を借りて、お礼申しあげます。 Basic Policy 省略できるものは基省略する 極端に理解が困難になる場合を除き、記述が少ないことを優先する 1. Naming 1.1. 役

    Swift 3.0 Coding Standard - Qiita
  • [Swift]他言語使用者のためのSwift入門知識まとめ - Qiita

    iOSアプリ開発に着手しようとし、Swiftを勉強し始めました。今まで触れてきた言語と共通する部分がありながらも、異なる要素もそれなりに含まれているなという印象です。そういった言語間の違いがあらわれそうなところを調べながらまとめてみました。 この記事ではいきなり書けることを目標とするのではなく、これをおさえておけば、なんとなくソースが読めるかも、というレベルを目指しています。概要をまとめただけで、ややこしい文法の詳細は他のページや記事に任せるようにしています。 みなさんが使われている言語によっては「これは他の言語にも共通じゃないか」と思われることもあるかもしれませんが、ご容赦ください。 ※バージョンはSwift3.1を想定 おすすめリンク 良いページがあれば随時更新します。個人的に公式ドキュメントを読めばだいたいなんとかなりそう。 Swift公式ドキュメント ここを読んでおけば間違いない。

    [Swift]他言語使用者のためのSwift入門知識まとめ - Qiita