kumamotone’s blog

iOS/Android アプリエンジニアです https://twitter.com/kumamo_tone

potatotips #45 に参加しました (iOSブログまとめ)

potatotips #45iOSブログまとめ枠で参加させていただきましたのブログです。

f:id:kumamotone:20171128234024j:plain

今回の会場はリクルートマーケティングパートナーズ さんのオフィスです。

f:id:kumamotone:20171128234113j:plain

溢れ出す親切さ。飲み物なども個人的にありがたいバランスでしたーありがとうございます。

以下発表内容です。間違いや気になるところなどあればご指摘ください。埋まっていない資料は公開されたのを見つけ次第反映します。

swagger-codegenから眺めるSwift4 / d_date さん

speakerdeck.com

SwaggerではAPIの仕様をYAMLで管理できる。 swagger-codegen を使って YAML 書いて CircleCI にぶち込んでクライアントとサーバーサイドのコード両方生成したい気持ちがある。

そんなswagger-codegenはSwift4に絶賛対応中。

絶賛対応中ということは壊れているということ。

運用でカバーでも良いが壊れてるなら直せば良いんですよ。→直した。手っ取り早く草を生やしたい人にオススメです。

感想

流れが速すぎて笑いました。関モバで予習していてよかった(?)

コード生成による自動化、壊れていたら直すの精神などもう1から10までエンジニアとして見習うべきだなぁと思いました。

XcodeGenでxcodeprojを卒業する / nonchalant さん

speakerdeck.com

xcodeprojっていうのがありますよね。ただのディレクトリなんだが、ターゲットの情報だとか、ビルド設定だとか、色々持ってる。

ところでxcodeprojってコンフリクトするよね。つらい。gitで管理したくない。

github.com

そこでXcodegen。説明によるとこれを使えばgitの管理下から外せるので、二度とxcodeprojでコンフリクトは起こらないとしている。

どういうものかというと、 project.yml を入力に xcodegen を叩けば xcodeproj にできる。Swift製。

github.com

サンプルリポジトリを作ってみました。見てみるとわかるが、project.ymlのほうが可動性がある。短いし。特にdependencesのあたりとかわかりやすい。

RIP *.xcodeproj :pray:

感想

良さそう。が、なかなかここらへん自分でいじるのは勇気要りそう‥‥

あと層ごとにフレームワークに分けるのも普通によさそう。

stackviewでボタンつくった話 / sun54907 さん

speakerdeck.com

仕事でボタン作った。要件はよくある感じのやつで、以下のようなパターンがある。

  • タイトル(文字だけ)
  • タイトルの左に画像がある
  • タイトル右の画像がある
  • 内容に合わせた幅になったり、固定幅になったりする

github.com

これを公開した。 工夫した点として、Stackviewで Android の wrap_content っぽい挙動を実現している。

内容が多くなれば広がるし、 isHidden を設定すればトルツメできるので便利。

感想

iOS8 切れない状況でConstraintをごにょごにょやってトルツメとかやったことあるので、ここらへんの便利さは分かりみがある。

全体的にUI周り不親切感あるなぁという気持ちが爆発している。普通にこのくらいUIButtonでいい感じに出来てほしいし、StackViewに乗せると自動で幅が変わってすごいっすよ〜みたいなの確かにすごいんだけど悲しくなってくる。未来の子どもたちはここらへんまったく意識せずにも実装できる世の中に生まれてほしい。

Codable Tips集 / tattn さん

speakerdeck.com

Codableは型のエンコードとデコードをサポートする機能。Codableは大人気でめっちゃ記事があるのでそれを参照してください。

CodableはSwift3.2で使えます

まずはこれを伝えたい。CodableはSwift4の機能だと思っている人たくさんいるが、CodableはSwift3.2で使えます。

複数行の文字数リテラルとかKeyPathリテラルクロージャ型KVOとかすげぇ便利なやつもSwift3.2で使える。Swift4が使えない事情があっても大丈夫。

Upper Camel Caseをkeyにするプロトコル

本題。APIがKeyがUpperCamelな名前でデータを返してきて、クライアントではふつうにlowerCamelで受けたいケースがある。こういうときはふつう CodingKeysを書いて対応すると思うけどtypoすると通らなくなるし冗長で嫌。

CodingKeyにはkey名とプロパティ名の対応をカスタマイズできるI/Fが用意されていて、これをカスタマイズすれば型で変換を表現できるしtypoしない。

Upper Camel Caseをkeyにするプロトコルを紹介したが、これ以外にもSnakeCaseCodingKey とか作れば snake_case でもなんとかなる。文字列処理のパフォーマンスがきになる場合は変換後のkey名をキャッシュしたりSourceryを使ってコード生成したりすると解決できる。

String を任意の型で受け取れる型を作る

ときどきあって、本当はサーバーで直してほしいのだが、Int で返してほしいValueがStringで返ってくるのをどうにかしたい。

Stringを別の型に変換する魔法の箱をつくると解決できる。

デコードの失敗を許容する型を作る

配列やURLをデコードしたいが、たまにデコードできない値が入るということがある。そんなときもデコードの失敗を許容する型を作って解決できる。

残り

時間がないので資料を見てください

github.com

感想

今日から使いたいTipsが多くガッツリ使いたい気持ちになった。

パフォーマンス改善の部分、具体的にどうなるのか気になる。

Human Interface Guidelinesを参考にApp Storeを見てみた / NatsukiIdota さん

App StoreのTodayは見出し+カードという構成。たぶん見出しはHIGの Clarity. に当たり、 角は Diference. に当たるんではないかと思う。

App Storeは、全体としてみると一見HIGにそっていないように見えるが、1つ1つを見れば、HIGに沿っているという感じがする。

感想

たしかにHIGに標準アプリを参考にするということはあると思うけど、App Storeは特に参考になりそうな部分かもなと思った。

最近あんまり意識してなかったのでざっくり眺めなおしても良さそう。

できるだけUI系のライブラリを用いないアニメーションを盛り込んだサンプル実装まとめ / sakmt さん

www.slideshare.net

仕事でUI書くこと多くて、AWAを参考にして以下の記事を書いた。

qiita.com

UIScrollViewの中にContainerViewが2つあり、画面を左右のスワイプあるいはタブのタップでに切り替わるみたいなUI。MVP使ったりした。

アニメーションや動きを伴う実装部分を色々DIYしてみたが、自分で作ってみると意外と趣があって良い。

感想

Qiitaが力作で、後でゆっくり読みたいと思った。

ScrollViewにコンテナがいくつかとTableViewがあって〜みたいな実装はよくあると思うので自分もDIYして知見溜めていきたい。

UIStackViewとかで快適UI作り事例紹介 / sakmt さん

UIStackView良いですよね。人間が美しく感じる形、同じ大きさ同じ形同じ間隔、それってUIStackViewじゃん、となる。

後半ライブコーディング。SnapKit+Kotlinのapply関数っぽいエクステンションの組み合わせを使って、カルーセルを作ってみる。

UIStackViewとScrollViewがあれば、5分たらずでよくあるカルーセルができる!

感想

ライブコーディングがかっこよかった。

SnapKit+Kotlinのapply関数っぽいやつの組み合わせ、気持ちよさそうなのでやってみたい。

ContainerViewController作成の流れ / vespid さん

github.com

ContainerViewControllerでTwitterプロフィール画面のUIを作ってみる。

制約:

  • スクロールできる
  • スクロールによってヘッダが縮む

とか。

素朴に作ると、UIの要件と、自然なUIの両立ができないときがある。たとえばcontentSizeが小さい場合に画面切り替えでヘッダがおかしくなるとか。こういう場合には落とし所を見つける必要がある。

今日は時間の関係上抽象的な話になりますが、再利用性を高めながらいい感じに作っていきましょう。

感想

動画キャプチャをいい感じに載せてくださっていてスライドがわかりやすくかっこよかった。

たしかにこういう画面割りとよくあって、作ってみると理解深まって良さそう。

ReactNative+GraphQLでなんか作る / yukiasai さん

speakerdeck.com

GraphQLはFacebookが頑張ってるやつで、Scheme,Query, Mutation, Subscription というのがある。

SchemaはSchema。Get に相当するのが Query、 POSTがMutationみたいな感じだと思ってもらっても良い。Subscriptionは購読できる。なんか値が変わったときに通知してくれる。イケてる。

ReactNativeとGraphQLでChatを作ってみる。 react-apollo を使って Reduxは使わない。簡単!

感想

たしかに既存のよくあるAPIのつらみみたいなのが解決できそうな雰囲気があって、MutationやSubscriptionのあたり、すごく良さそうだなという気持ちになった。

サンプルコード後で拝見したい。

さいごに

f:id:kumamotone:20171129001349j:plain

全体的にUIの話が多いな〜と感じた。京橋だけどあんまりリアクティブエクステンションの話は出てこなかった。

懇親会でUI周りのつらみとかXcodeのここがバグっている、みたいな話ができてよかった。

明日使えるTipsとしては @IBDesignable 付けてるとなんかやたらIBがビルドをはじめてバッテリを持っていかれるときがあり、そういうときは 「Editor > Automatically Refresh Views」 のチェックを外すと一旦走らなくなる、だとか、

あと悲しい感じの話としては「全体選択してctrl+Iでフォーマットできるけどカーソルがファイル末尾にぶっ飛ぶ」「Editor > Fix All in Scopeを選択すると赤丸のポチポチでFixしまくらなくて良くて便利だったがXcode9でなんかグレイアウトして使えなくなった」「Editor > Refactor to Storyboard...は便利そうだけど一回使ったらぶっ壊れた」などがありみなさま各々苦労してらっしゃるな〜という感じだった。

毎回頑張って聞いてまとめているとどんどん短い時間で理解できる力は増している感じはする。がAndroid枠の方も結構気になる発表とかあったのに聞き漏らしちゃってるのであとで資料を拝見したい。

最近毎回ブログ書いてるんですが毎回ブログ書いてると「ブログ枠空いてますよ」とか教えてくれたりする人とかもいて最高。基本的に良いことしか無いので今後もやっていきたい。