職場にOffice 365が展開されて見かけた不思議な反応

Office 2007のサポート期限間近と言うことで、とうとう職場にもOffice 365の波がやってきました。

でインストール大会が繰り広げられたのですが同僚の反応に軽くショックを受けました。

■選択インストールできないの？Access要らないんだけど
たいした容量じゃないんだし、別に入っても良いのでは。
バックグラウンドで動くわけでもなし。

■インストールが遅いんだけど
数台同時にインストール開始したらそりゃ通信ひっ迫して遅いでしょうよ。
オフラインインストールとか考えようよ。
てか未だにHDDとかやめようよ。

■Word起動しないんだけど
セーフモードで起動することで解決。
2007で入れていたアドオンのせいでWordだけ起動しなかった模様。

■OneDriveが気持ち悪いんだけど
基本的には利用しないので「使わない」なら良いんだけど、気持ち悪いって何？
裏でずっと動いてて重いとか、メモリ食ってるとかそういう反応ではなく、気持ち悪いって何？

■Officeにサインインしていると裏で設定とか同期していそうで気持ち悪いんだけど
だから気持ち悪いって何？

コレが事務職の人なら「へ～」で済むんだけど、一応IT技術屋なんだから、ちゃんとしようよ。

Xamarinのソリューションを読み込んでVisual Studioが固まるときの対処方法

.slnをダブルクリックしてVisual Studioが起動したあと固まることが何回かありました。

とりあえずbin, obj, packagesフォルダを削除したら動きました。

ついでにnuget restoreもVisual Studioでやるよりコマンドラインのほうが速いような気がするのでそうしておきました。

つまりこんなバッチファイルを作りました。

rmdir /s /q App\App\bin

rmdir /s /q App\App\obj

rmdir /s /q App\App.Droid\bin

rmdir /s /q App\App.Droid\obj

rmdir /s /q App\App.iOS\bin

rmdir /s /q App\App.iOS\obj

rmdir /s /q packages

nuget.exe restore App.sln

現場からは以上です。

Visual StudioでXamarin.Androidのリソースを追加削除するときはaapt.exeを実行しないようにしておくと速い

Visual StudioでXamarin.Androidのリソース、例えば画像をプロジェクトへ追加したり削除するとき、やけに、ものすごく時間がかかる事があります。
というか、ほぼハングしているようにしか見えません。

このときタスクマネージャの詳細を見ると「aapt.exe」がCPUを食いまくっています。

これをKillすれば少し速くなるのですが、画像の数だけ順にaapt.exeが起動されるようで50個とか追加しようとしているときは発狂します。

というわけで、プロジェクトを開いた後で冒頭の画像のようにAndroidのbuild-toolsのフォルダ名を変更し、この中にあるaapt.exeが実行されないようにするといいです。

画像の追加が終わったら元に戻せばOKです。

なおaapt.exeはbuild-toolsの中のバージョンごとのフォルダに存在するですが、実行中の１バージョンのフォルダ名だけ変更しても、次にまた別のバージョンのaapt.exeが実行されるようです。
どうせ変更するなら最上位を、ということです。

気が向いたらお試しください。

Xamarinでアプリ開発して良かったこと悪かったこと

業務でXamarin.Formsを使い、iOSとAndroid向けに同じアプリを作るということをしました。

以前はiOSとAndroidの担当が数名ずつで2チームだったのですが、仕様や実装に関する知識が分断しやすく、結果的に実装の都合を互いに押しつけあうなど問題があったのでその解決をXamarinに求めたのです。（その後他にも色々対策はしましたが）

「どうだった」と聞かれがちなので、良かった点と悪かった点を書いておこうと思います。随時追記もするつもりです。

■どんな感じだったか

• Xamarin.Formsをベースに、たとえばPageの切り替えアニメをiOSとAndroidで同様にするなど、独自のUIフレームワークを作りました。
• UIが絡まなくてNative機能を使いまくるところはPCL＋BindingLibraryな共通ライブラリを作り、UIからはあまりNativeを意識せず実装できるようにしました。
• UI側でNative機能を使いたいときはDependencyServiceやRendererを使いました。
• NuGetサーバやCI環境など色々必要になりました。

■良かった点

• 仕様に関する知識が分断しづらくなりました。
  ある画面がiOSだとこういう仕様でAndroidだと違う仕様というのが激減しました。もちろんXamarin.Formsの中で実装が異なるので挙動が違うというのは良くありましたがたいていはRendererなどで回避・調整可能でした。
• UIフレームワークやライブラリを使う「だけ」のNative分からない人も開発に参加できるようになりました。人の融通がしやすくなるという意味で良かったです。
• GitやiOS、Macなど今まで「食わず嫌い」だったものが少し浸透しました。
  SubVersionで止まっている人にGitを使わせたり、AndroidやWindowsしか触ったことのない人に多少なりともiOSやMacを触らせることができました。
  GitはMergeコミットだらけになったり色々アレですが、そこは具体的な悪影響が出るまで我慢です。

■悪かった点

• 開発環境を人数分揃えるのにかなりコストがかかりました（詳しくはココ）。
  XcodeやAndroid Studioだけなら無料なのに。
• 実装に関する知識は分断したままでした。
  Nativeを分かる人が独自のUIフレームワークやライブラリを作る担当になり、画面を作る人は別となることが多かったです。結果iOS、Android、C#それぞれで担当部分しか触らないという人はそれなりに残りました。うまく分担できたという気もしますが、もう少し「誰でも触れる」状態が作れればと思います。ただMacやMSDN付きでないとやりづらくコストもより増えてしまうので敬遠されました。
• 問題の原因を探る階層が増えました。
  例えばUI部品を思うように配置できなかったとき、Nativeならそれらの範囲を調べれば良いのですが、Xamarin.Formsの場合はそちらの挙動も見る必要があったりして手間を感じました。
• なにかとiOSはズルいです。
  普通に作るとどうしてもiOSアプリの方が安定しています。処理中にホームボタンを押したりしたときもiOSはただサスペンドしている感じですが、Androidは動き続けてヌルポで死ぬとか。画像を読み込む速度もiOSの方が早いです。
  さらには独自ライブラリのほうで依存関係が増えたとしても、iOSの方は簡単に取り込めるのに、Androidはアプリ側でイチイチBinding Libraryを作成してjarを取り込まないとClassNotFoundExceptionになったり。Androidはやりづらさがありました。
• Mac Agentがアテにならない
  Windows(Visual Studio)からMacへ接続してリモートビルドをかけるための仕組みですが、Visual Studioからのデバッグ実行などは頻繁に切れて失敗します。コマンド（msbuild）からなら割と安定しているのですが。
• Xamarinの更新がドキドキ
  XcodeやAndroid Studioであれば更新しても問題にあうことはさほど頻繁ではなかったように思いますが、Xamarinは毎回心臓に悪いです。特に今回のXamarin.Android 7.3のようにGCやMonoが変わって実行時に原因不明でクラッシュするとかやめてほしいです。
• 依存関係が難しい
  例えば今のプロジェクトはFormsの2.3.3.180を使っているのですが、2.3.4に上げるのは難しいかもしれません。
  というのもこれと合わせてXamarin.Android.Support.v4の23.3を使っていて、AndroidのBinding Libraryのほうも同じバージョンで、と揃えた状態で、これまたバージョンを上げるとどうなるか分からないというのがあります。ただモバイル開発は基本的にバージョン上げていかないとシンドイので、近いうちに、せーの、でやることになるのだと思います。

■その他

• 計測していないのですが、コードを共通化できた部分はさほどないと思います。
  前述の通りBindingLibraryやRenderer、DependencyServiceなども結構書きましたし。

というわけで、Xamarinは（目的と手段とスキルと制限などとコストが折り合いつけば、わりと）いいぞ。

Visual Studio for MacのmsbuildでビルドするとDEBUG定数がなくなる

ちょっと不思議な現象です。

あるXamarin.iOS（＋PCL）プロジェクトを、Visual Studio for MacのIDEでビルドするとDEBUG定数があるのに、同じMac上のmsbuildでビルドするとDEBUG定数がなくなるのです。

ソース内で
#if DEBUG
#pragma warning DEBUG is defined.
#else
#pragma warning DEBUG is not defined.
#endifと書き、またmsbuildに/v:diagを付けてログをみたところ、やはり"is not defined"と出力されましたし、DefineConstantsにTRACEしか付いていないみたいでした。

Ad-Hoc|iPhone構成にDEBUGを付けたのが悪かったのだろうか。

もうしばらく調べてみます。

MacでもWindowsと同じようにNuGetパッケージを作成しPushできる

以前、Xamarinを使った開発でNuGetのパッケージを作るならWindows側で行う方がよさそうというエントリを書きました。

その後Macの環境もVisual Studio for Macになり、何となく思いつきで「sudo nuget update -self」してみました。

すると2.xだったnugetが4.xになり、Windows(nugetは3.x)でpackしたNuGetパッケージと同じようなものが生成できるようになりました。
（ZIP展開して、中身がIDっぽい値以外ファイル構成や中身が同じでした。2.xの時はだいぶ違いました）

pushも問題なくできたので、そのまま使っています。

もともとこのMacはJenkinsのいちスレーブで、nuget pack/pushするためにWindowsスレーブも使っていたのですが、Macだけで済むようになりました。

めでたしめでたし。

Xamarinを使った開発でNuGetのパッケージを作るならWindows側で行う方がよさそう

Xamarinを使ったアプリ開発で「共通ライブラリ」的なものを作ることになりました。

複数のアプリで同じコードを使い回せるようにしたかったからです。

• 自作のネイティブライブラリ（Binding Library）のDLL(iOS, Android)
• Binding Libraryを使うXamarin.NativeのDLL(iOS, Android)
• PCLのDLL

これらのファイルをnuspecに書いて、JenkinsからXamarin Studio(Mac)側のNuGetでpackしました。

そして出来たnupkgファイルをローカルにおいてVisual Studioで読み込ませてみようとしました。

・・・が、できません。表示されないのです。

Simple NuGet Severで構築したサーバにPushするとインストールはできるのですが、アンインストールや更新ができません。（metadataが読めない的なエラーが出る）

別に作った、Binding Libraryがないnupkgだと普通にアンインストールも更新もできます。

ちょっとワケが分からなかったのですが、色々試した結果、Windows側のNuGetでpackすると多少マシになりました。

「インストール済み」を見ようとするとエラーが表示されるのですが、とりあえずパッケージを選んでアンインストールしたり更新したりはできるようになりました。

Macで作成したnupkgとWindowsで作成したnupkgを展開してdiffしてみると、テキストファイルの改行コードが一部異なったりして（これはGitの影響かもしれないけど）、まぁ違うんだなーと。

あとNuGetのバージョンもMacのほうは2.12で、Windowsのほうは3.4と異なるので、とりあえずWindowsでpack, pushするようにしました（Jenkinsおじさんが）

なんというかMSDN付きで良かったと思う、今日この頃です。