- バックアップ一覧
- ソース を表示
- OpenChangiExecEngineの開発で検討したこと。 は削除されています。
.NET 開発基盤部会 Wiki
目次 †
概要 †
OpenChangiExecEngineの開発で検討したこと。
Tablet系 †
専用端末化 †
- Android/iOS両方で実現可能。
- ただし,OSバージョン縛りがあるので(特にAndroidは)要注意。
Android †
Android 5.0から追加された「画面の固定」機能を使えばアクティブなアプリを限定できる。
iOS †
iOS6から追加された「Single App Mode」が使える。
HTML系 †
Web関係はMozillaが一番まとまっている気がする。
オフライン †
- オンライン環境でない場合に、オフラインで動作する方法を検討する。
- 実装はHTML(HTML5)のWeb技術を使用する(スマホ・ネイティブ解らんので)。
- オフライン時にlocal-Storageに溜め込んでバッチ送信みたいなことを考えている。
- 色々考え、処理系を切り替える必要があるので結構難しそうだと感じた。
- 切り替えが面倒なので、一律、
- ローカルストレージに蓄積
- 定期的な情報送信を行う。
という方式が良いと考えた。
チェック †
window.navigator.onLineでチェック可能。
ストレージ †
HTML5のストレージ機能には以下のものがある模様。
- WebStorage?(キーバリュー型のストレージ)
- 最もポピュラー
- 永久に保存される LocalStorage?
- セッション中のみ保存される SessionStorage?
- WebSQL Database
- RDB(SQLite依存)のため、標準化が停止されている。
- しかし、スマホ用ブラウザで唯一のため、未だに利用されている。
- Indexed Database
- オブジェクト型ストレージ(NoSQL)
- WebSQL DatabaseからIndexed Databaseへの移行が推奨されている
- File API(FileSystem? APIの代替)
定期的な情報送信 †
バック・グラウンド処理 †
setTimeoutやsetIntervalなどを用いることで実現できる。
最新の「Web Workers」については、別に使用しなくていもイイかな。という感想。
JSON処理 †
成功と失敗 †
- WebAPIの戻り値での判断は少々危険だと考える。
- トランザクションが成功した後にHTTPでエラーになると二重送信になる。
- HTTPで成功した後に、local-Storageのクリアに失敗した場合も、二重送信になる。
- 上記の二重送信の問題を解決するために、レコードにIDを付与する。
- 店舗ID+時間(yyyy/MM/dd HH:mm:ss SSS)
- 店舗ID:ユーザアカウントから取得可能。
- 時間:dateformat.jsを使用して取得可能。
エフェクト †
効果音 †
HTML5 Audio オブジェクトを JavaScript で制御する。
<script>
var audio = document.getElementById("audio"); // audioの取得
audio.play(); // mp3の再生
</script>
<body>
<audio id="audio">
<source src="xxxxx.mp3" preload="auto">
</audio>
</body>
アニメーション †
jQuery - Effects の .animate() のチェーンで実装可能。
以下は、ボタン押下時のアニメーション+効果音。
$(function() {
var audio = document.getElementById("audio"); // audioの取得
$('.imgbutton').on('click', function() {
audio.play(); // mp3の再生
$(this).animate(
{
width: '100px', // 小さくしたときのサイズ(幅)
height: '110px' // 小さくしたときのサイズ(高さ)
},
{
duration: 50, // 小さくするときにかかる時間(ms)
complete: function() {
$(this).animate(
{
width: '175px', // 大きくしたときのサイズ(幅)
height: '220px' // 大きくしたときのサイズ(高さ)
},
{
duration: 100, // 大きくしたときかかる時間(ms)
complete: function() {
$(this).animate(
{
width: '150px', // 元のサイズ(幅)
height: '165px' // 元のサイズ(高さ)
},
{
duration: 100 // 元のサイズに戻るときにかかる時間(ms)
});
}
});
}
});
});
});
スキーマ †
マルチテナントを考慮したスキーマ設計
マスタ・データ †
ユーザ情報 †
画面項目 †
画面によってスキーマが異なるので非構造化データに格納する。
- 非構造化データ(JSON)
- タイトル
- キャプション
- メッセージ
- 画像
- ボタンID
(有効期限の日付要る?)
トランザクション・データ †
アンケート結果 †
- 画面ID(GUID)
- 分割キー
- 端末ID
- ボタンID
- 日付
#DBMSスキーマ上にあれば、SQLの集計関数で集計可能。
画面 †
コンテンツ画面 †
HTML/CSS/JavaScript技術を中心に使用して開発する。
カスタマイズ画面 †
- エンプラ寄りのWeb Forms技術を中心に使用して開発する。
- 非構造化データ(JSONデータ)の編集処理の簡略化がキーポイント
- 画面の自動生成も面倒なので、
- JSONの生データを編集する方式にする。
条件検索画面 †
エンプラ寄りのWeb Forms技術を中心に使用して開発する。
条件検索と集計・グラフ表示機能 †
- 通常の条件検索と集計・グラフ表示機能を実装する。
- グラフ表示は、ChartControl?を使用する。
非構造化データの集計処理 †
非構造化データ(JSONデータ)の集計処理の簡略化がキーポイント
- CSVエクスポートを行い、エクセルで集計できるようにする。
- JSONデータをフラットな二次元表に展開する。
上記を踏まえた技術選定 †
Open棟梁はコミュニティ連携のため前提で(笑)。
OS †
Windows †
DBMS †
PostgreSQL †
- スタートアップで人気。
- MosPで運用実績がある。
WAS †
IIS+ASP.NET †
.NET開発基盤部会だけに。
フレームワーク †
ASP.NET Web Forms †
ASP.NET Web Formsを選択した。
- ASP.NET MVCであっても・なくても良かった。
- 赤波線の件と、
- コントロールのキャプション置換がWeb Formsの方が楽だと思ったから。
- グラフ表示画面もあるので、ChartControl?を使いたいと思ったから。
- B・D層を別DLL化して、必要ならUIサブシステムだけMVCに切替えるのはアリだと思う。
- その他
- HTMLに準拠した実装がし易いように、HTML Server Controlを使用する。
- Web Formsだけどオフライン実装を考慮しPostBack?無しのWebAPI(WCF-REST-JSON)で実装。
ADO.NET †
ADO.NETでイイと考えた。
,etc. †