よくある横スワイプで移動できるタブデザイン。 Androidは標準のUIライブラリに含まれていますが、iOSの場合は自作かライブラリを使うかのどちらかになります。 アニメアプリのアニマネ!ではいくつかのライブラリを比較した結果、RMPScrollingMenuBarControllerを採用しました。 当時の状況ではベストだと思っていたのですが、新しくとても良いライブラリを見つけました。 Xmartlabsというウルグアイの会社が作っています。 Githubのスターが2,231件(2016年3月現在)とかなりの人気ライブラリです。 アニマネで実装した時に見つけていればこちらを採用していたのに。。。 軽く触っただけですがこのライブラリは凄いと思ったので紹介してみます。 XLPagerTabStripの特徴 Swift製 活発に開発されている安心感(2016年3月現在) 豊富な表示方法 既存の
こんにちは、技術部モバイル基盤グループの茂呂(@slightair)です。 今回は、ちょっと地味ではありますが、クックパッドのiOSアプリ開発を支えているスクリプト群について書きたいと思います。 日々iOSアプリ開発を行うとすれば、Xcodeまたはその他のお気に入りのエディタでコードを書き、ビルドと実行を繰り返して開発を進め、アプリが完成したらサブミット、めでたくリリースという流れになると思います。 場合によってはこうした開発の所々をサポートするツールを使うこともあるでしょう。クックパッドでもいくつかのツールを使っていますし、場合によっては自作することもあります。 ツールを導入することで解決できることであればそれでよいですが、もうちょっと気の効いたことをして欲しい、リリースフローなど自分たちのアプリ開発の進め方の都合で発生する繰り返しタスクを省力化できないか、というような比較的小さな問題を
国内事業開発部 iOS エンジニアの三浦です。私は17年新卒で入社したのですが、それ以来複数の新規事業の開発に携わってきました。 現在開発中のアプリでは、バックエンドに Firebase を用いた開発を進めています。 この記事ではなぜ Firebase を使っているのかと、そこで得られた知見についてまとめようと思います。 なぜ Firebase みなさんご存知かと思いますが、Cookpad のレシピサービスでは主にバックエンドに AWS と Ruby on Rails が使われています。 なぜ新規事業ではその構成ではなく Firebase を使うのかということですが、以下のような理由があります。 基盤サービスが豊富 Firebase には RealtimeDatabase、FireStore といった Database を始めとして、CloudMessaging(Push通知基盤)、Aut
Sep 18, 2017 このところかなり忙しく、iOSDCでちゃんとしたことを話せるのか不安でしたが、なんとか無事に終わりました。あまり会場を盛り上げることができず、後半はしどろもどろで死にたくなりましたが、面白かったと言ってくれた方もそれなりにいたので少し安心しました。 DIは今回の話以外にも色々なことに挑戦していて、最初はデフォルト引数を使った手動のinitializer injectionから始めて、SwinjectやCleanseなどのライブラリを試してみたり、Cake Patternを模倣してみたりしていました。それらを通じて、自分が求めるDIのプラクティスは 依存の宣言とインスタンスの取得のためのコードが単純かつ十分に少ない コンパイル時に依存関係の解決が検証される というものだとわかりました。もしも「dependencyの宣言さえしておけば、あとはコンパイルエラーを直してい
はじめに ここ数年で注目を集めて続けているReactive Programmingですが、Swiftにもライブラリとして提供されていたり、実際にサービスにも多く導入されていることから、Reactiveのことからライブラリまで調べてみました。今回はじめてReactiveに入門したので何か指摘点等あれば気軽にコメント頂けると幸いです。 概念から学ぶ まずは、Reactiveの概念中心の内容になります。 Reactiveとは Reactive Application Reactive Programming Functional Reactive Programming RxSwift Reactive Extensions RxCocoa 初めにサンプルコードから学ぶを軽く見た方がイメージが湧きやすいかもしれないです。 Reactiveとは Reactiveというキーワードは特にエンジニアなら
Clean Architectureを採用しているとファイル数が膨大になってしまうため、イイ感じにグルーピングして管理したいですが、レイヤ単位で分けるか画面とそれ以外で分けるか悩むと思います。(悩みました🙋) 2,3の構成を試し、その中で一番イイ感じに運用できた構成を紹介します。 その前によく見られているであろうリポジトリ※ のディレクトリ構成をパターン分けしてみました。 ※「ios clean architecture」でググった際の結果とGitHub検索で出た上位結果 ディレクトリ構成のパターン 上記でさらっと挙げたように大きく2つのパターンがあると思います。 「レイヤ単位で分けているパターン」と「画面とその他で分けているパターン」です。 ここでは参考に上記の2つのパターンに分けて構成をまとめます。 以下では基本的にフォルダ名のみ記載します。 フォルダ名のみだと把握しにくいと判断した
高性能なMacマシンを確保まず、技術的なこと抜きに一定以上の性能のMacマシンを用意するのが良いです。取っ掛かりの勉強目的などならともかく、中規模以上のアプリを作る場合低スペックマシンでは著しく非効率です。 大体以下のようなイメージで、これ未満だと早めにマシン変えた方が幸せになれると思っています。 2–3年以内に買った20万円以上程度のMacBook Pro: 許容範囲iMac 5K: 良い感じiMac Pro: 一般的なiOSアプリ開発ではオーバースペック気味でコスパは微妙かも🤔会社で、交渉しても低スペック環境を強いられるのならば転職した方が良い気がしています🤔ちなみに転職ドラフトでSWHGという招待コードで登録するとお互いプロテインゲットできるので、気が向いたらお願いします( ´・‿・`) Continuous Integration(CI)環境次に、CI環境について触れます。CI
結論 小手先で楽をするためのボトムアップな設計は後々苦労する 継承を使った差分プログラミングは長年運用していくと大変だ 人は楽な方に流れるので、Baseクラスで解決すべきでない問題をBaseクラスで解決して後で困る はじめに この文章は2015年1月のpotatotips13で発表するネタ用のメモに書いてました。 実際に発表した内容を含む様子は下記のページにまとめています。 http://curiosity.co.jp/potatotips13/ 会場で質問されたりツイートの様子を見てて気づいたのですが、BaseViewControllerを使いたくないという"この文章"と同意の意見は、比較的経験のあるおじさんたちの意見であって、若い人からするとなぜBaseViewControllerを使ってはいけないように言われるのかについて具体例を聞きたがる傾向が強いです。 また、不必要に自分が気に入
WWDC 2015 で Swift 2.0 が発表されました。オープンソース化などのうれしいニュースでも盛り上がっていますが、言語仕様としては try, throw, catch が導入されるという大きな変更がありました。本投稿は、 The Swift Programming Language の新章 Error Handling を読み、多少のコードを書いた上での個人的な感想です。 結論から言うと、 try, catch の導入は良い変更だと思えないけど、 try, catch を導入する前提なら考え得る限りベストに近い仕様だった、って感じです。 よかったのは、 ErrorType は enum タイプセーフなエラー情報 エラー処理が強制されている(検査例外のような形) try! でエラーを無視できる あたりです。個人的には、 try, catch でなく Either 的なものを公式サ
概要 思ったよりバズったので、いくつか加筆修正しました beta3でArrayの型指定の方法が変わったなーと思って眺めていたら、もっと根本的な変化がありました。 SwiftのArrayがヤバイなどで話題になってたやつです。 公式ドキュメント The Swift Programming Language 変更点 Array in Swift has been completely redesigned to have full value semantics like Dictionary and String have always had in Swift. This resolves various mutability problems – now a 'let' array is completely immutable, and a 'var' array is complet
Objective-C特有の型だってもちろん使えます。 ターゲット2 コレクション型 Swiftでは基本となるコンテナクラスは今のところDictionaryとArrayのみという極めて貧弱極まりない環境です。 しかしその点Objective-C++なら、Objective-Cのコレクションクラスはもちろん、 状況に応じてC++のよく熟成された標準ライブラリに簡単に統合することが可能ですね。 例えば以下のように #import <Foundation/Foundation.h> #include <map> int main(int argc, const char * argv[]) { @autoreleasepool { struct CompareNSString { bool operator()(NSString * lhs, NSString *rhs)const { retu
とりあえずThe Swift Programming Language読んで、実際に自分で少し書いてみた感想。 諸事情でAppleにiOSデベロッパーとしてお布施していたので Xcode6beta落として少し書いてみた。プロジェクトスケルトンをswiftで生成できるので、そのコードを眺めたりしていた。 ファーストインプレッション Immutable脳の人が設計したっぽい。 スクリプト言語っぽい構文に、型注釈。これはGoとシンタックス上の設計思想が似ているんだと思う。 基本的にImmutableな設計でありながら、オブジェクト指向を採用しており、Scalaっぽいマルチパラダイム感がある。Scalaの人は好きになりそう。 型推論のおかげで動的型付け言語触ってきた人にも抵抗がない感じになってる。推論のおかげで静的型付け言語が動的型っぽくみえるのはHaskellとかOCaml方面の雰囲気。 LLV
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く