DEV Community: chuross

Androidでアプリの定数をBuildConfigではなくYamlから自動生成したい - Gradle Config Plugin

chuross — Mon, 27 Nov 2017 16:16:07 +0000

経緯

やりたかったこと

アプリケーションで使う定数的な値を一括管理したい
ProductFlavorごとにAPIの向き先など設定情報を変えたい
それらを管理するためのクラスを自分で作りたくない

BuildConfigを使わない理由

build.gradleが肥大化する
定数の記述が多少面倒
- いちいち型を記述しないといけないので面倒
- すべての値を文字列で埋め込むのも好みでない

Gradle Config Plugin

https://github.com/tmiyamon/gradle-config

特徴

ProductFlavorごとにYamlを定義できる
Yamlから値に参照するためのクラスが自動生成される
- 値の型はYamlの記述内容に合わせて自動的に解決してくれる

導入

buildscriptにプラグインを追加

buildscript {
  repositories {
    maven {
      url "https://plugins.gradle.org/m2/"
    }
  }
  dependencies {
    classpath "gradle.plugin.com.tmiyamon:gradle-config:0.2.1"
  }
}

プラグインを適用する

アプリのプロジェクトがあるbuild.gradleに以下を追記
(app/build.config)

apply plugin: 'com.tmiyamon.config'

使い方

コンフィグファイルを作る

アプリのプロジェクトルートにconfigディレクトリを追加する

ファイル名は以下が対応している

config/default.yml
config/default_secret.yml
config/${productFlavor}.yml
config/${productFlavor}_secret.yml
config/${buildType}.yml
config/${buildType}_secret.yml

ProductFlavorに応じてこれらのファイルが適宜読み込まれて1つのクラスが生成される

*_seciet.ymlのファイルは秘匿情報を入れることができる。使う場合はバージョン管理下に置かないように.gitignoreに入れておくこと

Yamlに項目を埋めていく

あとはYamlを作っていくだけ

size: 2
server: google.com
section:
  size: 3
  servers: [ {name: yahoo.com}, {name: amazon.com} ]

このように記述するとビルド時にSettingsという名前のクラスが生成される

生成されたクラスはこのように値を参照できるようになっている

Settings.size   // => 2
Settings.server // => google.com
Settings.section.size // => 3
Settings.section.servers.get(0).name // => yahoo.com
Settings.section.servers.get(1).name // => amazon.com

便利！！！😃

応用

kotlinの拡張を使って定数と引数を組み合わせた文字列を作る

例えばベースのURLだけYamlに書いておいて、パスの組み合わせをkotlinの拡張で実現する

url:
  base: https://hoge.com

続いてkotlin側でプロパティを拡張する

fun Settings.Url.getDetail(id: String) = "$base/detail/$id"

こんな感じでアプリ上で参照できるようになる

Settings.url.getDetail("1") // => https://hoge.com/detail/1

あとがき

設定情報は何かと細かく組み合わせたり、たくさん記述したりする部分なので、管理しやすくしたい

このプラグインはそうした部分の要求を叶えてくれるよいアプローチに思えた

Twitterのような画像をフリックすると画面を閉じれるライブラリを作った - FlingLayout

chuross — Thu, 23 Nov 2017 15:11:36 +0000

今回の成果物

FlingLayout

https://github.com/chuross/flinglayout

特徴

Twitterの画像とこで使われてるように、上下にフリック操作すると画面を閉じれる挙動をレイアウトに内包するだけで実現できる。

導入

jitpackをrepositoryに追加する

repositories {
    maven { url "https://jitpack.io" }
}

dependenciesにライブラリを追加する

dependencies {
    compile 'com.github.chuross:flinglayout:x.x.x'
}

使い方

サンプルプロジェクトではPhotoViewを使って実現している。

具体的にどう使えばTwitterみたいにできるんじゃみたいなの知りたい場合はここ見てね

https://github.com/chuross/flinglayout/tree/master/app

XMLにレイアウトを記述する

これだけで挙動自体は完成
内包できるViewは1つだけなので注意

<com.github.chuross.flinglayout.FlingLayout
    android:layout_width="match_parent"
    android:layout_height="wrap_content">

    <!-- something view parent -->

</com.github.chuross.flinglayout.FlingLayout>

ドラッグ操作を制御する

FlingLatoutにドラッグを無効にするフラグを用意しているので適宜セットする

val flingLayout = findViewById<FlingLayout>(R.id.flinglayout)
flingLayout.isDragEnabled = false

サンプルプロジェクトではPhotoViewのスケールを見てフラグを必要に応じてセットしている。(拡大時はFlingLayoutはドラッグ操作を受け付けないようにしている)

Dismissのリスナーを拾って画面を閉じる

いつものDismiss用のリスナーセットできるようにしてあるので、それを使えばおｋ

val flingLayout = findViewById<FlingLayout>(R.id.flinglayout)
flingLayout.dismissListener = { /** something your code **/ }

XML属性一覧

key	type	description	etc
fl_isDragEnabled	boolean	ドラッグの有効 / 無効
fl_isDismissEnabled	boolean	Dismissの有効 / 無効	無効にした場合はスワイプしても元の位置に戻る

ライセンス

Copyright 2017 chuross

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

   http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.

あとがき

内部的にはViewDragHelperを使用しているので、実装はいたってシンプルに作れた。

需要はありそうな気がしてたけど、ざっと検索した感じ引っかからなかったり、メンテされてなくてビルドできなかったりしてたので自分で作った。

中規模のSwaggerファイルをいい感じに管理するために薄いフレームワーク作った - swglow

chuross — Thu, 23 Nov 2017 03:58:28 +0000

今回の成果物

Swaglow

https://github.com/chuross/swaglow

特長

特定のルールに基づいたディレクトリ階層から、SwaggerのYamlファイルを結合して出力する。

SwaggerのYaml運用に最低限の秩序をもたらす
- フレームワークが生成したディレクトリに沿ってファイルを追加していくので、ファイル管理をルール化しやすい
ディレクトリ階層や名前からpathsやdefinitionsの定義を自動生成
- 最終的なYamlがどう生成されるのか意識する必要は無い
- Yamlファイルを個別に管理していくことに集中できる

経緯

Swaggerで扱うYaml(or Json)は最終的には1つのファイルとして扱わないといけないが、何も考えずにそれに乗っかるとファイルが肥大化して管理しづらくなる。

そのためYamlを分割して結合するのが良く、npmにも既にそれを実現するライブラリも豊富にある。しかし、そのどれもが$refを使う方式で、これだとファイルをどの単位で分割するかのルールが無いので、もうちょっと仕組み的に縛りたかった。

導入

$ npm install -g swaglow

使い方

初期化

まずはプロジェクトのルートディレクトリでinitコマンドを実行

$ swaglow init -o [output path]

するとこのようなディレクトリが出力先に生成される

swaglow root // -oで指定したパスのルート
- swaglow.json // 専用のコンフィグファイル
- paths // APIのエンドポイントを管理するディレクトリ
- definitions // モデルを管理するディレクトリ
- parameters // APIリクエストで使う共通のパラメータを管理するディレクトリ

開発

簡単な例としてREADME.mdにある内容をリンク貼っとく
GitHub - chuross/swaglow: simple swagger framework

より実践的な例だと、このライブラリを使ってQiita API用のSwaggerを作るリポジトリを用意したのでそちらを確認してほしい

swagger-toolsなどを用いて出力したyamlをvalidateしたりiOS Clientにビルドする仕組みを入れてCIで回すようにしている

GitHub - chuross/qiita-swagger-yaml: swagger yaml file for Qiita

ビルド

$ swaglow build -o [output path]

出力先に結合されたSwagger Yamlファイルが生成される

ライセンス

MIT

あとがき

今回紹介したように手運用でSwaggerのYamlを生成するのは基本的にはオススメしない。

追従しないとサーバー側の実装と乖離する可能性がある(メンテコストの増加)
Swagger Yaml職人が出る可能性がある(属人化)
- チーム全体で管理していく仕組み作りなどが必要になる

そういった意味では自社開発のAPIにリクエストを投げる場合であればメンテの効率を上げるためにサーバー側で書かれたコードから自動生成させるのが良いだろう。

では手運用は果たして意味が無いのかと言うと状況によってはそんなこともない。

例えばこのようなケースには使えると思われる

プロジェクトがスタートした直後でサーバー側の準備ができていない場合
- モックサーバーとして活用する
- 本格的な運用はサーバー側ができたらそっちでやるのが良さそう
別会社・別チームのプロダクトなどそもそもSwaggerの連携が難しい場合

このような感じでケース・バイ・ケースだと思うので、もし何らかの理由で手運用の管理が必要になった場合はこのフレームワークを使うと良いかもしれない。