アカウント名:
パスワード:
こういう問題を起こさないための共通プラットフォームなんじゃないのか。Windowsが乗るハードはいくらでも種類があるが、Windowsアプリをハードごとにテストするなんて話は聞いたことが無い。Android携帯はハードごとにOSに手を加えるなんて事をせず、インタフェースや搭載アプリでのみ差別化を図るべきだ。
Windows98、多分Windows2000の初期まではハードウェアが違うと対応しないとか走ってるプロセスの中身によっては動かない。とか普通でしたよ。# グラフィックボードに関するあれこれは除外します。あの頃は独自仕様のドライバじゃないと動かないハードウェアがゴロゴロしてて、そのドライバが悪さするとか普通でした。
しかし、いまどきのLinuxベースOSでそんな事があると言うのが恐ろしく不思議な話ですが。どちらかというとドライバやドライバ叩くミドルウェアの出来に、メーカごとのばらつきがありすぎるのでは…タレコミ文を読んでると、UI関連の動作のばらつきを問題例にしてるようですし。
Android携帯はハードごとにOSに手を加えるなんて事をせず、インタフェースや搭載アプリでのみ差別化を図るべきだ。
まぁ、μITronとかのRTOSだとOSに手を加えるのが普通なんですけどね(´・ω・`)そもそも補助記憶がそんなに大きくないからドライバ全部積むというわけにも行かない(そのハードウェアで必要最低限のドライバだけ積む)のでしょうし。
PCなんてモニタの数すら多様だし、さらに使っている最中に90度回転する奴もいるし。それでもアプリレベルで解決してますけどね。ウィンドウじゃなくてアクティビティだから話は違うだろという事かな。
ハードを無視した議論は無意味だと思いますよ。特に組み込み系は。
リソースジャブジャブのPCなら抽象化はそれほど難しくないでしょうけど、ギリギリのリソースしか使えない組み込み系はそんなことしたら重くて死ねる。移動機系ならバッテリーまで死ねる。
ことAndroidに関して言えば解像度の違いはフレームワークレベルで吸収されています。例えばフォントサイズを指定する場合、「160dpi端末で何ピクセル相当か」という値で指定し端末に合わせて適切な値に変換され、内部ではネイティブの数字で持っています。また、相対値での指定も多く使われます。まあもちろん全くのオーバーヘッドゼロではないですが、フレームワーク側でかなり初期に変換を掛けられますのでさほど問題にはならないです。というかまぁ今時のスマートフォンはロースペックでもCPUは500MHzとかですのでさすがにこのくらいの処理は余裕です。フレームワークから外れたことをすると考慮する必要は出てきますが、まあ概ね良く出来た仕組みですよ。
Androidのこの辺の問題を話す時、Android開発の外側の人は必ず「解像度の違い」とか「OSバージョンの違い」とかの問題だと勘違いするんですよね。でもそういうとこ、実はほとんど問題にならないです。最初からそんなことは当たり前として想定済みの設計ですから。問題になるのは「キーボードが付いているかどうか」とか「トラックボールが付いているかどうか」とかそういうところなんです。つまりトラックボールに依存したUIにしてしまうと、トラックボールがない端末では使えない、ということですね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike
なんのためのAndroidだ (スコア:0)
こういう問題を起こさないための共通プラットフォームなんじゃないのか。
Windowsが乗るハードはいくらでも種類があるが、
Windowsアプリをハードごとにテストするなんて話は聞いたことが無い。
Android携帯はハードごとにOSに手を加えるなんて事をせず、
インタフェースや搭載アプリでのみ差別化を図るべきだ。
不思議だ(Re:なんのためのAndroidだ (スコア:1)
Windows98、多分Windows2000の初期まではハードウェアが違うと対応しないとか走ってるプロセスの中身によっては動かない。とか普通でしたよ。
# グラフィックボードに関するあれこれは除外します。
あの頃は独自仕様のドライバじゃないと動かないハードウェアがゴロゴロしてて、そのドライバが悪さするとか普通でした。
しかし、いまどきのLinuxベースOSでそんな事があると言うのが恐ろしく不思議な話ですが。どちらかというとドライバやドライバ叩くミドルウェアの出来に、メーカごとのばらつきがありすぎるのでは…タレコミ文を読んでると、UI関連の動作のばらつきを問題例にしてるようですし。
まぁ、μITronとかのRTOSだとOSに手を加えるのが普通なんですけどね(´・ω・`)
そもそも補助記憶がそんなに大きくないからドライバ全部積むというわけにも行かない(そのハードウェアで必要最低限のドライバだけ積む)のでしょうし。
Re: (スコア:0)
PCなんて画面数すら多様 (スコア:1)
PCなんてモニタの数すら多様だし、さらに使っている最中に90度回転する奴もいるし。それでもアプリレベルで解決してますけどね。ウィンドウじゃなくてアクティビティだから話は違うだろという事かな。
屍体メモ [windy.cx]
Re:PCなんて画面数すら多様 (スコア:1)
ハードを無視した議論は無意味だと思いますよ。
特に組み込み系は。
リソースジャブジャブのPCなら抽象化はそれほど難しくないでしょうけど、
ギリギリのリソースしか使えない組み込み系はそんなことしたら重くて死ねる。
移動機系ならバッテリーまで死ねる。
Re:PCなんて画面数すら多様 (スコア:1, 参考になる)
ことAndroidに関して言えば解像度の違いはフレームワークレベルで吸収されています。
例えばフォントサイズを指定する場合、「160dpi端末で何ピクセル相当か」という値で指定し端末に合わせて適切な値に変換され、内部ではネイティブの数字で持っています。また、相対値での指定も多く使われます。
まあもちろん全くのオーバーヘッドゼロではないですが、フレームワーク側でかなり初期に変換を掛けられますのでさほど問題にはならないです。というかまぁ今時のスマートフォンはロースペックでもCPUは500MHzとかですのでさすがにこのくらいの処理は余裕です。
フレームワークから外れたことをすると考慮する必要は出てきますが、まあ概ね良く出来た仕組みですよ。
Androidのこの辺の問題を話す時、Android開発の外側の人は必ず「解像度の違い」とか「OSバージョンの違い」とかの問題だと勘違いするんですよね。でもそういうとこ、実はほとんど問題にならないです。最初からそんなことは当たり前として想定済みの設計ですから。
問題になるのは「キーボードが付いているかどうか」とか「トラックボールが付いているかどうか」とかそういうところなんです。つまりトラックボールに依存したUIにしてしまうと、トラックボールがない端末では使えない、ということですね。
Re: (スコア:0)
動作するかどうかなんてWindowsやMacでも一緒かと。
ソフトもハードも完全に一緒ではない限り、夢物語です。
# Windowsなんかではやらないのではなく、多すぎてやれないのです。
ちなみに、色々端末毎にカスタマイズされてるAndroidですが、一応CTS試験というAPIの仕様や挙動の
互換性試験をしていますので、普通の使い方をする分にはWindowsなんかと同じ程度(かどうかは、良く
知らないですが)には問題ないはずです。