Androidのレイアウト用のxmlで、画面の幅を割合で表示させる為に、「layout_weight」を使用する場合があるとおもいます。
この時によく、以下のように設定する事があると思います。
これは、「layout_weight=”1″」を設定している要素に「layout_width=”wrap_content”」を設定しています。
実はこれが無駄らしいのです。（こちら参照）
というのも、wrap_contentの幅の計算と、layout_weightでの幅計算が両方行われてしまうかららしいのです。
なので表示のパフォーマンスを向上させる為には、以下のように設定したほうがいいそうです。
Androidのドキュメントを読みなおしてみると知らない事が結構書かれているので、一度読んでみると面白いと思います。
AndroidのAsyncTaskのインスタンスを使いまわそうと思って、２回目の「execute」メソッドで
Cannot execute task: the task has already been executed (a task can be executed only once)
ってエラーがでて実行できませんでした。
AsyncTaskは１度しか実行できないようです。
使いまわさずに、必要な時に生成して、実行するようにしてくださいとのことでした。
「The task can be executed only once (an exception will be thrown if a second execution is attempted.)」
って書いてますし。。。
ちゃんちゃん。
いきなりですが、
GitHubをあまり知らないプログラマはWEB+DB PRESS Vol.69のGitHubの記事を読んだ方がいいと思います。
という私も、GitHubをあまり知らないプログラマですが…。
「WEB+DB PRESS」いつも読んでいる愛読書ですが、今月号のGitHubの記事は本当に秀逸でした。
その商品がこちら、
というより、この記事と筆者「@HIROCASTER」さんのブログ記事「プログラマがGitHubとどう関わっているのか垣間見て感じたこと」の両方を読んだ方がいいと思います。
この両方を読むと、すぐにGitHubを使いたいと思ってしまうはずです。
私は、なりました。
私は今までも、GitHubをGitリポジトリとしては使用していましたが、GitHubとして使用していませんでした。
この本を読むまでGitHubは、
「Gitリポジトリのホスティングサービスで、みんなにリポジトリを公開しているだけ」と思っていました。
でも、それは大きな間違いであると気付かされました。
GitHubの利用方法と、利用している人達の体験談を読んで、今までの考えが全くの間違いで単なるGitリポジトリのホスティングサービスに留まらず、プログラマの開発プロセスを一新しているものであるということに気付かされました。
GitHubとは、@HIROCASTERさんのブログでも書かれている、
SOCIAL CODING
これを実現出来るようにした、画期的なツールだったんだと初めて気付かされました。
この「WEB+DB PRESS Vol.69」のいい所は、GitHubで一番敷居が高いと思われるPull Requestを誰でも手軽に体験出来るようにリポジトリを用意してくれている所です。本当にありがとうございます。
これから徐々にGitHubを、使っていこうと思います。
まずは、「WEB+DB PRESS Vol.69」で掲載されているPull Requestから初めてみたいと思います！
もちろん、「WEB+DB PRESS Vol.69」の他の記事もいつ通り面白く興味深い記事ばかりなので読み応えありですよ。
Androidのレイアウトをxmlで設定している時に、ImageViewに下記の警告が出てきた
Missing contentDescription attribute on image
原因を調べたら、Imageの説明をcontentDescriptionで記述しなさいよと言う事らしいなので
「android:contentDescription=”ここに画像の説明”」
この要素を追加したら警告が消えた。
最近のAndroidのSDKの変更点のキャッチアップが全然出来ていないので、ちょっとずつやっていこう
今までは、configの設定に従ってキャッシュを使用してきていましたが、
今回はconfigの設定とは異なる設定で、キャッシュを使用する方法です。
以下が、configの設定とは異なる内容での使用方法の例です。
public function action_forge()
{
// ここで使用するストレージ名と設定内容を記述する、
// ここで設定しなかった、項目についてはcacheのconfigファイルの内容で設定される。
// 「$config = 'file';」のように、ストレージ名のみを文字列で渡して使用する事も可能
$config = array(
'driver' => 'file',
'expiration' => null,
'file' => array(
'path' => APPPATH.'cache_forge'.DS,
),
);
// String
$cache = Cache::forge('string', $config);
$cache->set('cache test');
$data['string'] = $cache->get();
// Array
$a = array(1, 2, array('key' => 'value'));
$cache = Cache::forge('array', $config);
$cache->set($a);
$data['array'] = $cache->get();
// Object
$o = new Library_Test();
$cache = Cache::forge('object', $config);
$cache->set($o);
$data['object'] = $cache->get();
return Response::forge(View::forge('cache/forge', $data));
}
(configの設定は、fileストレージの動作を確認した時と同様にしてあります)
14,20,26行目のように、Cacheクラスのforgeメソッドを使用してCacheクラスのインスタンスを生成すると、
第2引数で渡したconfigの設定内容でキャッシュストレージに接続に行きます。
動作後のデータを確認すると、ちゃんとキャシュの情報は「cache」ではなく「cache_forge」フォルダに生成されています。
第1引数はキャッシュのキーです。
キャッシュクラスのインスタンスを生成する時に使用するキー値を設定しているので、すごく違和感があります。なぜ「get」「set」などのメソッドの引数に、キャッシュのキーを取るようになぜ設計されていないのかすごく不思議です。
ちなみにコメントにも記述していますが、第2引数のconfigは配列でなく、ストレージ名を文字列で渡しても大丈夫です。
その場合、設定されていないconfigの情報はcacheのconfigから取得するようになります。
次回は、Redisのストレージを使用している時に気がついた、cacheのsectionについてまとめてみたいと思います。
