アカウント名:
パスワード:
やはりiPhoneにはメジャーにならないで欲しい。Javaの方が普通で良いと思う。
まだアプリの市場としてはiPhoneのが上なんですかね。Androidは機種ごとの差を考えるのが面倒臭そうです。OSのバージョンアップの浸透具合も考慮しないといけなさそうですし。
>Androidは機種ごとの差を考えるのが面倒臭そうです。
Tweetdeckの作者の発言を意図的にねじ曲げたアンチAndroid報道のせいで誤解されていますが、Androidの抽象化はしっかりしているので一般的な端末での互換性を取ることに問題はありません。
むしろiOS端末の熱心なクレーマー(同じiPhoneなんだから動くはずだろ絶対！！)の対応まで考慮すればむしろAndroid端末の方が楽かもしれません。消費者側の思考停止具合がiOS端末のそれよりもだいぶマシですから。
>OSのバージョンアップの浸透具合も考慮しないといけなさそうですし。
Androidマーケットでの配布において、OSバージョン(など)
>Androidの抽象化はしっかりしてても、>特定機種では独自魔改造が悪さをしてて動きませんとか普通にあると思うんですが。>特に国内メーカーのガランドロイド端末だと。
そういう例外系のほうを挙げるということであれば、是非具体例を出してみてください。
ちなみに、国産スマホはほぼSnapdragon一色で動作させるだけならむしろ安定です。「動かない」レベルの問題はほとんどありません。
横画面端末だと解像度申告において縦長と勘違いされて実際のアプリで下のほうのボタンが押せない、などが出る場合もありますが(これは開発者側で吸収可能であり、開発者が未熟なだけです)、
申し訳ありませんが、あなたの思考(というか職場の思考)が未熟なのが問題ではないかと思います。
>中身を（OSを）メーカがどういじったのか、品質的にGoogle様の基準を達したとしても>不安が残るから、そもそもクライアント担当者がdocomoやsbなど複数持っててどれでもちゃんと動くよね？>って一言いっちゃったもんだから、>いろんな端末で動作確認をしなきゃいけないわけです。
それは交渉で失敗しているだけです。クライアント担当者側が未熟ならそれを理解できるよう誘導するのも仕事のうちですよ。そこで、動作保証範囲を明確にせず「なんでも動く」などとしてしまえば、それこそデスマになるのは当然です。
これはiOSアプリでも同じで、前述「iPhoneならなんでも同じように動作するもの」と思考停止したクライアント担当者も多いものです。そんな担当者をうまく誘導できなければ、動作確認に必要な端末数は増加してしまいますね。
>品質保持においては理論云々より現場レベルじゃまだまだまだiOSに軍配が上がりますよ。
交渉に失敗している、という面は別としても、今の話は「品質保持(に必要なコスト)」ではありません。「品質保証(に必要なコスト)」です。両者は明確に違います。前者は品質問題発生というデジタルな要素で計測されますが、後者は心配要素、不安、安心というメンタルな面が多分に含まれるからです。
ここから先は、「機種が変わったら、実際問題多発するんかね？」の話になりますので、あなたの実経験を待たないと答えは出ませんが、「クライアント担当者が不安を持ちすぎなんだよ、 アーキテクチャ違いなど色のあるいくつかは試験必要だけどそれ以外はいらないのに」であれば、品質保持については、ぶっちゃけあなたの職場は過剰で無駄をやってるだけです。品質保証については、クライアント担当者をうまく誘導することで抑えられるでしょう。
最後に、「実際問題多発するんだよ」であればボカした書き方でいいので後学のためにどんな問題？を教えてくれると幸いです。
商用のPCソフトウェアをリリースするときに
「NECとFujitsuとDELLとhpとSONYとAcerとMSIとASUSとTOSHIBAとLenovoを全機種全OS揃えて動作確認しなきゃ！！」
ってやってますか？Androidの動作検証で無限スパイラルに陥ってる、前世紀指向の会社が今だ存在しますけど、今年中に破綻して来年には品質崩壊か撤退かするだろうなーと思ってます、はい。
せいぜい数機種をチェック（今ならXperia初代とGalaxyとTabくらい）、あとはチェックした機種を明記して「他で問題あったら連絡してね！」程度で十分。というかそうしないと破綻するのが目に見えてるのに、日本人はホントＭですよね。
事前チェックよりは、ユーザーデバッグｗの報告に対応する部分にコストかけた方が喜ばれます。
iOSのメリットなんて否定してないよ？単にAndroidのデメリットを否定してるだけで。ああ、上のほうのACと別人なので混乱したかね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
192.168.0.1は、私が使っている IPアドレスですので勝手に使わないでください --- ある通りすがり
Objective-Cでプログラムを書きたくないので， (スコア:0)
やはりiPhoneにはメジャーにならないで欲しい。
Javaの方が普通で良いと思う。
Re: (スコア:0)
まだアプリの市場としてはiPhoneのが上なんですかね。
Androidは機種ごとの差を考えるのが面倒臭そうです。
OSのバージョンアップの浸透具合も考慮しないといけなさそうですし。
Re: (スコア:0)
>Androidは機種ごとの差を考えるのが面倒臭そうです。
Tweetdeckの作者の発言を意図的にねじ曲げたアンチAndroid報道のせいで誤解されていますが、
Androidの抽象化はしっかりしているので
一般的な端末での互換性を取ることに問題はありません。
むしろiOS端末の熱心なクレーマー
(同じiPhoneなんだから動くはずだろ絶対！！)の対応まで考慮すれば
むしろAndroid端末の方が楽かもしれません。
消費者側の思考停止具合がiOS端末のそれよりもだいぶマシですから。
>OSのバージョンアップの浸透具合も考慮しないといけなさそうですし。
Androidマーケットでの配布において、OSバージョン(など)
Re: (スコア:0)
特に国内メーカーのガランドロイド端末だと。
Re: (スコア:1, 興味深い)
>Androidの抽象化はしっかりしてても、
>特定機種では独自魔改造が悪さをしてて動きませんとか普通にあると思うんですが。
>特に国内メーカーのガランドロイド端末だと。
そういう例外系のほうを挙げるということであれば、
是非具体例を出してみてください。
ちなみに、国産スマホはほぼSnapdragon一色で
動作させるだけならむしろ安定です。
「動かない」レベルの問題はほとんどありません。
横画面端末だと解像度申告において縦長と勘違いされて
実際のアプリで下のほうのボタンが押せない、などが出る場合もありますが
(これは開発者側で吸収可能であり、開発者が未熟なだけです)、
Re: (スコア:0)
仰ることは技術的には確かにそのとーりなんですが
こしらえたメーカが違うことは
中身を（OSを）メーカがどういじったのか、品質的にGoogle様の基準を達したとしても
不安が残るから、そもそもクライアント担当者がdocomoやsbなど複数持っててどれでもちゃんと動くよね？
って一言いっちゃったもんだから、
いろんな端末で動作確認をしなきゃいけないわけです。
品質保持においては理論云々より現場レベルじゃまだまだまだiOSに軍配が上がりますよ。
Re:Objective-Cでプログラムを書きたくないので， (スコア:1, 興味深い)
申し訳ありませんが、
あなたの思考(というか職場の思考)が未熟なのが問題ではないかと思います。
>中身を（OSを）メーカがどういじったのか、品質的にGoogle様の基準を達したとしても
>不安が残るから、そもそもクライアント担当者がdocomoやsbなど複数持っててどれでもちゃんと動くよね？
>って一言いっちゃったもんだから、
>いろんな端末で動作確認をしなきゃいけないわけです。
それは交渉で失敗しているだけです。
クライアント担当者側が未熟ならそれを理解できるよう誘導するのも仕事のうちですよ。
そこで、動作保証範囲を明確にせず「なんでも動く」などとしてしまえば、
それこそデスマになるのは当然です。
これはiOSアプリでも同じで、
前述「iPhoneならなんでも同じように動作するもの」と思考停止したクライアント担当者も多いものです。
そんな担当者をうまく誘導できなければ、
動作確認に必要な端末数は増加してしまいますね。
>品質保持においては理論云々より現場レベルじゃまだまだまだiOSに軍配が上がりますよ。
交渉に失敗している、という面は別としても、今の話は
「品質保持(に必要なコスト)」ではありません。
「品質保証(に必要なコスト)」です。
両者は明確に違います。
前者は品質問題発生というデジタルな要素で計測されますが、
後者は心配要素、不安、安心というメンタルな面が多分に含まれるからです。
ここから先は、「機種が変わったら、実際問題多発するんかね？」の話になりますので、
あなたの実経験を待たないと答えは出ませんが、
「クライアント担当者が不安を持ちすぎなんだよ、
アーキテクチャ違いなど色のあるいくつかは試験必要だけどそれ以外はいらないのに」
であれば、
品質保持については、ぶっちゃけあなたの職場は過剰で無駄をやってるだけです。
品質保証については、クライアント担当者をうまく誘導することで抑えられるでしょう。
最後に、「実際問題多発するんだよ」であれば
ボカした書き方でいいので後学のためにどんな問題？を教えてくれると幸いです。
Re:Objective-Cでプログラムを書きたくないので， (スコア:1, すばらしい洞察)
対応機種を限定することは商用ソフト販売において大きな制約です。
実機チェックをしないで対応を謳うのはリスクが大きいので、
ひととおり実機を揃える必要があると思います。
基本的にガイドラインに沿って開発すれば正常動作するはずなので、
仮に正常動作しない機種が見つかったら、それだけを非対応にしたりもできますし。
iOSの方が機種が少ないので、実機チェックは圧倒的に楽です。
それでも面倒くさい、という意見はわかりますが、
やろうと思えばやれる範囲です。
Androidでの全機種チェックはけっこう厳しいものがあります。
Re: (スコア:0)
商用のPCソフトウェアをリリースするときに
「NECとFujitsuとDELLとhpとSONYとAcerとMSIとASUSとTOSHIBAとLenovoを全機種全OS揃えて動作確認しなきゃ！！」
ってやってますか？
Androidの動作検証で無限スパイラルに陥ってる、前世紀指向の会社が今だ存在しますけど、
今年中に破綻して来年には品質崩壊か撤退かするだろうなーと思ってます、はい。
せいぜい数機種をチェック（今ならXperia初代とGalaxyとTabくらい）、あとは
チェックした機種を明記して「他で問題あったら連絡してね！」程度で十分。
というかそうしないと破綻するのが目に見えてるのに、日本人はホントＭですよね。
事前チェックよりは、ユーザーデバッグｗの報告に対応する部分にコストかけた方が喜ばれます。
Re: (スコア:0)
iOSに関してはチェック可能という話です。
実際問題としてAndroidはそういうやりかたでいいと思いますが、
iOSのメリットを否定する口実として、
全機チェックなんて前時代的だ、なんて言い訳するのはおかしいわけです。
できるものならチェックできたほうがいいんだから。
別にiOS自体が優れていると言っているわけではなく、
部分的に開発しやすい面もあるという話です。
Re: (スコア:0)
iOSのメリットなんて否定してないよ？
単にAndroidのデメリットを否定してるだけで。
ああ、上のほうのACと別人なので混乱したかね。