Macのキーボード設定
MacのKey Remap
Mac(USキー)を買い換えた時にいつも自分のカスタムキーバインドの設定を忘れて右往左往するので、備忘録がてらに。
よく使うキーではあるが、デフォルトのバインドだと手がしんどいものが以下。
あまりトリッキーな設定はせず最小限で。
- Spotlight表示
- 英数、かな変換
必要な作業
- Caps Lock -> Command
- Left Command単体 -> 英数
- Right Command単体 -> かな
これで手が楽になる。
Karabiner-Elementを使う
https://pqrs.org/osx/karabiner/
Karabiner-ElementはMac OSのキーボード設定をカスタマイズできるソフトです。
ダウンロードして、インストールするとMacのToolbarにアイコンが表示されるようになります。
そこをクリックしてPreferenceをクリックすると以下の画面が開きます。
Simple Modifications
ここでは、Caps LockにLeft Commandを割り当てて、Spotlightを当てやすい状態にします。
Caps Lockをそこまで使うタイミングがないので、必要あれば、Shift押しながら大文字にします。
Complex Modifications
USキーで少し面倒なのが、英数・かなの切り替えです。
単体で
Left Command -> 英数
Right Command -> かな
にするためには、Complex Modificationsを利用する必要があります。
使い方は簡単ですが、
https://pqrs.org/osx/karabiner/complex_modifications/
をインストールする必要があります。
上記をインストールして、Complex Modificationsに追加して終わりです。
DroidKaigi 2018 振り返り
DroidKaigi 2018
Androidの1年に1回のイベントで、
Elastic Team Buildingというテーマで登壇しました。
今年は、運営メンバーとしても活動していたのですが、
本ブログでは自分が登壇して得たものについて書きました。
まずは、登壇資料です。
Elastic Leadershipというオライリーから出版されている本があるのですが、
そのフレームワークを元に振り返り、また実践してみたことです。
かなりオススメです。
この本には以下の部分に関しては全く言及していませんでしたが、
私はそこが本質的な部分だと思っています。
テクノロジーにより”不確実性”が高まった世の中において、
生き残る行動指針はやはり、”変化”すること。
さて、登壇したことは貴重な経験になりました。
メリットは色々ありましたが、自分の中では
- 人に伝えること
- 自分の考えを整理すること
に関して大きな飛躍がありました。
人に伝えること
DroidKaigiで登壇することは、5分のLTと比べると準備の量が変わります。
そのため、プレゼン資料を作った後に、同僚2人にプレゼンし、フィードバックをもらいました。
双方ともに最初は、ネガティブなものでした。
改善すればいいだけなので、全く気にしませんでしたが、
相手がどう受け取るかということは考えているつもりで、見えなくなりがちです。
つまり、自分は人に伝えるという部分のフィードバックを上手く回せていないのだなと感じました。
今後は、普段人に伝える場面がある際には、必ずフィードバックを回せるような仕組みを考えようと思いました。
自分の考えを整理すること
何より、プレゼン資料作成中はめちゃくちゃ苦しかったです。
Elastic Leadershipも含めリーダーシップ系の本のみならず、
アジャイル、スクラムなどの開発手法も含めもう一度、
深く理解しようと通読しました。
経験を通した具体と構造化された概念を結びつける作業でした。
自分の経験から得たものを再現性を高めて、自分または他人の違う経験に活かしたいですし。
色々な角度から物事を見て、チームビルディングに対しての思考が更に深まりました。
反省していること
他の現場で働く知人、友人の話を事前に聞いておくべきだったというところでした。
私は、他の現場で働いた経験がないので、それを見聞きするだけでも、より濃く、意味のある話が出来たなと思いました。
特に、自分がこの登壇でやりたかったことの一つが、
ソフトウェアのチーム開発に携わる人が、"現場で実践すること"を持ち帰ること
だったので、現場の課題意識をより知っておくためにもやるべきだったと反省しました。
総じて
短いスパンでのアウトプットサイクルとDroidKaigiのような長いスパンでのアウトプットサイクルを自分の中でより多く回せることができれば、自分も成長できるし、聞いてくれる人にもいい影響を与えられるので、もう少し頑張ってみようと思いました。
- 作者: Roy Osherove,島田浩二
- 出版社/メーカー: オライリージャパン
- 発売日: 2017/05/13
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (2件) を見る
Androidで自作ライブラリ公開
Androidでライブラリ作成
Androidにおいて、自分のカスタムライブラリを作成する際に、必要な手順をまとめました。
Androidで公開ライブラリを作成する際には、JCenterとMavenCentralというリモートレポジトリサービスが一般的です。
今回は、JCenterを利用したので、その方法を備忘録に残しておきます。
手順は以下。
1. ライブラリ作成
2. Bintrayにアカウント登録
3. ファイルをアップロード
以上です。
一度試すと簡単なので、ちょっとだけ詰まるところをメインで。
ゴール
まずは、ゴールを確認します。
普段色々なGiantsたちのライブラリを使う側としては、build.gradleに簡単に書きたいですね。
このような形で書くことをゴールにします。
dependencies{
implementation 'com.neonankiti:bison:1.0.0'
}
ライブラリ作成
自分が作りたいライブラリをまず作ってください。
Androidにおいては、IDEでmoduleだけ作成することが不可能なので、いつもの手順でアプリをまず作ります。
File -> New -> New Module
上記で以下のように表示されるので、Android Libraryを選んでください。
作成するとprojectに新しいLibraryが出来ます。
Bintrayにアカウント登録
Bintray - Download Center Automation & Distribution w. Private Repositories
上記BintrayでSign upしてください。Githubアカウントで連携できます。
自作ライブラリのアップロードには、以下のpluginを利用します。
GitHub - novoda/bintray-release: A helper for releasing from gradle up to bintray
build.gradleに依存性を記載し、gradleタスクでアップロードします。
その際にアカウント情報(ユーザー名、APIキー)が必要になります。
BintrayのAPIキーはTop -> Profile -> Edit -> API Keyというところにあります。
最終的な使い方は次に書きます。
ファイルをアップロード
登録とライブラリ作成が終われば、アップロードするための仕組みを構築しましょう。
まずは、project rootのbuild.gradleに以下のように書きます。
buildscript {
dependencies {
// バージョンは上記githubを確認してください。
classpath 'com.novoda:bintray-release:0.8.0'
}
}
次は作成したライブラリ側のbuild.gradleに以下を書きます。
apply plugin: 'com.novoda.bintray-release' publish { userOrg = 'neonankiti' groupId = 'com.neonankiti' artifactId = 'bison' publishVersion = '1.0.0' desc = 'to support bisons that were almosts extincted' website = 'https://github.com/neonankiti/bison' }
上記を記載した後にgradleタスクを実行するのですが、その前に上記のプロパティを少しだけ。
userOrgはbintaryで登録しているのであれば、それを記載しましょう。
groupIdには、ドメインを記載してください。com.company的なものです。
artifactIdはプロジェクト名を記載してください。ライブラリの名前でいいと思います。
publishVersionは当たり前ですが、バージョン名です。
websiteは何でもいいですが、githubで管理することが多いと思います。
注意: repoNameは設定しなくてもいいです。デフォルトでmavenがセットされます。
その代わり自分でセットしない場合は、Bintrayのサイト上で、mavenというレポジトリを自身で作成してください。
(自分でセットしてもBintaryのサイト上では必要ですが笑)
その他のConfigurationは以下をみてください。
Configuration of the publish closure · novoda/bintray-release Wiki · GitHub
ここまで出来ればあとは仕上げです。
GradleコマンドでBintrayにライブラリをアップロードしてあげましょう。
./gradlew clean build bintrayUpload -PbintrayUser=YOUR_USER_NAME -PbintrayKey=YOUR_API_KEY -PdryRun=false
ただ、kotlinを利用していると、Javadocのタスク(AndroidJavadocs)で以下のエラーが発生します。
javadoc: エラー - パッケージ名 "ファイル名.kt" は不正です
JavadocタスクがKotlinファイルを処理しようとして失敗している？ようです。
以下のように、javadocタスクからKotlinファイルを取り除くタスクをgradleに追加しましょう。(project rootのbuild.gradle)
allprojects {
tasks.withType(Javadoc) {
excludes = ['**/*.kt']
}
}
上記でアップロードが成功するはずです。
アップロードが完了すれば、Bintrayのページを確認してみてください。
右下にあるAdd to JCenterを押して、次のページに遷移し申請してください。
コメントを適当に記載して、Sendを押してください。
数時間で反映されるそうです。(私も今申請中)
許可されて、JCenterに登録されると、
dependencies{
implementation 'com.neonankiti:bison:1.0.0'
}
ができるはず。
また報告します。
<追記> 2018/1/2
出来ました。
dependencies{
implementation 'YOUR_GROUP_ID:YOUR_ARTIFACT_ID:YOUR_PUBLISH_VERSION'
}
です。
Androidで複数Product Flavorを利用する
ゴール
複数のビルド生成ファイルを作成(端末インストール)する。
上記を実現する際に問題が生じることがある。
問題
ビルド時のアウトプットファイル(.apk)の名前が重複してしまい
複数アプリを同時にインストールできなくなってしまうことがある。
根本的な原因は以下。
applicationIdが同一
Content Providerのauthoritiesが同一
解決方法
1. applicationId
build.gradleファイル内のapplicationIdを別々にしたら解決。
free {
applicationId "com.bison.sampleapp.free"
}
paid {
applicationId "com.bison.sampleapp.paid"
}
ただ、Flavorをわけているので、applicationId変更しないことはないかな笑
問題はBuild Typeをrelease, debugに置き換える際に発生します。
Build TypeのプロパティにapplicationIdSuffixがあるので、それ使いましょう。
buildTypes{
release{
}
debug{
applicationIdSuffix ".debug"
}
}
これでdebugビルド後のみ生成ファイルが
applicationId + applicationIdSuffix
になるのでコンフリクトが起きなくなります。
2. Content Provider
Content Providerを利用する場合、同じように異なるFlavorでビルドを行った際にエラーが生じます。
<provider
android:name=".SampleContentProvider"
android:authorities="com.bison.sampleapp.provider"
android:exported="false" />
AndroidManifest.xml内のauthoritiesにユニークな識別子を与える必要あり。
そのためには、authoritiesを動的に変更できるようにします。
authoritiesはアプリのパッケージ名に揃えるのが通例です。
<provider
android:name=".SampleContentProvider"
android:authorities="${applicationId}.provider"
android:exported="false" />
applicationIdはbuild.gradleから動的に自動で割り当てられる変数です。 (もしくは、build.gradle内でManifestHolderを利用してください。)
以上。
Gradle徹底入門 次世代ビルドツールによる自動化基盤の構築
- 作者: 綿引琢磨,須江信洋,林政利,今井勝信
- 出版社/メーカー: 翔泳社
- 発売日: 2014/11/07
- メディア: Kindle版
- この商品を含むブログ (2件) を見る
Migration to Android Plugin for 3.0
Android Studio 3.0のリリース
Android Studio 3.0がリリースされて数ヶ月経ちました。
ようやくつい最近少し触ったので、メモ程度に。
公式ドキュメントにGradle Pluginの移行についてのHow toがあるので、英語みてわかる人はこっち見た方が早いです。
いっつも公式ドキュメントの英語が瞬時に理解できないのは、自分の英語力なのか、技術力なのか、はたまた両方なのかって感じですね。
こういう人にオススメ
Android Studio 3.0に移行したい、かつ以下のような状態が一つでもある。
- プロジェクト内に複数モジュールがある
- ビルドを速くしたい
- Product FlavorとBuild Typeの組分けが必要
- Content Providerをビルドバリアントに対応したい。
Gradle Pluginの更新(導入)
プラグインのバージョン3.0はGradleバージョン4.1未満では動きません。
まずは、gradle-wrapper.properties、project rootのbuild.gradleにそれぞれ以下を追加
distributionUrl=https\://services.gradle.org/distributions/gradle-4.1-all.zip
buildscript {
repositories {
// You need to add the following repository to download the new plugin.
google()
}
dependencies {
classpath 'com.android.tools.build:gradle:3.0.1'
}
}
Configure Build Variants
新しい概念がいくつかあります。
が、自分に一旦必要だったFlavor Dimension, Fallbackだけ書きます。
上記を考えるために以下のような具体例を考えましょう。
1. Flavorを複数持つ
- 日本版とグローバル版のアプリを同じワンソースで開発している。
2. Build Typeを複数持つ
- 本番・開発・QA配信環境をそれぞれ分ける。
このような状況は普通にAndroidアプリを開発していれば、特に違和感ないと思います。
そして、以前までのGradle Pluginのバージョンでは、少し問題がありました。
Build Type(であるべき)のプロパティがFlavor依存になっていることです。 (あるべきっていうのは少し誤解があるかもしれません。)
今までのGradle Pluginの問題点は、minSdkVersion, applicationId, manifestHolderなどの属性を変更するために、
新しいFlavorを追加する必要があり、結果的にFlavorの数が激増してしまうことです。
上記のような問題を解決するのが、Flavor DimensionとFallbackです。
Flavor Dimension
まずは、コードで。
android {
// Step1
flavorDimensions "applicationId", "minSdkVersion"
// Step2
productFlavors {
minApi18 {
// Step3
dimension "minSdkVersion"
// Step4
minSdkVersion 24
}
minApi15 {
dimension "minSdkVersion"
minSdkVersion 15
}
us {
dimension "applicationId"
applicationId "com.bison.sampleapp"
}
japan {
dimension "applicationId"
applicationId "jp.co.bison.sampleapp"
}
}
}
Dimension(applicationIdとminSdkVersion)を追加することで、各Flavorは必ず、Dimensionの属性を指定することが必須になりました。
なので、Dimensionを指定すれば、必ずその該当moduleの各Flavorにはその属性を機械的に指定してあげてください。
これにより、FlavorのDimensionの組み合わせが可能になりました。
上記の場合だと、ビルドバリアントのoutputとして、usMinApi15YourBuildType や japanMinApi24YourBuildType などが可能になりました。
手順をさくっと説明すると
Step1: Product Flavorのプロパティに依存する属性(applicationId, minSdkVersion)を決める。
Step2: 上記より分ける項目を追加(us, japan, minApi15, minApi18)
Step3: 各Flavorにdimensionを追加。
Step4: プロパティを追加
サンプルコードもあげてます。
Fallback
Fallbackという概念があります。
戻すとか元の状態にするみたいな意味です。
これはmoduleごとのBuild Typeの冗長性を排除します。
app moduleでは、Build Typeとしてrelease, staging, debugと3種類必要だけど、他のmoduleにおいては、
releaseとdebug(もしくは一つ)で十分なことがあったりします。
以前までは、app moduleに以下のように書く必要がありました。
// app build.gradle
dependencies {
// appのdebugコンパイル時には、bison moduleのusDebugを参照する
debugCompile project(path: ':bison', configuration: 'usDebug')
}
appのmodule側で直接bisonのmoduleのビルドバリアントを指定する形です。
また、app側からusMinApi15DebugCompileなどと、より詳細に指定することも可能です。
が、めちゃくちゃ数が増えるので面倒くさいです。
これからはこう書きましょう。
dependencies{
implementation project(':bison')
}
Gradleはapp moduleのビルドバリアントを、他の依存しているmoduleにも適用しようとします。
ただ、他のmoduleに関しては、特にProduct Flavorを区別する必要がなく(us, japan不要)、
Build Type(release, staging, debug)のみ変更したい場合があります。
その場合はProduct Flavorには何も書かなければ問題なしです。
もちろん書けば、そのFlavorが適用されます。(各moduleでもDimensionは必須です。)
さらに言うと、stagingも必要ない場合があります。(debugとreleaseだけでよい場合)
その場合は、appのbuild.gradleに以下のように書いてください。
buildTypes {
staging{
// appからの他のmoduleにstagingのBuild Typeを探しに行く場合、
// 他のmoduleにはstagingが存在しないので、debugを適用してあげる。
matchingFallbacks = ['debug']
}
}
おまけ
上記試した際に、ContentProviderの重複エラーが生じることがありますが、
それはAndroidで複数Product Flavorを利用するに書いています。
以上です。
