2018年8月 8日 (水)

古いプロジェクトを最新のASで開こうとした話

1. ことのはじまり

先日 Google Play から「2018年11月1日までに公開しているすべてのアプリの compileSdkVersion を API 26以上にしてちょうだい」とのメールが。詳しくは今後の Google Play でのアプリのセキュリティおよびパフォーマンスの改善についてというGoogle Developersのブログ記事を参照。

Oh、これ、対応しないと Ban されるやつだわ....。
ということで、GitHubにあげているソースをcloneして改修に入ることに。

2. 最新のAndroid Studioで読めるようにするには

「読めるようにするには」というよりもむしろ、「Gradleビルドが正常終了するようにするには」というほうが正しい。
いまのAndroidはgradleプロジェクトだけど、 build.gradle の設定はざっくりこんな感じ。

minSdkVersion 15
compileSdkVersion 19
targetSdkVersion 19
Gradle Wrapper 1.10
Android Gradle plugin 0.9
buildToolsVersion 19.0.3

注目すべきは Android Gradle plugin のバージョンで、どうやらこのアプリ、Android Studio 1.0がリリースされる前から開発していたようだw

2-1. Gradle Wrapper をアップグレードする

ここから先はASを使わず、エディタとコンソールで対応する。

Android の Gradle プロジェクトは、そのプラグインと Gradle そのもののバージョンに縛りがあり、これは公式で公開されている。

Android Studio 3.x には Gradle 4.4がすでにバンドルされているので、4.4以上にするのだが、たまたまシステムに Gradle 4.6 をセットアップしていたのでこっちの wrapper タスクを利用することにした。

また、 Gradle を 4.6 にするので、 Android Gradle plugin は 3.0.0 以降にする必要があるのだが、公式のAndroid Plugin for Gradle 3.0.0 への移行にあるとおり Google の Maven リポジトリを使う必要がある。
なので、ルートの build.gradle 中の buildscript に Google の Maven リポジトリを追加して Gradle プラグイン 3.1.x を使う設定を書く。

buildscript {
  repositories {
    google()  // 追加、Google Maven Repository を使う設定
    jcenter()
  }
  dependencies {
    classpath 'com.android.tools.build:gradle:3.1.4'
  }
}

また、appcompat-v7なども同様に Google Maven リポジトリからの取得になるので、dependencies ブロックにも設定を入れる。
Maven リポジトリの参照先をモジュールごとに変える理由はないので、ルートの build.gradleallprojects ブロックを定義する。

allprojects {
  repositories {
    google()
    jcenter()
    mavenCentral()  // jcenterがあれば普通は大丈夫だが、状況に応じて入れる
  }
}

ここまでできたら wrapper タスクを実行する。

$ gradle wrapper

正常終了したら、 Gradle Wrapper のバージョンは4.6になっているはず。

2-2. Android アプリモジュールの調整

今度は app/build.gradle をいじる。
buildToolsVersion を 27.0.3 以降にすればいいのだが、メジャーバージョンが targetSdkVersion の値と一致していないと警告の対象となるので、 targetSdkVersion は自然と同じ値になる。
また、これに引きずられて compileSdkVersionappcompat-v7 のバージョンも27以降にする必要がある。

今回は API 28 にするので、以下のとおりに変更。

android {
  compileSdkVersion 28
  buildToolsVersion '28.0.2'
  defaultConfig {
    targetSdkVersion 28
  }
}
dependencies {
  implementation 'com.android.support:appcompat-v7:28.0.0-rc01'
}

また、プラグインの仕様変更で、最初の行に書く apply plugin も書き換える必要がある。

apply plugin: 'com.android.application'

この状態で、 assembleDebug タスクが正常終了すれば、ASにインポートしてもビルドが通るはずである。

| | コメント (0) | トラックバック (0)

2018年1月31日 (水)

買いました報告:Android アプリ設計パターン入門

なんとなーくアプリを作っている身としては、こういう本が出てくるのはありがたい。

Android アプリ設計パターン入門

Android アプリ設計パターン入門

  • 著者:日高 正博,小西裕介,藤原聖,吉岡 毅,今井 智章,
  • 製本版,電子版
  • PEAKSで購入する

| | コメント (0) | トラックバック (0)

2014年4月12日 (土)

AndroidAnnotationsを使ってみる 〜Android Studio編〜

0. イントロダクション

 以前、こんなエントリを書いていたけど、今度はAndroid Studioで同じことをしてみよう、というお話。
# ネタの更新に1年もかけているのはどうなんだ、という話は置いといて(汗)

1. Android Studioのプロジェクトに導入してみる

 Android Studioの場合、導入のキモはbuild.gradleに書くことがわかっていること、これに尽きる。

 一応、ライブラリ検索はMaven Central Repository Search EngineGradle, pleaseを使えばdependencyに書く内容はわかるんだけど、AndroidAnnotationsはその名のとおりアノテーションプロセッサ。
 なので、Gradle Android Pluginsにアノテーションプロセッサを理解させる必要がある。

 幸い前回のネタから1年経過している現在では、そのあたりの事情もよくなって来ていて、公式にもGradleプロジェクト向けの設定方法も書かれている。今回はこいつを元に、Android Studioで作ったプロジェクトに適用してみた。

  1. プロジェクトを作ったら、プロジェクトのルートにあるbuild.gradleをひらき、depondenciesにAndroid-APTを追加する。
  2. dependencies {
          classpath 'com.android.tools.build:gradle:0.9.+'
        // AndroidAnnotationsの使用宣言
        //   Android-APTプラグイン(依存)
        classpath 'com.neenbedankt.gradle.plugins:android-apt:1.2'
    }
  3. 次に、実際のJavaソースがあるモジュールディレクトリへ降り、そこのbuild.gradleにプラグイン適用とAndroidAnnotationsの依存設定を書く。
  4. apply plugin: 'android-apt'
    dependencies {
        compile fileTree(dir: 'libs', include: ['*.jar'])
        apt 'org.androidannotations:androidannotations:3.0.1'
        compile 'org.androidannotations:androidannotations:3.0.1'
    }
    
    apt {
        arguments {
            androidManifestFile variant.processResources.manifestFile
            resourcePackageName 'net.formula97.aaex.app'
        }
    }
  5. build.gradleを2つ編集し終えたら、プロジェクトのルートで ./gradlew build を実行してやると、依存設定に追加したプラグインたちがMaven Central Repositoryから落ちてきてビルドが通る(はず)。

 あとはアノテーションを使ってActivityを拡張し、AndroidManifest.xmlの設定をいじるだけで使えるようになっているはず。

 ちなみに、僕のGitHubにこの手順で作ったプロジェクトを上げておいたので、よろしかったらご参考にしてください。

 あ、いい忘れてたけど、signingConfigsブロックにある大文字の部分は環境変数で、こいつはそれぞれこんな意味を持っている。

DEBUG_KEYSTORE : デバッグ証明書ストアのパス
RELEASE_KEYSTORE : リリース証明書ストアのパス
RELEASE_KEYSTORE_PASSWORD : リリース証明書ストアのパスワード
RELEASE_KEY_ALIAS : リリース証明書のキーエイリアス
RELEASE_KEY_PASSWORD : リリース証明書のパスワード

 こいつらの設定をしていないと、ビルドが通らないのでご注意を。

| | コメント (0) | トラックバック (0)

2014年1月12日 (日)

Android Support Librariesを使う

0. イントロダクション

 Androidで新規プロジェクトを作ると、libs/以下にandroid-support-v4というライブラリが追加されるようになっているのは、ずいぶん前からの話。
 で、実はこれ、ちょっと前まで「Fragmentを2.xデバイスでも使えるようにするためのもの」くらいの認識でしかなかったことと、僕自身Fragmentの仕組みをよく理解できていないこともあって、まったく使ったことがなかった。

 ということなので、自分向けメモとしてちょっと書いてみる。

1. システム要件

 条件としては、 Android SDKを最新に更新しており、Extrasの下にある「Android Support Libraries」をインストールしていることである。

2. セットアップ

 実際のセットアップは、以下のとおりとした。
 元ネタはSupport Libraries Setup | Android Developersなのだが、ActionBarで標準添付リソースが使いたかったので、リソース付きでセットアップする手順としている。

  1. メニューのFile -> Importで、Existing Android Code into Workspaceを選ぶ。
  2. {SDKのディレクトリ}//extras/android/support/v7/appcompat/をインポートする。
  3. Finishを押してインポートを完了する。名称はわかれば何でもよいが、僕はデフォのandroid-support-v7-appcompatとしている。
  4. インポートしたライブラリプロジェクトのlibs/を開くと、android-support-v4.jarとandroid-support-v7-appcompat.jarの二つがあるはずなので、この両方を右クリックからBuild Path -> Add to Build Pathを選んでJava Build Pathに追加する。
    この操作で、ライブラリプロジェクトのReferenced LibrariesにJarファイルが二つ追加されているはずである。
  5. ライブラリプロジェクトを右クリックし、Build Path -> Configure Build Pathを開くと、プロジェクトのJava Build Path設定のOrder and Exportタブが開いているはずなので、設定を以下のとおりとする。
    • android-support-v4.jarとandroid-support-v7-appcompat.jarの両方に、チェックを入れる。
    • Android Dependenciesのチェックを外す
  6. この状態で[OK]を押すと、ライブラリプロジェクトがビルドされ、使用可能になる。

 あとは、こいつを使いたいAndroidプロジェクトのプロパティを開き、Android -> Libraryに先ほど追加したライブラリプロジェクトをAddで追加してやればよい。

3. 注意点

 作業中に、Androidプロジェクトに最初から存在するandroid-support-v4.jarと、v7-appcompatに含まれるandroid-support-v4.jarが一致しない、という事象が起きた。

 比較したところ、Androidプロジェクトのほうがファイルサイズが小さかったため、おそらく元のAndroidプロジェクトを作成した時期のリビジョンと、SDKの現在のリビジョンが異なる(プロジェクトのほうが古い)ためと思われる。

 とりあえず、Androidプロジェクトのほうのandroid-support-v4.jarをBuild Pathから除去した後、libs/にあるandroid-support-v4.jarを物理的に削除することで、これを回避した。

 なおこのライブラリプロジェクトは、API Level 7(=Android 2.1)以上のアプリケーションプロジェクトが対象なので、もしAndroidManifest.xmlのminSdkVersionが6以下の場合は、7に変更しておくこと。
 大勢にはほとんど影響はないだろうけど。
# いまどき、API Level 4(=Android 1.6)を新規にサポートする意味はないだろうし、API Level 8(=Android 2.2)以下のデバイスはほとんど駆逐されているだろうし....。

| | コメント (0) | トラックバック (0)

2013年7月 2日 (火)

Android Studioで苦労した話

0. イントロダクション

自宅の開発マシンをWindows 7 x64からWindows 8 x64に移行したんだけど、そこで案外苦労させられたのがAndroid Studio

いや~、まともに動くようになるまでここまで苦労するとは。
ということで、その時の体験を備忘録的に書き連ねていく。

1. Microsoftアカウントの表示名は、日本語を使わないこと

Windows 8はMicrosoftアカウントをログインに使用できることは周知の事実だが、ローカルアカウントがない状態でMicrosoftアカウントをログインに使うと、Windows 8は表示名の「名」でユーザープロファイル領域を作る。

普通なら、いまどきこんなことで問題になることはないんだけど、Android Studioでは「内蔵のSDKインストール先が見つからず、プロジェクトを作ってもリソース等が自動生成されない」という事象に見舞われた。どういうわけか。

なので、ユーザープロファイル領域のパスに全角文字が混ざっている場合は、ユーザープロファイル領域のパスを全角文字が混ざっていない場所に移動するか、Microsoftアカウントの設定を変えてユーザープロファイル自体を作り直す必要があった。

2. Androdi SDKのインストール先をパスに含めること

僕はEclipseをメインに使っていることもあり、Android SDKを別途インストールしているんだけど、adbコマンドをDOS窓で叩く場合があるので、Android SDKのインストール先の下にある、toolsとplatform-toolをパスに含めている。

で、Android Studioでは、Android SDKではインストール先の直下にもあるSDK Manager.exeとAVD Manager.exeがインストール先のsdk\tools\lib以下だけに置かれており、どういうわけかAndroid StudioのIDEからこいつが見えない。

仕方ないので、Android SDKのインストール先そのものをパスに加えたところ、見えるようになった。

3. そもそも、インストーラのデフォルトインストール先ではまともに動かないバージョンがある

「なんぞ?」と思われる方もおられるかと思うが、Windows 8ではUACがさらに強化されていて、UACの影響下にあるC:\Program Files (x86)以下にAndroid Studioをインストールしていると、インストール先につくられるキャッシュファイルがUACのおかげでロックされた状態になり、インストール完了後に改めて起動しなおそうとすると「キャッシュがロックされてるZ!」てなことで怒られてしまい、起動しなくなる。

回避方法はただ一つ、インストール先をUACの影響下にない場所に変えることだけなので、インストール先をデフォルトからC:\bin\Android以下に変更した。

ちなみにここ、いまは修正されているらしいが、実際に元に戻したことはないので未確認。

4. まとめ

僕はね、Android Studioにはとても期待しているんですよ、ええ。

なので早く使いこなせるようになりたいんですが、いかんせんアクが強すぎるのが玉に瑕。なんとかならんものかねぇ?

| | コメント (0) | トラックバック (0)

2013年5月19日 (日)

AndroidAnnotationsを使ってみる ~Eclipse導入編~

0. イントロダクション

 先日オープンセミナー2013@岡山に参加してきたんだけど、その懇親会LTで、@ryosms氏がAndroidAnnotationsについて触れていたのに触発されたのが、事の始まり。

 そもそもAndroidAnnotationsって何さ? という話なんだけど、Androidアプリのソースコードはとても冗長で、例えばボタンを押した時の処理を書こうと思うと、こんな感じになるのは周知のとおり。
# 匿名クラスを使った場合

Button btn = (Button) findViewById(R.id.button1);
btn.setOnClickListener(new OnClickListener() {
    public void onClick(View v) {
        // ボタンを押した時の処理を書く
    }
});

 Visualなんたらに慣れてる人とかだと、「なんじゃこれ」という感じになりそうだけど、これがAndoridの常識といえば常識。
 だけど、クリックイベントだけにフォーカスしたコードだけを書ければ素敵じゃない?

 AndroidAnnotationsは、この面倒で冗長なコードをコンパイル時に自動生成してくれる、ありがたいライブラリなわけです。

 てなわけで、導入してみるのです。

1. Eclipseのプロジェクトに導入してみる

 とりあえず、公式にあるやり方の日本語抄訳を載せる。

  1. まず、DownloadのページにあるDownload AndroidAnnotations 2.7.1から、AndroidAnnotationsのZipアーカイブをダウンロードして、適切な場所に展開する。
    これを展開すると、androidannotations-api-2.7.1.jarとandroidannotations-2.7.1.jarという二つのJarファイルと、その他もろもろのファイルが展開されているはず。
  2. 展開してできたJarのうち、androidannotations-api-2.7.1.jarをプロジェクトのlibsディレクトリに入れる。
  3. androidannotations-2.7.1.jarを、libsディレクトリではないどこかに入れる。
    名前は何でもいいんだけど、僕はfactoryというディレクトリを作って、そこに入れた。
  4. プロジェクトのプロパティを開き、その中のJava Compiler -> Annotation Processing を開いて、Enable annotation processingのチェックを入れる。
  5. Annotation Processingの下にあるFactory Pathを開き、androidannotations-2.7.1.jarを追加する。
  6. この状態でプロパティを確定すると、「プロジェクトをリビルドしろ」と言ってくるので、プロジェクトをリビルドする。
  7. プロパティの Java Build Path -> Libraries を開き、androidannotations-api-2.7.1.jarを追加する。
    ※追加されていない場合

 あとは、この状態でアノテーションを定義していけばよい。

2. 実際に書いてみる

 実際に、上のコードをAndroidAnnotationsで書いてみると、こう書ける。

@Click(R.id.button1)
public void button1_click() {
    // ボタンを押した時の処理
}

 ふむ、Visualなんたらみたいになったねw

 これで、findViewById()で見つけたリソースをキャストしてコールバックリスナーを定義する、あの面倒なコーディングともおさらばできそうです。

 Fragmentと一緒に使うと、コードの見通しがよくなっていいかもしれないけど、いかんせん僕がFragmentの使い方を理解できていないので当面はイベント周りのアノテーションから使っていくことになりそうだ。

| | コメント (0) | トラックバック (0)

2013年1月14日 (月)

Androidアプリ「ナンバーズ計算機」

「ナンバーズ計算機」というアプリを公開。

何をするものか、というと、ナンバーズ3とナンバーズ4の番号を計算するだけのアプリ。
なので、これといった特徴もないですが、こちらからどうぞ。

ちなみに、GitHubにソースをあげてますので、よろしかったら見てやってください。

| | コメント (0) | トラックバック (0)

2012年12月24日 (月)

「カー計簿」更新

「カー計簿」を更新しました。

「統計表示画面において、統計範囲を『すべての期間』とした場合、本来範囲外のはずの月を統計範囲として表示してしまうことについてのバグフィックスです。

保存されているデータには、影響はありません。

先ほどGoogle Playストアに更新版を公開したので、ストアに反映されるまでしばらくお待ちください。

| | コメント (0) | トラックバック (0)

2012年12月18日 (火)

アプリ長者とは

先日、僕が参加させていただいた勉強会の懇親会で、日本Androidの会 岡山支部長をされている@LuckOfWise氏の話を聞く機会があった。

この方、今までに70以上もAndroidアプリを公開してきたそうなのだが、話とは、「そこで得た収入について」という内容。

本人がぶっちゃけちゃったとはいえ、額はさすがに僕の口から言える話ではないのだが、はっきり言ってすごかった。
広告収入恐るべし。

ただ、単純に「出せばいい」というわけではないだろうし、お金が絡む以上、そこには「需要の掘り起こし」という作業もついて回る。

ということは、拙作の「カー計簿」のように「定期的に起動してくれるアプリ」の方が都合がいいことになるんだろうけど、こいつに広告画面を載せるつもりは毛頭ない。

正直、使う側からみれば、広告画面はウザイ。ので、入れるつもりはないです。

とはいえ、あの話は魅力的だったなぁ(´Д`)。

| | コメント (0) | トラックバック (0)

2011年4月19日 (火)

LISMOの突然死

我が愛機IS03がAndroid 2.2になったこともあり、以前はもっさり感バリバリだったLISMOを、せっかくだから使ってみよう、ということで、ここ最近ロードテストをしている。

で、巷で話題の「LISMOで音楽を再生していると再生が突然止まる」という現象、いわゆる「LISMO突然死」だが、それほど頻度は高くないものの、ぼくの環境でも何度か発生した。

「これは調べねば!」ということで、開発環境のEclipseまで持ち出して「その瞬間」をトラップできないか、とやってみたのだが....。状況を整理していて、ふと思いついたことがある。「Automatic Task Killer」の存在だ。

Androidにおける音楽再生手続きは、Activity(≒フォアグラウンド実行中のプログラム)がAudioサービスにデータを引き渡すことで行われ、制御がバックグラウンドサービスに移行することでスリープ中でも音楽が流れ続ける、という仕組みになっているのだが、親ActivityであるLISMO Playerをkillしてしまうと、戻り値を返すActivityがないのでそれにつられてAudioサービスが再生をやめる、という、よく考えてみれば至極当然のことだったという。

しかも「Automatic」というくらいである。スリープ復帰の際無視リストにないアプリは根こそぎkillしてくれるので、こちらとしては現象がよく理解出来ないまま「突然死しやがった、なんだよこれ」ってことになるわけで。

まぁ、自分だけで完結している話なら「ああ、納得」で済むところだったんだが、いかんせん早とちりしてトンチンカンなことをツイートしてしまい、僕が迷惑をかけてしまった人がいる。
一応「ごめんなさい」mentionは送ってみたが....。

まぁ、こういうのがネットデマの発端だったりするんだろうなぁ、反省。

| | コメント (0) | トラックバック (0)

より以前の記事一覧