Locked History Actions

Diff for "Android/Principle"

Differences between revisions 3 and 4
Deletions are marked like this. Additions are marked like this.
Line 19: Line 19:
また、リソースを使用しないことにより、モジュールを単純なjarファイルにまとめることができ、
それを再利用することができるのである。

Androidの「ライブラリ」のやり方は答えになっていない。
Line 24: Line 29:

== プレゼンテーションとビジネスロジックを分離すること ==

巷の多くのサンプルはこれらをごたまぜにしている。
このような小さな機器のプログラムであってもそれらは分離されなければならない。

Androidアプリの開発方針

Android開発においてはJavaを用いることができ(一部では既にScalaを用いた開発も行っているようだが)、 Objective-Cのような中途半端な言語を使用しない点は評価できるのだが、しかし現代のJava開発の常識が汲まれているとは到底言いがたく、不可解な点も散見される。これに盲目的に従ってはならない。

すべてをラップすること

一般的に言えることであるが、APIを直接使用してはならない。ラップして使うべきである。なぜなら、

  • 一般にAPIはありとあらゆるケースを想定して仕様が決められているものである。その一部をラップしてその機能に限定して開発チームに使わせた方が効率がよい。
  • APIは大きく変更されることがある。ラップしていれば、その変更を吸収することができる(可能性がある)。
  • 特にAndroidの場合には、APIを直接使ってしまうとエミュレータ上か実機上でしかテストを実施することができない。Eclipse上では不可能なのである。

リソースをできるだけ使わないこと

リソースには意味が無い。というよりも、コードで生成することのメリットよりも、リソースを使うことのメリットが勝ることを説明する文書はどこにも見当たらない。 つまり、この仕組みの開発者でさえそれを説明することができないし、それを盲目的に利用しているあまたの本やウェブサイトの著者も明確な答えは持っていないのである(反論を歓迎します)。

また、リソースを使用しないことにより、モジュールを単純なjarファイルにまとめることができ、 それを再利用することができるのである。

Androidの「ライブラリ」のやり方は答えになっていない。

Eclipse上でテストすること

ユーザインターフェース自体は現在のところエミュレータ上でテストするしかないが、それ以外はできる限りEclipse上(Eclipseを使わないのであればJUnitのみで)テストできなければならない。

なぜJavaのコードであるのに、Eclipse上で動作させられないのであろうか?あるいは、通常のJavaとして動作させられないのであろうか?これはまことに不可思議であるとしか言いようがない。この点について、Android SDKの作者は根本的な間違いを犯していると断言できる。

プレゼンテーションとビジネスロジックを分離すること

巷の多くのサンプルはこれらをごたまぜにしている。 このような小さな機器のプログラムであってもそれらは分離されなければならない。