【Xamarin.Android】元Windows.Formプログラマから見たXamarinの雑感

2016年度からVisualStudio Professionalに統合され、実質無料化されたXamarin。
C#大好き人間を自認する自分としては、これに飛びつかないわけにはいかなかったのだが……。

 

まあ何と日本語情報の少ないこと……orz

とはいえ、C#とXamarinがクラスプラットフォーム開発に極めて有用な手段であることは間違いないと思うので、色々ハマった箇所をこうしてブログ形式でまとめながら紹介していこうと思う。
Windows.Formプログラマが見るXamarinの世界ということで、他の記事と差別化していこうかな~と思いました(笑)

 

Cordovaでなく、Xamarinにした理由

もともとWeb屋のウチの会社だから、Cordovaのほうが圧倒的に親和性は高かったと思う。
では何故Xamarinにしたのかというと、

「ワイ……C#はんにはお世話になったけんのぅ……( ´・ω・)」

という個人的な事情もさることながら(笑)、基本的にサービスメインのアプリだったからである。
具体的に言えばGPSを利用したトラッキング系のアプリだったので、UI部分をHTML化してもそれほどメリットもないし、バックグラウンド処理は結局プラグインに依存することになるので、もうそれならネイティブでやった方がいいと思った次第であります。

だってCordovaって、バックグラウンドサービスの操作には明らかに親和性ないしね。

 

んで、流行のXamarin.Formsを何故使わなかったかといえば、

固有のお作法がわからんのに共通化なんてしても絶対理解できない

と思ったからである。
幸いにしてAndroid開発の予定しかなかった(iPhoneはイラナイ)ので、これ幸いとばかりに開発手法はXamarin.Androidを選択した。
XamarinはコードこそC#で書けるが、実際にはネイティブのAPIを駆使して実装することになる。
ということは、まずネイティブのAPIのお作法に慣れておく必要は、やっぱりあるわけだ。

我ながら向学心に溢れる同期だ、多分(笑)

 

というわけで、初心者の皆様(私もですがw)には、

Visual C#>Android>Blank App(Android)

を選んで冒険の旅に出ることをオススメしたいと思う。
複数のOSで動作させる場合には、共通ロジックをPCLに逃していくことになるわけですな~。

 

そして書き始めると、C#というプログラミング言語&VisualStudioの強烈な入力保管機能にムネがアツくなるのでした。
やっぱりC#はイイ言語だ。マイホーム。

 

早速の違和感は、やっぱりUI

とにかく、WindowsFormプログラマ諸氏にとって、最大の壁はUIだと思う。
「それはお前だけだ!」という人にはごめんなさい(笑)

私はWeb開発もこの会社で経験したので、まだ理解できた。
だがしかし、axmlという特殊なファイルで記述されたUIの作成方法は、XAMLを経験した新世代プログラマはともかく、Windows.Formsで切って貼って楽しく開発していたあの日々の面影は遠い。
もちろん、デザイナで画面作成を行うことはできるのだが、「まあまあ」ぐらいに考えていたほうがいい。
過ぎた時代を嘆いても仕方ないけど、Windows.Formの画面の作りやすさは異常だった。

……まだちょこっと小手先で便利アプリ作るときは、WindowsForm使っちゃうなぁw

 

さて、ソースコードだが、これは慣れたような慣れないような、といった感じだ。

今まで(太古?)Windows.FormがではDesigner.csがやってくれてたことを、全部自分でやらなければいけない。

この時点で、「Windows.Formが簡単すぎるからその通りにだけ切って貼ってしてました~Designer.csなんて知りません~」という人は厳しいですw

 

簡単に解説すると、

 

オマジナイ。
厳密に言えば基底クラスの処理を読んでる。
Xamarin様が書いてくれた根本部分の処理を読んでる。

 

UIの定義をセットしてる。
この引数になってるのが、layoutフォルダ内のMain.axml(Main、は人による)ファイル。
UIの配置やらプロパティやらを色々宣言してるデザイナファイルで、Windows.Formでいう○○.Designer.csの定義部分だ。

この処理をすることによって、UIが「存在することになる」のだ。

 

ただ、存在することにはなっても、Main.axmlなんてのは所詮XML。
C#がわかる形にインスタンス化してあげる必要があるのです。

旧Windows.Formsの○○.Designer.csではそもそもインスタンス作ってからVSがプロパティ設定してくれるからいらなかった部分でした。
自動でしてくれよ~と思わぬでもないw

 

ここも昔は自動だった(笑)

デザイナ上でイベントを選んでダブルクリック!
……とはいかず、今はコード中で自分でイベントを書いてやる必要あり。

デリゲートはC#から入ったプログラマにとっては、結構難しい世界だと思う。
関数を変数として…みたいなこと言われても、そんなものはJavaScriptの世界の話であり、C#erには馴染み薄い。
ここ以外にも、処理でデリゲート使いまくるから、デリゲートがわからない人、結構ハードル高いと思う。

 

真の強敵(≠トモw)は別にある

とまあ、最初のPOSTなので、さらっとさわりの部分触れてみました。
ただまあ、このあたりは正直楽勝でしたよ、エエ。

 

さて、多くのWindows.Formプログラマな皆様。

流行には付いていっておられたでしょうか?

私は全然ついていっておりませんでした(笑)

 

“await/async”

コレがわからないと、かなり厳しい戦いが待っております。
私はボコボコにされました(笑)

The following two tabs change content below.
大木 真之介
2016年1月、株式会社マンタ入社。プログラマー/SEが本職で、主にスクールiネットやその付随機能の開発を担当。記事を書くのが好きなため、2016年11月よりスクールiネットブログのメインライターに就任しました。読んで楽しい記事をたくさん書いていきたい!!