起動時チェック
さて
コミケビュワーアプリですが
起動時に
ＳＤカードとか
本家カタロムから
コピーしないといけない
必要ファイルの警告メッセージを
出す様にしましたぁ〜
コピーし忘れとか
説明を読まない人ようｗｗ
（自分も何か有ってから説明書読むタイプなんでｗｗ）
コンナ感じですなぁ〜〜
ただ、メッセージだけなので
その後の操作で制御は掛けてません
まあ、MAPファイルとか無くても
カタログとかは動く事は動くからねぇ〜
ＤＢファイルは無いと厳しいので制御入ってますがｗｗ
さてマーケット公開
ドウシヨウカナぁ〜〜
投稿者：秀at 00:16
| さんでープログラム（Android編）
| コメント(0)
| トラックバック(0)
画面の向きが変わったとき
画面の向きが変わったときに
画面が破棄されて
onCreateが再度実行されて
たまに落っこちてたので
画面の向きを縦に固定していた
っで
AndroidManifest.xmlで
android:configChanges="orientation|keyboardHidden"
を追加すれば
再スタートは無くなるですね
コンナ感じで記述（取敢えずカタログ画面のみ）
＜activity android:name=".CatalogActivity"
android:label="@string/app_name"
android:configChanges="orientation|keyboardHidden"＞
＜/activity＞
ふむ、
寝転がったりして操作してると
コロコロ向きが変わるので
操作し難いかぁ？？
画面はコンナ感じ
投稿者：秀at 00:07
| さんでープログラム（Android編）
| コメント(0)
| トラックバック(0)
コミケビュワーicon
さて
コミケビュワーのアイコン出来ましたぁ〜
タブレットが今無いのでマウスで
マスクかけつつ色付けぇ〜
ま〜大昔マルチペイントで
鍛えたから大まかな色ならマウスでOKだねぇ〜
まあ御覧の様にかなり小さくなりますがぁｗｗ
勿体無いので内部の裏表示でも使いましたぁ〜ｗ
こっちの方が表示は大きいです
ふむ
あとは、起動した時に
ＳＤカード準備できて無いぞ
とか
必要なカタログからのファイル無いぞ
など
メッセージ出す様にするかなぁ〜〜
投稿者：秀at 00:10
| さんでープログラム（Android編）
| コメント(0)
| トラックバック(0)
処理待ち表示
コミケビュワーアプリの
遅そうな箇所に処理待ち表示を仕込んでみた
こんな感じですねぇ〜
あと検索画面に
開催日とジャンルのスピナーを追加ぁ
さて次はアイコンのデザインかぁ〜〜
投稿者：秀at 03:02
| さんでープログラム（Android編）
| コメント(0)
| トラックバック(0)
icon作ってみたぁ
ふむ
アプリのアイコンが
標準のままだったんで作ってみた
透過PNGで作らないと行けなかったので
Pixiaと透過PNGのDLLも
落としてきてチマチマ作成ぃ
久々の画像ソフトだったが
昔フォトショップでイラスト書いていたので
ま〜そこら辺は、
やりたい機能探すのに手間取った位で何とかなったぁ
が、Pix形式で保存すると
ベースレイヤーの縦横サイズが大きくなるのななぜだ？ｗｗ
まぁその他レイヤーは大丈夫なので
開きなおしたらサイズ変更すればいいのだが
もしかして、その他レイヤーの、
はみ出してる部分も含めて広げてるのか？
ま〜ソンナこんなで
iconはコンナ感じぃ
まぁ〜文字だけなアイコンですねｗｗ
さてさてマーケットに公開するか悩んでる
のであるぅ〜〜〜
投稿者：秀at 00:11
| さんでープログラム（Android編）
| コメント(0)
| トラックバック(0)
文字コード変換
ふむ
SQLiteデータのVerUPアプリで
Ｖｅｒ３ＤＢ作成時ロジックを
JNIで処理する様にしましたぁ
っで
文字コード変換も入れたかったのですが
AndroidのJNIではiconvが標準で無かったので
Javaでコード変換しましたぁ
処理結果は
09-19 14:31:06.793: INFO/DB_dump(281): 11926ms
09-19 14:31:13.093: INFO/dump_u(281): 6265ms
09-19 14:32:23.833: INFO/DB_read(281): 70709ms
09-19 14:33:34.433: INFO/DB_dump(281): 11992ms
09-19 14:33:39.873: INFO/dump_u(281): 5410ms
09-19 14:34:46.943: INFO/DB_read(281): 67030ms
09-19 14:35:44.533: INFO/DB_dump(281): 11309ms
09-19 14:35:49.822: INFO/dump_u(281): 5254ms
09-19 14:36:57.545: INFO/DB_read(281): 67694ms
dump_uが、コード変換なんだけど
１０ＭＢ強が６秒弱かぁ
まあまあかな？
っで
文字コード変換の有無チェックボックスを設けてみました
これで略完成かなぁ〜
投稿者：秀at 00:44
| さんでープログラム（Android編）
| コメント(0)
| トラックバック(0)
resetじゃなくfinalizeなのかぁ
ふむ
先日のJNIでSQLietを使って
ダンプを取込む処理で落ちてた件が解決しましたぁ
まぁ〜原因はメモリーリークかなぁ
まあ、そう思ってＳＱＬ(SQLステートメント(st))使った後に
リセット(sqlite3_reset)してみた
こんな感じ
rc = sqlite3_prepare_v2(db, fs1, -1, &st, NULL);
rc = sqlite3_step(st);
sqlite3_reset(st);
だがエラーが出る（＾＾；）
それで
DB閉じる前にやっていた
ファイナライズ(sqlite3_finalize)を
リセットの場所に入れてみた
sqlite3_finalize(st);
ハイ落ちなくなりましたｗｗ
ふむ
勘違いだったのは
sqlite3_resetはSQLを
再実行出来る様にする為で
あって
確保したメモリー領域を再利用する訳じゃないのね
なのでsqlite3_finalizeで解放しないと
永遠とメモリーに放置されるのねぇ（＾＾；）
まあ
SQL再利用しない場合は
sqlite3_prepare_v2
sqlite3_step
sqlite3_finalize
の３点セットで行わないと
メモリーにゴミが溜まるのねぇ〜
はい勉強になりましたｗ
あぁ〜あと実行結果は
（３回計測）
09-18 17:57:32.465: INFO/DB_v2dump(11610): 9233ms
09-18 17:58:13.805: INFO/DB_v3reload(11610): 41339ms
09-18 17:59:08.895: INFO/DB_v2dump(11610): 9234ms
09-18 17:59:47.177: INFO/DB_v3reload(11610): 38280ms
09-18 18:01:47.805: INFO/DB_v2dump(11610): 8554ms
09-18 18:02:26.456: INFO/DB_v3reload(11610): 38653ms
速いなぁｗ
４０秒弱かぁ
Javaでは１００秒弱だったし
約半分かぁ〜
ただ
ＤＢのVerUPだけなら、このままで正しいのだが
文字コードが元のままで
「SJIS」から「UTF-8」に変換掛けてないので、
その処理入れないとAndroidでは
漢字とか文字化けするのよねぇ〜
さて本番ロジックに取込む前に
そこら辺もテストロジックで組んでみるかなぁ〜〜
投稿者：秀at 03:45
| さんでープログラム（Android編）
| コメント(0)
| トラックバック(0)
元々ＤＢがandroid産だと
ふむ（＾＾；）
本家ＤＢをＤＢverUPアプリでコンバートした後
そのＤＢをコミケアプリで読込んで
サークル画面開こうとしたら落ちたｗ
調べて見ると
ＤＢがandroidで作成されていると
DatabaseHelperのonCreateを通らないのねぇ〜〜
なのでチェックリスト用の
テーブルが作成されないのね〜〜
まあ、ちょろっと変更かけて直りましたがぁｗｗ
さてコレでコミケカタログＣＤ−ＲＯＭから
ＳＤカードにデータコピれば
スマホだけで動かせる様になったねぇ〜
作成目標の冬コミまで余裕だったなぁｗｗｗｗ
投稿者：秀at 12:51
| さんでープログラム（Android編）
| コメント(0)
| トラックバック(0)
今更ながらぁプログレス
ふむ今更ながらだがロジックに
プログレスダイヤログ(ProgressDialog)を仕込んでみる
表示されないぃ・・・
と言うより処理の最後に一気に表示されてる？？
色々調べてみると朧だが解ってきた
まだ完全に理解した訳じゃないので曖昧だが。。。
androidはメインスレッドだけが
画面更新できる見たいですね
なのでボタン押した時の処理等に
まとめてダイヤログ表示処理と
重い処理を一緒にすると
重い処理が終わるまで
メインスレッドに処理が返って来ないので
処理の最後に一気に表示されている様な形になるのかな多分
そこで
重い処理を別スレッド（以降「Ｓスレッド」）にして
マルチスレッド化して
メインスレッドにすぐ処理が戻る様にしました。
（今回はRunnableとThreadを使いましたが
AsyncTaskってのも有るみたいだね）
っで
ＳスレッドからHandlerのpostを使って
メインスレッドへ画面更新等をする感じですねぇ
例として下記の処理で
mHandler.post(new Runnable() {
public void run() {
waitDialog.setMessage("Ｖｅｒ３一時ＤＢの作成中");
Toast.makeText(jp.or.sqliteDBverup.SqliteDBverupActivity.this,
"一時ＤＢ作成中です", Toast.LENGTH_LONG).show();
tv.setText("一時ＤＢ作成中です。");
}
});
以下の様な画面更新を、しています。
あぁ〜画像には無いですが
一時ポップメッセージも表示してます
ふむ
もう少し簡単に画面更新だけでも
出来ると楽なんだがぁ
AsyncTaskも調べてみるかぁ
投稿者：秀at 08:55
| さんでープログラム（Android編）
| コメント(0)
| トラックバック(0)
高負荷で落ちるねぇ
さてさて
SQLiteのダンプ取込みをJNIで組みましたぁ
まあ、シンプルな構造です
小さなダンプだと問題ありませんｗ
ただ。。。
レコード数が多いと以下のログを吐出します。。。
----------------------------------------
09-15 08:53:04.163: INFO/ActivityManager(59): Low Memory: No more background processes.
09-15 08:53:08.922: INFO/ActivityManager(59): Process jp.co.omronsoft.openwnn (pid 1080) has died.
09-15 08:53:08.942: WARN/ActivityManager(59): Scheduling restart of crashed service jp.co.omronsoft.openwnn/.OpenWnnJAJP in 5000ms
09-15 08:53:08.942: INFO/ActivityManager(59): Low Memory: No more background processes.
09-15 08:53:11.753: INFO/ActivityManager(59): Process jp.or.test02a (pid 1362) has died.
09-15 08:53:11.913: INFO/ActivityManager(59): Start proc com.android.launcher for activity com.android.launcher/com.android.launcher2.Launcher: pid=1535 uid=10025 gids={}
09-15 08:53:11.913: INFO/ActivityManager(59): Low Memory: No more background processes.
----------------------------------------
そう「Low Memory: No more background processes.」
悲鳴を上げてますね（＾＾；）
トランザクションでメモリー食ってるのかなぁ
また調べモノがぁ増えたぁ
一応、繰返しロジックはこんな感じ
sqlite3 *db;
int rc = sqlite3_open("/sdcard/cmkdata/test_3.DB", &db);
sqlite3_stmt *st;
strcpy(fs1,"");
while ( fgets(fs,n,fp)!= NULL){
ct++;
strcat( fs1, fs );
ret = strrchr( fs1,';');
if(ret != NULL){
if((strlen( fs1 ) - 2) == (ret - fs1)){
rc = sqlite3_prepare(db, fs1, -1, &st, NULL);
rc = sqlite3_step(st);
strcpy(fs1,"");
}
}
}
sprintf(pszRet,"%ld",ct);
sqlite3_finalize(st);
sqlite3_close(db);
シンプルすぎるのかなぁｗｗｗ
投稿者：秀at 18:49
| さんでープログラム（Android編）
| コメント(0)
| トラックバック(0)
参照メンバ名は同じゃなかったｗ
ふむ
SQLiteのVer2とVer3のメンバー名同じジャナカッタｗｗ
ＤＢオープンもsqlite3_openとsqlite_openだったｗｗ
思い込みは怖いねｗｗ
まあ、それはそれとして
Javaで個別のJNIライブラリ読込みについて
結果は、こんな感じ
出来たね〜〜
別々にJNIライブラリを作成して
Java側から参照する様にしてます。
少し端折りますが
ライブラリTest02jniでは
sqlite.h(Ver2用)を参照(include)します。
ライブラリTest02v3jniでは
sqlite3.h(Ver3用)を参照(include)します。
個々で別々のメンバ作成します。
今回は「stringFromJNI」(Ver2側)と
「sqliteDBv3」(Ver3側)ですね。
jniフォルダーに個別フォルダーを作ってAndroid.mkを作ります。
何でも良いのですが
今回はTest02フォルダーとTest02v3フォルダーですね。
jniフォルダーにも配下ホルダーを参照する
Android.mkを作ります。
中身は「include $(call all-subdir-makefiles)」だけです。
NDKでビルド（ndk-build）してライブラリを作ります。
あとは、Java側(Activity)で
Test02jniとTest02v3jniの
ライブラリを参照します。
static {
System.loadLibrary("Test02jni");
System.loadLibrary("Test02v3jni");
}
だね
あとはJavaで
個々のメンバ名を参照で
「stringFromJNI」とか
「sqliteDBv3」とか使えば良いですね
ふむぅ（＾＾；）無理やりポイ感じがぁｗｗ
何とか成る事は、なったかぁ・・・
ま〜ダンプ取込んでVer3ＤＢ作成する
ロジックをテストで組んで見るかぁ〜〜〜
投稿者：秀at 00:08
| さんでープログラム（Android編）
| コメント(0)
| トラックバック(0)
トランザクションの効果
ふむ
ダンプファイルを読込んで
ＤＢ作成するＳＱＬ処理に
トランザクションしてみた。
有無の結果
（各３回計測）
トランザクションあり
09-13 23:10:35.532: INFO/DB_Create(16332): 97438ms
09-13 23:10:35.532: INFO/DB_SQL(16332): 47289 COUNT
09-13 23:10:35.553: INFO/out_DB(16332): aa.DB
09-13 23:13:10.142: INFO/DB_Create(16332): 98947ms
09-13 23:13:10.142: INFO/DB_SQL(16332): 47289 COUNT
09-13 23:13:10.192: INFO/out_DB(16332): aa.DB
09-13 23:15:31.922: INFO/DB_Create(16332): 100513ms
09-13 23:15:31.922: INFO/DB_SQL(16332): 47289 COUNT
09-13 23:15:31.942: INFO/out_DB(16332): aa.DB
トランザクションなし
09-13 23:23:15.762: INFO/DB_Create(20289): 303476ms
09-13 23:23:15.762: INFO/DB_SQL(20289): 47289 COUNT
09-13 23:23:15.792: INFO/out_DB(20289): aa.DB
09-13 23:29:19.762: INFO/DB_Create(20289): 308013ms
09-13 23:29:19.762: INFO/DB_SQL(20289): 47289 COUNT
09-13 23:29:19.782: INFO/out_DB(20289): aa.DB
09-13 23:34:59.752: INFO/DB_Create(20289): 306070ms
09-13 23:34:59.752: INFO/DB_SQL(20289): 47289 COUNT
09-13 23:34:59.773: INFO/out_DB(20289): aa.DB
47,289レコードで有り無しで3倍違うかぁｗ
トランザクションは「赤い彗星」だねぇｗ
まあ、計測時間はダンプファイルの読込み時間も含んでいるので
純粋なＳＱＬ実行時間では無いのだがぁ
ファイル読込み時間は、トラン有り無しで
同じだろうから、もっと差が有るはずだねぇ〜〜
あと一応、元ＤＢからのダンプ作成時間は
ＪＮＩでのダンプ処理の結果
09-13 23:42:05.072: INFO/DB_dump(27903): 10238ms
09-13 23:46:06.432: INFO/DB_dump(27903): 9686ms
09-13 23:48:21.872: INFO/DB_dump(27903): 9312ms
・・・速いなぁ
こちらは「連邦の白いヤツ」かぁｗ
まあ書出しダケ何で、、、
とは言え元ＤＢ読んでダンプ吐出してるわけだし
変わらんのかぁ。。。
ふむぅ〜
Ｖｅｒ３ＤＢ作成もＪＮＩ化を考えるかぁ〜
もっと早くなるかなぁ？
まだ思いつきだが
参照メンバーが同じ問題は
(sqlite_openなど)
Ver2のライブラリ参照でダンプ作成
と
Ver3のライブラリ参照でDB作成
で
別々のライブラリ作成しておいて
Java側からJNIライブラリを指定する再に両方参照すればOKかなぁ？
ぼちぼちとテストロジック組んで試してみるかぁ〜〜ｗ
投稿者：秀at 09:53
| さんでープログラム（Android編）
| コメント(0)
| トラックバック(0)
とりあえず出来たねぇ
ふむ
Android単体で
SQLiteデータVer2からVer3へのUPdata一応出来たねぇ〜
画面はコンナ感じ
まぁ〜シンプルですね（＾＾；）
Ver2ダンプからテーブルをクリエート(createのSQL発行)する際に
項目で内容コメント付けている場合は
(こんな時ね「comiketNo INTEGER not null,-- コミケ番号」)
項目ごとの間に"￥n"を入れないと落ちました（＾＾；）
ま〜仕様なのねｗ本家ダンプでも入ってるしぃ〜
まぁlogってSQLみました
出来上がったＤＢをWinで見てみる
一部で文字化けってますねぇｗ
「VALUES('en_US')」に成ってますからねぇ〜〜
まあAndroidは「UTF-8」なんで、あたりまえかぁ〜〜
「br = new BufferedReader(new InputStreamReader(file_tmp,"SJIS"));」
って、やってるので
元の状態が変化してますが
AndroidでDB使う前提なので、いいっかｗ
駄目な時は中間ダンプファイル作ってるので
それで他の環境で生成する事も出来るしぃ
しかしダンプ出すときはJNIで作ってるので速いですが
ダンプから取込みはJavaでSQL発行なので劇遅ｗｗｗｗ
３万５千レコード以上だからねぇ（＾＾；）
ま〜トランザクションも使ってなんでまあぁ〜〜ねｗ
取込みもJNIで、やれば良いんだろうけど
SQLiteのVer2Ver3ライブラリで
同じメンバなどが有るのよ
(sqlite_openなど)
ライブラリ指定してメンバ使えたっけぇ
ちょろちょろ調べてみますかぁ〜〜
取敢えずトランザクション使って結果みるかぁ〜
何処まで改善っするかなぁ〜
投稿者：秀at 19:59
| さんでープログラム（Android編）
| コメント(0)
| トラックバック(0)
権限チェックしてたのねぇ
SQLiteコンバートのテストロジックから
本番ロジックにコピーって
実行してみたら通らなかったぁorz
色々やってみたが
androidのマニフェストで
SDカード許可アクセス出さないとダメだったｗ
チェックして無いと思ってたんだがぁアマッカッタｗ
＜uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" /＞
テストで色々試行錯誤した際に残してたの忘れてた（＾＾；）
投稿者：秀at 23:36
| さんでープログラム（Android編）
| コメント(0)
| トラックバック(0)
SQLiteのダンプぅ
ふむ
SQLiteのVer2コードがJNIで動くようになったので
コンバートに必要なデータを作るコーディングに取り掛かりました。
SQLで吐いてゴリゴリやろうかと思ったのだが
もともとコマンドラインでダンプ出す機能(.dump)が有るので
ちとshell.cの中身を解析ぃ
ちょいちょいコード拝借してコーディングして
エラー＆トライを繰り返しましたぁ
ま、こちらもSELECT文で吐出して
編集してるのね（＾＾；）
結果は
ハイ出来ましたぁｗ
難所は
ポインタ構造体の所で、
よく引っかかりましたがぁ（＾＾；）
アセンブラの方がポインタ素直でスキｗｗｗ
８〜９年ぶりＣ言語のリハビリには
ちょうどヨカッタかなぁｗ
あぁ〜コマンドラインが懐かしいぃ〜
JNIを使ってみて
昔（高校まで）X1turboでプログラムしてた頃の
Basic＆アセンブラ（16進コード）で
組んだモノを連想したねぇ〜
雑誌ではOh!Xとかベーマガぁｗ（解る人は少ないかｗ）
あの頃も、どうしょうも無い所は、
アセンブラに任せる感じだったからね
まぁ〜〜
プログラムって多言語の複合技で、
やれないと駄目なんだけどねぇｗｗｗ
今は情報も溢れてるし
いい時代に、なったものだぁ〜〜なぁ〜〜〜
投稿者：秀at 07:11
| さんでープログラム（Android編）
| コメント(0)
| トラックバック(0)
やぁ〜〜〜っとぉｗ
うむ
ＤＢファイル指定で、やっと動いたおぉ！！
何したかと言うと
SQLiteのOS識別での設定で
一時領域を確保してるんだけど
"/var/tmp"
"/usr/tmp"
"/tmp"
コレ/mntには有りませんねぇ
しかも/mntに勝手にフォルダーなんぞ作れません。。。
だからＳＤカード上に
"/sdcard/test/var/tmp"
"/sdcard/test/usr/tmp"
"/sdcard/test/tmp"
って作ってみました
っでコードを
に、しましたぁ
ハイ実行ぉ
通ったときの「DB_ok」メッセージ
エミュレータに返ってきましたねｗ
っで、ＤＢのファイルサイズは
増えてますねぇｗ
ふいぃ〜〜〜〜〜
SQLiteのコード半分くらい読んだかもぉ（＾＾；）
でも、もとのコードは余り改変したくは無いのだがぁ。。。
jniで基礎ディレクトリ/mntから変えれ無いのかなぁ？？
ちょっと調べてみるかぁ〜〜〜
さてスッキリしたｗｗｗ
気になって熟睡できなかったのでヨカッタおｗ
投稿者：秀at 03:21
| さんでープログラム（Android編）
| コメント(0)
| トラックバック(0)
OSの認識がぁ
さて
Ｃコードず〜〜〜っと眺めてると
ＯＳ識別かなぁ〜〜っと
実際に何返って来るかやってみる
結果
ふむ"UNIX"だねぇ〜〜
ここの判定ロジックかぁ
って事は、この設定かぁんなぁ
さてさてコレどうすれば良いか
コード追うかぁ・・・
でもファイル名を「:memory:」にしても"UNIX"なんだがぁ
エラー来ないんだよね？ｗ
投稿者：秀at 00:32
| さんでープログラム（Android編）
| コメント(0)
| トラックバック(0)
やっぱ駄目かぁ。。。
ふむ
sqlite_openのポインタ返ってこないねぇ
0 が返ってくる
ま、エラーメッセージを排てるしね。。。
ちなみにＤＢファイルを":memory:"にして
一時的にメモリー上に作成すると
テーブル作成SQL(sqlite_exec)も通るし
sqlite_closeも通る・・・
さて何だろかぁ。。。
さっぱり解らん、一時的な作業領域かぁ？
エラー返してくる
コード部分をバッサリ消すか！？
（-д-）それは駄目だろｗ
ちなみにVer3も同じ様に１個のライブラリ化して
試したが此方は動くのねぇｗ
ふむぅ、、、
投稿者：秀at 05:31
| さんでープログラム（Android編）
| コメント(0)
| トラックバック(0)
もしかしてぇ。。。
ソースコード読んでも何でか解らんかったので
いろいろやってみた
環境設定かなぁ〜っとputenv試したり・・・
格納場所変えてみたり・・・
またソース読んでみたりぃ・・・
ディレクトリのパーミッション系かなぁ〜っと
DDMSのファイルエクスプローラー眺めていると
あれ？ＤＢファイル出来てるじゃん。。。
Ｃコード
ＤＢファイル（ＤＤＭＳ）
作成時間が現在時間とズレていたので今まで気付かなかったぁ
Androidエミュレータの時間なのねぇ orz
国際標準時間かぁ？
まあ、ＤＢファイルが出来たって事は
ＤＢ掴んでるのかなぁ？
あのエラーメッセージは何ぃ？？？
ふむ、何かinsertしてみてselectしてみるかぁ・・・
投稿者：秀at 04:27
| さんでープログラム（Android編）
| コメント(0)
| トラックバック(0)
メモリー上はOKぇ？
一応、ＤＢ名を":memory:"にすると
メモリー上に一時的ＤＢ展開出来るみたいなので
やってみた
sqlite *db;
db = sqlite_open(":memory:",0666, &sqliteerror);
エラー返ってこないので出来たのかな？
ふむ、ファイル関係かぁ・・・
でも試しにＣコードでfopenを使って
ファイル作ってみたけど普通に出来たんだがぁ。。。
さて何だろかぁ？
投稿者：秀at 05:29
| さんでープログラム（Android編）
| コメント(0)
| トラックバック(0)