私は、「現場」で働く特定の専門家が使用することを目的とした新しい iOS アプリの要件と仕様に取り組んでいます。これらの人々は、何週間にもわたって一日中、あらゆる種類の情報を追跡する標準化されたフォームを使用して、上司にかなりの報告の負担を負っています。従来、これらのフォームは PDF 形式で、単純に印刷してインクで記入し、同じ作業をしている数十から数百の他のユーザーと共有していました。データを入力してフォームの一部として印刷できるように、フォーム フィールドを含む PDF を使用する場合もあります。いずれにせよ、彼らのワークフロー、時間とストレスのプレッシャー、およびその他の要因を考えると、標準化されたレポート フォームを作成するのはあまり生産的な方法ではありません。
私たちが仕様としているアプリは、フィールドに入力されたデータを追跡し、データごとに論理的な方法で整理するための iOS (可能であれば Android も - ただし、現時点では 2 番目または 3 番目の要件) のユーザー インターフェイスを提供します。個々のユーザーは、ボタンを押すだけで、そのすべてのデータを取得し、標準化されたフォームを使用してその PDF ファイルを自動的に作成します。
もちろん、フォームはこの業界では厳密かつ厳格に標準化されており、形式、構造、または表現の逸脱はまったく許容できません。
そこで私は、アプリが認定機関からの元の標準化されたフォームの内部リポジトリを維持し、可能な各データ領域がフィールドとして定義されると考えて、プロジェクトに取り組みました。アプリは次のことを行います。
- 当面のタスクに必要な PDF フォームを開きます。
- 辞書を解析して特定のデータ フィールドを識別します。
- 単一のフィールドごとに、iOS アプリの独自のユーザー インターフェイスとデータ テーブルから関連データを識別し、そのデータを PDF/辞書の対応するフィールドに割り当てます。
- PDF を新しいPDF ファイルにエクスポートします。このファイルは、アプリが電子メールで送信するか、iCloud、Dropbox、またはその他の形式のファイル共有を介して保存します。
#4 の問題点は、その PDF ファイルは Windows および Mac の標準 PDF アプリケーション (Acrobat、Preview など) で編集可能なままにしておく必要があるため、すべてのフィールドを残す必要があることです。また、PDF は Windows でも Mac でも同じように表示できるはずです。
現在、PDF (元のドキュメントでもエクスポートされた最終ドキュメントでも) を iOS アプリ内に表示する必要はありません。
これが可能かどうかはわかりません。これは私たちの最初の iOS プロジェクトであり、開発時間を節約し、プラットフォーム間での移植を容易にするために、Moai や Corona などのフレームワークを使用してアプリを構築することに傾倒してきました。とはいえ、Lua とこれらのフレームワークの 1 つを使用してそれができない場合 (私は懐疑的です...彼らはゲームに非常に向いているようです)、Objective C で直接それを行い、しばらくしてから Android バージョンをビルドすることに反対しません。道路。
しかし、いずれにせよ、これが実際的な事業であるかどうかを評価するのに途方に暮れています。私たちの要件は明確であり、率直に言って、これができない場合、プロジェクトはそれ以上追求されません. しかし、私のオプションが何であるか、Lua でそれを実行できるかどうか、およびこれを達成するのに最も役立つ SDK を特定するために、皆さんの助けを借りることは間違いありません。