ボツ．．．

だいぶ前から作ってきた、「AndroidでiPod風音楽プレイヤー」計画、頓挫した。

MacでのiTunesと同期をとるアプリはCore Dataを使ってSQLite3形式で吐き出して、SDカードにデータベースを置いて、それをAndroidで読み書きすればいいと思っていた。

で、久しぶりにAndroid側のアプリを書き始めた。

手こずったものの、SDカード上のSQLite3のファイルへのアクセスに成功した。ただ、まだ、READONLYでしかオープンできず、更新ができないのだが、これは再生するまでは更新できなくても制作を進められるので当面は問題ない。更新が必要になるのはiTunesに再生履歴（回数の最後に再生した日時）を戻すための履歴を戻す処理を作る段階でも構わない。

しかし、ここで思わぬ盲点が発生した。

「Androidで扱えるSQLiteデータベースはAndroidで作った物」でないといけないようなのだ。必須ではないものの、それをエミュレートしなければならない。実データを置くテーブルは問題なさそうだが、android_metadataというテーブルにLOCALEというひとつだけカラムがあって、そこにロケール情報（日本語が入ってた）が登録されている。

そのテーブルがないと、データベースのオープン時に例外が飛んで来る。

これから作る予定のWindows側の母艦アプリではそれを作ればいいが、Mac用の母艦アプリはCora Dataが使えなくなってしまった。Scripting Bridge部分やUIはともかく、DBアクセス部分はすべて作り直しになる。素のデータベースアプリケーションを書かなくてはならなくなった。

こうなってくると、Windows側もC#ではなく、C++を使ってソースを共用化した方がいいのか？Cでもいいのか？二度手間は避けたいところ。テーブル定義に差が出るのがまずいから同じソースを使うのがいいだろう。

逆にテーブル構造も、Core Dataのオブジェクト定義に引っ張られて複雑になっていたのを正規形を崩して、Androidで使いやすいものに変更できるというメリットも出てきた。

のんびりやろう。