« 2014年12月 | トップページ | 2015年9月 »
ラウンチャーに表示される名前は、<intent-filter> の android:label に設定すれば良い、 という記事をいくつか見かけ、
そのとおりに実装したのですがなぜかうまくいかず、<activity> に設定したlabelが使用されてしまい悩んでいたのですが、どうもAPI21以降の不具合のようです。 既存のアプリに影響がある(後方互換性が崩れている)のがやっかいですね。どうもAndroid Studio上ではこれ以上の情報が出力されないようなので、エラーの原因がわかりません。Error:Execution failed for task ':app:preDexDebug'. > com.android.ide.common.process.ProcessException: org.gradle.process.internal.ExecException: Process 'command '/usr/lib/jvm/java-8-oracle/bin/java'' finished with non-zero exit value 1
$ gradle :app:preDexDebug
と打てばエラーがわかります。というエラー出力なんですが、これはJava8を使用してコンパイルするとclass -> dex変換ができない、って怒ってるわけですね。com.android.dx.cf.iface.ParseException: bad class file magic (cafebabe) or version (0034.0000) at com.android.dx.cf.direct.DirectClassFile.parse0(DirectClassFile.java:472) at com.android.dx.cf.direct.DirectClassFile.parse(DirectClassFile.java:406) at com.android.dx.cf.direct.DirectClassFile.parseToInterfacesIfNecessary(DirectClassFile.java:388) at com.android.dx.cf.direct.DirectClassFile.getMagic(DirectClassFile.java:251) at com.android.dx.command.dexer.Main.processClass(Main.java:704) at com.android.dx.command.dexer.Main.processFileBytes(Main.java:673) at com.android.dx.command.dexer.Main.access$300(Main.java:83) at com.android.dx.command.dexer.Main$1.processFileBytes(Main.java:602) at com.android.dx.cf.direct.ClassPathOpener.processArchive(ClassPathOpener.java:284) at com.android.dx.cf.direct.ClassPathOpener.processOne(ClassPathOpener.java:166) at com.android.dx.cf.direct.ClassPathOpener.process(ClassPathOpener.java:144) at com.android.dx.command.dexer.Main.processOne(Main.java:632) at com.android.dx.command.dexer.Main.processAllFiles(Main.java:510) at com.android.dx.command.dexer.Main.runMonoDex(Main.java:280) at com.android.dx.command.dexer.Main.run(Main.java:246) at com.android.dx.command.dexer.Main.main(Main.java:215) at com.android.dx.command.Main.main(Main.java:106) ...while parsing com/example/SomeThirdPartyClass.class 1 error; aborting
sourceCompatibility = JavaVersion.VERSION_1_7
targetCompatibility = JavaVersion.VERSION_1_7
なんかを追記してやればいいでしょう。
UNEXPECTED TOP-LEVEL EXCEPTION:
com.android.dex.DexException: Multiple dex files define L;
at com.android.dx.merge.DexMerger.readSortableTypes(DexMerger.java:596)
at com.android.dx.merge.DexMerger.getSortedTypes(DexMerger.java:554)
at com.android.dx.merge.DexMerger.mergeClassDefs(DexMerger.java:535)
at com.android.dx.merge.DexMerger.mergeDexes(DexMerger.java:171)
at com.android.dx.merge.DexMerger.merge(DexMerger.java:189)
at com.android.dx.command.dexer.Main.mergeLibraryDexBuffers(Main.java:454)
at com.android.dx.command.dexer.Main.runMonoDex(Main.java:303)
at com.android.dx.command.dexer.Main.run(Main.java:246)
at com.android.dx.command.dexer.Main.main(Main.java:215)
at com.android.dx.command.Main.main(Main.java:106)
:app:dexDebug FAILED
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':app:dexDebug'.
> com.android.ide.common.process.ProcessException: org.gradle.process.internal.ExecException: Process 'command '/usr/lib/jvm/java-8-oracle/bin/java'' finished with non-zero exit value 2
同一ライブラリのバージョン違いなどが指定してあるとこのエラーになりますね。
以前「ここが変だよ android.util.Log」
というエントリで、android.util.Log及びその仕様を引きずったslf4j-androidはちょっと使いづらいと書きました。
簡単に言うと、デバッグ目的でログを出すのに使うのだから、ログレベルを簡単に変えられるべきだがそうはなっていない、ということです。
で、できないならできるようにしちゃえ、ということで自分向けにslf4j-androidを書き換えましたので記録しておきます。
リソースファイルでログ出力レベルを決定できるようにしていますので、手軽に変更できるようになっています。
テストケースなどは一切書いていませんが、まあ、リリース版で使用するわけではないので…
名前はlogmouseです。logcatからの連想でつけてます。
$ git clone -b feat/logmouse/1.7.12 https://github.com/yukihane/slf4j.git
$ cd slf4j && mvn clean package
$ cd slf4j-android && mvn install
compile 'com.github.yukihane.slf4j:logmouse:0.0.1-SNAPSHOT'
設定はlogmouse.propertiesに記述します。 /app/src/main/assets にファイルを置いてください。
defaultLoglevelでデフォルトのログレベルを、log.タグ名で各タグのログレベルを設定できます
(この辺はSimpleLoggerに合わせました)。
ログレベル値はVERBOSE,DEBUG,INFO,WARN,ERRORのいずれかになります。VERBOSEの代わりにTRACEも使えます。
この辺はslf4jとandroid標準の兼ね合いで決めました(参考)。
あらかじめ書いておくと、実装する上で本質的な話ではないです。
もともとMVPパターンのモデルっていうのは、MVCパターンが言うところのモデルと同じ、つまり やはりお前らのMVCは間違っている
モデルとはアプリケーションの本質そのもの
とか、あるいはThe Model-View-Presenter (MVP) Pattern
model (both the business logic and the application data)
だと思うんですよ。一方で、Android界隈でMVPのモデルっていうと、 Architecting Android…The clean way? | Fernando Cejas にある図(クリックで拡大)
にあるようなPresentation Layerに属すもの、要はMVVMパターンで言うところのViewModel (ただしデータバインディング機構は必須ではない)か、あるいはその元ネタデータの入れ物のことを指してることが多いんじゃないかと。
ただ、冒頭に書いたことの繰り返しになりますが、これは別に本質的な話じゃなくて、単に呼び方が違うだけなのかな、と。
他人が書いた文章を読むときにはどっちの意味でModelという単語を使っているのか意識しておきましょう、という程度です。
[追記]
本エントリは、人によってModelと呼んでる対象が違うので注意しましょう、ということが言いたかったものなので蛇足気味なのですが、たまたま今日こちらのスライドを見つけまして、かなり分かりやすかったので紹介しておきます。
第2版出版(されることを私が知った)記念に。 Kindle版は2015/08/05に入手できるようです。
Hazelcastとは、分散キャッシュ(Distibuted Cache)だとかインメモリデータグリッド(In-Memory Data Grid; IMDG)だとか呼ばれているカテゴリの製品です。
んじゃあ分散キャッシュ/IMDGとは何ぞやということなんですが、それについてはOracle Coherenceについての資料を読むと十分理解できるかと思います。
日本語ドキュメントも充実していますので、いきなりHazelcast関連ドキュメントから入るよりとっつきやすいかと。
今サクッとググってみた結果を以下に載せますが、他にも色々検索で得られると思います。
これらを流し読みした後、Mastering Hazelcast を読めばHazelcastがどんなものかはわかるかと思います。
IMDGプロダクトの性質は、RDBMSに近い感じでしょうか。どういうことかというと、
みたいな。
さて本題の、読書感想ですが、読んだ当時(2014年末ごろ？)に書いていたものがありました。
この本で解説されているHazelcastのバージョンは2.6ですが、このレビューを記載した時点での最新リリースバージョンは3.4です。
変更されているAPIも多くあり、サンプルコードを動かすためのマイグレーションにも労力が必要です。
それに加えて、記載内容も基礎の基礎に留まっており薄いです。
出版当時の状況はわかりませんが、現在に至っては、公式サイトのドキュメント、及び公式サイト内にあるオンラインブック Mastering Hazelcast を読めば、この本以上の情報が得られます。
というわけで、今から第1版を購入するのはおすすめしません。
そもそも前述の通り、導入自体はさほど大変ではないので、その部分については無料で入手できる範囲の資料で事足りる気がします。
v2.6とv3.4をの差異を当時記録したものがありますので、万が一本書を読むようなら参考にしてみてください。
現在の安定最新版である1.2.2ではエラーが出たので無理でした。
1.3betaにアップグレードして導入しています。本日リリースされた1.3RC1でも今のところ問題ありません。
具体的な手順はこちらのREADME.mdをどうぞ。
関連:
そういえば話題に挙がっているのを見たことがなかったので。
Eclipse4.4(ちなみに現時点での最新版は4.5(Mars))でJava8対応されましたが、ラムダ式に変換できる箇所で
Ctrl+1
のクイックアシスト機能でラムダ式に変換できます。逆変換も可能です。
Save Actionsにも設定が増えており、保存時にラムダ式に変換することも可能です。
参考:
はじめに注意事項:
ActiveAndroidの開発は停滞しており、issueやpull-requestは放置されていますから、ActiveAndroidの未来は明るくなさそうです。
将来的にローカルのデータベースを使った機能を拡充したいことを考えると、ORMについてはそろそろ刷新する必要があると感じています。
公式モジュールが配布されているリポジトリがどこにあるかわからないので自前でビルドします。
Mavenのバージョン3.1.1をダウンロードして使用できるようにセットアップしてください。
これより古いバージョンではビルドできません。新しいバージョン(3.2.5以降？)でも問題が発生します。(補足を後述)
$ git checkout https://github.com/pardom/ActiveAndroid.git
$ cd ActiveAndroid
$ mvn clean source:jar javadoc:jar install -Dmaven.test.skip=true -Dandroid.sdk.path=$ANDROID_SDK_HOME
特定のバージョン(API 16)のシステムイメージに依存しています。ビルドに失敗する場合はその旨のエラーが出力されると思いますので、API16のSDK Platformをインストールしてください。
/build.gradle の allprojects > repositories を編集し、ローカルリポジトリを参照先に加えます(参考)。
allprojects {
repositories {
(略)
mavenLocal()
}
}
次に、/app/build.propertiesに依存関係を追加します。(参考)。
もしAndroid Studioが生成する/app/build.gradle をそのまま使用しているならば、 com.android.support:support-v4 が依存関係に追加されています。ActiveAndroidが依存している com.google.android:support-v4 とこれは競合するので除外しておきます。
dependencies {
(略)
compile ('com.activeandroid:activeandroid:3.1-SNAPSHOT') {
exclude module: 'support-v4'
}
}
以上でActiveAndroidが利用できるようになります。
Maven3.3.3でビルドすると以下の例外が出て失敗します。
Exception in thread "main" java.lang.NoClassDefFoundError: org/eclipse/aether/spi/connector/Transfer$State
at org.eclipse.aether.connector.wagon.WagonRepositoryConnector$GetTask.run(WagonRepositoryConnector.java:608)
at org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run(RunnableErrorForwarder.java:67)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.ClassNotFoundException: org.eclipse.aether.spi.connector.Transfer$State
at org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
at org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:271)
at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:247)
at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:239)
... 5 more
これは利用しているandroid-maven-pluginというMavenプラグインのバージョンが古いのが原因らしいので、新しい物を使用するように設定変更すれば最新Mavenでもビルドできるようになります。
以下のPull requestをmergeしてください。
androidプログラムでアノテーション処理プログラミングを行う際のサポートを目的としたAndroid Studio向けのGradleプラグイン。複数の実装があり(1, 2)、いずれもandroid-aptと呼ばれることがあるが、特に共通仕様があるわけではない。
初めてandroid-aptという単語を見た時は、android環境向けのaptコマンド実装か何かかと思いましたが、全然違いました。非常に紛らわしいネーミングだと思います。
Android Studioを使用しないのであれば不必要なものですし、android実行環境に特化したものというわけでもありません(例えば.dexファイルを処理する、といったようなことを行うものではない)。
最近Androidプログラミングを始めまして、色々ひっかかったところをWeb検索して調べています。
テスト対象コードにAndroidフレームワークのコードが入っていると、JUnitテスト実行時に例外が発生します。
モック化して対処する(例外メッセージに記載されているURL先の記述通り、自動でモック化するオプションもあります)のが適切な場合もありますが、まずはじめに考えるべきことは、Androidフレームワークに依存しない処理に切り出し、それをテスト対象とする、ということでしょう。java.lang.RuntimeException: Method e in android.util.Log not mocked. See https://sites.google.com/a/android.com/tools/tech-docs/unit-testing-support for details.
at android.util.Log.e(Log.java)
at yukihane.dq10don.login.LoginJsonParse.processHTML(LoginJsonParse.java:32)
at yukihane.dq10don.login.LoginJsonParseTest.testProcessHTML(LoginJsonParseTest.java:42)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
dependencies {
(略)
compile 'org.slf4j:slf4j-android:1.7.12'
testCompile 'org.slf4j:slf4j-simple:1.7.12'
}
1.3 Preveiw0 バージョンでは修正されているようです。
([追記]1.3 RC 1でここに記載している対応が不要であることを確認しました。)
apply from: 'build.workaround-missing-resource.gradle'
原因は裏蓋をきっちり閉じられていなかったことだったようです。
写真を撮り忘れてしまっていたので Nexus 5 Teardown - iFixit から拝借しました画像で説明しますが、以下の破線で囲った枠(2箇所)内にツメが出ています。
このツメは直立に生えているわけでは無く、少し角度が付いていますので、まっすぐ下ろしてふたを閉めると本体にちゃんとはまらないようです。そのためワイヤレス充電が機能しなかったものと推測されます。
ふたを閉める時に画像の左側のフチから本体にはめていくとうまくかみ合います。
(クリックで拡大)
これまた検索してヒットする情報が古くて困ったのでメモ。
かなり昔のことでバージョンの詳細等は忘れてしまったのですが、原因突き止めるのに時間がかかった事象なので覚えている限りのことを記録しておきます。
Ubutuのバージョンを上げたのが原因か、最近Xが固まってしまう事象がたまに発生します。
フリーズした場合、Alt+PrintScreen+R+S+E+I+U+Bと押していく
とやれば再起動できるんですが、このMagic Sysreq機能、デフォルトでは無効化されてるようでした。
kernel.sysrq = 1
検索してみると、古い記述ばかりでそのままコピペしても動かなかったためメモ。
UbuntuとAndroid Studioでショートカットキーがかぶっているからなのですが。
Christain Bauer: HIBERNATE イン アクション
理論と実践が双方とも素晴らしい製品であるHibernate。本書はそのプロダクトを書名に冠していますが、Hibernateを使うつもりがなく、ORマッピングの解説書として読むにしても十分な良書です。Second EditionとしてJava Persistence With Hibernateという書籍も出版されていますが、残念ながら現在のところ
和訳はされていません。-インアクションは2.xの、Java Persistence-は3.1の頃のものなので、最新版とはちょっと違うところもあることに注意。 (★★★★★)
アンドリュー・S・タネンバウム: 分散システム 原理とパラダイム 第2版
クライアント/サーバシステムを構築する上で必要となる知識が総論されてます。Web技術者も、フレームワーク部分を開発するのであれば必読。 (★★★★★)
Ｊｏｅｌ Ｓｐｏｌｓｋｙ∥著: ジョエル・オン・ソフトウェア
前述の書籍「ソフトウエア開発プロフェッショナル」をより砕いたもの、という感じでしょうか。
前書きではプログラマでなくSE向けの本のように書かれているが、プログラマが読んでも面白い本であると思われます。
SEになった新人（あるいはそういう会社に入る/入りたての人）にとっては、これからどういったことが仕事を遂行していく上で起こりえるのか、どのように考えて行なっていけばいいのか決定する助けになると思います。
元は″Joel on Software″というブログの記事で、web上でも一部日本語で読めます。
http://japanese.joelonsoftware.com/
(★★★)
ドナルド・Ｃ・ゴース,ジェラルド・Ｍ・ワインバーグ: ライト、ついてますか
問題解決（一昔前のの流行語で言うところの『ソリューション』）能力は、システムエンジニアのスキルとして備えるべきもののうちのひとつです。しかし、これは難しい。学校で出されるテストと違い、唯一の、（問題提出者が想定している）解を求めるだけが「問題解決」では無いからです。そもそも、何が問題なのか、それは本当に問題なのか、それは本当に解決すべき問題なのか、その問題解決方法は正しいのか、などを解決しなければ、「その解は正しいのか」に辿りつくことができません。この本の最も良いところのひとつは、本があまり厚くないこと。すぐに読めるし、何回も読み返す気になるでしょう。 (★★★★★)
スティーブ・マコネル: ソフトウエア開発プロフェッショナル
コードコンプリートで有名なスティーブマコネルの著書。新人ＳＥに読んで欲しい。個人として業界の中でどうあるべきか、組織としてどうあるべきか、ＳＥのプロ意識とは？ＳＥの心構え概論、といったところでしょうか。また、業界における資格の重要性についても説かれています。この業界では資格が特に軽んじられる傾向がありますが、この傾向はどんな弊害をもたらすのか、将来的にこの業界は資格に対してどのような姿勢で臨んでいくべきなのか。日経ＢＰ社では（他の出版社もだが）最近、似たような類いのあまり面白くない書籍が乱出版されていますが、この本は別格だと思うので安心して購入して欲しいと思います。 (★★★★★)
最近のコメント