よくある横スワイプで移動できるタブデザイン。 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つのパターンに分けて構成をまとめます。 以下では基本的にフォルダ名のみ記載します。 フォルダ名のみだと把握しにくいと判断した
また、人それぞれ見解が多少異なると思うので、同じタイミングであろうとも色々な方が書かれてみるのも面白い題材かなとも思っています( ´・‿・`) それではiOSアプリ開発に必要な要素ごとにつらつらと書いていきます。それぞれ語りすぎるとボリュームが増えすぎるので、あえてなるべく浅めに書いていきます🐶 高性能なMacマシンを確保まず、技術的なこと抜きに一定以上の性能のMacマシンを用意するのが良いです。取っ掛かりの勉強目的などならともかく、中規模以上のアプリを作る場合低スペックマシンでは著しく非効率です。 大体以下のようなイメージで、これ未満だと早めにマシン変えた方が幸せになれると思っています。 2–3年以内に買った20万円以上程度のMacBook Pro: 許容範囲iMac 5K: 良い感じiMac Pro: 一般的なiOSアプリ開発ではオーバースペック気味でコスパは微妙かも🤔会社で、交渉
結論 小手先で楽をするためのボトムアップな設計は後々苦労する 継承を使った差分プログラミングは長年運用していくと大変だ 人は楽な方に流れるので、Baseクラスで解決すべきでない問題をBaseクラスで解決して後で困る はじめに この文章は2015年1月のpotatotips13で発表するネタ用のメモに書いてました。 実際に発表した内容を含む様子は下記のページにまとめています。 http://curiosity.co.jp/potatotips13/ 会場で質問されたりツイートの様子を見てて気づいたのですが、BaseViewControllerを使いたくないという"この文章"と同意の意見は、比較的経験のあるおじさんたちの意見であって、若い人からするとなぜBaseViewControllerを使ってはいけないように言われるのかについて具体例を聞きたがる傾向が強いです。 また、不必要に自分が気に入
概要 思ったよりバズったので、いくつか加筆修正しました 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
とりあえずThe Swift Programming Language読んで、実際に自分で少し書いてみた感想。 諸事情でAppleにiOSデベロッパーとしてお布施していたので Xcode6beta落として少し書いてみた。プロジェクトスケルトンをswiftで生成できるので、そのコードを眺めたりしていた。 ファーストインプレッション Immutable脳の人が設計したっぽい。 スクリプト言語っぽい構文に、型注釈。これはGoとシンタックス上の設計思想が似ているんだと思う。 基本的にImmutableな設計でありながら、オブジェクト指向を採用しており、Scalaっぽいマルチパラダイム感がある。Scalaの人は好きになりそう。 型推論のおかげで動的型付け言語触ってきた人にも抵抗がない感じになってる。推論のおかげで静的型付け言語が動的型っぽくみえるのはHaskellとかOCaml方面の雰囲気。 LLV
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く