Xamarin: 第9回 Plus Programming .net 勉強会


- メモ&アノテーション
- [第9回 Plus Programming .net 勉強会](https://atnd.org/events/55564)
- 聴き漏れとか誤解とあるよ

# INTRO:Xamarin 概要

- 田淵 義人（エクセルソフト）
- [slideshare](http://www.slideshare.net/ytabuchi/xamarin-201408) 
- http://j.mp/xm201408
- [swift](http://dev.classmethod.jp/smartphone/iphone/learn-swift/)
- "Shared C# Backend" + UI(iOS/Android/Windows)
- ネイティブアプリがビルドされる

    - C# + .NET ランタイム
    - ネイティブ UI
    - ネイティブ "パフォーマンス"

- async/awsit, LINQ, Lambda....
- TFS, Resharper...
- .NET BCL

## FAQ

- C# の C# T-Store をビルドしたアプリでただでTシャツを買う事ができる
- 有料
- iOSアプリではXCodeが必要
- MacではWindowsストアアプリは無理。 Windows でVSを使え
- ネイティブAPIで使えない機能は基本的にはない
- iOS SDK Betaに対応している。正式版がでたら基本的に即日対応。
- Android L Preview/Wearは、最新Alphaで対応
- ネイティブで作ったライブラリはバインディングで使える(P/Invoke, JNI)
- iOSのバインディングDLLはAndroidでは使えない
- Xamarin ライブラリは ネイティブで使えない
- Nugetは使える 。ComponentStoreもある。
- WinForm/WPFは使えない。  
- PrismはPCL化されていて使える。
  (http://sourcechord.hatenablog.com/entry/2014/05/08/014102)
- 30% - 60% ぐらいは共通化できるでしょう。
- UI定義とOS固有機能はクロスできない。
- Xamarin.Formsだと基本的UIもクロスできる。
- 共通化: 

  1. Universal App(Shared Projecdt), 
  2. PCL(Portable Class Library), 
  3. リンク参照 , 
  4. MvvmCrosなどのフレームワーク


# Main: Xamarin.iOSでデバイスを超えるプログラミング

- 後藤 康浩
- ソフトバンクテクノロジー株式会社


- OneDrive http://msdn.microsoft.com/ja-jp/onedrive/dn614593.aspx
- WithOneDrive for Xamarin.iOS
- objective-c のデリゲートの定義はコツがいる

## バインディングプロジェクト作成

- Xamarin Studio を使う(VSはめんどくさいっぽい)

## ライブラリ追加

- .a ファイルをさがせ
- .a で終わっていないライブラリは .a を追加すること( LiveSDK は LiveSDK.a にリネームする)
- 追加すると LiveSDK.linkwith.cs が作成される
- ライブラリが依存しているFramework .linkwith.cs を追加する


## リソースファイル

- SDKに付随するリソースを Resources ディレクトリにこぴる
- xib ファイルはバインディングライブラリを使うプロジェクト側に追加すること


## SDKのAPI定義をC#に記述

- ApiDefinition.cs
- StructsAndEnums.cs

## Objective Sharpie

- ライブラリの.hファイルから自動生成
- 生成されたコードは完璧ではない

- .hファイルがよろしくないとエラーになるので、
  .hファイルを適宜編集!
- LiveSDKの場合、LiveSDK/Public/LiveConectClinet.hファイルにたいして１行追加

~~~
#import <UIKit/UIKit.h>
~~~

  (XCodeだとこの#importなくてもobjective-cのビルドはできる)

## バインディング定義ファイルを修正

- Verify("...")を消す。確認したら消せ、ということ。
- ummapped : enumの型がわからない、のでStructsAndEnums.cs に定義
- 変数名で "delegate" がつかわれていると、"iosdelegate"みたいにリネームする。
- Export シグネチャの ":" はobjective-c 側のメソッドの引数を表す。よって、引数無しのAPIを呼ぶ時には":"がついていない事を確認。
  ビルド、シュミレータまでOKでも実機で動かない、とかがある。
- .hにあるすべてを実装する必要なくて、必要ないAPIの定義は削除してよい。

## バインディングライブラリを使うプロジェクトを実装

- SDKにxibファイルがアル場合、プロジェクト直下に追加。
- これはXamarin Studio を使う事！！！
- (Visual Studio)xibのビルドアクションをInterfaceDefinitionに変更すること。
- バインディングDLLが完成したら、これをプロジェクト参照ではなく、DLLで参照したほうがよい(事故が減る)


## Objective-C Delegateの実装

- Objective-C delegate == C# interface
- バインディングライブラリではabstract Classとして実装される(多重継承できない！)
- ２通りの実装がある

    - Strong Delegate (Strong = Strongly Typed)
    - Weak Delegate (Export("デリゲートメッセージ"))

- Strong の場合、デリゲートに要求される objective-cのプロトコル(C#インターフェースみたいな物)を継承したクラスを定義(デリゲートクラスを管理するコントローラクラスの中にネストクラスとかで)
- このクラスのインスタンスをデリゲートクラスのインスタンスの obj.Delegate にセットする
- Strong Delegate の場合、Delegateオブジェクトの生存期間をケアすること(GC回収されないように） 
- Weakの場合、処理するデリゲートのプロコルメソッドを実装するクラスを, デリゲートクラスのインスタンスの obj.WeakDelegate にセット
- プロトコルメソッドには Export("objective-c セレクター")アトリビュートで修飾しておく
- デリゲートクラスのインスタンスをホールドするクラスに定義すればGC回収の問題からフリー


# LT1:TFSとスクラムでやれば良かった

- 佐野尚之
- http://rururu.sakura.ne.jp

- VSSつかってたけどTFSを入れていれば良かった
- スプリント計画、デイリースクラムすればよかった(課題解決票、リーダーの協力性)
- タスクボードで他人のタスクをしることが出来ていたはず
- 他のメンバーのタスクと課題も自分のタスクと課題としてとらえる事が出来ていたはず
- 共通プログラムの修正の通知が行き渡らないとか
- 遅れている人の作業をフォローできていたはず
- 大規模開発でも、チームを細分化するとか、部分的につかうとかでスクラム使った方がいいよ

# LT2:TFSでエンプラアジャイルスクラム開発

- ソフトバンクテクノロジー
- SHIN-ICHI

- エンタープライズ・アジャイル
- 要件、要求、スコープ不確定

    - バックログが出し切れないケース
    - 確認するフェーズもスクラムに入れようよという発送
    - 要件定義をWF型でやる。この部分もスクラム的に。 

- リリース日程を柔軟に

    - スプリントを３週間->1週間
    - スプリントを数回やったらバックログ、見たいな
 

- 全体ロードマップ/予実の見える化

    - 全体ロードマップ不明じゃない？ 
    - 中の人はスプリントだけ見てしまうようになる.
    - 外の人からは進捗がわかりづらい
    - はじめの見積もり、実績などを定義して管理することで、機能単位で実績がわかるようになった


- 請負じゃなくてもできる？ 

    - 委任 : 必要なぶんだけ開発できる
    - 請負 : 費用と成果物期間が決まっている 

    - 最初にすべてのバックログを出してこれを成果物として挙げる

        -  できないところを事前に調整