4月 092017
 

タイトル通りなのですが、数日間ブログが閲覧不能になっていまして、今日まで気付きませんでした。
ご不便をおかけして申し訳ありません。

詳細な原因をつかむ前に直ってしまったので、若干腑に落ちてないですが、プラグインで内部エラー起こしてたっぽいです。pluginsディレクトリ内で更新日時が最も新しかったのがJetpackで、4月5日にアップデートしてたようです。最早、記憶にないけど。Jetpackを更にアップデートしたら解決しました。何なんだ。

アクセス解析を見ると4月5日からアクセス数がガクッと落ちてました。それでも若干のアクセスログがあったのはキャッシュかな。

時期は違いますが、前科があるようですね、Jetpack。便利なだけに困ったもんだ。

休日の一部をブログメンテに費やすと激萎えしますし、就職してからあまりこちらの面倒を見られないことを痛感します。おそらくアップデートが記憶に残らないほど流れ作業化して、そこから最終確認が抜け落ちてたのだと思います。

ひとまずは確認を怠らなければいい話なので、今後気をつけます。

2月 112017
 

普段Windowsを使っていて、隠しファイルは表示しているんですが、システムファイルは非表示にしてました。

そのせいで、Windows Media Playerが曲に埋め込まれているアルバムアートを、勝手に抜き出して同じディレクトリにシステムファイルとして縮小版を保存する、という挙動を勝手にしていることを見落としていました。

  • AlbumArtSmall.jpg
  • Folder.jpg

上記の2ファイルがシステムファイル属性で保存されます。こういう汚いファイルの散らかし方はいかにもMSだなぁ。

私はアルバムアートをfolder.jpgとして保存することがあって、それで上記ファイルと衝突して気が付きました(Windowsのファイルシステムではアルファベットの大小を区別しません)。

そんな感じで実際に不都合が生じているので、対処します。

Continue reading »

12月 102016
 

つい最近、このブログで過去に掲載したソースコードの利用に関して問い合わせがありました。ご丁寧にありがとうございます。そんな質問来るとは思いませんでした。

大したものは書いてないにせよ、利用条件は明示しておいたほうが使いやすいこともあるのかなと思いました。ので、簡単にルールを決めました。

  • ライセンスの明示していないソースコードについては、
    • 他の条件を満たす限り、複製・改変・再配布は自由にしてよい。利用報告は不要。
    • 基本的に権利表記は不要だが、ほぼオリジナルのままの状態で、著作者を偽って再配布することは禁止とする(本サイト掲載のものがオリジナルであることを保証するため)。
      • 例えば、本サイト掲載のソースコードを組み込んだソフトウェアのソースコードを公開したいときは、該当部分について、著作者(wizaman)や当サイトへのリンクをどこかわかる場所に記載するのが無難。
    • 無保証のため、自己責任で利用すること。

これは現段階で考えたものですので、あとで変える可能性はあります。「このサイトについて」にて、最新の条件はまとめていきますので、実際に利用する時はそちらを参照してください。

上記の条件はちょっとだけ文面が長くなっちゃいましたが、考えていることは、著作権表記と無保証を示すMITライセンスを参考にしています。ただ、ちょっとしたコードを利用するのに著作権表記が必ず必要というのは使いにくいので、そのためのあれやこれやを定義した感じです。

ソースコードの公開さえしなければ特に制限はないです。が、ソースコードを公開する場合には、こちらがオリジナルであるということが誤解されて面倒事に発展するのは避けたいので、そこだけ誤解のないように配慮することをお願いしています。権利主張より自衛が狙いです。

11月 142016
 

前回の記事「AndroidのpersistentDataPathがカオス」の続きです。

UnityでAndroidManifest.xmlを利用する方法のメモです。

前回の記事からの続き

※この節は前回の記事からの誘導なので、UnityでのAndroidManifest.xml利用方法を知りたいだけの人は読み飛ばしてください。

「外部」のアプリ固有パスにしかアクセスしないならば、Android 4.4(KitKat)以降は権限が不要ですが、それより前のバージョンも対象にする場合には、互換性のために権限を持たせることになるという話でした。しかし、これは無駄なので、特定のバージョン以降でその権限を要求しないようにする設定項目が追加されました。

ただ、やはりというか、残念なことにUnity側でそれを指定する設定は存在しないんですね。なので、もう少しAndroid側に寄って、自分で直接設定を書くことにしましょう。そのための手段ならUnityも提供しています。

Androidアプリの設定は、AndroidManifest.xmlというファイルにまとめられます。Unityから直接Androidアプリをビルドするときも、プロジェクトのルート直下に一時的に作られるTemp/StagingAreaディレクトリに、自動生成されたAndroidManifest.xmlがあることが確認できます。これだけ見ると、Androidプロジェクトを吐き出させて、AndroidManifest.xmlを編集してから、自前でAndroidのビルドを行わなければいけないようにも思えますが、そこまで不便ではありません。

これから任意のAndroidManifest.xmlをUnityで利用するための方法を説明していきます。

やりたいこと

WRITE_EXTERNAL_STORAGE権限を、Android 4.3以前では要求し、4.4以降では要求しない、という設定を指定したいです。

uses-permissionタグが権限を与える設定ですが、これの属性としてandroid:maxSdkVersionを与えてやればいいです。指定する値は、その権限が有効な最大APIレベルです。

上記記事にも書いてある通り、uses-sdkタグにも同名の属性がありますが、まったく別物なので、調べ物するときには気をつけてください。

WRITE_EXTERNAL_STORAGEをAndroid 4.4(API Level 19)より前のバージョンでのみ要求したい場合、API Level 18を最大として設定すればいいので、下記の設定をAndroidManifest.xmlに書きたいわけです。

<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" android:maxSdkVersion="18" />

Continue reading »

10月 112016
 

  • 2017/05/06
    • targetSdkVersionの決定方法が間違っていたので修正。
  • 2017/02/06
    • Unity 5.3.6での仕様変更について追記。
  • 2016/11/14
    • Android 4.4でのREAD_EXTERNAL_STORAGE対応、maxSdkVersionについて追記。
    • Android 6.0でのユーザによる権限の付け外しについて追記。
    • 掲載スクリプトの読み取り可能チェック処理でREAD_EXTERNAL_STORAGEを見ないように修正し、実行結果を更新。
    • 一部、誤植の修正。

Unityで外部ファイルにデータを読み書きするとき、普通Application.persistentDataPathを使うと思うのですが、AndroidだけpersistentDataPathの返すパスが権限によって変わります。

これドキュメントに書かなきゃいけない重要事項だと思うんですが、全く触れられていない・・・。

詳しいことはこれから説明していきますが、やりたいことによっては必要な追加権限があるにも関わらず、それを設定したときには、persistentDataPathはセーブデータの保存先として信用できないという衝撃的な問題が存在します。

(2017/02/06追記)Unity 5.3.6でpersistentDataPathおよびtemporaryCachePathがAndroid 4.4(コードネーム:KitKat、API Level 19)以降、「外部」を指すよう仕様変更となったそうです(リリースノート)。また混乱することを・・・。いずれにせよ、AndroidでpersistentDataPathを利用することは推奨しません。

以下、死ぬほど長いまとめ書きましたので、覚悟してください。

Continue reading »

9月 042016
 

引き続きUnityの記事を書き溜めていたので放出。

Unityでシリアライズ可能なコレクションは、Listだけです。但し、当然ですが、型引数もシリアライズ可能型を指定してやる前提です。

C#のListはいわゆる配列リストってやつで、C++でいうvector、JavaでいうArrayListに相当します。C#にもArrayListは存在しますが、古い機能のため非ジェネリックです。

ともかく、Listは内部実装として配列を持つため、List<T>ならば、T型配列としてUnityがシリアライズしてくれるわけですね。Listだけシリアライズ可能なのはまあ納得です。

とはいえ、Listだけで事足りるかというと、LinkedList(連結リスト、線形リスト)やDictionary(ハッシュマップ)あたりは欲しい感じです。

ScriptableObjectやJsonUtilityでシリアライズ・デシリアライズするとき、ISerializationCallbackReceiverを実装していると、シリアライズ前、デシリアライズ後に決まったメソッドが呼ばれます。これを利用してコレクションをListに変換してシリアライズできます。公式ドキュメントでもこれを利用してDictionaryをシリアライズ・デシリアライズするサンプルが掲載されています。

※OnBeforeSerializeとOnAfterDeserializeを実装しますが、何故かOnBeforeSerializeに解説が集中しているのでそっちのリンクを掲載。

この場合、インスペクタを介したリアルタイムな編集はできませんが、永続化が目的ならばこれで十分でしょう。LinkedListやDictionaryをインスペクタで触れるようにするとむしろ怖い。

そんなこんなで、Unityで使用可能なC#のコレクションをISerializationCallbackReceiver実装クラスで一通りラップしてみたので、以下に公開します。

Continue reading »

9月 042016
 

なんだかんだUnityとの付き合いが多いので、メモがてらあんまりネット上で見なかったり見つけにくかったりする情報をまとめる感じで。

今回はenum型(列挙型、列挙体)のシリアライズについての話です。前回「C#のenumの使い方」の続きでもあります。本当は同じ日に仕上げるつもりでしたが、長くなったので分離しました。enumそのものの使い方は前回の記事にまとめておいたので、その知識は前提とします。

Continue reading »

Top