バナー表示広告で今までads:adSize="BANNER"を使ってきましたがスクリーンサイズによって左右に余白が出来てしまいちょっと残念だったので最近はads:adSize="SMART_BANNER"を使っていました。
昨日play-serviceのバージョンを変えたついでにSMART_BANNERにしたところなぜか広告が表示されなくなり、何かやらかしたと思い、何が悪いのか悩んだまま気がついたら寝落ちしていました(笑)
2015年6月11日木曜日
2015年6月2日火曜日
統合されたものはちゃんと分割されていた
昨日統合されすぎて巨大になっていたcom.google.android.gms:play-services:7.5.0ですが、ちゃんと分割されているようです。
Setting Up Google Play Services
ちゃんとドキュメントは見ないとダメということで(笑)
Setting Up Google Play Services
ちゃんとドキュメントは見ないとダメということで(笑)
2015年5月24日日曜日
SurfaceのCanvasはダブルバッファなのかトリプルバッファなのか？
一時期Chromeでダブルバッファリング絡みのバグがあって非常に残念な時期があったが、どうも手元のA1000-Fはトリプルバッファなんじゃないかという感じがしています。
いろいろな所に書かれている話としては「SurfaceViewはダブルバッファリングなので～」という感じに書かれていますが、Android4.1の（現時点で古い感じの）端末でトリプルバッファということは、グラフィックスチップに依存する部分なのでしょうね。
いろいろな所に書かれている話としては「SurfaceViewはダブルバッファリングなので～」という感じに書かれていますが、Android4.1の（現時点で古い感じの）端末でトリプルバッファということは、グラフィックスチップに依存する部分なのでしょうね。
2015年5月20日水曜日
Bitmap setWidth setHeight setConfig reconfigの罠
ビットマップの再割り当てを減らすために再生成せずに作り変えることが出来そうなメソッドがあったので早速使ってみました。
APILEVEL 19(KitKat)以降で利用できるようなのでそれも加味して実際に動かしてみると
最初はスレッドが干渉して例外になってしまうのかと考えsynchronizedで包んでやりました。
同期させてしまうのならついでにCanvasも一緒に生成させるようにしてあげて再実行。
最初は上手く行ったと思ったら結局同じ例外が出てしまい、ちょっとありがちな制約が気になってドキュメントを見てみると…
This method can be used to avoid allocating a new bitmap, instead reusing an existing bitmap's allocation for a new configuration of equal or lesser size. If the Bitmap's allocation isn't large enough to support the new configuration, an IllegalArgumentException will be thrown and the bitmap will not be modified.
ありましたね…「a new configuration of equal or lesser size」 限定という罠です。
再割り当てするには割り当てられるメモリのサイズが同じか小さい場合ということで、大きくなった場合は、IllegalArgumentExceptionが発生して変更されないという話です。
経験上この辺の話は良くあることなので当たり前ですけど、やっぱりなんともということでした。
メモリの再割り当てを考えればへたに食いつぶすよりは素直に新たに割り当てたほうがメモリ効率は良くなるんじゃないかなぁって思うので結局毎回createすることにしました。
ただ、Canvasは毎回生成するよりは使いまわしてしまったほうが良さそうなので同期はそのままにしておきましょうかね。
APILEVEL 19(KitKat)以降で利用できるようなのでそれも加味して実際に動かしてみると
java.lang.IllegalArgumentException: Bitmap not large enough to support new configuration早速例外が。
at android.graphics.Bitmap.nativeReconfigure(Native Method)
最初はスレッドが干渉して例外になってしまうのかと考えsynchronizedで包んでやりました。
同期させてしまうのならついでにCanvasも一緒に生成させるようにしてあげて再実行。
最初は上手く行ったと思ったら結局同じ例外が出てしまい、ちょっとありがちな制約が気になってドキュメントを見てみると…
This method can be used to avoid allocating a new bitmap, instead reusing an existing bitmap's allocation for a new configuration of equal or lesser size. If the Bitmap's allocation isn't large enough to support the new configuration, an IllegalArgumentException will be thrown and the bitmap will not be modified.
ありましたね…「a new configuration of equal or lesser size」 限定という罠です。
再割り当てするには割り当てられるメモリのサイズが同じか小さい場合ということで、大きくなった場合は、IllegalArgumentExceptionが発生して変更されないという話です。
経験上この辺の話は良くあることなので当たり前ですけど、やっぱりなんともということでした。
メモリの再割り当てを考えればへたに食いつぶすよりは素直に新たに割り当てたほうがメモリ効率は良くなるんじゃないかなぁって思うので結局毎回createすることにしました。
ただ、Canvasは毎回生成するよりは使いまわしてしまったほうが良さそうなので同期はそのままにしておきましょうかね。
2015年4月26日日曜日
AndroidManifest.xmlの変更後のアップデートインストール
AndroidManifest.xmlの変更を行ってapkをGoogleDriveなどから更新する場合どうも値が上手く反映されていない場合がある。
例えば<activity>タグ内に android:excludeFromRecents="true" を追加した時のことだが、更新後にアプリの履歴から変更したアクティビティーを消した後に、ランチャーから起動しても履歴に表示されてしまった。
例えば<activity>タグ内に android:excludeFromRecents="true" を追加した時のことだが、更新後にアプリの履歴から変更したアクティビティーを消した後に、ランチャーから起動しても履歴に表示されてしまった。
登録:
投稿 (Atom)