タグ付けされた質問 「mobile」

**モバイルアプリケーション開発**は、モバイルデバイス(通常は低電力のハンドヘルドまたはポータブルデバイス)用のアプリケーションソフトウェアが開発されるプロセスです。

3
モバイルアプリの複数のバージョンをサポート
現在サーバーへのWebインターフェースのみをサポートしている既存のアプリケーションを補足するために、ネイティブモバイルアプリケーションのスイートを構築しています。アプリケーションは、クライアントが独自のインフラストラクチャにインストールしてホストすることも、それを利用したいクライアントのために自分でホストすることもできます。大企業のお客様は通常、セルフホスティングを選択しましたが、小規模のお客様はホスティングオプションを選択しました。 アプリケーションの複数のバージョンをサポートする必要があります。すべてのお客様が同時にアップグレードを希望するわけではありません。Webインターフェイスでは、サーバーのインストールに関連付けられたサーバーバージョンがWebインターフェイスで自動的に使用されるため、複数のバージョンのサポートは難しくありません。通常、App Storeで利用できるアプリが1つしかないモバイルアプリケーションでは、モバイルアプリでのさまざまなレベルのサーバーAPIと機能のサポートが課題になります。他の人が問題をどのように解決しているか知りたいです。私の心には、次のようなオプションがあります。 アプリストアでアプリの複数のバージョンをサポートします。 モバイルアプリケーションにサポートを組み込み、通信しているサーバーのAPIバージョンを自動的に決定し、関連するサーバーAPIエンドポイントに呼び出しをルーティングします。また、サーバーのさまざまなバージョンで利用できる機能に基づいて、モバイルアプリケーションの機能を有効/無効にするために、ある種の機能切り替えメカニズムを使用することも紹介します。 アプリのデプロイにアプリストアを使用しないでください。アプリのダウンロードとインストールに使用できるバージョン固有のURLをユーザーに示します。 オプション1 -IMOはアプリのユーザーを混乱させます。また、実際には2つの独立したアプリケーションであるため、あるバージョンのアプリから次のバージョンへの移行パスは適切ではありません。 オプション2-一方、UIビジュアルは、基本的に、通信しているサーバーAPIのバージョンで利用可能な機能に適応する必要があることを考慮すると、すぐに非常に複雑になる可能性があります。また、必要なサーバーAPI呼び出しのさまざまなバージョンをサポートする必要があります。 オプション3-アプリのサイドローディングを行う場合、Androidの世界で可能ですが、私の知る限り、iOSではサポートされておらず、今後のWindows 10モバイルアプリの画像はどのようになるかわかりません。 この問題に取り組むために他にどのようなアプローチがありますか?私たちがネイティブアプリを作成しているという事実について議論しないでください。それは私が求めていることではありません。サーバーAPIの異なるバージョンと通信する同じネイティブモバイルアプリの複数のバージョンをサポートする問題に他の人々がどのように取り組んでいるのかについてのガイダンスを探しています。

3
HTML5とJSアプリがネイティブアプリと同じように機能しないのはなぜですか。
私が理解していることから、 HTMLはマークアップ言語であり、XAML、XIB、Androidが使用するもの、およびその他のネイティブUI開発フレームワークのコンテンツも同様です。 JavaScriptは、イベント処理、クライアント側の検証などのさまざまなフレームワークでC#、Java、Objective-C、またはC ++が行うことを含むクライアント側スクリプトを処理するためにJavaScriptと一緒に使用されるプログラミング言語です。 SenchaやAngularなどのフォームフレームワークで利用可能なMVC / MVVMパターンがあります。 他のフレームワークと同様に、sqliteとキー値ストアの両方の形式のlocalStorageがあり、不足しているほとんどすべてのAPI仕様があります。 ネイティブUIフレームワークがUIをレンダリングする必要がある場合は常に、同様のマークアップを解析してUIをレンダリングする必要があります。 質問の内訳 HTMLとJS自体で同じことをやめるのは何ですか? Webコントロールまたはブラウザーをレイヤーとして使用する代わりに、HTML(CSSと共に)とJSを同じように実行できないのはなぜですか? レイヤーがある場合でも、。++ランタイムとJVMは、C ++、Cが使用されていない他の場合にそうです。 それでは、DalvikのようなAndroidの場合を考えてみてください。なぜ、Chromiumが(dalvikとNDKと共に)別のオプションではないのですか? だから問題は、 現在の実装はそれほど良くない場合でも、理論的には、HTML5ベースのアプリケーションを他のモバイル用のネイティブアプリと同じように機能させることは可能ですか?

7
シンプルなiPhoneアプリは、モバイルWebサイトよりもユーザーにとって魅力的ですか?
クライアントがiPhoneアプリを実行したいのは、モバイル向けに最適化されたサイトでiPhoneアプリを使用する可能性が大幅に高いためです。iPhoneアプリは非常にシンプルです。いくつかの画像とテキストを表示するだけです。プログラマーとしては、コンテンツの単純な性質を考えると、むしろモバイルサイトを使用したいと思います。技術的な観点からは、この状況でiPhoneアプリを使用するのはやり過ぎだと思います。 ユーザーがむしろiPhoneアプリであるという理由だけで、モバイルサイトで十分なときにiPhoneアプリを構築することは理にかなっていますか?とにかく、モバイルサイトが使いやすいことをユーザーに簡単に納得させることはできますか?
9 iphone  mobile 

3
ネイティブモバイルアプリの開発-ユーザーストーリーをどのように構成しますか?
プロトタイプのネイティブモバイルアプリ(最初はiOSとAndroid)、およびこれらのアプリが通信するためのWebベースの管理インターフェイスとAPIの開発を伴うプロジェクトに着手しようとしています。既に作成されたストーリーのリストがありますが、それらの多くは次の形式になっています。 As a mobile user I want to be able to view a login screen so that I can sign into the app これが単一のプラットフォームを対象にしている場合、問題は発生しません。ただし、複数のプラットフォームを対象としているため、これらを「Androidユーザーとして」などに複製する必要があるかどうかは不明です。これは重複のように見えますが、プラットフォームごとに個別に完了する必要がある作業です。 これは、私たちがネイティブに行った最初のモバイルプロジェクトです。以前はPhonegapで、すべてのストーリーを「モバイルユーザーとして」にまとめました。これは本質的にネイティブコードでラップされたWebベースのアプリだったので、それほど問題にはなりませんでしたが、完全にネイティブなアプリは別の球技だと私は意識しています。

4
有料のオープンソースアプリ
気になるのは、オープンソースのアプリがモバイル市場でうまく売れることを期待することは可能/実現可能/合理的であるかどうかという疑問です。 ユーザーはチェックアウトバージョンを作成するのではなく、自分のアプリを使用すると思いますか。さらに重要なのは、OSSライセンスでアプリを利用できるようにした場合、どのように競合に対処できるでしょうか。 これまでのところ、私が見つけたテーマに関する唯一のリンクはhttp://blog.zachwaugh.com/post/17554643060/selling-open-source-appsですが、Mac OS Xアプリを扱っています。 私の質問は、iOS、Android、または別のOSに焦点を当てていないことに言及する必要があります。それは、モバイルアプリケーション全般に​​関するものです。 編集:私のユーザーがプログラマーであるかどうかの非常に合理的な質問が尋ねられました。 ほとんどのユーザーがリモートからプログラミングに精通しているとは思いません。

2
iOS、Android、ウェブ向けに専門的に開発-洞察
これは3つすべてを開発する方法についての質問ではなく、さまざまなクロスプラットフォームの方法などを知っています。しかし、開発者の観点から、基本的にiOS、Android、およびWebアプリの開発がどれほど難しいか知りたいですか? 私は現在、モバイル/ウェブ開発者としての最初の仕事をしています。私はすでに最初のiPhone / iPadアプリを開発しましたが、今やAndroid用のアプリを開発する必要があります。試したWebバージョンが十分に機能せず、Webデータベースがうまくいかなかったためです。しかし、私はすべてのAPIを覚えておくなどの点で3つすべてを開発するのが得意であるかどうかはわかりません。さまざまなプラットフォームでAPIを使用する方法だけでプログラミング言語に問題があるとは言えません。また、私が見る他のすべての言語は、暇なときに、自分が薄くなっていくように感じます。 一人の人がiOS、Android、Webアプリを開発することは現実的ですか?iOSとWebベースのアプリに削減することを検討すべきですか? 私はすべてを自分で開発しているので、すべてに最適な解決策は何かを議論する人が誰もいません。 そこにクロスプラットフォーム開発者はいますか?企業はプラットフォームごとに異なるチームを持っていますか? どんな洞察も、私が私の頭をまとめるのに役立ちます。うまくいけば、この質問は理にかなっています。
9 android  web  mobile  ios 

6
モバイルアプリケーション開発のためにJavaを学ぶべきですか、それともC#だけで学べますか?
.NETフレームワークを掘り下げるのを楽しみにしていますが、ほとんどのモバイルアプリケーションはJavaで開発されているようです。私はおそらくAndroidやiphone OSではなく、NokiaやMotorollaのようなより安価な電話をターゲットにするでしょう。これらのものをC#で実行できますか?
9 java  c#  mobile 

2
モバイル開発のためのRESTとRPC
多くの人が知っているように、最近のモバイル開発は急増しており、私がコーディングしているものに影響を与えていると思います。具体的には、モバイルアプリケーション向けのWebサービスの開発に興味があります。 RPCとRESTの2つのアーキテクチャが考えられます。私はRESTサービスとRPCサービスの両方を開発しましたが、RPCサービスは、特にPHPなどの言語でコーディングする方がはるかに簡単であることがわかりました。それに関する問題はスケーラビリティにあるようです-多くの手順が存在する場合、サーバー側は簡単に混乱する可能性があります。 一方、RESTははるかに構造化されているように見え、サーバー側での保守が比較的容易になりますが、データを複数のリソースに分割する可能性があり、モバイルアプリケーションには(複数の理由で)悪影響を及ぼします。 私が経験したことから、ほとんどの場合RPCは少し良いようです: クライアント側とサーバー側の両方が、使用可能な手順と実行される呼び出しの数を最小限に抑えることを懸念しています。 アーキテクチャのルールに従うことは、そうでなければ可能である最適化で対抗しません。 RESTやRPCについて誰かに説明してもらうことはあまり期待していません。Webはそれでいっぱいです。モバイルアプリの開発経験のある人に、サーバーサイドでこれら2つのアーキテクチャを使用することについての意見を表明してほしい。ヒントも歓迎します(だれがヒントを好きではないですか?)。

1
PhoneGapのいくつかの重要な概念が欠けているようです
複数のプラットフォームでアプリを開発することを計画しており、PhoneGapが最適だと思います。私はそれがすべてのプラットフォームの1つのコードベースであることを読んでいましたが、PhoneGapガイドを見ると、プラットフォームごとに個別の指示があるようです。それで、iOS、Android、BB、WP7用に開発したい場合、4つの異なるコードセットを記述する必要がありますか?私はここで基本的な何かを見逃していると確信しています。 それ以外に、人々は通常どのようにPhoneGapビルドにアプローチしますか?あなたは明らかに/おそらく完成したアプリをネイティブアプリのように見せたいと思います-PhoneGapと一緒にjQuery Mobileを使用しない方が一般的ですか? 優先IDEはありますか?ガイドでは、iOS向けにXcodeを提案しているようです。Xcodeを使用しても問題ありませんが、HTMLとCSSには少々やり過ぎです。Xcodeで開発する必要がありますか?そうでない場合はどうすればよいですか?別のIDE /テキストエディターを使用してから、ビルドとテストのためにXcodeにコピーして貼り付けますか? この質問は根本的に根本的なものですが、ガイドでは適切に扱われていないと思います。 ありがとう。

5
マイクロ最適化はモバイルデバイスで価値がありますか?
通常、マイクロ最適化は次の説明では価値がないと見なされます。プログラムを1パーセント未満高速化する可能性がありますが、その小さなブーストを気にする人はいません。 さらに、1秒間に1000回起動し、非常に高速に終了するイベントハンドラが存在する可能性があります。それがどれほど速いかは誰も気にしません-それがすでに「観察できるほど速い」ので、それを速くすることは注目に値しません。 ただし、モバイルデバイスではエネルギー消費が重要な要素です。同じイベントハンドラーを10%速く実行するように最適化すると、消費されるエネルギーが少なくなり、バッテリー寿命が長くなり、デバイスの動作時間が長くなります。 モバイルデバイスに関する後者の判断はどの程度正確ですか?それを確認または反証する実際の例はありますか?

1
電話アプリに統合された広告-バッテリーの浪費を避ける方法は?
3月に発表されたPCWorldレビューを検討してください。 広告が詰め込まれた無料のAndroidアプリは主要なバッテリー消耗 ... Microsoftと共同でパーデュー大学の研究者は、無料のスマートフォンアプリでのサードパーティの広告が、アプリのエネルギー消費の最大65〜75%を占める可能性があると主張しています... ユーザーのバッテリーを使いすぎないように、広告サポートをモバイルアプリケーションに統合するためのベストプラクティスはありますか? ... AndroidフォンでAngry Birdsを起動すると、研究者たちは、コアゲームコンポーネントがアプリの総エネルギーの約18%しか消費しないことを発見しました。調査によると、最大のバッテリー消費量は、アプリの総エネルギーの45%を占めるサードパーティの広告と分析に電力を供給するソフトウェアによるものです... レポートにあるように、「3Gテイル」から遠ざけるためのより良い方法を誰かが呼びましたか?Wi-Fi / 3G無線の継続的な使用を回避するために、数時間キャッシュされる大量の広告セットをダウンロードし、それらを使用して広告スペースに入力する方が良い/可能ですか? モバイルアプリに広告を含めるためのベストプラクティスはありますか?

5
モバイルプラットフォームでパブリックメンバー変数を使用してJavaドメインオブジェクト/データ転送オブジェクトを作成するのは慣例ですか?
最近、外部の請負業者によって開発されたモバイルアプリケーションJavaコードのコードレビューを実行しましたが、すべてのドメインオブジェクト/データ転送オブジェクトが次のスタイルで記述されていることに気付きました。 public class Category { public String name; public int id; public String description; public int parentId; } public class EmergencyContact { public long id; public RelationshipType relationshipType; public String medicalProviderType; public Contact contact; public String otherPhone; public String notes; public PersonName personName; } もちろん、これらのメンバーには、コード内のどこからでも直接アクセスできます。これについて尋ねたところ、開発者は、モバイルデバイスはリソースに制限のある環境であるため、これはモバイルプラットフォームで使用される通常のパフォーマンス強化設計パターンであると私たちに話しました。それは意味をなさないようです。パブリックゲッター/セッターを介してプライベートメンバーにアクセスすることは、多くのオーバーヘッドを追加する可能性があるようには見えません。そして、カプセル化の追加の利点は、このコーディングスタイルの利点を上回るようです。 これは一般的に本当ですか?これは、上記の理由により、モバイルプラットフォームで通常行われることですか?すべてのフィードバックを歓迎し、感謝しています-

3
あなたのアプリとあなたのウェブサイトの間のコミュニケーションの最良の方法?PHP、Webサービスなど
自分のウェブサイトと通信したいアプリケーションを作成しています。アプリは、ウェブサイトのデータベースから特定のアプリユーザーのデータを取得する必要があります。これを行うための最良の方法は不明です。 たとえば、これを行う1つの方法は、アプリにログインページを作成し、それが私のウェブサイトのlogin.phpロジックにヒットすることです。1つのコードベースを使用して、Webサイトとアプリの両方のサインインを処理できるため、これは便利です。 私が見た別のソリューションは、JSONリクエストを使用してアプリとWebサイト間の通信を処理することです。JSONオブジェクトは作成と解析が簡単なので、これは便利です。 私は基本的に、このコミュニケーションを実現するための最良の/一般的な方法、お互いを重ねることの長所と短所、および考慮すべきその他のセキュリティ問題を知りたいです。 たとえば、一方の方法をもう一方の方法で使用する場合、機密のユーザーデータを公開するリスクはありますか?もしそうなら、これをどのように防ぐことができますか?暗号化とユーザー検証は、どこでどのように機能しますか?
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.