アレが来ないの♪

とかって心配が生まれてこの方一度も無いあたしです。


使用中のnexus7 (2012)にLollipopの更新が来ません。

何度か最新の確認をしているんですが、全くです。

OTAが全く来ませんし、とても重くなるとかの問題も発生して居るみたいなので、しばらくは無理ですね。



そんな感じで、全く更新はしていないのですが、ここ数週間というか、数回と言うべきか？

土日に放置しているnexus7が落ちているのです。


会社で利用していることも有り、何も使っていない土日において充電しっぱなしと言うのもどうかと思いまして、帰宅時に電源を切ってしまう方のタップに接続しているんですが、

買ったのは2013年の1月頃だったかと思うのですが？

それから毎週土日は電源を抜いて放置です。

電池もへたってきたんじゃ無いかとか、思うでしょ？？


でも、そんなことは無いんですよ、１００％まで充電して有る状態から、月曜日の朝（もしくは火曜日の朝）出社してから、電池のメーターを見ても、減っているのは、僅か数％

大抵が９９％か９８％とか、ほぼ減っていない。


しかし、こんな記事を見つけたのです。

http://d.hatena.ne.jp/hinkyaku49/20130511/1368285900

あたしはnexus7の末期に買ったんですが・・・この人は出てすぐ買ったのでしょうか？

だとすれば、今のあたしが、充電１００％なのに電池が切れちゃう的な問題は、時期的に同じ症状の可能性があるわね？

って言うか、充電ランプが点灯すれば、そんな問題も無いのに！

電源が入っている状態だと、充電しているのかしていないのかが分からない。
ついでに言うと、起動中は１００％に成ると充電を止めるらしい。

まぁ、だから、電源を切った状態で、充電をする必要があるのでしょうけど。


会社に来ても１％くらいしか減ってないよ？

ではなくて、３５％位なのに１００％と表示されていたのかもしれません？
１００％なので３５％食らいでも充電しなかったのかもしれません？

分かりませんね？


取りあえず、フル充電には６時間くらい掛かるらしいのですが？

画面の表示はすでに８０％あたり、
まだ１時間しか経っていません。

あと5時間は画面上の表示が充電完了でも、繋いでいないとダメっぽいですね。


それはそれとして、
nexus7は完全放電すると充電出来ない持病があるとかって記事も見つけましたが、

本当の意味で完全放電してしまうと、充電器側にとって、繋がっているのか、繋がっていないのかすら分からない状態になります。これはnexus7だけの問題ではありません。

なので、完全放電状態の機器に再び充電出来るようにするには、

充電器に繋いで数時間〜数日待つと、
充電器はごく僅かずつの電力を常に出力しているので、その微量の電気で少しずつ充電が行われ、バッテリの保護回路が起動する状態まで電力が蓄積されると、普通に充電出来るようになります。

当然、保護回路の種類や、充電容量などにより、普通に充電出来るようになるまでの時間は異なります。

ちなみに、ACアダプタを差していると充電していなくても電力が消費されると言われる所以がこの機能のためです。

あたしが持っている物の中で、完全放電（数年）の状態の物を再び充電出来るようになるまでに掛かった時間は1週間です。

何度も、途中で捨てて新しいのを買おうかと思ったことか・・・

安いものならそっちの方が全然良いとは思いますけどね？

9時から始めて６時間後というと15時ですね。結構長いです。

OneDrive Sync Enginが正常に動作しません。

ファイルを追加しても更新をしない。
一時停止したり、なんだりを繰り返していると、「再起動しています」と表示され、ファイルの検索中からやり直しです。

ファイル数が５万を超えているのが原因でしょうか？

書き込んだ瞬間にクラウドにアップロードしろとか？　そういう事は考えていないんですよ、遅くても良いので確実にやって欲しいのです。

その点、DropBoxは途中でクライアントが落ちることもありませんし、大量のファイルを一気に移動したりしても特に問題なく動いています。


Bitcaseの時もYahooBoxのときもそうでしたが、OneDriveでもダメのようです。

まぁ、それをいったらVSもそうでしたね、
ファイルを更新すると、本来はビルドしてから実行されるのですが、

とあるプロジェクト（Ｇ単位）の場合、ファイルを変更しても、全く無反応です。
ソリューション全体の中で、ごく一部のプロジェクトだけなんですよね。

わけわかりません。
（ＶＳでは、ソリューション単位やプロジェクト単位でその手の設定は出来ず、VS全体の設定です。）

おそらく、Windowsのファイルやらディレクトリの変更検出の仕組みその物が、ファイル数とか、ハンドル数の上限があって、それのせいであぶれているのが有るんじゃ無いかと思うんです。
（FileSystemWatcher の事です。）

そもそも、ファイル更新通知は非同期に送られてくる時点で、ファイル更新の検知としては精度が低いんですから、システム負荷にならないように、ゆっくり確実に行って欲しいです。

システムの監視が行き渡らないので有れば、ファイルの情報をアプリ側で保持し、　特に、ファイルIDですね、これでファイル名が変更されても一意性を確保できますので、NTFSのジャーナルファイル（使い方知らない）などと併せて、移動なども上手く検出出来るようになれば良いですね。

階段から落ちました。

ついさっきです。


ちょ〜足痛いです。


このビルに通い始めて、４，５年になるかと思いますが、
あたしが、階段から落ちたのはこれで３回目です。


１年くらいに１度落ちているという感じですね？

ちなみに落ちそうになるのは数ヶ月に１度有るので、１割くらいの確率で、本当に落ちていると言うことでしょうか？


階段を降りながら、あれこれしているのが悪いことは分かっていますが、あれこれをし終わってから出かけるとか、あれこれするために何処かで立ち止まるとか、そういう事をすると、数分のロスが発生するので、ちょっと困ります。

ちょっと困るのと、年に一度、かなり困るのとどっちが良いのかと言うことですよね？

年に一度落ちて、５日くらい掛けて治したとして、
その間は歩行速度が２／３に落ちたとして、

一日１時間程度歩いているあたしとしては、ロスは３０分くらいでしょうか？なので×５で１５０分／年の無駄が発生しているわけですね。


それに対し、２２日／月主にお昼休みだけとすると、１日に月３分準備に欠けた場合１ヶ月で６６分　１年で７９２分

重大な故障を起こさない限りは、ながらの方が良いと言うことですよね？


なので、注意力が散漫になりすぎるような行動をする場合は、止まりましょう。

足を比ねって済むくらいのないようなら、ゆっくり降りれば良いでしょうか？


ところで、捻挫をしたくらいで病院に行くのもアレなので、薬局でサロンパスを買ってきました。

愛用のタイガーバームも売っては居ましたが、会社で使うので、ちょっとね？


で・・・まぁ箱のサイズも小さいですし、サイズも箱に記載されていたので小さいのは分かっていたのですが・・・


めっちゃ小さいよね？

驚きの小ささだよ！

そして、何を考えているのか分からないけど、２枚が一つのフィルムにくっついて格納されていて、取り扱いがえらく面倒。

２枚ずつ使えって事かな？

取りあえず、ひねった左足の足首周辺に１枚貼りました。

仕事を始めて３０分。

足から、膏薬が蒸発してきたので、目が痛い。
そして、かなり臭う。

これならタイガーバームの方が良かったかもしれない。

枚数が半分で、これの倍くらいサイズがありそうなのが、倍の値段で売ってたんだけど、
そっちは臭わないとか書いてあったから、それじゃ無いとダメなのかもしれない。

以前のサロンパスのＣＭで、ヒラメ貼りとかって、喫茶店の従業員が足に貼っていましたが、こんなに臭っては仕事出来ないですよね〜

取りあえず、余りの３９枚は冷蔵庫に入れておきました。

次誰か使うでしょうか？？

実は１６日に書いていたのですが、途中で忙しくなり消してしまったので、また１から書き直しです。

先日の最後にフォルダの作成方法について書きました。

また、フォルダをたどっていくときの注意点についても書きました。

あと、何が必要でしょうか？？


ファイルの送信ですね？


ファイルの送信は、色々なところに紹介されているようなMIME形式でMethod POSTを利用するのが最も楽です。

先日までの手段を用いて、フォルダのupload_locationを取得したら、それに対して、methodをPOSTに設定して

UploadFileで送信するだけで終わりです。

始め、ご丁寧にMIMEのmulti-partを作成してUploadDataを使って送信しようとしたんですが、"Content-Type"でエラーが出て送信が出来なかったんですよ。

ですので、送信先と、送信元で違うファイル名を設定することが出来ません。
ファイルに対する情報設定は事前にやっておく必要があります。


実際の送信方法はこちら

Byte[] bData = wc.UploadFile(UploadLocation + "?access_token=" + access_token, "POST", FullName);

また、APIその物に
http://msdn.microsoft.com/en-us/library/dn631834.aspx
ここを見ていただければ分かりますが、
name、description、sort_by以外に書き込める内容が存在しません。

プロパティの変更は、ほぼ何も出来ないと思って間違い有りません。

まぁ、descriptionにコード化したupdatetimeなどの情報を忍ばせても良いですが、
そこまでするのかな？って感じはしなくもありません。

ローカルの送信元のファイルがクラウド側の送信先のファイル日付より新しくなっていたら、更新するという非常にシンプルな構造でも、自動更新は可能です。

取りあえず、実行完了時に帰ってくるByte[]にフォルダ作成時と同じように新しいファイルのid等が入ったJSONが有りますので、それを利用すれば、デスクリプション等の変更やファイルのダウンロードが可能です。


これで、一応目的の、OneDriveの指定場所に、指定したフォルダの内容を自動的にアップロード／更新が出来る状態になりました。

ですが、まだちょっと問題が有ります。


そう、消したファイルです。


消したディレクトリを、まるまるクラウド側で消すのは、色々と問題が有ります。

なので、ディレクトリ削除については今回は行いませんが、

１個１個のファイルなら別です。


ファイルを削除する場合はこちら

ちなみに、UploadDataを利用していますが・・・送信データはありません。
wc.UploadData("https://apis.live.net/v5.0/" + id + "?access_token=" + access_token, "DELETE", new Byte[0]);

また、削除するので、返信もありません。多分、JSONが帰ってきたら、ファイルの削除に失敗しているとかそういう感じでしょうか？

イマイチ分かりません。

それにしてもMethod Deleteが日の目を見るとは思いませんでした。
httpの仕様にはかなり以前からDleteは存在したのですが、誰かが、Deleteを送信しただけでファイルが削除されてしまってはWWWなんか存在出来たものではありません。

ですが、OAuthが出来て、セキュリティの高い認証・クラウドでのファイルの授受が頻繁に行われるようになった現在になって、漸く利用出来るようになったと言うことでしょうか？


では、次回からは上級編です。

アクセストークンの更新の仕方などを調べておきます。
（１時間？程度で有効期限が切れます。）

Vista以降のWindowsを終了していると、

xx個のプログラムが閉じられていません。

とか、そう言った類のメッセージが出て、なかなか終了出来ないときがあります。


これは主に、アプリケーション側が、OSからの終了メッセージに対して、終了しようとしたときに、

「ファイルを保存しますか？」

とかってメッセージを出して放置している場合になります。


それに対して「シャットダウンする」ボタンを押したりすると、アプリケーションは強制終了され、データは保存されないままで終了してしまいます。

まぁ、さっき編集した内容が保存されないだけなら、未だ何ともないのですが・・・・

自動で保存され、保存している最中に強制終了とかした場合には、未だ処理されていない書き出し内容が、全く保存されないままで、終了してしまうため、ファイルが壊れると言うよりも、未完のままって事になり、二度と読めなくなってしまうでしょう。


ちなみに、diskアクセスが終わっていないだけの場合は、アプリが堕ちても問題は無いので大丈夫です。

データは途中でフラッシュなどせず、迅速に出力し、その後で、書き終わるのを待つと良いでしょう。


では、本題。


最近気がついたのですが、携帯もタブレットも、タスクを着ることが無くなりました。

それだけAndroidというOSが安定してきたと言うことに成ると思います。

先月頃202Fが爆音を発し大変な目に遭いましたが、あれは再起動することで治りました。
どうも、音声出力系でおかしな事になったみたいです。

アプリも堕ちなければOSも堕ちなかったので、数ヶ月ずっと使い続けてきた結果軽微な不具合が蓄積されていったんでしょうね？

タスクスケジューラや、タスクキラーと言われるアプリケーションが活躍する場面は無くなったと言うことです。

Windowsのタスクマネージャも、結局の所アプリがフリーズするから必要になるものであって、アプリもOSも正常に動いているのであれば、タスクを切る必要は全くなく、タスクマネージャも要りません。


Ctrl+Alt+Delなんて呪文は要らなくなる時期が来るのかもしれません。


ところで、microsoftが言うWindowsが未だに堕ちまくると言う原因についてですが、

一般的には、デバイスドライバの不具合だそうです。

OSの深層部分はきわめて堅牢に出来ており滅多なことでは落ちません。
でも、デバイスドライバはそれよりも下層で動作する物も有り、デバイスドライバで不具合が起きるとOSにも影響があります。

OSはデバイスも仮想化して、デバイスをOSよりも上層で動作させている物も多いですが、全てではありませんし、結果的にはOSより下層のハードウェアに対して処理を送る関係で、デバイスドライバの不具合というのはとても致命的です。

また、OSよりも上層のアプリケーションであっても、OSによるタスクスイッチの瞬間を狙われたらひとたまりもありません。

OSとアプリが同じハードウェアで実行されている現状ではどうしようも無いのです。
.netフレームワークなどのOSを丸ごと隠蔽してしまうような、そう言った開発環境のみにしなければ防ぎようがありませんが、未だにC++やら他の言語がいまだに使われていますし、C#使いながらもAPIを呼びまくっています（笑

ランタイムの拡充と、OSの不可侵を推し進めないとダメですよね〜

先日のアップから間が空きましたが・・・仕事の方が忙しくて結構時間掛かったんですよ？


で先日はOneDriveのルートディレクトリを取得するところまで書きましたが・・・

では、そのデータの解体から始めましょう。

受信するのは先述の通りテキスト形式のJSONと言うものです。

で、これが・・・まぁ、色々と面倒なんですよ？
専用の形式であるため、自分で解読するしか無い様な雰囲気です。
まぁ、複雑な書式では無いので、1行ずつ読んでも良いですが、面倒なことこの上ありません。

そこで、.netの３．５とか４あたりからはこれのデコーダーが付録されています。

JsonReaderWriterFactory

と言うものですね。

しかも、これがやっかい、XML形式で返答するという物。

そこであたしのお勧めはこちら、

System.Net.WebClient wc = new System.Net.WebClient(); //WebClient作成
System.Xml.XmlDocument xDoc = new System.Xml.XmlDocument(); //出力用のXMLドキュメント

Byte[] dat = wc.DownloadData(URL); //バイナリ形式で戻り値を取得
System.Xml.XmlDictionaryReader xdr = System.Runtime.Serialization.Json.JsonReaderWriterFactory.CreateJsonReader(dat, System.Xml.XmlDictionaryReaderQuotas.Max); //リーダーに掛ける

xdr.Read();//ルートオブジェクトの読み込み
xDoc.LoadXml(xdr.ReadOuterXml());//変換済みのXMLソースをXmlドキュメントに流し込む

あとはxDocを一般的なxmlとして処理すれば、問題なくＯＫ


所で、これで取得するのは、ルートディレクトリの情報です。

これを取得しただけでは何も出来ません。

操作したい対象のフィルだを開いて、ファイルをダウンロードする、アップロードする、　そう言った事をしないといけません。


じゃぁ、目的のフォルダを取得するにはどうしたら良いでしょうか？
じゃぁ、
https://apis.live.net/v5.0/me/skydrive?
とやったところを
https://apis.live.net/v5.0/me/skydrive/フォルダ１/フォルダ２?

と殺れば出てくるでしょうか？？

答えはノーです。

実際のフォルダは全て数字名になっているので、この方法では取得出来ません。

そこで利用するのが「upload_location」タグです。

これは、下位層の情報が含まれている場所へのリンクが格納されています。
（注：これ以降の情報はJSON形式がXML形式になったものです。）

<upload_location type="string">https://apis.live.net/v5.0/folder.xxxxxxxxxxxxxxxxxxx/files/</upload_location>
これをダウンロードすることで、フォルダの中身一覧が取得出来、その中から希望するフォルダの情報を取得することになります。

ちなみに、
upload_location以外の情報源として、<id type="string">folder.xxxxxxx</id>があります。

https://apis.live.net/v5.0/に idタグの中身を貼り付けることでフォルダその物にアクセス出来ます。
さらにその後ろに/files/を付けることで、フォルダの中のファイルの一覧を取得出来ます。

なお、ファイルの一覧と言っていますが、ファイルやらフォルダがすべて混ざって値が返ってくるので、
<type type="string">folder</type>または<type type="string">album</type>で、<name type="string">フォルダ名</name>が探しているフォルダ名かどうかを確認することで、確定出来ます。


また、ファイルの場合は
<id type="string">file.xxxxxxxx</id>
と、idの先頭もfileになり、
upload_locationの後ろもfilesからcontentに変わり、これを取得することで、多分ダウンロードすることになります。
<upload_location type="string">https://apis.live.net/v5.0/file.xxxxxxxxxxxxxx/content/</upload_location>


ってことで、/フォルダ１/フォルダ２を取得するには、

１．ルートディレクトリの情報を取得する。
２．ルートディレクトリのファイル一覧を取得する。
３．フォルダ１の情報を探す
４．フォルダ１のファイル一覧を取得する。
５．フォルダ２の情報を探す。
６．フォルダ２のファイル一覧を取得する。
といった方法をとる必要があるようです。

ちなみに注意事項ですが・・・・
ファイル一覧に表示されているフォルダの情報は当該フォルダのファイル一覧へのリンクしか保持していません。

フォルダその物の情報が必要な場合は、upload_locationを使う場合は、/files/を消してからデータの取得をするか、
idを用いるか、どちらかと言うことに成ります。

なぜフォルダの情報が必要なのでしょうか？
ある程度の情報なら、わざわざ取得しなくても分かるのでは無いかと言うことですが・・・・

じつはこれ、それなりに重要なのです。

フォルダの新規作成は、フォルダに対して行うので/files/や/content/が付いている状態で行っても、成功しません。
それと、
新規作成したフォルダは、当然中身がありません。

中身の一覧を返す/files/では中身が無い状態では、ほぼ情報を返しません。

<root type=\"object\"><data type=\"array\"></data></root>

これだけですね。

なので、フォルダの情報とフォルダのリスト情報をペアで保存しておかなければ前後不覚に陥ります。
基本的には、ディレクトリ階層のフォルダのidを全部保存しておく必要があるでしょう。
他に使うのであれば、日付などの情報も、予め抜いておくと良いでしょう。

せっかくのXML形式なのでそのまま取っておけば、便利かもしれません。
でも、必要な情報だけを保持した、構造体とかにしておくのも一つの手ですね☆

ちなみに、データが一つでもあれば、

<parent_id type="string">folder.xxxxxxxx</parent_id>

で、前のフォルダ情報が分かります。

不便です。


ちなみに、フォルダの作成方法ですが・・・・

フォルダを作成するフォルダのidに対して、
https://apis.live.net/v5.0/folder.xxxxxxxxxxxxxx?access_token=xxxxxxxx

{name:"フォルダ１"}

をデータで送ります。

wc.Headers["Content-Type"] = "application/json";

にする必要があります。

先日の記事をバッサリしました。


ふんだんに間違えております。


まず、OneDrive関連の開発をする人は、ここを見ましょう。

http://msdn.microsoft.com/ja-jp/onedrive

日本語サイトです☆　ありがたいです。

で、ここでログインしておくと便利なのか、その先でログインしておいた方が便利なのかは微妙なんですが、

ダッシュボードのタブのリンクを開くと

ここ
https://account.live.com/developers/applications

へ飛ばされます。

こここそが、マイアプリ用のクライアントIDを発行してくれる場所です。


注）
先日の販売者ダッシュボードは、別のクライアントIDを発行するので、oAuth用クライアントIDと書かれては居ますが、それを発行しただけでは、OneDriveへのアクセスは出来ません。


で、正しい方での話ですが・・・
「マイ アプリ」を押したり、「アプリケーションの作成」を押したりすると、アプリケーションの登録画面が出来るので、好きな名前でアプリケーションの作成をします。

Windows8用とかを押すと、ストアアプリ用の有料サイトに飛ばされるので、デスクトップアプリの場合は「Windows ストア ダッシュボード」は押さないで、そのまま名称を入れて「同意する」を押します。

すると、それ以外の情報を設定する画面が出るので、主に必須項目を入れるだけで、ＯＫです。
クライアントIDを取得する場合は、API設定の所で
「モバイル クライアント アプリ/デスクトップ クライアント アプリ:」を「はい」にして、保存します。

販売者ダッシュボードのように面倒な設定は一切無く、セキュアコードも不要ですし、リダイレクトURLも要りません。


そう、これで、簡単に発行出来る上・・・・販売者ダッシュボードのように、アカウントの承認も要りません。


あっ、ちなみに、承認はされました☆

念のため取っておこうかと思います。


で、設定したアプリの名称やアイコンやらメモやらは、ログイン画面で表示されますので、それなりにちゃんとやった方が良いかと思います。


ってことで、その辺りを適当にこなせば、晴れて接続が出来る様になります。

ちなみに、販売者ダッシュボードで発行されるクライアントIDはクラスIDの用なとても長いもので、ハイフンで繋がれていますが、

正しい方は？１６桁くらいの英数字です。

ってことで、正しい？アクセル用のアドレスは以下の通り

https://login.live.com/oauth20_authorize.srf?client_id=クライアントＩＤ&scope=wl.skydrive_update&response_type=token&redirect_uri=https://login.live.com/oauth20_desktop.srf

読み込み専用のscopeはwl.skydriveですね。


これでアクセストークンが帰ってきます。

ユーザーのログイン画面で、無事ログインが完了すると、アクセス権確認画面がひょうじされ、ＯＫすると、画面はリダイレクトされて、

https://login.live.com/oauth20_desktop.srf#access_token=超長いコード&token_type=bearer&expires_in=3600&scope=wl.skydrive_update&user_id=IDらしい

の画面が表示されます。

ちなみに、真っ白な画面です。

で、ここで重要なのが、アドレスに付いている#access_token以下です。
アクセストークンは８００文字以上の超長い文字。

処理が完了してログアウトするまでこの値はずっと必要です。

webbrowserコントロールを利用している場合は

DocumentCompletedのe

WebBrowserDocumentCompletedEventArgs.Url.Fragment
を確認して#以下が格納されていればアクセストークンが正しく帰ってきています。

そうで無い場合、DocumentCompletedは、ログイン処理中に何回かリダイレクトがある関係で、何度も呼びだされますので、アドレスが正しいか確認してから、内容を取得する様にした方が良いですね。


さて、ここまでwebBrowserで対応してきた人も、ここから先は出来ません。

なぜって・・・・実際のアクセスを行うときは「skydrive.json」とかって名前でデータが帰ってきますし、そもそもhtml形式では無いからです。

webbrowserでは名前を付けて保存しますか？ってダイアログが出て非常に不便です。

これ以降は、
System.Net.WebClientでも使った方が良いでしょうか？

webbrowserと違い、プロクシの設定とかが必要になるのかもしれませんので、ご注意を☆

で、実際のこれ以降のアクセス方法については、次回をお待ち下さい☆ミ