macOSアプリのCI事情8 – 一連の流れをコマンドで実行してみる

pkgファイルをiTunes Connectにアップロードするところまでをコマンドラインから実行できるようになったら、一度流れを整理しておこう。 “macOSアプリのCI事情8 – 一連の流れをコマンドで実行してみる”の続きを読む

macOSアプリのCI事情7 – deliverでpkgファイルをiTunes Connectにアップロードする

iTunes Connectにアップロード可能なpkgファイルをコマンドラインから作れるようになったら、今度はそのpkgファイルをコマンドラインからiTunes Connectにアップロードしてみよう。 “macOSアプリのCI事情7 – deliverでpkgファイルをiTunes Connectにアップロードする”の続きを読む

macOSアプリのCI事情6 – xcarchiveからpkgファイルを作る

今度は、作成したxcarchiveからpkgファイルを作る。Apple純正ツールを使ってできるのはこのステップまで。その先は難易度が上がるので、まずはここまでの流れを確実なものにしておく。 “macOSアプリのCI事情6 – xcarchiveからpkgファイルを作る”の続きを読む

macOSアプリのCI事情5 – xcodebuildでxcarchiveを作る

前のポストでは、プロジェクト/ワークスペースからipaを作り、iTunes Connectにアップロードするところまでの流れを確認した。このポスト以降では、この流れを一つずつスクリプトに置き換えていく。 “macOSアプリのCI事情5 – xcodebuildでxcarchiveを作る”の続きを読む

macOSアプリのCI事情4 – ビルドからアップロードまでの流れ

テストに成功したので、今度はリリース用のビルドをxcodebuildを使って作成し、App Storeにアップロードするところまでをスクリプト化したい。しかし、この手順は設定が多く、サードパーティツールが必要になり、仕様変更などがあった場合に都度確認・調整が必要になることもある難所だ。スクリプト化をする前に、XcodeとApplication Loaderを使って、申請までの流れの確認をしておこう。 “macOSアプリのCI事情4 – ビルドからアップロードまでの流れ”の続きを読む

macOSアプリのCI事情3 – xcodebuildを使ってテストする

macアプリのCIを構築していく上で、xcodebuildの基本的な使い方を押さえておく必要がある。

xcodebuildはXcodeをインストールすると使えるようになるコマンドで、プロジェクトのビルドやテストの実行などに使われる。JenkinsのXcodeプラグインや、fastlaneのgymなどのサードパーティ製のビルド補助ツールも、基本的には内部的にはxcodebuildを使っている。macOSアプリ、iOSアプリ、tvOSアプリなど、Xcodeが対応している各種プロジェクトは共通してxcodebuildを使ってビルド・テストできる。まずは、テストを実行してみよう。 “macOSアプリのCI事情3 – xcodebuildを使ってテストする”の続きを読む

macOSアプリのCI事情2 – 使うツール群とサービス

まず、macOSアプリのCIを実現する上で必要なツール・サービスについて。

macOSアプリのCIでは、主に下記のツール・サービスを使用していくことになる。あらかじめ、各ツールの役割・立ち位置について頭に入れておくと、色々と理解しやすくなり、思い通りに動かない時にも対応しやすくなる。 “macOSアプリのCI事情2 – 使うツール群とサービス”の続きを読む

macOSアプリのCI事情1 – 概要

デベロッパ・市場規模のせいか、iOSアプリのCI(継続的インテグレーション)に関する情報は簡単に見つかるが、macOSアプリやtvOSアプリのCIに関する情報はなかなか見つけにくい。長いこと苦戦してきたが、macOSアプリに関しては、ようやく良さげな解決策を見つけるところまで至ったので、ここに共有しておく。 “macOSアプリのCI事情1 – 概要”の続きを読む

AndroidのData Binding Libraryが便利だ

Android Plugin for Gradle 1.5.0-alpha1から使えるようになったData Binding Libraryが便利だ。

Data Binding Libraryを使うメリットはData Bindingの概念がもたらす本来的なメリット(宣言的プログラミングが可能になる)と、Data Binding Libraryが備えている便利な機能がもたらす副次的なメリット(諸々の箇所で実装が短くなる)があるが、その内容は下記の記事でとてもわかりやすくまとめられている。

http://angelolloqui.com/blog/35-Improving-your-Android-apps-with-Data-Bindings

Data Binding LibraryをButterKnifeの代替になる、と紹介している記事も多く見かけるが、実際に使ってみるとそれ以上の有り難みを多く感じる。

  1. 表現に関するより多くのコードをレイアウト(XML)側の記述だけで実現できる場面が増え、FragmentやActivityがすっきりする。
  2. 自然と宣言型プログラミングになり、プレゼンテーションに関する処理とそれ以外の処理がFragmentやActivityの中に混在する、といったようなケースが減る。宣言型プログラミングを強く意識しなくても、半自動的にそうなるし、誰が書いてもそのようになる、というのは良いことだ。

具体的な導入手順を説明している記事はすでに多く出ているので、それらを参照されたい。最後に、凡ミスも多いがAndroid Data Binding Libraryを導入してすぐの頃にはまってしまったミスを列挙しておく。

  1. プロパティに違う型のデータを渡してしまっていた
    1. ProgressBarのprogressには本来intを渡すべきだが、Data Objectからはfloatを渡していた
    2. TextViewに数値の値を表示する時には、Stringで指定する。intを渡すとstringsのリソースのIDとして処理されてしまう。
  2. Data ObjectにパブリックなGetterを定義していなかった
  3. Importのし忘れ
    1. android:visibilityをセットする場合にdataセクションに<import type=”android.view.View” />を定義していなかった

参考情報

  1. Data Bindingとアニメーションの組み合わせについて

Parse亡き後、我々はどこに向かえば良いのだろうか

2017年1月28日にParseがシャットダウンすることが発表された。残念ながら、BaaSを使う上で懸念される最も大きいリスク・デメリットが具現化される形になってしまった。Parseの何が良くなかったのか、今後BaaSがどうなっていくのかを考えたいところだが、終了までの期間が限られているため、Parseに依存しているプロジェクトをどうするかを考え始めなければいけない。

なお、このポストの内容は新しい動きがあり次第、適宜追記していく予定だ。 “Parse亡き後、我々はどこに向かえば良いのだろうか”の続きを読む