はじめてのAndroidプログラミング

私にとってモバイルや通信は全くの専門外ですが、勉強も兼ねてボランティアで日本語学習者を対象とした Android OS 向けの辞書アプリを作成しています。その際に利用した最初かつ唯一の入門書が本書になります。


超初心者でも大丈夫! はじめてのAndroidプログラミング Android Studio 2対応

取り敢えずのJavaの基礎さえあれば、これ一冊で導入から短期間でアプリケーションの開発ができてしまうのですから驚きという他にありません。

もちろん、私自身は全くの初心者という訳ではなく、学部生の時分にはアルバイトで分散リアルタイム解析を行っていたぐらいのJavaの知識はあります。

冒頭の写真にある参考書の内容ぐらいは把握していますので、その程度の知識と経験を持った上での感想である事をご了承ください。



本書の構成は章ごとに独立したアプリケーションの作成を通して新しい内容を学ぶ事に一貫されており、まずは開発環境のAndroid Studioの導入と設定に始まり、画面の作成、画面の遷移、ダイアログ表示やカレンダー、センサーの利用と進み、最終的に OR Mapper や外部の Web API を用いたアプリケーション開発までの範囲を網羅しています。

これだけ幅広い内容を取り扱いながら、文字コードの設定 (日本語入力に必須) やエディタの行数表示などの細かい部分にまで気が配られている事に好感を覚えます。

『はじめに』に記述されている「プログラミングの初心者でもつまづかないよう」にとの配慮でしょうが、それだけにエラーメッセージについての項目がなく「ツールウィンドウがある」という表記に留まっているのが少し気に掛かりました。

詳しくは後述しますが、プログラミングでつまづいた際に解決する手掛かりとなるのがエラーメッセージなので、ググり方を知らない本当の初心者だけでなく「ある程度の経験がある」読者のためにもあっても良いのではないかと思われました (私は最初の頃はエラーで苦労しました)。

それというのも本書のコードを見ながらメソッドを穴埋めしていくとビルドに失敗したり、クラッシュしたりする事が何度かあったのです。

そこでエラーメッセージを見直してみると次のような警告がなされていたりします。

error: no suitable method found for show(android.app.FragmentManager,String) method

このエラーが出る原因は android.app.DialogFragment を読み込むべきところに自動インポートで android.support.v4.app.DialogFragment を読み込んでいる事にあります。

本文の説明やサンプルコードには android.app.DialogFragment をインポートするとしっかり書いてありますが、(自動インポートだけに) コード解説部分では省略されているので気が付かないと何処が間違っているのか分からずに立ち往生します (インポート部分だけはサンプルコードからコピー&ペーストした方が確実です)。



さらに困った事には、現行の Android Studio 2.2.2 でボタンの OnClick 動作を行うとプログラムが落ちてしまう事があります。

これは Android Studio のバグかもしれません が、Android入門者には何が起こっているのか見当もつきません。

Javaの開発経験で養った勘を活かして次のようなエラーメッセージを確認する事で、初めて何が起こっているのかを把握する事ができます。

java.lang.IllegalStateException: Could not find method methodName (MainActivity)(View) in a parent or ancestor Context for android:onClick attribute...

これを見るとメソッドを見つける事ができない事が原因となっているので、activity_main.xml を編集して手動でメソッド名を追加してしまえば何とかなるのではないかと対処方法を考える事ができるようになります※。

換言すれば、若干、不足気味と感じられたのは問題発生時の対処程度であり、入門書で扱う範囲については過不足なくまとめられている良書であると思われました。

さすがにGradleによるビルド等には触れられていませんが、この一冊だけでAndroidアプリケーションの構成からGUIとイベント処理、ミドルウェアの取り扱いについて不安がなくなった事は事実です。

章ごとに独立したプロジェクトを立ち上げるのでアプリケーションが乱立気味にはなりますが、その分、繰り返す事により後半に進むに連れて展開が予想できる程にAndroid開発に慣れてきます。

この章ごとに独立した構成から最初の4章までを除いて、以降は興味のある内容を扱った章のみを摘み食いしても差し支える事はおそらくありません。

総評すると最初の一冊としての選択として間違いのない内容であったと思われました。




※ この問題については Layout の編集において”Text”タブをクリックし、

android:onClick="methodName (MainActivity)"

上の部分を次のように書き換えると無事に参照できるようになります。専門外なので原因は分かりません。

    android:onClick="methodName"

余談

プログラミング初心者の方の為に追記しますが、第2章のレイアウトXML編集 (レイアウトエディタ) では本書で紹介されている LargeText が存在しない為、自己判断で Plain Text で代用しました。

変数の参照さえ合っていれば、部品は何を使っていてもプログラムとしては問題ありません。

同じく第4章では、ボタンクリック後の遷移先の画面に空の (画像を指定しない) ImageViewを作成できなかったので Drawable の中の適当な画像を選択して my_hand_image を作成しています。

プログラムの構造上、この変数は遷移前の画面で指定された画像に置き換わる事は自明なので、本書と同じように空の ImageView が作成できないという理由で立ち止まらず、変数だけ作成してしまって先に進んだ方が賢明です。

関連記事:

廉価 Android タブレット・ASUS ZenPad 8.0 を購入

自身で開発したアプリケーションのデモ機として ASUS の Android タブレット ZenPad 8.0 Wi-Fiモデル を購入しました。

デモ用途、つまり他人に見せる目的で使用しますので、求めているものは安定してストレスなく動作する最低限の性能と壊されても惜しくない価格の両立です。

目的からして Android OS におけるスタンダードモデル HTC Nexus 9 であっても構わなかったのですが、2GBの内蔵メモリ(RAM)が搭載されており、現時点における最新版のOSがプリインストールされているのであれば十分だろうという判断から。より安価な本モデルを選びました。

Android端末はおよそ1年ほど使用しているので、OSの使い勝手は良く把握しています。しかし、実売価格で2倍以上の差があるハイエンド端末 (Xperia Z5) と比較して、低価格を優先して性能を妥協したモデルで大丈夫かなという不安はもちろんありました。

特に気になったのはフリック入力の反応速度とシステムの安定性です。しかし実際に使用して見たところ、文字入力のストレスもありませんでしたし、幾つものアプリケーションを並行して走らせても挙動が不安定になることはありませんでした。

こうした点が気掛かりであったのは、初期のAndroidタブレットではカナ漢字変換の処理が重かったり、キーボード入力から文字が反映されるまでの速度が気になるモデルが散見されていた為です。

本モデルでは文字入力が気にならないどころか、XperiaやiOSデバイスと比較しても全く違和感がなく、画面の切り替えも思った以上にスムーズにできる事に驚きました。

画面解像度 1280 * 800 も液晶画面も文句なく美しいです。

逆に気になったのは、見かけに反して 本体重量が重い 事と、この重さと大きさにも関わらず 内蔵バッテリーが4000mAhしかない 事です。

私は自作のアプリケーションをインストールして他人に貸し出す用途のみに使うので全く問題ありませんが、普通のタブレット端末として使用する場合には心許ない気がします。



デモ機としてはありがたい事に、USBポートは筐体上側のヘッドフォンジャックの横にあります。この位置ですとケーブルを接続したまま、実機を用いてのUSBデバッグを繰り返し試すことができるので都合が良いのです。



一通りのテストを実施しての感想としては、デモ機としては十分過ぎる贅沢な環境に思えますが、まだまだ使って見ないと何とも言えませんので使用において気づいた点があれば改めて追記します。

関連記事:

ニューラルネット翻訳が実用化される時代にできる事を考える

日本国内の機械学習クラスタ※では昨日から大きく話題になっていますが、Google翻訳における日本語・英語翻訳にニューラルネットワークが導入されたようです。

ニューラルネットワークを用いた機械翻訳自体が新しい (私の記憶違いでなければ初出は2014年) ので実装と実運用だけでも十分に話題性がありますが、そうした研究者、開発者の視点を排すると、翻訳先言語の出力文が従来の翻訳方式と比較して格段に流暢になっている事が注目の理由です。




ニューラルネット翻訳以前の (統計的) 機械翻訳は、翻訳元言語の1センテンスを単語または単語列の要素に分解してから翻訳先言語の単語 (列) に個別に変換する処理を行うものです。

従って部分的には正しい訳文を出力する事があっても、センテンス全体としては不自然な訳文が得られる事が少なくないのは皆さんのよく知られるところです。

今回、新しく導入されたニューラルネット翻訳は、翻訳元言語の文を入力として翻訳先言語で新しく出力文を生成するので、1センテンス単位で見た際に翻訳先言語の文として破綻が少ない事が特徴です。

その出力結果を見て、機械翻訳は数年以内に完成すると言った意見や翻訳者が不要になると言った趣旨の発言が散見された事が、今回の記事を書く事に至った直接的な動機となっています。

結論から述べると、今後の数年のうちに機械翻訳が完成する事はありませんし、翻訳者が不要になる事もありません。いくらニューラルネット翻訳の訳出が優れているとは言え、その原理上、既に過去に翻訳されて対訳文が整備された分野と言語対の組み合わせでなければ正確な翻訳は期待できませんし、現在の機械翻訳で新しい訳語を一から作り出す事はできません。

また (再現性とのトレードオフになるので微妙なところですが) 原文のニュアンスを伝えるための訳者のセンスは (その原著者と訳者の専用対訳コーパスなどを整備でもしない限り) 反映されませんので、訳文も常に画一的になります。

そして一般的には余り認知されていない事なのですが、機械翻訳に用いられる対訳文という特殊な翻訳文は量自体が限られている上に、分野と言語対の組み合わせに著しい偏りがあります。

機械翻訳は対訳文という過去の翻訳例を参照して再現するものですので、英語・フランス語間の法律文の翻訳など十分な対訳文が得られる分野と言語対では威力を発揮する事が期待されますが、日本語・ヘブライ語間での日常会話の翻訳には余り期待はできません。



機械翻訳と翻訳者の関係はここで終わりにしますが、この2者の関係は自動化が進む他の分野に於いても人ができる事を示唆する事例になると私自身は考えています。

自動運転でも光学文字認識 (OCR) でも音声認識でも新規性と同時に有用性を謳う以上、潜在的に既存の仕事を置き換える可能性を意識せざるを得ない場面はある訳ですが、一方で全ての運転手や議事録作成者が不要になる事は現実的ではないと思われます。

恒常的に反復されマニュアル化され得る部分については自動化が進む事が予想されますし、積極的に推し進めるべきでさえありますが、ルーチンでは処理できない判断や推測が必要となる部分ではどうしても専門家の知見が必要となります。


※ 人工知能という単語はアレルギー反応の原因となるので使いません