API-19 と 20+ 間を Material Design でどう跨いでいけばいいのか

Introduction_-_Material_design_-_Google_design_guidelines

とりあえず公式をみてみる.

* テーマの設定

1. Holoのようなこれまでのテーマを継承して定義する
res/values/style.xml

2. 同じ名前でテーマをMaterialテーマを継承して定義する.
res/values-v21/style.xml

3. これらのテーマを AndroidManifest.xmlでアプリに設定する.

* レイアウトの設定

21+向けのディレクトリをそれぞれ準備する
res/layout-v21/
res/values-v21/

API-21+ に対しては, 各リソースファイルを「*-v21」として新規に作成するという考え方.

これまでのUIデザインを変化させずに, 新しく OS 5.0+ の端末に対してのみマテリアルなデザインを表示させる.

その後にこう書いてる.

* サポートライブラリをセット

Theme.AppCompat を使えば いくつかのウィジェットは MaterialDesign のものを使える.

dependencies {
compile 'com.android.support:appcompat-v7:21.0.+'
compile 'com.android.support:cardview-v7:21.0.+'
compile 'com.android.support:recyclerview-v7:21.0.+'
}

EditText
Spinner
CheckBox
RadioButton
SwitchCompat
CheckedTextView
RecyclerView
CardView
Palette

完全ではないもののいくつかのウィジェットは appcompat-v7 で対応できる.

Lollipopを載せた端末の拡散具合や人気を考えると, OS4.x系端末でのマテリアルデザイン表示をしないと「マテリアルデザインに対応します(しました)」とうたいづらい.

よほどUIが凝ったアプリで無い限り, この appcompat-v7 ウィジェットを使って, これまで(API-19まで)のテーマに適用する, まずは.

/res/values/styles.xml

...
<style name="AppTheme" parent="Theme.AppCompat.Light.NoActionBar">
...

とこれまでのテーマの親にもつ.

このあと, 微調整を行い, API-19までのUIをマテリアルなかんじに仕上げていき, そのあと *-v21 のリソースを触りながら, 気にせず Lollipop端末に向けてのマテリアル化を進めていく.

と, そんな順序が王道ではないかな...

Maintaining Compatibility | Android Developers

Android 5.0 (Lollipop) MaterialDesign を構成するGoogle発UI系サンプル動画 40個くらい

すべては, 以下にあるやつ今現在最新のサンプルUI系をLollipopで動かす.

Google_Samples

Google Samples

AndroidStudio の ImportSample のプレビューが表示されないので並べて置くと何かと便利かななどと思い.

AndroidStudio

パーツやふるまいの名前が分かればそれで良かったのでYouTubeのGIF書き出しでやろうかと思いましたが, 一般公開間近の非公開ステータス.

GIF_Beta_sign_up

Nexus6でやってます.

こんな感じで40個くらい.

以下から順不同で.

続きを読む >>

でかすぎる Google Play Services が 6.5.87 で分割された件

Androidアプリでメソッド数が65536を超える場合は少し手間が掛かっていました.

Androidでメソッド数が65536を超えた時の対処方法 - Qiita

GoogleAnalyticsやGoogleMapなどを利用できるライブラリ com.google.android.gms:play-services ですが、実は使っている機能は1つか2つということが多いのではないでしょうか。
com.googleは18513個もメソッドがあるので、これを節約するだけでかなりメソッドの数が減ります。

このよく言われている「com.google.android.gms:play-services」がでかすぎという話.

必要なものだけピックアップして使えるようになったようです.

Setting_Up_Google_Play_Services___Android_Developers

Setting Up Google Play Services | Android Developers

自動で, com.google.android.gms:play-services-base:6.5.87 が読み込まれたりするし, どれを使うべきなのかわかりづらいようなものもあるように思えたり.

あと, 公式ドキュメントや AndroidStudio の自動チェックで, 「推奨」から「非推奨」と言われ始めたバージョン記述「+」で書かれていたり.

compile 'com.google.android.gms:play-services:6.5.+'

compile 'com.google.android.gms:play-services-fitness:6.5.+'
compile 'com.google.android.gms:play-services-wearable:6.5.+'

これらの「+」記述は, 最新 Android Studio 1.0 でも警告される.

version

こう書いてるけど.

At the time of writing, the correct version to use is 6.5.87. As this is a very granular number, it will get updated quite quickly, so be sure the check the latest version when you are coding. Often people will use a ‘+’ to denote versions, such as 6.5.+ to use the latest 6.5 build. However, it’s typically discouraged to use a ‘+’ as it can lead to inconsistencies.

でも, やっぱり「+」は怖くないですか.

Google Play services and DEX method limits | Android Developers Blog

Android 5.0 SDK 対応はまず何をしたらいいか

デザインとかもあるけどまずはでとりあえず.

Android_5_0_Lollipop_の_SDK_と、新しい_Nexus_プレビュー版イメージを公開しました_-_Google_Developer_Japan_Blog

SDKをAPI21に更新.

Android_SDK_Manager

Project_Structure

...
android {
    compileSdkVersion 21
    buildToolsVersion "21.0.0"

    defaultConfig {
        ...
        targetSdkVersion 21
        ...
    }
...

NDKをr10cに更新.

Android_NDK___Android_Developers

ndk~$ chmod a+x android-ndk-r10c-darwin-x86_64.bin
ndk~$ ./android-ndk-r10c-darwin-x86_64.bin
...
Extracting  android-ndk-r10c/build/gmsl
Extracting  android-ndk-r10c/build/core
Extracting  android-ndk-r10c/build/awk
Extracting  android-ndk-r10c/build
Extracting  android-ndk-r10c

ndk~$ export PATH=$PATH:~/android-ndk-r10c

Android NDK | Android Developers

とりあえずこれくらいで.

Android 5.0 Lollipop の SDK と、新しい Nexus プレビュー版イメージを公開しました - Google Developer Japan Blog

gradle なら AndroidManifest.xml 内 <uses-sdk> が不要だった件

_uses-sdk____Android_Developers

Android Studio が警告なフキダシを出してる.

main_AndroidManifest

記述が2箇所あってきもちが悪かったのですが.

build.gradle

android {
    ...
    defaultConfig {
        minSdkVersion 9
        targetSdkVersion 19
    }
    ...
}

AndroidManifest.xml

<uses-sdk
    android:minSdkVersion="9"
    android:targetSdkVersion="19"/>

Android Studio の設定で「バージョン」の記述してるとこありすぎね?

で, AndroidManifest.xml側の記述は不要らしい.

Gradle overrides the manifest values, and I prefer to update build.gradle file rather than manifest. And probably this is the right way using Gradle. Gradle supports product flavours which can be controled via IDE and those product flavors can change many things in our Manifest like package name, version code, version name, target SDK and many other. Then by one click in Android Studio You can change many properties and generate another apk.

You can left the manifest as it is and do all configuration in build.gradle. You can safely remove

<uses-sdk></uses-sdk>

from manifest as well as version codes.

Android studio: why are minSdkVersion and targetSdkVersion specified both in AndroidManifest.xml and build.gradle? - Stack Overflow

Gradle が自動埋め込んでくれるっぽい.

apk化後, バラしてみてみると確認できます.

android-apktool - A tool for reverse engineering Android apk files - Google Project Hosting