Androidモバイル開発のDelphiユーザー

Valentinaさん、 Delphi for Androidで最初のアプリケーションを紹介しました 。 特定の問題を解決するのか、それとも先を見越した開発、「ペンテスト」だけなのか？ この背景には実際のビジネスニーズがありますか？



私にとって、Delphi for Androidで書かれた最初のモバイルアプリケーションは、モバイルプラットフォーム上で企業の情報構造の特定の部分を開発する能力を目指した一種の試練です。



多くの企業（当社のお客様）では、モバイルプラットフォームで実行できるタスクをすぐに見つけることができます。 これは何よりもまず、従来のコンピューターまたはラップトップから情報システム情報にアクセスする能力を持たない人員に関連するタスクであり、ローカルエリアネットワークとWiFiはなく、モバイルネットワークのみです。 これらは、特定の性質のために静止した職場を編成することができないリモートサイトの従業員です。たとえば、出張中の宅配業者や管理者などです。

このようなタスクには、3Gモジュールを搭載したAndroidタブレットが適切なソリューションです。 データベースとの通信、便利なインターフェイス、コンパクトなデータ交換トラフィックを提供する必要があります。



解決中のタスクについて-Android向けのモバイル開発を使用して、具体的には特定せずに（お客様の利益を観察して）、現在解決中のタスクについて説明します。



タスクの1つ：リモートサイトにあるスペシャリストが、注文に関する少量の運用情報（彼が解決した問題の現在の状態、および出力）を送信する必要があります。 チェーン内の注文のさらなる通過はこれに依存するため、データは情報システムに迅速に転送する必要があります。 さらに、彼の問題を解決するために、彼は他の専門家によって、おそらくモバイルデバイスからもシステムに入力された追加の関連情報を受信する必要があります。 Windows PCではなくモバイルデバイスの使用は、主にタブレットの重量特性によって決まります。 「7インチ」は大きなポケットや小さなハンドバッグに簡単に収まり、余分な重さとしては感じられないため、いつでもどこでもこれらのデバイスを着用できます。 はい、彼らは6時間以上働くことができます。



この問題の以前の解決方法：専門家は、3Gネットワ​​ークに接続する機能を備えたラップトップを持ち歩くか、SMSを呼び出したり、ディスパッチャに送信したりしました。 ラップトップで作業することは常に可能とは限らず、ディスパッチャを介して作業することは、データの効率性と関連性、そして当然のことながら人的要因の損失です。







オプションでのモバイルプラットフォームへのそのようなタスクの削除-MS SQL Serverデータベース（タスクのみ）-Data Snap-Androidアプリケーションには上記の欠点がありません。



非常に需要のあるもう1つの典型的なタスクは、リモートサイトからの運用データの収集であり、一部の機能により、固定された職場の展開の可能性はありません。たとえば、電気のない無防備の暖房のない部屋です（時々起こります）。



そのようなタスクには、安価なAndroidタブレットが非常に適したソリューションです。データベースへのセッション接続のみが必要なため、操作時間はそれほど重要ではありません。



Appleのアプリケーションアップデートに関するポリシーにより、制作タスクではiOS向けのソリューションが副業のままであり、デバイスのコストについては話していません。近い将来、良い方向への変更はありません。 たとえば、実稼働環境での大量使用では、100台以上のモバイルワークステーションを展開する場合など、所有コストと専用ソフトウェアの更新速度が不可欠です。



また、従業員がネットワークに接続された固定コンピューターを備えた職場を持つ企業全体に分散したポイントからデータを迅速に入力するタスクもありますが、仕事の詳細のため、彼は職場から離れた場所にあるデータを入力する必要があります。 注文コレクターは注文アイテムを確認し、「OK」または「問題」のみを入力します。 このようなタスクでは、Wi-FiネットワークとWi-Fiモジュールを備えたAndroidタブレットを使用すると、ソリューションのコストがさらに低くなります。



モバイルアプリケーションの設計は、通常「ユースケース」に基づいています。 共有できますか？



モバイルアプリケーションのインターフェイスとイデオロギーを開発する場合、モバイルデバイス自体の機能（タッチ入力、推定画面解像度、ユーザーの「機能」）の両方が考慮されます。 言い換えると、オンサイトマネージャーとリモートサイトのオペレーターに実装されている同じ機能は、モバイルデバイスユーザーの「知覚機能」によって異なる場合があります。



まず第一に、それはアプリケーションの機能を損なうことなく作業を快適にすることです。 クライアントサーバーアプリケーションのユーザーは、機能豊富な画面、実際にはすべての必要な情報が常に手元にあるか、視野にあるか、ワンクリックで利用できるか、ポップアップ通知によって配信されるリモートコントロールで作業することに慣れています。 したがって、モバイルアプリケーションのインターフェイスでは、作業中にユーザーが自分の行動や必要な情報へのアクセスに制約を感じないことが非常に重要です。



ユーザーの不快感の神格化は「マウスを動かすように強制する！」というフレーズで非常によく表現されます。したがって、モバイルアプリケーションのユーザーがゲームのようにそれを知覚することを理想的に望んでいます。



そして突然、開発中に、モバイルデバイスに情報を表示するための「グリッド」の使用が必ずしも正当化されないことがわかりました。スクロールするのは不便であり、ほとんどの場合、ListBoxとListViewを使用すると、モバイルデバイスユーザーにより多くの直感的な機能が提供されます。



最も不愉快なのは、モバイル版のアプリケーションでは、ユーザーがデスクトップの「マルチウィンドウ」を失うことです。ここでは、ソリューションを「動員」するために犠牲にしなければならない情報と、ブックマークの下に隠すか、別のフォームやポップアップメニューを配置するかを決定する必要があります。 したがって、タスク「デスクトップ」と同様の機能を持つ「モバイルブラザー」のインターフェイスは完全に異なります。



モバイルアプリケーションは特定の顧客とタスク向けに開発されているため、顧客が使用するデバイスと特性を正確に把握しているため、デバイスとの互換性の問題はありません。



できればスクリプトの開発中に、いくつかのスクリーンショットを要求できますか？



技術的な問題はありませんが、他の考慮事項があります。 私たちの顧客は、資産内のモバイルソリューションの存在を追加の競争上の優位性と見なしているため、写真のアップロードを拒否することにしました。 ところで、これはモバイルアプリケーションだけでなく、クライアントサーバーシステムにとっても大きな問題です。 私は最も多くのパイロットプロジェクトのみを表示することができます。それでも、「グロスオーバー」する必要がありました。 本格的な現在のプロジェクトのインターフェースは、「耳の上」でつまらなくてはなりません。「充電付きのストリップ」しか残っていません。 私は、顧客を害することなく、最初のプロトタイプだけを見せることができます。それは、ぼやけたデータでも可能です。 IDEには、シンモバイルクライアントとDataSnapサーバー用の別の種類のプロジェクトがあります。







アプリケーションインターフェイスの開発は、人間工学的にはかなり時間のかかる作業であることがわかりましたが、アプリケーションの実際の機能は問題を引き起こしませんでしたが、通常のプログラミング環境であるDelphi XE5で作業しています。



ところで、ほとんどの開発者と同様に、私は自分で何かを「彫刻」します。 私はそれを見せることができます：







アプリケーションのコンポーネントの基礎は何ですか？ どのように使用されますか？



アプリケーションの開発では、特にサードパーティコンポーネントのセットを可能な限り最小化して、プロジェクトを新しいバージョンのEmbarcadero製品に転送するときに他の開発者に依存しないようにします。



モバイルアプリケーション、Data Snap、FireDACの可能性があるため、モバイルアプリケーションを開発する場合、Delphi XE5 Enterpriseバージョンに含まれるコンポーネントの標準セットでも十分です。



さらに、Androidの「スタイル」を使用すると、アプリケーションインターフェースを「アニメーション化」できます。



外見的にも機能的にも魅力的なTMSが提供するソリューションはそのように見えますが、これまでのところ、これらのコンポーネントはMac OS用のアプリケーションの開発にのみ使用していました。 Embarcaderoが、少なくともエンタープライズバージョンから標準パッケージにそれらを含めれば、素晴らしいでしょう。 結局、Fast ReportとFire DACでも同じことが起こりました。



データはどのように、どこから来たのですか？



データの操作は次のように編成されています-データベースサーバー（MS SQL Server）、データスナップサーバーがあり、それを介してAndroid上のクライアントがデータを処理します。



「データベース」にユーザーアクションはどのように記録されますか（データベースとの接続がある場合）。



当然、データベースとの接続があり、ユーザーが行ったすべてがすぐにデータベースに反映されます。



このアプリケーションなしでマネージャはどのように管理しましたか？



当然のことながら、リモートサイトの管理者と従業員の両方は、モバイルアプリケーションを使用せずに実行していました。 以前は、普通の人は携帯メールと電話なしでやっていました。 彼らはラップトップを使用し、電話をかけ、手紙を書き、宅配便をパッケージで送り、データがもはや関係ないほど遅れてレポートを作成しました。



ビジネスプロセスはどの程度加速していると思いますか？



一般的に、生産の自動化では、モバイルソリューション（ここではモバイルアプリケーションだけでなくWebソリューションも意味します）を使用すると生産効率が大幅に向上するため、かなり堅実な結果になります。 非モバイルバージョンでは、技術的にまったく実装されていないプロセス、または非常にコストの高いプロセスが存在するためです。



モバイルソリューションが提供する主な利点は、フィードバックとの運用上の相互作用です。これがまさにクライアントサーバーソリューションの基礎です。すべてのプロセスはリアルタイムで発生します。



アプリケーション機能のさらなる開発が見られますか？



はい、少なくともモバイルマネージャーにとっては、既に開発のアイデアがあります。これらのアイデアは、私たちだけでなく、ユーザー自身からも生まれています。 時間と資金があれば、デスクトップシステムに機能を持ち込むことができ、特別な技術的な問題はありません-これによりEmbarcadero Delphi XE5 Enterpriseが可能になります。 システムが元々3リンクとして設計されていた場合、変換速度はコードを記述する技術的な速度によって決まります。 主なことは、段階的に問題を急いで解決しないことです。

主な問題は、モバイルデバイスの画面サイズと人間工学です（コントロール要素のサイズは、マウスよりも指の方が大幅に大きくなければなりません）。



このソリューションは、「企業モビリティ」のフレームワーク内でどのように典型的だと思いますか？



私たちのモバイルソリューションは、同じ業界のさまざまな顧客の主要なビジネスプロセスは、マネージャーの好みと歴史的なルール（地理的な場所を考慮に入れても）だけが異なることが多いため、当社が開発した業界に典型的であると考えています。



たとえば、当社のモバイルソリューションのユーザーは、セールスマネージャー、倉庫作業員、フォワーディングドライバー、注文ピッカー、リモートサイトのロジスティクス担当者、調達/セールスマネージャー、原材料/生産マスター、ドキュメント承認者、機器修理工（はい、当社のシステムモニターです）機器）、生産技術者。 つまり、典型的な生産上の問題が解決されます。



この機会に、Embarcaderoの無糖の願いをお伝えください。



私はこの問題について独創的ではないと思いますが、他の「投石機」とは異なり、開発ツールの製品によって解決される複雑で新しいタスクを理解し、それらを投げないようにします。 ところで、他の（何も言及しません）開発ツールでモバイルアプリケーションを開発することを検討しているので、2つの世界（2つのシステム）を比較して、いくつかの提案をすることができます

• 特に、ユーザーがタブレットに新しいバージョンをインストールするのは難しくないため、企業のモバイルアプリケーションのサイズは重要ではありません。 ただし、アプリケーションの数を減らしたいと思っています。
• 私はこれがアプリケーションの通常の欲求であることを理解しています-仕事ですべてのRAMを占有します。 Live Bindingの欲求は特に良いです-ここでも少し進歩してほしいです。
• 不正なチャネルを介してターミナルサーバーを操作する場合など、ライブバインドを使用する場合、インターフェイスの "スローダウン"の不快な機能に気付きました。 加速したいです。
• アプリケーションが起動したら...私はコーヒーを飲む時間がありませんが、時間を作ることができます））5-7秒が最小です。

上記のすべてが開発プロセスに大きく干渉するわけではありませんが、これらの問題を解決することは、企業部門だけでなく競争力のあるモバイルアプリケーションを開発する手段としてのEmbarcaderoの魅力を大幅に高めます。



バレンタインありがとうございます！