Microsoft Azure サービスを使って、いろいろWEBアプリを作っているのですが、AZURE WEBアプリが他のサービスなどに接続する際の認証を、システム設定で許可してしまう方法があります。この日本語の言い回しが正しいか怪しいですが、要するにパスワードやシークレットキーなどが無しで認証する方法です。あくまで、Azure Appが、同じAzureサービスの中での認証です。「Managed ID」と呼ばれています。(特別なプリンシパル名？証明書？)

「マネージド ID」で探さないと、何故か日本語のAzureサービスのサイトでは、検索できない？みたいです。

そもそも、このAzure サービス全体的に、日本語訳が怪しい部分が多いです。機械翻訳なのでしょうか？それで、余計に混乱します。

何度やっても、今一、なんとなく・・・といった気持になるのですが、大体のポイントを残しておこうと思います。いろいろなやり方があるようで、アプリの構成によってベストプラクティスは、別々にあると思います。管理者が何度も変わるような職場でしたら、難しい方法は避けた方が、良いと思います。

今回は、Azure SQLサーバーにAzure Appから繋ぐのに、Managed IDを経由しました。(全部は説明できないので要点のみ)

①まずは、「マネージド ID」を作る。

②できているか、確認。

「マネージド ID」を作成すると、自動的に「エンタープライズアプリケーション」（サービス プリンシパル）が同じ名前で作成される。これは、「アプリの登録」を作成した場合と同じ動作。

リストにデフォルトでフィルターが掛かっていると、一覧に表示されないので、フィルターを削除しないと探せません。

③Azure Appで、「ID」をオンにして、「ユーザー割り当て済み」に追加。なんで「マネージド ID」と表示されていないのか？と疑問に思いますが・・・。

④Azure SQL Database側でも、ユーザーの追加と、権限を追加。

Azure SQLにユーザー登録する際、外部ユーザーを登録できる権限がないといけません。

何故、Managed IDでやりたかったというと、プログラムのソースコードに、認証で使うシークレットを書きたくなかったからです。その分、設定はいろいろと複雑です・・・・。

2025年12月18日施行　

なのですが、結局、GoogleもAppleも外部アプリストアから、手数料を取るそうです。でも責任は取らないみたいです。🤨

WEBアプリなら、サブスクで、収益化できると思いますが、WEBブラウザーでできることは、セキュリティ上、限られているので難しいのでしょうね。
アプリストアから購入するアプリとは、やはりゲームが主なのでしょうか？
インストールしなくても、WEBブラウザーで動かせる仕組みを作るしかないですね。

そもそも、Ａｎｄｒｏｉｄ　ＯＳは、ＷＥＢで完結させる思想だったのですが・・・。
　思想が変わってしまったのですね。

 

以前から、非常に気になっていた、AndroidのLINE使用時のGPSの位置取得間隔が長すぎる問題について。

原因は、Andoridの省電力機能。プライバシーの点からも、GPS常時ONを許可しない設計。この点について、iPhoneは、OS自体がGPSを管理しており、常時オンでも省電力設計になっている。

AndroidのLINEは、GPSをリアルタイムに取得せず、簡易モードでの取得になっているため、OSから「直近の測位結果」を取得する動きになっているらしい。

その為、AndroidのLINEでGPSを常時ONにする為には、GPSを常時ONにするアプリを同時に立ち上げる事で、この問題は解消する。が、消費電力は多くなる。(このアプリのバッテリ管理を制限なしにする必要あり)

地図系のアプリで位置情報をトラッキングするアプリであれば可能。起動と同時に(記録開始しなくても)GPS常時ONにできるアプリはいろいろありますが、例えば「OwnTracks」というものがあります。

この辺は、Android OSとiOSの基本的な設計の違いが原因ですね。多くの部分をメーカーに任せるAndroidと、OSから端末までを一元に開発しているiOSとでは、このような差が生まれるのですね。

Pixelは、将来的にこのようなiPhoneとの差を縮めれるのでしょうか？

 

先日、「QRコード読取→URL開く」を作ったのですが、カメラの取り扱いが面倒です。

最近のスマホは、カメラが複数搭載されています。なので、どのカメラで読み取るのか？という選択をしなければいけません。

基本的に、デフォルトは背面になると思うのですが、そうはならない機種もあります。結局、”back”という文字が含まれるかどうかで判断するようにしたのですが、背面カメラも複数あります・・・・。😔

https://mblsta001.azurewebsites.net/cameradevs

他にも、解像度の違いも機種によってばらばらですし・・・・。

国内では現在、iPhone 50%、Android50%くらいのシェアでしょうか。Androidの場合、少し前のミドルクラスの機種に合わせるのが妥当かと考えています。🤔

スマートフォンで、QRコードを読み込んで、別の案内サイトを開くことがよくあるので、WEBアプリで作成しました。

以前作成したバーコードテストをそのまま流用しました。これなら、スマホにアプリを入れる必要がありません。こういうスマホアプリは、宣伝だらけですからね。

QR to URL

スマートフォンのWEBブラウザで、ショートカットを作成しておけば、いつでも使用できます。

動作確認デバイス:

KYOCERA TORQUE G04 : Android OS 10

Xperia XZ2 Compact : Android OS 10

Blackview BV 9300 Pro: Android OS 13

iPhone SE2 : iOS 18.0.1

先日作り始めたWEBアプリですが、バーコードの読み取りをテストしてみました。以前、Blazor WebAssemblyでバーコードの読み取りアプリを作成したのですが、今回は、Blazor Serverアプリで新たに作り直しました。

試すには、下記URLよりログインして最初の画面の「JAN,QR読取ﾃｽﾄ」をクリックしてください。

JAN13,JAN8とQRコードのみ読み取るように設定してあります。「SCAN」ボタンをクリックすると読み取りを開始。「STOP」ボタンをクリックすると、終了します。

動作確認は、iPhone SE2(iOS18) , Kyocera TORQUE G04(OS10)です。PCではスマホと違って背面カメラというものが無い為、現状、対応しておりません。(・・・時間があったら対応予定・・・)

スマホのカメラでいろいろバーコードを読み取ってみましたが、比較的QRコードは読み取りがいいです。まあ、当然と言えば当然ですよね。JANコードは、白黒は読めますが、それ以外は読み取りがよくないですね。また、白枠の余白が小さいとダメです。そこはレーザー式と比較できないので仕方ないですが・・・。

ただ、カメラ性能も上がってきており、オートフォーカスも良く働くので、最近のスマホは、100%ではないにしろ、商品の90%は読めるのではないでしょうか。

スマホで、バーコードシステムを作るならやはり、QRコード一択ですね！

「Google Play」にアプリを投稿していましたが、古い端末向けのアプリは排除されてゆく運命にあります。それでたどり着いたのが、WEBアプリでモバイル端末向けのアプリを開発するという方法です。業務用に実際に開発はしていますが、WEBアプリの場合、iPadくらいの画面サイズなら実用的かと思います。スマホだと画面も狭いですし、スペックの低い機種では、バーコード読取時のカメラ性能が不十分だったり、文字入力がやりにくかったり、問題が多いです。Panasonic製のToughPadのような業務用スマホを使う手はありますが、お値段が・・・。😔

今後はモバイル端末でもPCでも使用でき、長く使えるアプリをめざして、Webアプリ開発も進めて行こうと考えています。特定のユーザー向けには開発していますが、一般向けとなると、シンプルさと汎用性を考えないといけないです。また、アプリ開発以前に、ユーザー認証の問題があります。🤔

とりあえず、一歩踏み出そうと、ユーザー登録＆認証画面を作ってみることにしました。

https://mblsta001.azurewebsites.net

①ログインページ

②新規ユーザー登録ページ

社内システムだと、会社のサーバーからAD認証などを使用できるので、Blazorプロジェクトのサンプル通りコーディングするだけでOKです。また、ユーザー管理はサーバーの管理画面でやっているので、社内システムでは、作る必要もありません。なので、その代わりの物を自作しなければなりません。

今回作成した仕組みは、クラウドのデータベース(Azure SQLServer)に、ユーザー情報を持たせる仕組みです。一つのシステム内でも、ユーザーIDでデータを切り分けることで、同時に複数のユーザー運用が可能になります。どのSNS(FacebookやLINEとか)も同じ仕組みだと思いますが・・・。

③正常に認証されるとこの画面になる。

予算の関係で、Freeプランの為、1回目でSQL Serverに接続できない(sleep状態)場合がありますが、少し待って再度「ログイン」するとSQLサーバーのユーザー情報と照合して、この画面になります。

 

ご興味がありましたら、適当に登録して頂いて構いません。また、入力された情報を他社や他のサービスに使用することは決してありません。

 

プライバシーポリシー (mobile-sta.com)

短期間で社内システムを開発するには、

①クラウドサービスに合わせて、社内の業務を変える。顧客に渡す帳票類などは、別途開発。

②クラウドサービスと連携して、アジャイル開発。ランニングコストが許す限り、クラウドサービスを有効活用。

何度も会議を重ねて、詳細な仕様書を作成している間に、環境はどんどん変化して行ってしまいます。現場の要望は、毎週のように、常にレベルアップしてゆきます。同じやり方で、1年以上やっているような時代ではありません。

昔のシステム切り替えは、10年くらいだった気がしますが、現在では５年でも長すぎると思います。扱うデータ量が桁違いに増えているので、スマホでも同じですが、5年前のシステムは、だんだんと力不足になってゆきます。(インフラも含めて全体的に)

従来型(ウォーターフォール型開発)の「要求定義」～「概要設計」～「外部設計」～「内部設計」～「プログラミング」～「単体テスト」～「デバッグ」～「結合テスト」～「システムテスト」～「受け入れテスト」をやっていたら、一体、何年かかるかわかりません。まして、うまくゆくかもわからないのに・・・。

古いシステムのリプレイスを何度もやったことがありますが、はっきり言って、仕様書は無いよりましなくらいです。とにかくソースを見て、実際にどうなっているのか、動かしてみて、想定通りなのかを確認しないとダメです。自分でソースを解析しないとダメです。人が書いたものですから、想定外の未知のバグが出てきます。要するに、他人が書いたものをそのまま信じてはダメです。

また、仕様書より、現場の担当者に聞いた方が正解です。当初と運用も変わってたりしますから。これを言うと、理屈では仕様書が正解というのが正しいのかもしれませんが、仕様書が間違っている場合もあるのです。

制御系の設計の場合は、確かに「ウォーターフォール型」でないとまずいです。(若い頃に、電気制御システム設計をやっていたので)　なので、あくまで、ソフトウェアだけのシステムの場合、アジャイル開発が今の時代には向いていると思います。

 

表題の件、業務アプリ開発専門＆Microsoft信者の視点でお話しします。

①使う側の視点での違い。
🖥 DESKTOPアプリ: 
・.Net Runtimeをインストールすれば、Windows,Linux,iOSで動きます。
・プログラムは、ローカルPCで実行されます。
・プログラムをインストールする必要がある。

🌐 WEBアプリ：
・EdgeやChrome、SafariのWEBブラウザー上で動きます。
・プログラムは、WEBサーバー上で実行されます。(WEBブラウザー内で実行する部分もあり)
・プログラムをインストールする必要は無い。

②開発側の視点での違い。
🖥 DESKTOPアプリ:
・DESKTOPアプリ開発者が開発。
・小規模システム向け。
・DBへの接続の認証などは必須。
・テスト環境は構築しやすい。
・プログラムソース全体の量は、WEBアプリより少なくなる。
・ユーザーの要望は殆ど実現可能。 😀

🌐 WEBアプリ：
・WEBアプリ開発者が開発。(フロントエンド開発者、バックエンド開発者で別々が基本？)
・大規模システム向け。
・WEB上にデータが流れるので、ログイン時やデータ接続時の認証は必須。 (AzureのようなWEBサービスを使用するのが必須。)
・テスト環境の構築には、若干手間が必要。
・プログラムソース全体の量は、DESKTOPアプリより多くなる。バックエンドとフロントエンドの別々の開発が必要な為。
 1)バックエンド:サーバー内で動く部分。
2)フロントエンド:WEBブラウザー内で動く部分。
 ↑WEBアプリの構造上、ここは変わらないと思います。
・WEBブラウザーの制限上、できないことが多々ある。 😢

・DeskTopアプリ: ローカルPCで実行するプログラムのみ。

・WEBアプリ: サーバー側とローカル側の2つのプログラム。
★この違いはその後の保守の容易さにも影響してきます。

■社内向け業務アプリ開発 >「①デスクトップアプリ」 or 「②WEBアプリ」どっちがいい？ 🤔

表題の通り、社内向け業務アプリ開発で、そもそも「 🖥 デスクトップ/ 🌐 WEB」で悩むところだと思います。
私の個人的な認識は以下の通りです。
(ちなみに私は業務アプリ開発専門&Microsoft信者ですので。 😊 )

①🖥デスクトップアプリ: 
<メリット>
・アプリの柔軟性が絶大。ローカル環境での他のシステムとの接続が自由。
・動作が軽い。(ローカルPCで動く為)
・画面の設計が自由。操作性がよく直感的に使える。

<デメリット>
・新規・更新の配布の際、自動的にダウンロードするメニューなどを用意する必要あり。
※共有フォルダーなどから、随時ダウンロード。
・社外の人にプログラムを共有するのに、手間が掛かる。
※SharePointなどで、共有etc。

②🌐WEBアプリ:
<メリット>
・Azure Webアプリのように、WEB上に公開できるので、配布が楽。
・不特定多数のユーザーの使用に向いている。
・プログラムの入れ替えが楽。(ただし入れ替え時、一時的にサービスが使えない)

<デメリット>
・WEBなので、セキュリティ対策が必要。(IP制限、AzureAD認証など)
・起動時の認証と、ページ読み込みで、時間が掛かる。
・WEBアプリなので、WEBシステム上の制約が多い。
 ※他のシステムとの連携がやり難い。
・WEBサーバーのスペックがそれなりに必要で、ランニングコスト大。

★社内のユーザーに、同じプログラムを、「①デスクトップ版」と「②WEB版」の両方を作って、どちらが使いやすいか聞いてみました。

私も当然予想はしていましたが、①デスクトップ版の方でした。

試したプログラムは、照会系でデザイン的には全く同じものでした。
(なので、私のWEBのデザインが悪かったというのは無しです。 😓 )

特定の業務向けのアプリの場合は、WEBよりデスクトップアプリの方が向いているようです。 😊
※ちなみに、iPadでやる時は、Webアプリ(Blazor)で開発しています。

#社内システム開発 #VisualStudio