itoa

typescript環境構築の自分用メモ yoは入れておく。 yo aspnetで足場は作れるようにしておく。 typings install dt~jquery --save --global とかやると typings/globals/jquery/** に型定義ファイルができる。 typings/index.d.tsをrefernce指定すれば補完が効く。 gulpを使うためにgulpfile.jsを作っておく。 gulpfile.jsのなかみは以下のような感じ。 var gulp = require('gulp'); //var del = require('del'); var paths = { unify: [ 'app.js', 'app.js.map' ], scripts: [ 'TypeScript/**/*.tsx', 'TypeScript/**/*.ts', 'TypeScript/**/*.map' ] } gulp.task('default', function () { //del(['wwwroot/TypeScript/**/*']); //del(['wwwroot/js/*']); gulp.src(paths.unify) .pipe(gulp.dest('wwwroot/js')); gulp.src(paths.scripts) .pipe(gulp.dest('wwwroot/js/TypeScript')); }); delはあってもなくてもよい。 ワークスペースのフォルダ構成は以下の感じ。 /TypeScript    →ここに*.tsを入れとく /Views    →cshtmlはこの下に置かれる。 /Controllers    →コントローラのコードはここに置かれる。 /wwwroot    /js       ここにコンパイルされたjsが配置される...

GOPATHの設定をどうするか的な話。 プロジェクトごとにルートパスが違うのでシステムに単一のGOPATHだと いやだなぁと思っていて、かと言って相対パスでローカルパッケージを 指定してもvs.codeでローカルパッケージだとインテリセンスが効かない のも嫌だなぁというのをなんとか解決する話。 GOROOTを.bash_profileに設定する。  export GOROOT=/usr/local/opt/go/libexec .bash_profileにcode .とうつと起動するように仕込みを入れる。 code () {     if [[ $# = 0 ]]     then GOPATH=$(pwd)         open -a "Visual Studio Code"     else GOPATH=$(pwd)         [[ $1 = /* ]] && F="$1" || F="$PWD/${1#./}"         open -n -a "Visual Studio Code" --args "$F"     fi } exportしないでGOPATHをワークスペースに設定しておく。 こうすると、vs.codeで自前パッケージのインテリセンスが有効になる。 起動後に.vscode下にtasks.jsonを作る。 以下のような感じ {     "version": "0.1.0",     "command": "go",     "showOutput": "always",     "options": {         "env": {             "GOPATH": "${workspaceRoot}"   ...

Xamarin.Formsでのカスタムコントロール構築 共通プロジェクト側で、BoxViewを継承したクラスを作る BoxViewを継承したクラスをメインのXamlページではっつける プラットフォーム毎のプロジェクトでBoxViewの中を描画するためのRendererクラスを作る // 例） public class CustomControlClass : BoxView { } RendererクラスのiOS/Android共通の要件は以下の通り。 assembly:ExportRenderer属性を設定する。 例）[assembly:ExportRenderer(typeof(ShapeView), typeof(ShapeRenderer))] RendererクラスのiOS固有の要件は以下の通り。 iOSの場合、VisualElementRenderer<>から継承する。 (Xamarin.Forms.Plarform.iOS名前空間で定義) VisualElementRendererの型引数はターゲットとするViewBoxを継承したクラス。 Rendererクラスでは、Drawメソッド内にコントロール固有の描画コードを記述する。 //例） [assembly:ExportRenderer( typeof (CustomControlClass), typeof (CustomControlRenderer))] namespace Hoge.iOS { public class CustomControlRenderer : VisualElementRenderer < CustomControlRenderer > { public override void Draw(System.Drawing.RectangleF rect) { // specify draw code here. } } } Android固有のRendererクラスの要件 Androidの場合、ViewRenderer<>から継承する。(Xamarin.Forms.Plarform.Android名前空間で定...

macでdylibのプロジェクト(ここでは、libXXXX.dylib)とそれを使用するアプリ(ここではXXXXDriver)のプロジェクトがあって、xcodeからは実行できるけど、ターミナルから叩くと dyld: Library not loaded: /usr/local/lib/libXXXX.dylib   Referenced from: /Users/username/Library/Developer/Xcode/DerivedData/XXXXi_dylib-cagqvakmzwqigmgxxrwzutupseja/Build/Products/Release/./XXXXDriver   Reason: image not found Trace/BPT trap: 5 というようなメッセージが出力されて起動できない問題に対処したのでメモ 解決方法１： /usr/local/libに ロードしようとする libXXXX.dylibをコピーする → 環境が汚れるし、なんか負けた気がするのでNG 解決方法２：起動用のshファイルを作ってそれを叩く方法 test.shファイルを作ってそれをターミナルから叩いて実行させるようにする話。 #!/bin/sh # dylibのロードするパスを通す export DYLD_LIBRARY_PATH=/Users/username/Library/Developer/Xcode/DerivedData/XXXXi_dylib-cagqvakmzwqigmgxxrwzutupseja/Build/Products/Release:$DYLD_LIBRARY_PATH # 実行 ./XXXXDriver このファイルをtest.shとして保存して、chmod +x test.sh とやって実行できるようにする。 これでターミナル上で./test.shと叩けば、きちんと実行できるようになる！！

Xamarin.FormsでiOSの自作ネイティブライブラリを使用しようとしてハマった話。 普通にiOSでやれば簡単だったけど、Cross-platformにしようとしたら面倒だったという話。 環境 mac book pro/El Capitan Xamarin 5.10.3 手順 新規ソリューションの作成でCross-platform / Xamarin.Forms Appを作る ネイティブバインディング用のプロジェクトとして、iOS / Bindings Libraryを作る Sharpieなどを使ってバインディングコードを書く → ここ あたりにやり方が描かれている。 1で作られたiOS用のプロジェクトに2のネイティブバインディングのアセンブリを参照設定で追加しようとする。 → プロジェクト参照では、Xamarin.iOSとmonotouchで互換性がないのでNGと怒られるので、「.Net Assembly」タブの「ブラウズ」で無理くり参照設定する。 ビルド → エラーになってビルドが通らなくなる。 対応 結局、csprojファイルを直接書き換えることで対応した。 いじる対象のcsprojファイルはバインディング側のプロジェクトファイルだ /Project/PropertyGroup/ProjectTypeGuids要素を修正する。     <ProjectTypeGuids>{8FFB629D-F513-41CE-95D2-7ECE97B6EEEC};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids> となっている箇所を     <ProjectTypeGuids>{6BC8ED88-2882-458C-8E55-DFD12B67127B};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids> に変更する。 この要素は、プロジェクトのタイプを示していて、<ProjectTypeGuids>[作ったプロジェクトの種類(例えばiOSのアプリ...

iOSのシミュレータ用の.aファイルと実機用の.aファイルを一つにまとめて使いやすくする巻 $> xcrun -sdk iphoneos lipo -create ../Release-iphoneos/libPDMani.a ../Release-iphonesimulator/libPDMani.a -output ../libPDMani.a 説明： ../Release-iphoneos 下の libPDMani.a (ARM系バイナリ) と ../Release-iphonesimulator 下の libPDMani.a (i386系バイナリ) を１つにまとめて-outputに指定した ../libPDMani.aに出力する方法。 -sdk iphoneos とか lipo とかはよくわからん。何かのおまじない。

Part4. データバインディングの基礎 データバインディングは２つのオブジェクトのプロパティをリンクし、片方の変更を契機に もう片方の変更を発生させることができます。 これは大変価値のあるツールです。そしてデータバインディングはソースコード上で完璧に 定義することができ、XAMLはそのショートカットと利便性を提供します。 その結果として、バインティングがXamarin.Formsのマークアップ拡張は最も重要な機能 の一つとなります。 データバインディング データバインティングは２つのオブジェクトのプロパティを接続し、ソースからターゲットへ 呼び出しを行います。コードの中では、２つのステップが要求されます。 一つ目は、ターゲットオブジェクトのBindingContextプロパティを必ずソースオブジェクト にセットする必要があります。 二つ目は、SetBindingメソッド（しばしばBindingクラスと組み合わせて使用される）で、 ソースオブジェクトのプロパティに、そのオブジェクトのプロパティをバインドするために、 ターゲットオブジェクトから呼び出されなければなりません。 ターゲットプロパティは、バインディング可能なプロパティである必要があります。 つまり、ターゲットオブジェクトは必ずBindingObjectから継承されている必要があります。 オンラインのXamain.Formsのドキュメントでは、プロパティはバインド可能なプロパティで あることを示しています。 マークアップ中では、これらは同じ２つのステップが要求され、バインディングマークアップ の拡張機能は、SetBindingの呼び出しと、Bindingクラスの代わりに使用されます。 しかしながら、これらはターゲットオブジェクトのBindingContextへセットする単一の テクニックではありません。 しばしば、StaticResourceもしくはx:Staticマークアップ拡張機能を使用して、コード ビハインドのファイルからこれらは設定されます。 バインディングが最も頻繁に使用されるのは、画面表示系のプログラムとベースのデータモデル を接続する時で、しばしばMVVM(Model-View-ViewModel)アプリケーションアーキテクチャ で実現されます。MVVMについては...