Kotlin varとvalの違い

var と val の違いとは?

  • var : 再代入可能な変数(読み書き可能な変数)
  • val : 読み込み専用の変数

以下のような操作を行った時、valではbuild errorとなります。

class Foo{}
val foo = Foo()
foo = Foo() //変数fooに再度Foo()インスタンス

valについて

いや、valに代入したArrayListの要素を変更できるんですけど?

val foo = arrayListOf(1,2,3)
foo.add(4)

再代入ではく代入したインスタンスを読み込んでいるだけ。val fooを別のインスタンスに変更しようとしているわけではありません。読み込んだインスタンスが何かしらの操作をしているのであって、fooが保持しているArrayListのインスタンスはadd前も後も同じものです。

変数fooが保持しているArrayListが変わるわけではなく、変数fooが保持しているArrayListの中身が変わったとみなせます。

対比として以下をイメージすると理解しやすいかもしれません。

val foo = arrayListOf(1,2,3)
foo.add(4)

//新しいインスタンスを作成して再代入しようとしている為、これではエラーになります
foo = arrayListOf(1,2,3,4)

でもこれでエラーになるんだけど?

foo と bar は同一のインスタンスだよね?

class Foo{}
val foo = Foo()
var bar = foo
foo = bar //エラー

保持しているFoo()インスタンスを同じFoo()インスタンスに変更しようとしているから。

オブジェクトは理解したけどプリミティブ値は?

プリミティブ値も内部的にはオブジェクトなので同様の扱いです。 プリミティブ値に対して、+==の演算子が自然と使えるのは演算子をオーバーロードしているからだと思います。

ループ内でvalを使うと再代入出来るんだけど?

(0..5).forEach {
    val p = Integer.parseInt(it.toString())
}

val 変数のスコープが{ }の間だけだから。

varを使うケース

実はvarを使うシーンはあまりありません。使うケースとしては

インスタンス作成時に参照オブジェクトが決まらないメンバ変数

lateinit varを使う

lateinit var foo:View

計算結果によってプリミティブ値に変化を加える

var i:Int = 0
if( true ){ i++ }

思いつけば追記予定

Android 怖くないRecyclerView

タイトルは釣りです。ごめんなさい。

昨日、ハマってしまったのでRecyclerViewについて整理したことをメモ。

RecyclerViewの最小構成

layoutファイル

activiity_main.xml 画面幅一杯のRecyclerViewを配置

<?xml version="1.0" encoding="utf-8"?>
<android.support.constraint.ConstraintLayout
        xmlns:android="http://schemas.android.com/apk/res/android"
        xmlns:tools="http://schemas.android.com/tools"
        xmlns:app="http://schemas.android.com/apk/res-auto"
        android:layout_width="match_parent"
        android:layout_height="match_parent"
        tools:context=".MainActivity">
    <android.support.v7.widget.RecyclerView
            android:layout_width="0dp"
            android:layout_height="0dp"
            app:layout_constraintEnd_toEndOf="parent"
            app:layout_constraintStart_toStartOf="parent"
            app:layout_constraintTop_toTopOf="parent"
            app:layout_constraintBottom_toBottomOf="parent"
            android:id="@+id/recycler_view"/>
</android.support.constraint.ConstraintLayout>
layoutファイル RecyclerViewのitem

RecyclerViewのアイテム サンプルとしてImageViewとTextViewを配置

recycler_item.xml

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout
              xmlns:android="http://schemas.android.com/apk/res/android"
              xmlns:app="http://schemas.android.com/apk/res-auto"
              android:orientation="vertical"
              android:layout_width="match_parent"
              android:layout_height="match_parent">
    <ImageView
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            app:srcCompat="@drawable/glogo"
            android:id="@+id/imageView"/>
    <TextView
            android:layout_width="match_parent"
            android:layout_height="wrap_content" android:id="@+id/textView"/>
</LinearLayout>
Activity

Activity側の最小の実装

class MainActivity : AppCompatActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        val recycler_view = findViewById<RecyclerView>(R.id.recycler_view)
        //RecyclerViewを利用する時は必ずlayoutManagerを指定する
        //指定しないと例えadapterをセットしてもUIに反映されない。というかadapterのコールバックが呼ばれない
        recycler_view.layoutManager = LinearLayoutManager(this,LinearLayoutManager.HORIZONTAL, false)

        //RecycleViewはデフォルトでViewHolderパターンを採用しているので、
        //ViewHolderの定義しておく
        class mViewHolder(item_view: View): RecyclerView.ViewHolder(item_view){
            val textView = item_view.findViewById<TextView>(R.id.textView)
        }
        // adapterのセット
        // RecycleViewのadapterはRecyclerView.Adapterの抽象メソッドを実装する
        recycler_view.adapter = object : RecyclerView.Adapter<mViewHolder>(){
            //ViewHodlerの生成
            override fun onCreateViewHolder(parent: ViewGroup, p1: Int): mViewHolder {
                val itemView = LayoutInflater.from(parent.context).inflate(R.layout.recycler_item, parent,false)
                return mViewHolder(itemView)
            }
            //ViewHodlerで保持しているviewに対して値をセット
            override fun onBindViewHolder(holder: mViewHolder, p1: Int) {
                holder.textView.setText( p1.toString())
            }
            //RecycleViewに配置するitem数
            override fun getItemCount(): Int {
                return 3
            }
        }
    }
}

ListViewと違うのは、layoutManagerをセットしないとadapterをセットしただけでは動作しません。

recycler_view.layoutManager = LinearLayoutManager(this,LinearLayoutManager.HORIZONTAL, false)

上記の実装ではLinearLayoutManager.HORIZONTALを指定したので、横スクロールします。

f:id:letitride:20190615152707p:plainf:id:letitride:20190615152730p:plain

アイテムのサイズを調整する

私はアイテムサイズを変更の際、recycler_item.xmlをLinearLayoutで記述しており、何故か中のViewがloopしていると勘違いしていました。よって、中のView自体のサイズを変更すると以下のようなレイアウトになってしまいます。

f:id:letitride:20190615153536p:plainf:id:letitride:20190615153541p:plain

ご覧のように画面幅一杯にitemが配置され、いくらviewサイズを小さくしてもpaddingが大きくなります。

itemのサイズを小さくするにはLinearLayoutのViewGroupがloopしているのでViewGroupのサイズを調整します。

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
              xmlns:app="http://schemas.android.com/apk/res-auto" android:orientation="vertical"
              android:layout_width="300dp"
              android:layout_height="match_parent">
    <ImageView
            android:layout_width="wrap_content"
            android:layout_height="wrap_content" app:srcCompat="@drawable/glogo" android:id="@+id/imageView"/>
    <TextView
            android:layout_width="match_parent"
            android:layout_height="wrap_content" android:id="@+id/textView" android:textSize="36sp"/>
</LinearLayout>

f:id:letitride:20190615154402p:plain:h400

少し頭を冷やせばすぐにitem自体がloopしていると気づくのですが、これに気づかずに長時間ハマってしまいまいた(^_^;)

アイテムのマージンを調整する

アイテムのマージンはRecyclerView.ItemDecorationの実装をセットします。

val recycler_view = findViewById<RecyclerView>(R.id.recycler_view)
recycler_view.apply {
    layoutManager = LinearLayoutManager(context,LinearLayoutManager.HORIZONTAL, false)
    addItemDecoration( object : RecyclerView.ItemDecoration(){
        override fun getItemOffsets(outRect: Rect, view: View, parent: RecyclerView, state: RecyclerView.State) {
            outRect.right = 20
        }
    })
}

このようにgetItemOffsetsにマージンの値を指定します。

Android WebViewに直接HTMLを記述する

WebViewに対して、さらっと書き捨てのHTML等を直接記述出来ます。

val webView = findViewById<WebView>(R.id.web_view)
webView.loadData("<a href=\"https://www.google.com\">グーグル検索</a>", "text/html", "utf-8")
何が便利か?

クッションページが必要だけど、敢えてHTMLファイルとして作成するほどでもないケース。

私の場合、RecyclerViewの各ItemにWebViewを配置したのですが、WebViewがアクセスするURLにPDFファイルも含まれていた為、PDFへのURLの場合、クッションページを用いました。 例えば、以下のように記述すると書き捨てのaタグのクリックイベントが奪えるので、PDFファイルへのリンクを他のインテントに飛ばしたり出来ます。

if( url == PDFリンク ){
    webView.loadData("<a href=\"" + url +  "\">PDFファイルを確認</a>", "text/html", "utf-8")
    webView.webViewClient = object : WebViewClient(){
        override fun shouldOverrideUrlLoading(view: WebView?, request: WebResourceRequest?): Boolean {
            return false
        }
    }
}else{
    webView.loadUrl( url )
}

Android Kotlin 怖くないAsyncTaskLoader

タイトルは釣りです。すいません。

AsyncTaskLoaderを気軽に使えるように整理したのでメモとして残しておきます。

基本形

  • 別スレッドでの処理はAsyncTaskLoaderのloadInBackgroundに記述
  • loadInBackgroundで完了した処理データをUIスレッドで操作するにはLoaderManager.LoaderCallbacksのonLoadFinishedに記述
supportLoaderManager
  1. supportLoaderManagerinitLoader()を実行してLoader(別スレッド)が起動。
  2. supportLoaderManagerはActivity内で一つしか存在しない
    • Activity内で複数のLoaderを扱いたい時はinitLoader()の第一引数idを変更して管理します。
    • 例えば、supportLoaderManager.initLoader(1, null, callbacksA)とした後、supportLoaderManager.initLoader(1, null, callbacksB)としてもcallbacksAに定義されたローダーが再び呼び出される。正しくはidを変更してsupportLoaderManager.initLoader(2, null, callbacksB)とします。
LoaderManagerのコールバック
  1. initLoader()にはLoaderManagerがコールバックするLoaderの生成処理Loaderがロードを完了した時の処理Loaderがリセットされた時の処理のインターフェース実装を渡します。
    • initLoader()時にLoaderの生成処理がコールバックされます。
  2. Loaderの生成処理はAsyncTaskLoaderを実装したオブジェクトを生成してLoaderManagerに返します。
AsyncTaskLoaderの実装
  1. AsyncTaskLoaderは実際にバックグラウンド(別スレッド)で行う処理バックグランドで処理を開始する準備が整った時に呼び出される処理(onStartLoading)を記述します。
    • 理由はよくわからないのですが、私の環境ではinitLoader()後、ActivityのonResumeがトリガされたタイミングでinitLoaderせずともonStartLoadingが呼び出されるような挙動を確認しました。必要に応じて、正しいAsyncTaskLoaderの使い方 - Qiita この記事のように再ロード防止のフラグを設けます。

上記の実装の最小構成が以下となります。

val context = this
//supportLoaderManagerがコールバックするメソッドの実装
val callbacks = object : LoaderManager.LoaderCallbacks<String> {
    //ローダー生成の実装
    override fun onCreateLoader(id: Int, args: Bundle?): Loader<String> {
        return object : AsyncTaskLoader<String>(context) {
            //生成したローダーが行う処理の実装
            override fun loadInBackground(): String? {
                return null
                }
            }
            override fun onStartLoading() {
                forceLoad()
            }
        }
    }

    override fun onLoadFinished(loader: Loader<String>, data: String?) {
    }

    override fun onLoaderReset(loader: Loader<String>) {
    }
}
//ローダーの起動
supportLoaderManager.initLoader( 1, null, callbacks )

ジェネリクスはloadInBackgroundで返却されるオブジェクトの型です。大半の場合はStringで良いかと思います。

インターフェース実装をメソッド化して取り扱う

他の各Activityや同じActivity内で複数のローダーが必要な場合など実装を生成しやすいようメソッド化します。 各、コールバックメソッドの実装をエンクロージャ引数として渡すようにすれば、呼び出し側から各処理の中身を定義することができます。

fun <T>createLoaderCallbacks(
    context: Context,
    backgroundTask:(()->T?)?,
    onLoadFinishedTask:((Loader<T>, T?)->Unit)?,
    onLoaderResetTask:((Loader<T>)->Unit)?
    ):LoaderManager.LoaderCallbacks<T>
{
    return object : LoaderManager.LoaderCallbacks<T> {
        override fun onCreateLoader(id: Int, args: Bundle?): Loader<T> {
            return object : AsyncTaskLoader<T>(context) {
                override fun loadInBackground(): T? {
                    return backgroundTask?.let {
                        backgroundTask!!()
                    }
                }
                override fun onStartLoading() {
                    forceLoad()
                }
            }
        }

        override fun onLoadFinished(loader: Loader<T>, data: T?) {
            onLoadFinishedTask?.let {
                onLoadFinishedTask!!(loader, data)
            }
        }

        override fun onLoaderReset(loader: Loader<T>) {
            onLoaderResetTask?.let {
                onLoaderResetTask!!(loader)
            }
        }
    }
}

呼び出し側の実装

呼び出し側はシンプルに実装できます。

private fun getWord():String?{
    return "文字列"
}
private fun printWord(loader:Loader<String>, data:String?){
    Log.d("word", data)
}

private fun doBackground() {
    //引数つきの関数オブジェクト
    val funcAssignTopics:(Loader<String>, String?)->Unit = ::assignTopics
    //無名関数の場合
    //val funcAssignTopics:(Loader<String>, String?)->Unit = fun (loader:Loader<String>, data: String?){}
    //ラムダ式で渡す場合
    //val funcAssignTopics:(Loader<String>, String?)->Unit = { loader, s -> }

    val callbacks = createLoaderCallbacks<String>(
        this,
        ::getWord,
        funcAssignTopics,
        // { loader, s -> } ラムダ式で記述も出来る
        null )

    val lm = supportLoaderManager
    lm.initLoader(1, null, callbacks)
}

このように必要な処理のみ記述でコールバックの実装の生成が可能です。

参考 https://developer.android.com/guide/components/loaders?hl=ja

Android KotlinでDialogFragmentを扱う

Javaで記述したDialogFragmentをKotlinに自動変換行った時、

method kotlin.jvm.internal.Intrinsics.checkParameterIsNotNull, parameter savedInstanceState

とエラーが出ることがあります。これはエラーメッセージの通りsavedInstanceStateにnullが渡される可能性があるので、オプショナル型で受け取る必要があります。

class MyDialogFragment: DialogFragment() {

    //method kotlin.jvm.internal.Intrinsics.checkParameterIsNotNull, parameter savedInstanceState
    //Bundle を Bundle? とします
    override fun onCreateDialog(savedInstanceState: Bundle?): Dialog {
    }
}
DialogFragmentの実装

実装はKotlinらしくapplyを利用して比較的すっきり記述することができます。

各ラベル内容をBundleで渡し、リスナーの実装を定義できるようにすることである程度使い回し可能なクラス定義となります。

class MyDialogFragment: DialogFragment() {

    var onPositiveListener:DialogInterface.OnClickListener? = null
    var onNegativeListener:DialogInterface.OnClickListener? = null

    override fun onCreateDialog(savedInstanceState: Bundle?): Dialog {
        val builder = AlertDialog.Builder(context!!)
        builder.apply {
            setTitle(arguments?.getString("title"))
            setMessage(arguments?.getString("message"))
            setPositiveButton(arguments?.getString("positiveButtonLabel"), onPositiveListener)
            setNegativeButton(arguments?.getString("negativeButtonLabel"),onNegativeListener)
        }
        // Create the AlertDialog object and return it
        return builder.create()
    }
}
DialogFragmentの利用例

こちらもapplyを用いて以下のように記述できます。

MyDialogFragment().apply {
    arguments = Bundle().apply {
        putString("title", "確認してください")
        putString("message", "規約に同意します")
        putString("positiveButtonLabel", "はい。同意します")
        putString("negativeButtonLabel", "いいえ")
    }
    //OKボタンリスナー
    onPositiveListener = DialogInterface.OnClickListener { dialog, which ->
    }
}.show(supportFragmentManager, "test")

applyですっきりするするのが良いですよね(^_^)

Android プラットフォーム リソースにアクセスする

Androidにはデフォルトで用意されているアイコンとして利用可能な豊富なdrawable プラットフォームリソースがあります。

f:id:letitride:20190614101125p:plain

プラットフォームリソースを確認する

Layout EditorのAll attributeから確認するのが簡単です。

f:id:letitride:20190614101834p:plain

f:id:letitride:20190614101738p:plain のアイコンを押下し、Drawable -> androidと選択するとプラットフォームリソースの確認が行えます。

プラットフォームリソースにアクセスする

Layout XMLからアクセス

頭に@androidを記述してアクセスします。

android:icon="@android:drawable/alert_dark_frame"
ソースコードからアクセス

R.drawable.resource_nameとするとプロジェクトのres/drawable/フォルダ内の参照となるので、頭にandroid.をつけプラットフォームリソースへアクセスします。

view.setIcon(android.R.drawable.alert_dark_frame)

参考 リソースへのアクセス  |  Android Developers

はてなブログPROの独自ドメインでアドセンス申請時に「お客様のサイトにリーチできません」となる問題

結構な人が困っているようなので、自分が解決した時の対処を記載しておきます。

前提として

  • ドメインはお名前ドットコムで取得
  • はてなブログはhttps対応としてしている

です。

そもそもの問題

はてなブログPROの独自ドメイン機能はURLの独自ドメインの頭にwww.をつけることが必須となりますが、アドセンス申請時にwww.ドメイン名で入力するとwww.が無視されるため。

はてなブログ側でブログのURLを

https://www.letitride.jp と設定すると、

アドセンス申請のURLが

https://letitride.jp となってしまいブログのURLと別URLへ申請することになってしまっています。

ブラウザによっては、URL入力バーに直接https://letitride.jp入力すると、https://www.letitride.jpと補完されたアクセスするブラウザもあるかもしれませんが、これはブラウザの機能なのでアドセンス側での自動確認処理では当然、https://letitride.jpにアクセスするので「お客様のサイトにリーチできません」と表示され混乱することがあるかもしれません。

解決編

URLの転送設定を行います。

以下の例として記載している私のドメインletitride.jpはご自身で取得したドメイン名に置き換えて下さい

もしすでにletitride.jpのAレコードアドレスにご自身のサーバをお持ちであれば、:80または:443ポートに届いたリクエストをwww.letitride.jpに転送すれば良い話しですが、以下はご自身でサーバを管理していない方向けへの解決方法です。

お名前ドットコムのドメイン管理画面で転送設定を行う
  1. お名前ドットコムにログイン後、ヘッダーメニューのオプション設定を選択します
  2. 転送Plus欄のURL転送設定を選択します
  3. はてなブログに設定したドメインの設定するボタンを押下します
  4. 下の画像のように転送先のURLをはてなブログPROに設定したURLに。ここでははてなブログ側で自動でhttpのアクセスはhttpsにリダイレクトをするので、http://として入力しました。転送タイプはリダイレクトと設定します。 f:id:letitride:20190613223040p:plain お名前ドットコムで転送Plusを設定するとletitride.jpに対しての転送用サーバが自動で配置され、下段の163.44.76.141が自動配置されたサーバのアドレスとなります。

お名前ドットコムでの設定は以上です。

数十分もまてばお名前ドットコム側で転送Plusの設定が完了するはずなので、ブラウザからwww.なしのURLをURL欄に入力して確認してみて下さい。

f:id:letitride:20190613224349p:plainf:id:letitride:20190613224401p:plain

実際にはブラウザとサーバ間では2度の転送が行われています。(お名前ドットコムでhttp://letitride.jpからhttp://www.letitride.jp、はてなブログでhttp://www.letitride.jpからhttps://www.letitride.jpに転送)

アドセンス申請時の入力URL

お名前ドットコムの転送Plus設定はhttpのアクセスのみ転送されます。httpsは転送されません。 f:id:letitride:20190613225141p:plain

よって、アドセンスの申請はhttpにて申請します。www.はアドセンス側で削除されるのですが、http://www.letitride.jpと申請して下さい。理由はアドセンス内部では支払い対象のサイトURLとしてwww.letitride.jpを認識できているようです。後に余計なトラブルになる可能性もあるので、http://www.letitride.jpと申請しておいたほうが良いと思います。

アドセンスのコード確認ツールはhttp://letitride.jpから上記のように2段階の転送を経てhttps://www.letitride.jpにアクセスされます。 これでアドセンスのコード確認ツールがはてなブログにアクセス出来るようになります。

まとめ

  1. お名前ドットコムの転送Plus設定を行う
  2. アドセンスにはhttpでwww.付きで申請