coroid(nicoroid) ver.0.0.0a - Androidからマイリスト追加

注意：本記述は古い。最新の情報についてはcoroid, nicoroidを参照のこと。

プログラミングは少しの間休むつもりが、簡単に実現出来そうなアイデアが浮かんだので実装してみた。

まず、サーバサイドの機能追加について。従来はニコニコ動画ランキングからの視聴のみだったが、これに加えてニコニコ動画公開マイリストに登録されている動画の視聴を行えるようにした。

次に、クライアントサイドについて。Androidの共有機能から、公開マイリストへ動画の登録を行えるようにした。

上記の機能により、Android端末でWebを閲覧している時に視聴したい動画を見つけた場合でも、視聴操作がAndroid端末で完結するようになった。

サーバサイドアプリのインストール方法は前回のエントリを参照のこと。これに加え、coroid\grails-app\conf\Config.groovyに、マイリストの設定を行う。自身のアカウントで作成した公開マイリストの番号(例えば、http://www.nicovideo.jp/mylist/1234 であれば1234)をcoroid.mylistに設定する。

クライアントアプリは、Androidにインストール後、設定画面でサーバURL(http://<Windows PCのIPアドレス>:8080/coroid/nicoContent/)を入力すればよい。

使用方法についても前回のエントリを参照のこと。マイリスト登録は、AndroidのWebブラウザにある機能「リンクの共有」(標準ブラウザでは、リンク長押し->リンクを共有)で、nicoroidを選択すればよい。なお、登録できるリンクはhttp://www.nicovideo.jp/watch/XXXX形式のもののみである。例えばgoogle検索結果のリンクは余分なパラメータが付与されているため、マイリスト登録できない。

サーバサイドアプリ(coroid ver.0.0.0a)のダウンロード(Windows PCで実行する)

クライアントサイドアプリ(nicoroid ver.0.0)のダウンロード(Android端末へインストールする) 

クライアントアプリは次のQRコードからもダウンロード可能。

なお、マイリスト登録機能が不要であれば、クライアントアプリはインストールする必要が無い。

カシオ太陽電池式(タフソーラー)腕時計の電池交換を行った

カシオのWVA-400TJというモデルの腕時計を6年半程前に購入したのだが、6年経過後辺りからアラームが鳴らなくなり、最近では頻繁に針が止まってしまうようになったため、サポートへ連絡、修理依頼を行った。

期間は配達の送り戻し期間を含めて4営業日で、料金は送料を除いて2,100円だった。サポートからこちらへの配送料は、カシオ側で負担してくれたようだ。

修理作業報告書から抜粋:

【要因】
性能低下

【修理部位】
二次電池
センターアッシー
モジュール

【修理内容】
交換
防水/防滴検査OK
検査/各部点検

ご連絡: 二次電池の性能が低下していたことによるものです。部品交換・各部点検致しました。

技術料 \0
ニジデンチ \0
機能検査・点検料金 \2,000

サポート問い合わせ時に二次電池の寿命について尋ねたところ、「特に想定しているわけではないが、大体5-6年」というような回答があった。

ちなみに、通常電池の交換料金はこちらにある通り。同じようなモデルだと、通常の電池交換も太陽電池式の電池交換も同料金になるようにしているのだろうか。

機能検査・点検料金についてはこちらに説明がある。

●腕時計の機能に関わる修理を『機能修理』と位置付けて定額修理料金としております
※定額修理料金とは、技術料金、防水検査料金、電池代金、部品代金を含んだ料金です。
機能修理対象故障例
表示部不良、時間のずれ、止まり、データ異常、センサー類不良、電波受信不良、充電不良、電池消耗早い、ボタン部動作不良、針交換、文字板交換、本巻真（リューズ）交換

お手元の腕時計の病状が上記内容に当てはまる場合は修理をお申込み下さい。 所定の基準にて修理料金を自動見積り致します。

検査の結果、正常動作の場合は以下の機能検査・点検料金を申し受けさせていただきます。
[後略]

大体の修理は2,100円のように読めるが、どうなのだろう。

参考：

• ﾀﾌｿｰﾗｰ太陽電池技術ｴｺﾄﾞﾗｲﾌﾞ – 2ch.net(の過去ログ)

補足：

• タフソーラーの電池交換はカシオの電池交換依頼ページからは申込めない。修理依頼から行うことになる。ただし私の場合はサポートに電話したところ、リペアセンターに送ってくれと言われたので、直接宅配便で送付した。
• 二次電池交換料金は、Webを検索すると0円～7500円という幅のある情報がヒットする。kakaku.comの書き込みによると、2009年1月までは二次電池交換料金は0円だったらしい。また、カシオのサイトのWeb見積もりのページ(上記修理依頼ページを進めていったところだったと思う)では、私の場合も7500円と出たので、この値段のことではないかと思う。
  • 故障箇所によっては、私の例より高額になる可能性はある。
  • 消費者としては、普通の電池式腕時計よりランニングコストやメンテナンスの面でメリットがあると信じて(メーカもそれを売りにしており)購入したと思うので、寿命が短すぎると考えるのであれば(1年持たなかった例もあるようだ)、それなりの主張をしてみてはどうか。

coroid-server – Android(HT-03A)でニコニコ動画を視聴する

おしらせ

coroidはSourceForge.JPへ移行中です。質問事項はQ&Aフォーラムへ、バグ報告や機能リクエストなどはチケット登録で行っていただけるとありがたいです。(現時点では移行中であるため、本エントリのコメントとして投稿して頂いても対応致します。)

概要

coroid-serverは、ニコニコ動画サービスに登録されている動画をAndroidで視聴可能な動画形式に変換(トランスコード)し配信するソフトウェアです。

この機能により、Android端末(HT-03Aを想定していますがNexusOneやXperia、その他非AndroidでもiPhoneなどから利用されている方もいらっしゃいます)からニコニコ動画サービスに登録されている動画が視聴できるようになります。

coroid-serverは、Windows/Linux で動作します。Android上で動作するソフトウェアではありません。

本ソフトウェアを利用するメリットは以下の通りです。

• Android端末でニコニコ動画サービスに登録された動画をコメント付きで再生できる
  • Android2.2でのFlash対応などにより、本ソフトウェア利用が唯一の方法では無くなってしまいましたが…
• 端末への負荷が少ない
  • 端末に最適なサイズにあらかじめトランスコードしますので、再生負荷(消費電力、必要CPU性能)は最も抑えられるはずです。
• マルチプラットフォーム
  • Androidに依存した仕組みでは無いため、iPhone等他のスマートフォンでも利用できます(私が試したわけではないので、正確には「利用できるようです」ですが)。

機能

ニコニコ動画サービスに関する下記の機能があります。

• HT-03A等Android端末での、ニコニコ動画登録動画各ランキング上位100位までの動画の閲覧
• 公開マイリストに登録した動画の視聴
  • 一般サイトからAndroidでのマイリスト登録はnicoroidが便利です
• 検索結果からの視聴
• ランキングから公開マイリストへの登録
  • サムネイル画像をクリックして下さい

動作環境

JDK6及びGrails1.3.1(これ以外のバージョンでは未検証)がインストールされたWindows。Grailsのインストールについてはこちら(公式サイト)やこちら(日本語で解説されているページ)を参照。

Linux(Ubuntu9.10で動作確認)も実験的ですが動作します。詳細はこちらを参照。

JDK6とGrailsをインストールし、JAVA_HOME, GRAILS_HOME, PATH環境変数を設定してください。

なお、内部でffmpegを利用していますが、どうもDEPを有効にしていると強制終了されるようです。Vista/7ではデフォルトでDEPが有効になっている場合があるらしいので、coroid-serverは起動したものの変換が上手くいかないようであれば、こちらを参考に、coroid\bin\ffmpeg.exeについてDEPを無効にしてみて下さい。

実行方法

coroid\grails-app\conf\Config.groovy をエディタで開き、coroid.saccubus.mail, coroid.saccubus.passwordにニコニコ動画サービスのid,passwordを設定します。また、coroid.mylistにこのアカウントが所有する公開マイリストの番号を設定してください。

その後、coroidディレクトリに於いて grails run-app -https コマンド(grails[スペース]run-app[スペース]-httpsです)を実行することでcoroidが起動します。初回起動時はプラグインの読み込みで結構時間がかかります。また、フレームワークの問題で、上記コマンド実行後に、下記のエラーが出て起動できない場合がランダムに発生することを確認しています。

WARNING: Dependencies cannot be resolved for plugin [hibernate] due to error: null

この場合、何度かコマンドを実行し直してみてください。

起動が完了すると、”Server running. Browse to http://localhost:8080/coroid”というようなメッセージが出ると思いますので、サーバを起動したマシンのWebブラウザでアクセスしてみて下さい。ページが開ければ正常に起動しています。

起動後、Android端末等で、http://<Windows PCのIPアドレス>:8080/coroid/ へアクセスすれば一覧が表示されます。操作の概要については以前のエントリ内動画を見てみて下さい。念のため書いておくと、Windows PCのIPアドレスはipconfigコマンドで見ることができます。

使用するポートをデフォルト値から変更したい場合は「coroid-server 少し高度な設定の説明」のエントリを参照してください。

実行方法 - SoftBank X06HT(HTC Desire)に関する補足

X06HTのデフォルトAPN設定では、HTTPは80番ポート、HTTPSは443番ポート(つまりそれぞれのwell-known port)しか通らないようになっているという情報を頂きました。

従って、X06HTからcoroidを利用する場合には、以下の2つの手段のうち、どちらかの設定で運用する必要があります。

• coroidのHTTPを80番、HTTPSを443番で動作させる
  • 設定方法はcoroid-server 少し高度な設定の説明を参照してください
• APN設定を変更し、well-known port以外でもHTTP/HTTPSを通すようにする
  • HTC Desireで80と443以外のポートを通す方法(どことなく技術屋な日々 さん)の記述を参照してください。ただしリンク先にも注記がありますが、自己責任でお願いします(私は実機を持っていませんので検証のしようもありません…)

アンインストール

coroidアンインストールは以下の2ディレクトリを削除して下さい。また、GrailsやJDKもアンインストールしたい場合は、前述「動作環境」で記載した環境変数も編集し直して下さい。

• 展開したcoroidディレクトリ
• [プロファイル・フォルダ]\[ユーザ名]\.grails\[Grailsバージョン]\projects\coroid ディレクトリ
  • “プロファイル・フォルダ”はOSのバージョンによって異なります。こちらのページの最後の方の表”Windows 2000／XPとWindows Vista／7のプロファイル・フォルダなどの対応”を参照して下さい。
  • Grails自体もアンインストールする場合は.grailsディレクトリを削除して下さい。

アップデートに関する注意事項

旧バージョンからアップデートする場合、上書きインストールは行わず、coroidディレクトリ以下を置き換えて下さい。その上で、自身で更新したConfig.groovyの内容の書き換えなどを新しいcoroidに対して行って下さい。

その他、各バージョンの互換性に関する注意点は以下のとおりです。

• ver.0.5.0
  • 対応Grailsのバージョンが1.3.1になりました。このバージョンのGrailsをダウンロードしハードディスクに展開した後、環境変数GRAILS_HOMEを更新してください。コマンドプロンプトで grails コマンドを実行すれば、設定されているgrailsのバージョンが確認できます。
  • 起動コマンドラインに、-httpsオプションが必要になりました。
  • ポート設定をデフォルト値から変更する場合、Config.groovyに修正が必要になりました。
• ver.0.3.0
  • TOPページのURLがhttp://localhost:8080/coroid/nicoContent/ からhttp://localhost:8080/coroid/ に変わりました。本バージョンでは旧URLへアクセスできますが、将来的には保証されません。
  • JavaScriptを使用するようになりました。本バージョンではJavaScriptを切っていても動作しますが、将来的には保証されません。
• ver.0.2.0
  • 対応Grailsのバージョンが1.2.1になりました。本バージョンのGrailsをダウンロードしハードディスクに展開した後、環境変数GRAILS_HOMEを更新してください。コマンドプロンプトで grails コマンドを実行すれば、設定されているgrailsのバージョンが確認できます。

補足

• 付属のffmpegを使うとかなり音質が悪くなるようです。これはffmpeg内蔵aacエンコーダを利用しているからで、よく利用されているFAACを利用すれば改善します。ただ、FAACをリンクしたffmpegはGPLv3で配布できないため、同梱していません。FAACを利用したい場合、ソースコードから自力でビルドするか、2chにアップされているffmpeg.exeを自己責任で利用してみてください。なお、さきゅばす用でない一般的なffmpegは利用できません。
  • ffmpeg.exeは coroid\bin ディレクトリに配置してください。
  • faacを利用する場合のオプションは –acodec libfaac です。後述Config.groovyファイル該当行を書き換えて下さい。
  • 同梱のffmpeg.exeでも、オプションに-ab 192000 等を追加し、音声のビットレートを上げれば多少改善するようですが…
• ffmpegのオプションを変更するには、前述Config.groovy中の coroid.ffmpeg.optionを修正する。
  • デフォルトオプションでは、どうも再生できない動画が多い。-qmaxの値が小さすぎのようだ。40から50程度にすると再生可能になるようだが、画質は低下する。 大分改善されたはず。
  • ffmpegのオプションに詳しい方がいれば… 

ダウンロード

coroid-server最新版 (2010/06/08 ver.0.5.1)をダウンロードする

バイナリ部のソースコードはさきゅばす拡張ダウンロードページから。一部Java/Groovy部のソースは上記coroid-serverに同梱されています。

現在、配布はSourceForge.JPで行うよう変更しました。

さきゅばすのNicoBrowser拡張ver.1.3.5 実行可能ファイル配布

以前までのバージョンでは、オリジナル版さきゅばすに上書きインストールする形の、差分ファイルのみを配布していたが、今回、実行可能な形で配布してみる。

その他の変更点として、以前、ライセンスをAGPLv3としていたが、GPLv3とAGPLv3のソースコード単位での混在は不可能だそうだ。このため、オリジナル版に従いGPLv3に戻している。

機能的には、前回のバージョンから差異はない。

現在、同梱のffmpegについて、以下の点が問題になるかもしれないと考えている。

• 同梱のffmpegはGPLv3に適合するよう、FAACをリンクしていない。動画エンコードについて明るくないため詳細は分からないのだが、公式サイトによると”FAAC is an MPEG-4 and MPEG-2 AAC encoder.”ということなので、AACエンコードに不都合があるかもしれない。
  • [追記]H.264エンコード動画で、低ビットレート時に音質がかなり悪くなるのを確認した(64kbpsで確認)。
  • FAACが必要であれば、自力でffmpegをビルドするか、にちゃんねるのさきゅばすスレッドでアップされているffmpeg.exeに置き換える。
• “HE-AAC のサンプリングレートが半分の値で認識されたり、PS ありで本来はステレオ音声のものがモノラルとして認識されたり”する可能性がある。
  • 参考
  • これについては上記リンク先のパッチを当てるだけなので対策可能だと考えるが、現在でも発生する不具合なのか確認できなかったため適用していない。
• オリジナル版のffmpegと比較して、大幅にオプションが変更になっている。このため、同梱optionディレクトリ以下のファイルは正常に動作しない可能性が高い。

ダウンロードはこちらから。

FEST-Swingを利用する(7) EDTで発生した例外をJUnitで検知するの追補

EDTで発生した例外のハンドラをカスタム化するにはsun.awt.exception.handlerプロパティを使用する、と以前記載した。

先日リリースされたFEST-Swing 1.2a4では、カスタム化するためのクラスAWTExceptionHandlerInstallerが用意されたようだ。こちらを使用する方が良いかもしれない。ただし、実装上は、内部で上記プロパティを利用しているので差異は無い。

これに関連してJavaのBug ID:4714232 RFE: replace sun.awt.exception.handler system property with official API の存在を知ったのだが、Java7ではこのプロパティを用いる方法を採らなくても良くなるらしい(EDTも通常のスレッド同様setUncaughtExceptionHandlerメソッドを使えばよくなる？)。

追記：

現在のバージョンでも特定の条件下以外はsetUncaughtExceptionHandlerで問題ないようだ。特定の条件というのは、モーダルダイアログが表示されている状態であり、この状態では設定した例外ハンドラが使用されない、というバグらしい。下記のコードは、1.6.0_14-b08では確かにハンドラが用いられていない。1.7.0-ea-b78では想定通りの動作となった(関連バグ BugID:6727884 Some Uncaught Exceptions are no longer getting sent to the Uncaught Exception Handlers より)。

import java.awt.event.ActionEvent;

import java.awt.event.ActionListener;

import javax.swing.JButton;

import javax.swing.JDialog;

import javax.swing.JFrame;

import javax.swing.SwingUtilities;

public class MyFrame extends JFrame {

    public MyFrame() {

        super();

        setTitle("メインウィンドウ");

        setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);

        JButton b = new JButton("起動");

        b.addActionListener(new ActionListener() {

            public void actionPerformed(ActionEvent e) {

                JDialog d = new JDialog(MyFrame.this, "モーダルダイアログ");

                d.setModal(true);

                JButton b2 = new JButton("例外");

                b2.addActionListener(new ActionListener() {

                    public void actionPerformed(ActionEvent e) {

                        throw new RuntimeException("例外送出");

                    }

                });

                d.add(b2);

                d.pack();

                d.setVisible(true);

            }

        });

        add(b);

        pack();

    }

    public static void main(String[] args) {

        SwingUtilities.invokeLater(new Runnable() {

            public void run() {

                new MyFrame().setVisible(true);

                // EDT例外ハンドラの設定

                Thread.currentThread().setUncaughtExceptionHandler(new Thread.UncaughtExceptionHandler() {

                    public void uncaughtException(Thread t, Throwable e) {

                        System.out.println("キャッチされなかった例外:" + e.getMessage() + "(" + t.getName() + ")");

                    }

                });

            }

        });

    }

}

ネットワークスペシャリスト試験に合格した

てっきり落ちたものだと思って確認していなかったのだが、先日ネットワークスペシャリストの合格証書が届いた。

この試験、平成12年までは「ネットワークスペシャリスト」、平成13年から20年までは「テクニカルエンジニア(ネットワーク)」と名前が変わり、更に21年から「ネットワークスペシャリスト」に名前が戻った(参考)。

転職サイトで保有資格に追加しようとしたのだが、「旧ネットワークスペシャリスト」「テクニカルエンジニア(ネットワーク)」の選択肢しかないところがあり、どちらにチェックを付けるべきなのか分からない、という事態に。具体的に言うとイーキャリアなのだが。

MacのJavaでファイル名を扱う際には気を付けた方が良い、らしい

QTJのエントリでAppleのJavaを思い出したついでに。

年末、合成文字の件でUTF-8に興味を持ったので、少し調査を行った。当時は、UnicodeとUTF-8がどういう関係[1]にあるのかもよく知らず、とりあえずユニバーサルに、何も気にしなくても使用できる便利なもの、という程度の認識だった。

私自身はMacを所有しておらず、確認する術がなかった。そこで、不明な点についてはにちゃんねるのスレッド[2]で質問させていただいた。本エントリを読むよりこちらのスレッドを見た方がわかりやすいかもしれない。

1点目。ファイル名の文字コードについて、Windows(NTFS)ではUnicodeで管理される[3]。ここでUnicodeという言い方はおそらく正しくなく、本来はUTF-8というべきなのだと思う。

[追記: UTF-16だそうだ…というより、ファイルシステム上は文字列というより単なるバイナリ列として扱われている、というほうが正しいのだろうか。

NTFS allows any sequence of 16-bit values for name encoding (file names, stream names, index names, etc.). This means UTF-16 codepoints are supported, but the file system does not check whether a sequence is valid UTF-16 (it allows any sequence of short values, not restricted to those in the Unicode standard).

]

Windowsのファイル名としては、合成文字について、NFD正規化された状態であろうがNFC正規化された状態であろうが、そのまま保存される。したがって、同じ名前の(ようにみえる)ファイルが同一ディレクトリ下に存在する可能性がある。Windowsが同一名であると認識できるのは、文字列が同一バイト列から成る場合だけである。これは、Linuxでも同様のようだ。なお、濁音をNFD正規化した場合、以前のエントリの通り、Windows Vistaより前のバージョン(Windows XPなど)では文字化けする。

2点目。Mac OS(HFS+)でもUTF-8だが、NFD正規化されたコードが用いられる。ただしAppleが独自に変形したNFD正規化であり、正確には正規化とは呼べない[4]。このコード体系は、UTF8-MACと俗称されている。

1点目と2点目より。Windows(やLinux)で日本語をIMEで濁音を入力した場合、変換される文字はNFC正規化されたものであるため、ファイル名の濁音は、一般的にはNFC正規化された文字が使用される。一方でMacではIMEがどう変換しようと濁音はNFD正規化された状態で保存される。この差異が原因で、FTPやWebDAVといったファイル転送を伴なうプロトコル/サービスでしばしば問題が発生する。

3点目。MacのJavaでjava.io.Fileのコンストラクタ引数にファイル名を与える際には、UTF8-MAC文字列である必要はない。NFC正規化文字列を与えてもシステムコールやファイルシステムでUTF8-MACに変換される。一方で、WindowsのSun JDKでは、引数に与えた文字列がそのままファイル名に用いられる。つまり、NFC正規化文字列を与えた場合とNFDの場合では異なるファイルが作られる。

4点目。Apple実装のMac Javaでは、Fileの各種メソッドから得られるString型のファイル名は、NFC正規化されたものである(UTF8-MAC符号化されたものではない)。

2点目と4点目より。Macの実際のファイル名はNFD正規化(に似たUTF8-MAC符号化)された文字列であるのに対し、Java上ではNFC正規化された文字列で扱われることになる。Javaだけで完結するシステムであれば問題ないかもしれないが、他の言語のプログラムと連携するような場合には問題が起こりそうな気がする。

再度2点目と4点目より。前述した通り、UTF8-MACは正規化されていない文字がある。しかしFileのメソッドで取得した文字列はNFC正規化される。したがって、異なる2つのファイル名を取得しようとした場合でも、区別の付かない同一文字列が返ってくる場合がある。具体的には”雪羽”と”雪羽”はUTF8-MACにおいては区別される([4]より。”羽”はU+7FBD、”羽”はU+FA1E)が、NFC正規化するとどちらも同一の文字列”雪羽”になる(NFD正規化も同様)。つまり、ファイルシステム上は別個のものとして扱われるがJava上では同一とみなされてしまう。

5点目。NFC正規化やNFD正規化を行う際、Javaではjava.text.Normalizerクラスのメソッドを使用すればよいのだが、導入されたのがJava6である。MacでJava6以降を動作条件にしても良いのか分からない。

参考：

• [1]UnicodeとUTF-8の違いは？ – おつあり
• [2]MacでJava その4 172-187 – 2ch.net
• [3]Windows のファイル名の文字コードについて – IBM Linux at IBM
• [4]Text Encodings in VFS – Apple Developer Connection
• JIS X 0213の改正は、文字コードにどんな未来をもたらすか（7） 番外編：改正JIS X 0213とUnicodeの等価属性／正規化について（上） 及び (下) – INTERNET Watch

[読書]QuickTime for Java – A Developer’s Notebook

だいぶ時期を外してしまったが、本棚整理時に発見したので紹介。

2005年発刊のもので、私が読んだのは2007年終わりごろ。この頃のQuickTimeバージョンは6.Xであり、現在の最新バージョンが7であるため、もしかしたら記述が古くなっている可能性はある。

また、そもそもAppleがJavaに力を入れておらず、おそらくQTJ自体フェードアウトさせるのではないかと思っているので、今からQTJを学ぶのは如何なものか。

それはさておき、QTJはバージョン6.1以降で大きくAPIが変わった。現在はどうか知らないが、2007年当時はAppleの開発者ページでも古いAPIでの解説が多くを占めるなど、Appleのサイトはあまり役立つとは言い難かった。

そういった中で、本書と、オライリー社のサイト”ONJava”(参考リンク)は、入門用としてとっつきやすく、当時情報はこれらから入手していた。

本書は、日本語版では”開発者ノートシリーズ”として出版されているシリーズである。このシリーズに対するamazonの評判などを見て分かる通り、網羅的な解説が為されるシリーズでなく、深い知識を得ようとする目的には向いていない。ただ、「こういうことができる」ということと、「こうやればできる」ということが簡潔に書かれているため、初めて該当プロダクトについて学ぶのには良い。

したがって、全くQTJの知識が無い人が最初の一冊として購入するのにはベストだと考える。

その次のステップのための書籍があるかというと、無さそうなのだが。

余談だがTIPSとして。QuickTime APIを知っておけば、Pro版でしか使えない機能もAPIから呼び出せる、という利点がある(Javaを利用する必要はないのだが)。

過去のQTJに関するエントリ：

• QuickTime for Javaで字幕をつけてみる
• iPod touchで字幕表示
• QuickTime for JavaのDeprecatedなpackage
• QTJ for WindowsではdrawTextで文字列を書き出せない？
• QuickTime for JavaでiPod用動画を作成する

Androidの位置情報が未だに昔の住所を指す

現在の住所に転居してから数ヶ月が経過するが、未だにHT-03AのWi-fi情報から得られる位置情報が昔の住居のままだ。

一方で、iPod touchの方はこちらで言及したサイトの登録が効いたのか、登録後1ヶ月強で現住所を指すようになった。

iPod touchもAndroidも同じ会社のサービスを利用していると思っていたのだが、違うのだろうか。

Androidでメールが受信できなくなったので初期化した

HT-03Aを購入後、かなり初期(まだ1.6になっていなかった頃)から、「メール」アプリでメールの新着を自動通知してくれる機能が働かなくなっていた。

そこで今回、思い切ってシステムリカバリユーティリティを利用した初期化を行ってみた。

結果、今のところ正常に通知してくれるようになっている、ように見える。

これはこれで良かったのだが、再設定が面倒だ。上記リンク先にある通り、連絡先はGmailと同期をとることで回復できるのだが、アプリのインストールとそれぞれのアプリの設定をやり直さないといけない。

動作は、体感でかなり速くなったように感じる。

追記：

これまで使ってきたアプリケーションをインストールしてみると、軽快さは初期化前と大差無くなったように感じる。更に、メール自動受信も機能しなくなってしまった。メールについてはデフォルトアプリの使用をやめて、K-9 MAILというアプリを使用してみることにした。このアプリはエラーログなども出力されるようなので受信で気なかった場合の原因が何かわかるかもしれない。現状では自動受信は、初回に一度タイムアウトが出ていたが、その回以外は正常に機能しているようだ。

Androidでビデオへオーバレイできるか

以前のエントリ「【ダウンロード違法化直前】HT-03Aでニコニコ動画をストリーミングその2」から派生して。

上記リンク先では、ニコニコ動画をAndroidで視聴する方法のひとつを提示した。その方法とは、サーバ側でAndroidで再生可能なフォーマットに変換し、Androidはそのファイルをストリーム再生する、というものであった。コメントも動画に埋め込んでしまうことで、コメントも動画の一部として再生させた。

しかし、コメントも動画の一部としてしまった場合、コメントだけの更新が不可能になり利便性が低いのではないかという意見が有った。

ここで、コメントを動画に埋め込む方式(エンベッド方式と呼称)と、クライアント側で動画の上にコメントを描画する方式(オーバレイ方式と呼称)の利点と欠点を挙げる。まず、エンベッド方式のメリットとして、以下の点が挙げられる。

• 端末依存性を無くすことができる。
• (前回の方式で例えると)mp4ストリーム再生可能な機種であれば再生ができる。AndroidもiPhoneも再生可能である。
• オーバレイ方式では、専用のクライアントアプリが必要である。
• 端末の処理負荷を低減できる。これは反応速度や電池の持ちに影響する。
• エンベッド方式では、コメントを表示する場合に動画再生処理以外の処理が不要。
• オーバレイ方式では、動画再生処理+コメント表示処理が必要。

一方、デメリットとしては以下の点が考えられる。

• コメントを表示する/しないのリアルタイム変更が不能。
• エンベッド方式では、変換要求時までに決定する必要があり、切り替える場合はそれぞれに対応する変換処理が必要になる。
• オーバレイ方式では、再生時に合成するため、再生中に切り替えることが可能。
• コメントを最新化する場合の処理負荷(ここでは、キャッシュ保存に関する法的な問題は考えない)
• エンベッド方式では、画像変換処理をやり直す必要がある。
• オーバレイ方式では、コメントデータのみを再取得すれば良い。

個人的には、携帯端末でPCほどの多機能性は不要であり、エンベッド方式で十分だと考えている。

ところで、Androidで動画にオーバレイすることは可能なのだろうか。

既存のアプリGoogle Goggles(日本語解説)やLayer(紹介動画)では、カメラから取り込んだ映像にウィジェットをオーバレイしているが、どうもビデオへのオーバレイはHT-03Aの現行OSであるバージョン1.6では不可能なようだ。

FrameLayoutを用いればウィジェットを重ねあわせることができる。また、SurfaceViewは背景を透明化することができる(参考)。不透明な動画再生Viewを下に、透明なコメント再生Viewを上にして重ねれば上手く行くかと考えたのだが、透明化すると下のViewが見えるようになるわけではなく、下のActivityが見えてしまった。つまり下のViewも透過してしまうようだ。

では、動画再生Activityとコメント再生Activity、というようにActivityを分けてしまえば良いのかというと、動画再生Activityがバックグランドに回った時点で動画再生は停止してしまい、こちらもうまくいかなかった。

さきゅばすが利用しているffmpegのavfilterや、以前JMFで試したようなeffect filterといった、動画像を画面描画前にフィルタ処理するようなAPIも、調べた限りではなさそうだ。

ただ、API Level 5、つまりAndroid2.0ではSurficeViewにsetZOrderMediaOverlayというメソッドが追加されており、これを利用すれば可能になるかもしれない。

しかし透過させるために前述の方法では特定のViewだけ透過させることは不可能であるしどうするのか、と思っていたのだが、Color.TRANSPARENTという色が定義されているようで、これを用いれば良いのかもしれない(ちなみにAndroidで使用するのはjava.awt.Colorではなくandroid.graphics.Colorだ)。

調査が中途半端になってしまったが、他に行わなければならないことが多くあるため、これよりいくらかの期間プログラミングを休むことにする。なお、書きかけのプログラミング関連エントリもいくつかあるのだが、これらについては簡単に終えられるようであれば完成させて投稿したい。

追記：

上で「どうもビデオへのオーバレイはHT-03Aの現行OSであるバージョン1.6では不可能なようだ。」というように書いたが、ドワンゴのインターンシップでAndroid用ニコニコ動画プレーヤを作成した方の記事を読んだところ、別に問題なく行えるようだ[参考:hiroki - ドワンゴインターンで作ったもの, 第1回名古屋Android勉強会 でインターンについて発表してきた]。

また、「調査が中途半端になってしまったが、」と書いたが、こちらについてもよくよく考えると今に始まったことではなかった。

Android SDK Toolsを更新できない

Android SDKを更新しようとしてSDK Setup.exeを起動したところ、Android SDK Tools, revision 4も更新対象になっていた。

そこでこのToolsも更新対象に含めて更新を行ったのだが、以下のようなエラーが出て更新が正常に完了しない。

Downloading Android SDK Tools, revision 4
Installing Android SDK Tools, revision 4
Failed to rename directory E:\android-sdk\tools to E:\android-sdk\temp\ToolPackage.old01
-= Warning ! =-
A folder failed to be renamed or moved. On Windows this typically means that a program is using that folder (for example Windows Explorer.) Please close all running programs that may be locking the directory 'E:\android-sdk\tools' and try again.

toolsディレクトリ内のファイルを、何かのプロセスが掴んでいるためリネームできない、ということのようだ。

そこで、ロックしているプロセスを調べたところ、ロックしているのは自分自身、つまりSDK Setup.exe(正確にはこのexeが呼んでいるjava.exeやcmd.exe)だった。

どうもWindowsではtoolsの更新をこの更新ツールでは行えないようだ。

解決策としては、最新のAndroidSDK(現時点ではandroid-sdk_r04-windows.zip)をダウンロードして展開し、この中のToolsディレクトリを、自分が使用しているSDKディレクトリにコピーすればよい。

本件は Issue 4410: folder failed to be renamed or moved on SDK install として登録されている。