タグ

ブックマーク / blog.ishkawa.org (5)

  • Storyboardとの付き合い方 2018

    Aug 12, 2018 少し前に、自分のStoryboardの使い方をツイートしたら割と反応があったので、改めてまとめてみようと思います。これまで何年かiOSアプリの開発をしてきて、Storyboardとの付き合い方は何度も変わりました。なので、今回紹介するものはあくまで2018年現在のもので、来年には変わっているかもしれません。 説明のイメージを掴みやすくするため、画面の例を用意しました。左が編集時のStoryboardで、右が実行時のiOSシミュレーターです。具体的なトピックが出た時に、この例を説明に使うことがあります。 記事の最後にこれが動作するサンプルコードも用意しましたので、興味があればどうぞ。 Storyboardを使う目的 以下の2つを重視して、Storyboardを選択しています。 動作確認に掛かる時間を短縮する 成果物の構造を把握しやすくする ただし、Storyboar

    Storyboardとの付き合い方 2018
  • Swiftで書いたコマンドラインツールをHomebrewでインストールできるようにする

    Feb 18, 2015 toolという名前のコマンドラインツールをつくるとします。 Makefile ビルドターゲットのINSTALL_PATHは/usr/local/binとします。 DSTROOT=/tmp/tool.dst prefix_install: xcodebuild install -scheme tool DSTROOT=$(DSTROOT) mkdir -p $(PREFIX)/bin cp -f $(DSTROOT)/usr/local/bin/tool $(PREFIX)/bin/ class Tool < Formula homepage "https://github.com/yourname/tool" version "0.0.1" sha1 "0123456789abcdef0123456789abcdef01234567" url "https://g

    Swiftで書いたコマンドラインツールをHomebrewでインストールできるようにする
  • 堅牢で使いやすいAPIクライアントをSwiftで実装したい

    Feb 17, 2015 昨年末にはてなの@cockscombさんと@yashiganiさんがつくっていたSwiftでenumとジェネリクスを活用したかっこいいAPIクライアントを書くが 面白かったので、これを参考にしつつSwiftらしい堅牢で使いやすいAPIクライアントを考えてみました。 目標としたのは以下の3つの条件を満たすことです。 レスポンスはモデルオブジェクトとして受け取る (便利) 個々のリクエスト/レスポンスの定義は1箇所で済ます (変更しやすくしたい) リクエストオブジェクトはAPIクライアントから分離させたい 例にはGitHub System Status APIを使用しています。 サンプルコードはGitHubに上がっています。 APIクライアントのインターフェース APIの呼び出し用に用意されたメソッドはcallのみで、callに渡すリクエストによってレスポンスの型が変

    堅牢で使いやすいAPIクライアントをSwiftで実装したい
  • Circle CIでiOSアプリのリリース作業を自動化

    Jan 7, 2015 ※ 現在(2015/01/07)Circle CIのiOSビルドはベータとなっているため、利用するにはサポートへの連絡が必要です。 できること GitHubへのコミット毎に以下のタスクを実行します。 ユニットテストの実行 ipaの作成 ipaのバリデーション CrittercismにdSYMをアップロード Circle CIにテストレポートを出力 iTunes Connectにipaをアップロード これらの作業を自動化すると、masterブランチにgit pushするだけでテストが通ったアプリがiTunes Connectに登録され、 TestFlight(新)からダウンロードできるようになり、そのままApp Storeに申請することまで出来るようになります。 Circle CIのメリット 無料(1 container) 見た目がきれい private reposi

    Circle CIでiOSアプリのリリース作業を自動化
  • xib/storyboardとの付き合い方について - blog.ishkawa.org

    アプリが大きくなるとstoryboardの小回りの利かなさに泣きたくなることがあると思います。 そうした反動からすべてのUIをコードで実装しているiOS開発者も少なくないと思います。 自分は全部storyboardにして痛い目にあってから、全部コードにしてまた痛い目に遭い、 結局コードとxibとstoryboardを上手く使い分けるのが良いという結論に達しました。 最近、やり方が定まってきてストレスを感じなくなってきたので方法をまとめます。 これから書くことは個人の見解ですが、自分のやり方を決める上では無駄にならないと思います。 使い分け方と理由 基方針: 以下に挙げる条件にマッチする場合除いて、コードで実装を行います。 xibを使う条件 viewの複雑度が高い場合(subviewが2,3個以上の場合)にはxibを使います。 xibを利用する理由は以下のような退屈なコードをたくさ

  • 1