KotlinのExtensionでDataBindingのBindingAdapterを使う。

本記事では DataBinding の方法については省略します。
DataBinding の方法については以下の記事を参照下さい。

BindingAdapterとは?

カスタムセッターを定義するものです。
BindingAdapterアノテーションを付けた関数を定義すると、その関数をレイアウトのxmlから参照できます。 Javaでの関数の定義は以下のとおりです。

@BindingAdapter("android:paddingLeft")
public static void setPaddingLeft(View view, int padding) {
   view.setPadding(padding,
                   view.getPaddingTop(),
                   view.getPaddingRight(),
                   view.getPaddingBottom());
}

xml側での呼び出しは以下のとおりです。

    <TextView
        android:layout_width="wrap_content"  
        android:layout_height="wrap_content"
        android:id="@+id/firstNameTextView"
        android:paddingLeft="@{1000}"
        />

android:paddingLeft="1000" ではなく android:paddingLeft="@{1000}" と設定する点に注意してください。

参考にしたページ

KotlinでのBindingAdapterを定義する。

※オススメしない方法ですが検索するとこの方法がヒットするので記載します。
Kotlin で Jave のような staticメソッドを作るには companion object を使うようですが、BindingAdapter で companion object を使うとエラーになります。
そこで以下の通りobject指定でクラスを作り、実装します。

object CustomBindingAdapter {
    @BindingAdapter("android:paddingLeft")
    @JvmStatic
    fun setPaddingLeft(view: View, padding: Int) {
        view.setPadding(padding,
                view.paddingTop,
                view.paddingRight,
                view.paddingBottom)
    }
}

xml側の変更はありません。

参考にしたページ

KotlinのExtensionsを使う。

上記の通りで実装できますが、Kotlin で BindingAdapter を使う場合は、Extension を使えばいいよね。という投稿をいくつか見ました。

Extension を使った実装は以下のとおりです。

@BindingAdapter("android:paddingLeft")
fun View.setPaddingLeft(padding: Int) {
    this.setPadding(padding,
            this.paddingTop,
            this.paddingRight,
            this.paddingBottom)

}

こちらの方が余計な object 宣言のなく簡潔に実装できます。

なぜこれで動くのか?

Kotlin の Extension は Java の staticメソッドに展開されます。
展開されたコードが最初に紹介した Java での関数定義と同じになるため、 Kotlin の Extension で BindingAdapter を定義できます。

参考にしたページ

Kotlinプロジェクト(Android Studio 2.1.1) に Crashlytics を導入

Kotlin で Crashlytics が正常動作検証した際に、build.gradleの修正に手間取ったのでメモしておきます。
手間取ったのはおそらく Kotlin が原因ではなく、 Android Studio の build.gradle の構成が変わってことが原因です。

  • build.gradle(Project)
buildscript {
    ext.kotlin_version = '1.0.2'
    repositories {
        jcenter()
        maven { url 'https://maven.fabric.io/public' } // この行を追加。
    }
    dependencies {
        classpath 'com.android.tools.build:gradle:2.1.0'
        classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlin_version"
        classpath 'io.fabric.tools:gradle:1.+' // この行を追加。

        // NOTE: Do not place your application dependencies here; they belong
        // in the individual module build.gradle files
    }
}

allprojects {
    repositories {
        jcenter()
    }
}

task clean(type: Delete) {
    delete rootProject.buildDir
}
  • build.gradle(Module)
apply plugin: 'com.android.application'
apply plugin: 'kotlin-android'
apply plugin: 'io.fabric'

android {
    compileSdkVersion 23
    buildToolsVersion "23.0.3"

    defaultConfig {
        applicationId "com.example.firstkotlin"
        minSdkVersion 17
        targetSdkVersion 23
        versionCode 1
        versionName "1.0"
    }
    buildTypes {
        release {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
    }
    sourceSets {
        main.java.srcDirs += 'src/main/kotlin'
    }
}

dependencies {
    compile fileTree(dir: 'libs', include: ['*.jar'])
    testCompile 'junit:junit:4.12'
    compile 'com.android.support:appcompat-v7:23.4.0'
    compile 'com.android.support:design:23.4.0'
    compile "org.jetbrains.kotlin:kotlin-stdlib:$kotlin_version"

    // 以下の3行を追加
    compile('com.crashlytics.sdk.android:crashlytics:2.5.5@aar') {
        transitive = true;
    }
}

repositories {
    mavenCentral()
    maven { url 'https://maven.fabric.io/public' } //この行を追加
}

Buildが失敗する場合は一度 Android Studio を再起動してみてください。
私は再起動後、正常に動作するようになりました。

関数型プログラミング入門のまとめ

気になる連載があったのですが、Indexがなかったので勝手にまとめました。

PlaygroundでViewControllerを表示する。

Assistant Editors を開いて、下記のようなコードで表示できます。

import UIKit
import XCPlayground

let window = UIWindow(frame: CGRect(x: 0, y: 0, width: 300, height: 300))
let viewController = UIViewController()
viewController.view.backgroundColor = UIColor.greenColor()

window.rootViewController = viewController
window.makeKeyAndVisible()

XCPlaygroundPage.currentPage.liveView = window
XCPlaygroundPage.currentPage.needsIndefiniteExecution = true

try! Swift 3日目個人まとめ

初めにまとめサイト紹介

スライドの写真もある速記まとめ(3日目だけのまとめはない)

全日程の資料まとめ

クラスメソッドさんのまとめ

個人まとめ

"Motivation based library abstraction"

レポート

  • 業務の中で出てきた課題に対応するための3つのライブラリを紹介されていました。
    • UTIKit
    • HUDKit
    • URLMatcher ※公開されていないようです。
  • HUD
    • Progress画面など最前面に画面を出したい時に使用する。
    • UIPresentationControllerを使っている。
  • また発表の中で紹介されていた はてなの教科書 です。

まとめ

  • アプリを開発する過程でライブラリ化出来るものは積極的にライブラリ化していきましょうという発表でした。

Server Side Swift

まとめ

  • ライブコーディングでWebサーバを実装し、HerokuへのDeployまで行っていました。

"Swiftにおける実践的なモック化について" : "Real World Mocking In Swift"

まとめ

  • SwiftでのMoc化に関する発表で、いくつかMocライブラリが紹介されていました。
  • 最適なMoc化は状況によって異なるため、その状況に応じて最もSimpleな方法でMoc化するのがよいと発表されていました。

"Swiftヒップスター" : "Hipster Swift"

レポート

  • @noescape
    • メソッドclojureを渡すとそのメソッド内で実行されずにプロパティに保存される(escape)かもしれない。
    • そうされないための @noescape .
    • 最適化される。
  • @autoclosure
  • lazy variable
    • @autoclosureと似た動きをしてくれる。
    • 強くselfをキャッチするので注意。
  • loop label
  • type omission
    • enum でなくても型が決まれば static な var/func を型を省略して呼べる。

まとめ

  • Swift独特な構文について詳しく紹介されていました。

"Core Imageによる高度な画像処理" : "Advanced Image Processing with Core Image"

レポート

  • Core Imageで編集した画像をUIImageとして使う場合はパフォーマンスの問題が出てくることがあるので、CIContextを使い回すなどチューニングが必要。

まとめ

  • 画像処理をおこなうためのライブラリ Core Image について、コードを用いて紹介されていました。

"Swiftトレーニング: 統計学を例に" : "How to Train Your Swift: Examples of Computational Statistics in Swift"

まとめ

  • 統計学の理論をSwiftを使って実装されていました。

"CODE INJECTION FROM SCRATCH"

まとめ

  • objc/clangを使って Swift Code Injection する方法を紹介されていました。
  • 非公開部分をハックしていたため、同じ方法を使うことは少ないと思いまし、危険です。

"デザイナーをSwiftのコードベースに巻き込む10の方法" : "10 Ways to Get Designers In Your Swift Codebase"

レポート

  1. 興味のある人を探す。
  2. メンターシップの土俵をチームに作る。
  3. ストーリーボードを使う。
  4. Autolayoutを使う。
  5. IBDesainableを設定してあげる。
  6. Sketchを使用してもらう。Adobeの問題を解決してもらう。
  7. 協力してあげる。デザイナの意見も受け入れる。壁を作らない。
  8. デザイナをほっておかない。
  9. ドキュメントを準備する。
  10. 気軽に受け入れられるタイミングで受け入れる。

まとめ

  • デザイナを開発に巻き込む方法について紹介されていました。

"パーサーコンビネーター in Swift" : "Parser Combinator in Swift"

レポート

発表に使われていたライブラリ(発表後に公開された)

まとめ

"オープンソースSwiftへの貢献" : "Contributing to open source Swift"

まとめ

  • Swiftの周辺ライブラリではなく、Swift本体への貢献について発表されていました。
  • Swift本体といってもCompilerや標準ライブラリなど様々な分野があり、それらについて俯瞰的に発表されていました。
  • Swiftがどういう構成要素によって成り立っているのか把握するには良い発表だと思います。

"Artsyにおけるテスト手法の紹介" : "An Artsy Testing Tour"

レポート

  • テストの前に大切なこと。
  • emergence(TVOS)
    • いっさいテストしていない。
    • その理由。
      • リリースするまで時間がなかった。
      • 一人で開発した。
      • 新機能の追加がない。
  • energy
    • 最初はテストがなかったが後で追加した。
    • 追加した理由。
      • 属人化をなくしたい。
    • どのようなテストを書いたか。
      • テストでアプリケーションがどのように振る舞うか定義した。
      • DIを使った。
  • eigen
    • 複数のnetworkアクセスがあるアプリ。
    • コーディングスタイルが異なるエンジニアがいるチーム。
    • iPhone/iPad対応したアプリ。
    • どのようにテストしたか。
      • 最初は神オブジェクトをテストしようとしたが、internalのテストが必要になり大変だった。
      • 既存神オブジェクトへのテストは諦め、コードの追加や、変更の際にテストを書くようにした。
      • SnapshotのUIテストを導入した。
  • eidolon
    • Quickライブラリ(RSpecスタイル)を使ったらテストが読みやすくなって良かった。

まとめ

  • 4つのアプリに対してそれぞれ異なったテストアプローチを取った話をされていました。
  • 最適なテストはアプリや開発チームによって異なるため状況に応じてテスト手法を選択したのでしょう。

以上です。

try! Swift 2日目個人まとめ

初めにまとめサイト紹介

スライドの写真もある速記まとめ

全日程の資料まとめ

クラスメソッドさんのまとめ

個人まとめ

"実践的 “Boundaries”" : "Boundaries in Practice"

レポート

まとめ

  • Functional ProgramingでiOSアプリを作る方法としてCoodinatorsが紹介されていました。

"プロトタイピングの魔法" : "Prototyping Magic"

レポート

  • iOS7からアニメーションがなくなり、魔法がなくなってしまったように感じる。残念な変化。
  • SkeuomorphismとInteractionは異なる。
  • プロトタイピングにPlaygroundは最適。

まとめ

  • 意図を持った魔法のようなanimationは必要で、そのプロトタイピングにPlaygroundは最適だと紹介されていました。

"プロトコルエクステンション: 歴史について" : "Protocol Extensions: A History"

レポート

  • こんな感じの流れでした。
    • コードを共通化する方法としてClass継承が発明された。
    • 単一継承では共通化出来ない部分があり、複数継承すべきだと考えた。
    • ただし、複数継承では名前の重複があった場合に問題になる。
    • ダイナミックディスパッチで解決しようとしたがだめだった。(ここよくわかっていない)
    • 実装を持たないprotocol/interfaceが発明された。
    • protocol/intefaceは実装を持たないので複数継承して名前が重複しても問題ない。
    • Swiftではprotocol extensionでprotocolに実装を持つことができる。
    • protocol extensionは強力だが名前が重複すると同じ問題が発生するので注意が必要。

まとめ

  • プログラミングの歴史を振り返って、protocol extension はどのような問題を解決しようとしていて、まだどのような点に気をつければならないか紹介されていました。

"Building Women Who Code in Tokyo"

レポート

  • 初心者へのアドバイス。
  • ゴールを設定する。
  • とりあえず行動する。
  • 初心者を排除するコミュニティは発展しない。

まとめ

- エンジニアではなかった発表者が Women Who Code in Tokyo を運営してきた話をされていました。

"Swift版「誰のためのデザイン?」" : "The Design of Everyday Swift"

レポート

デザインの7つの原則

  • Discovarability
    • 見つけやすくする。
    • アクセス修飾子を適切に。
    • Futureをわかりやすく。テストコードを書くのも良い。
  • Feedback
    • Compileエラー、テストコードの失敗などでFeedbackする。
    • ランタイムエラーは処理が実行されないとわからないから良くない。
  • Conceptual Model
    • 概念モデルをわかり易い言葉で伝えられるようにする。
  • Affordances
  • Signifiers
    • 実現可能な方法を感覚で表現する。
    • Swiftのアクセス修飾子やclass/struct/enumなどで表現する。
  • Mapping
    • Xcodeのフォルダ構成で伝えることが出来る。
  • Constraints
    • Swiftの型システム。

まとめ

  • 将来の自分、他のデベロッパーをユーザとして、ユーザのためデザインの原則をSwiftコードにも適用した場合、どのような点に気をつけてコードを書くべきか紹介されていました。

"モダンCore Data" : "Modern Core Data"

まとめ

  • CoreDataに限らず、既存の古いAPISwiftらしく使いやすくする具体的なコードが色々紹介されていました。
  • 詳細はスライドで確認して下さい。

"SwiftコンパイラとLLDBの連携" : "Swift compiler integration in LLDB"

レポート

  • LLDBの中にSwift Cpmpilerがある。
  • breakpoint に詳細な設定が出来る。

まとめ

"ライブラリの開発" : "Creating a Library"

まとめ

  • マルチプラットフォームに対応したライブラリのbuildの設定やテストコードの書き方など、コード周りの設定、書き方について紹介されていました。

"Protocol-Oriented Programming in Networking"

レポート

発表で使っていたコード

まとめ

  • 次の3Topicについて紹介されていました。
    • protocolを使って処理を抽象化。
    • ptorocolに制約を与えてDefault実装を与える。
    • Rxを使って、イベントも抽象化。

"ライブデザイニング:🎙🎨 " : "Live Design:🎙🎨 "

まとめ

  • Sketchを使ってアプリのアイコンをライブデザイニングしていました。

"SwiftらしいTable View Controllerの使い方" : "Table View Controllers in Swift"

レポート

  • initにconfingを渡して、振る舞いを制御するcofigurationパターン。

まとめ

  • generic, didset, struct などSwiftの特徴的な機能を使用して、TableViewControllerを使ったコードの機能追加、リファクタリングをライブコーディングしていました。

以上です。