MOTO+4 Applocations のブログ

MACは操作は人間工学に反しています。日本にあってません。もともとMACは急がすゆったり使う人用なのかもしれません。 日本社会では仕事用はWindowsなので、MACから切替えると業務支障をきたします。取引先がMACの場合も把握しておく必要がありそうです。その覚え書きです。随時更新中

Windowの巡回めくりができない。

「ALT +ESC」に相当するものがない。Windowの切り替えランチャーみたいなものがありますが、選びたいんじゃなくて、とにかく考えずにめくってマウスを使わず次に操作するWindowに移りたいんです。いちいちクリックしてたら操作時間と考える時間を余計に消費します。

「1」だけキーが幅が倍であやまって押しやすい

他PCでは「ESC」の位置なので習慣的に押しやすい、いろんなとこに予期せず「1」が入ってしまいますい、後で取り除かないといけません。「1」を沢山押すような社会的業務的要件は思いつきません。ブランクキーにでもしとけばいいのに… 邪魔すぎです。

CAPSが左下隅にあり、ダイレクトにおせるので予期せずCAPS ONになりやすい

キーボードに手を置くと、左下隅は小指の付け根あたりが当たりやすいです。他PCだと「Ctrl」なので単体で押す分には害はないです。しかし、MACはCAPS単体で CAPS ONになります。他PCでは、Shiftと同時に押さないと CAPS ON になりません。CAPS無効にはできるのですが、ディスクトップ機でApple純正無線キーボードを使った場合は効きません。「大文字小文字違いがそんなに重要?」と思われるかもしれませんが、Vi 使いにとっては非常に重要です。大文字小文字でコマンドが違うんです。意図せすCAPS ONになると、書いていたコードがぐちゃぐちゃになってしまいます。

漢字変換がバカすぎる

いうまでもありません。古いMAC OSでは、Google日本語変換が使えていましたが、最新MAC OSではインストールしてもGoogleに切替えできなくなりました。

本来したい操作の邪魔になる「ソフトウェア芸」

役にたたない「かっこいいでしょ」といわんばかりのアクション(「ソフトウェア芸」と呼びます)が、意図せず発動するとびっくりしますし本来したい操作の邪魔です。例えば、背景をクリックするとWindowが四方に散らばります。Windowが沢山のときディスクトップ上の何かが見たいとき一理ありるようにおもえますが、見たいWindowあるので強引です。Window移動のためタイトルバーをクリックして上にちょいスライドさせると縮小モードになりますが、何の意味もありません。

MAPがGoole MAPとちがう

世界標準はGoole MAPでしょう。目標物などがMACのMAPは少ないようです。MACユーザがら送られていたMAPをみて、待ち合わせ場所に行こうとすると間違えてしまいました。周囲のコンビニが、Goole MAPでは2つ、MACでは1つでした。MACユーザがら送られていたMAPは信用せず、番地を聞いてGoole MAPで特定しておく必要があります。

MAC同士でリモートディスクトップはない

リモートワークで欠かせないWIndowsのリモートディスクトップ。MACでも画面共有はありますが、画面だけなので、キーボート操作が変わってしまいます。特に日本語切替がリモート側でなく、ホスト側のみになってしまいます。

なんとなくキーボードの応答が遅い

MACからWindows PCに戻るととても作業がはかどります。キーボートの応答性がわるいんですかね。

改行がCR+LFでない

MACは、FreeBSDがベースだとか。CRオンリーのようです。基本UNIXマシンなんですね。昔HPや日立UNIXマシンもそうでした。MACユーザとtxtファイル交換時は要注意です。

ログインしなとshutdownできない

MACがサーバ機になることはないでしょうから、ログインなしでshutdownさせてもいいんいでは? いちいち面倒すぎる。

タブキーによるフォーカス遷移ができない部分がある

「ALT+ESC」の件も含めて、マウスがないと何んも出来ない。MAC-miniをWindows Xamarinからbuildエンジンとして使うだけのとき、マウス繋いでないのでいちいちマウス接続を要してしまう。

Swift-UIでは 一画面のGUI最大表示数は 20個くらいです。それを超える情報を表示するには Table object を使うしかない。 そこで Table object に初期値を表示するWEB記事は多数ありましたが、リアルタイム更新する事例が見受けられませんでした。もしかして出来ない??? と思い試した覚書です。Xcode 14.1 です。

結論からいうと @State変数 を割当てれば普通に使えました。例では Foreground と Background でサーバとの通信の統計を表示する例です。

まず表示値を格納する@State変数を宣言します。

 	// 内部用の表示項目
 	@State private var	recvCnt 	 : [Int32]	= [0,0]
 	@State private var	recvErr 	 : [Int32]	= [0,0]
 	@State private var	sendCnt 	 : [Int32]	= [0,0]
 	@State private var	sendErr 	 : [Int32]	= [0,0]

Tableの列定義は、リアルタイム表示したい列は@State変数を定義します。

	// 統計コード列
	struct TokeiColums: Identifiable {
		let id = UUID()
		let name: String
		@State var value1: Int32
		@State var value2: Int32
		@State var value3: Int32
		@State var value4: Int32
	}

表示データの定義は、各列に表示値の@State変数を割当てます。

		// 統計行定義
		let TokeiInfo: [2] = [
			TokeiColums(name: "Server受信",
				value1: recvCnt[0], value2: recvErr[0], value3: recvCnt[1], value4: recvErr[1] ),
			TokeiColums(name: "Server送信",
			  value1: sendCnt[0], value2: sendErr[0], value3: recvCnt[1], value4: recvErr[1] ),	]

Table object の定義コードは以下です。縦余裕がないとさり気なく下から表示されなくなるため、一行余裕のある高さを指定おくのががベターです。

				/* 稼働統計 */
				Table(TokeiInfo) {
					TableColumn("項目") { locationColums in
						Text(locationColums.name)
					}
					TableColumn("OK件数-FG") { locationColums in
						Text("\(locationColums.value1)")
					}
					TableColumn("NG件数-FG") { locationColums in
						Text("\(locationColums.value2)")
					}
					TableColumn("OK件数-BG") { locationColums in
						Text("\(locationColums.value3)")
					}
					
					TableColumn("NG件数-BG") { locationColums in
						Text("\(locationColums.value4)")
					}
				}
			}

リアルタイム値の更新はタイマーで周期的に行います。

		.onAppear {
		   // タイマで3秒周期に更新
        updateDataTmr = Timer.scheduledTimer(withTimeInterval: 3,
							 repeats: true){ _ in
							 
					 		recvCnt[0] 	= 変更したい値
		          recvErr[0] 	= 変更したい値
		          sendCnt[0] 	= 変更したい値
		          sendErr[0] 	= 変更したい値
					 		recvCnt[1] 	= 変更したい値
		          recvErr[1] 	= 変更したい値
		          sendCnt[1] 	= 変更したい値
		          sendErr[1] 	= 変更したい値
				}
		}

表示例は以下のとおりです。

iPadでは特に問題はなかったのですが、iPhone では表示が真っ白でした。これは table object そのものの課題なのかもしれません。またタイマーは View をCloseしても生きています。必ず解放します。さもない View 再表示毎にタイマーが溜まってヤバイことになります。他言語ではVewとともに解放されますが、、、自分で停止するタイマを作る場合、インスタンスをGlobal定義し、invalidateで停止させないと効きません。タイマloop内で return も flg 値==falseでも脱出でできません。以下コード例です。

var    updateDataTmr:Timer? = nil     // 位置情報更新タイマ

struct ビュー名: View {
        :
       中略
        :
    var body: some View {
        :
       中略
        :
    }
    .onDisappear {
       if updateDataTmr != nil {
            updateDataTmr?.invalidate()     // タイマ停止
            updateDataTmr = nil
        }
    }

iOS で background ( 端末画面が非表示のとき ) 処理を定期実行させることは鬼門のようです。Appleの情報、ネット記事、有識者の情報 どれも幾分違っていて真実が分かりません。iOSではバッテリ節約が最優先され、background 処理時間に制限が厳しいと言われているようです。 ’24年7月に実装した結果を報告します。

1) 条件

2) background 検証時の注意

基本 background は「アプリが前面に表示されていないが動作しているとき」ですが、完全なbackground状態にするには以下の配慮が必要なようです。

• iOS系は 画面スリープ無し に設定できますが、これは有効にしないこと。
• USBで電源供給したままにしない。
• Xcodeと接続しない。

またプログラムに、

• トレースログが取得できる仕組みを作成しておく。

3) 定周期でbackground処理

取り掛かりとしてApp の onChange(of:scenePhase) イベント で background と foreground の切替りを検出してました。そのbackground のifスコープにで タイマーをつっこみました。(以下赤字部) これが一番シンプルかなと…カンで組んでみました。

struct TestApp: App {
    @Environment(\.scenePhase) private var scenePhase
	
    var body: some Scene {
         // 中略
    }
    .onChange(of:scenePhase){ phase in
	if phase == .background{
	     //------------- Background ---------------------
	     BackTimer = Timer.scheduledTimer(
		withTimeInterval:intarvalSec, repeats: true){ _ in
                 // 各種業務処理    
       	    }
	}
	else if phase == .inactive{
             //------------- パージ状態 ---------------------
	}
	else {
   	    //------------- Forground ---------------------	
        }
    }
}

一見動作しているように見えたのですが、途中でお亡くなりになるようです。background に移行してから動作可能な時間制限があるとのことですが、正確にどのくらいか色々試してもよく分かりませんでした。 UIApplication.shared.beginBackgroundTask ～endBackgroundTask を使って時間制限を検出しリカバリする方法も試しましたが、なんだか効果なしです。BGTaskScheduler というのもありますが有識者によると、「定周期background 処理は基本的ﾆ出来ない」とのことで試さずじまいです。

4) リージョン出入り検出でbackground処理

iOSで background 処理を定期的に行う手法として、GPSによる中心座標からの半径範囲(リージョン)への出入りを検出する方法が、いろいろと紹介されています。これは XamarinのiOS Background処理の説明ページにも記載されています。概念図は以下の通りです。

もちろんこれが適用されるのは、端末がある程度の時間経過とともに移動するシステムに限ります。その検出部のコードは以下のような感じです。

class TestLocation: NSObject, ObservableObject, CLLocationManagerDelegate { 
  // 中略
 private var myLocMgr: CLLocationManager	// iOS Location管理 
 private var myRegion  = CLCircularRegion	// カレントRegion

 init() {
	myLocMgr  = CLLocationManager()		// super.init()より必ず先
	super.init( )
		
	myLocMgr.delegate = self
	myLocMgr.requestWhenInUseAuthorization()
	myLocMgr.requestAlwaysAuthorization() 			// BG中も座標取得する場合、要call
	myLocMgr.desiredAccuracy = kCLLocationAccuracyBest	// 位置精度=最高
	myLocMgr.allowsBackgroundLocationUpdates = true	 	// BG中も座標取得する場合true
	// バッテリ消費に対してtrueが推奨だが、BG中に止められる場合ありとのこと。
	myLocMgr.pausesLocationUpdatesAutomatically = false

	myRegion = CLCircularRegion(center: coordinate, // 中心座標
			  	    radius: 10 ,        // 半径
				   identifier: "test01" //リージョン名、何でもよい )
	myRegion.notifyOnEntry 	= true   // 脱出検知あり
	myRegion.notifyOnExit 	= true   // 入り検知あり
		
	myLocMgr.startMonitoring(for: myRegion) // Regionを登録し検出開始。
    }

   // Region出た検出イベント
   private func locationManager(_
	manager: CLLocationManager,
	didExitRegion region: CLRegion
   ) {
      // background 定期処理 
              :
              :
   }

   // Region出た検出イベント
  func locationManager(_
	manager: CLLocationManager,
	didEnterRegion region: CLRegion
   ) {
      // background 定期処理 
              :
              :
   }

ポイントとしては、

• 移動しないとBackground実行できません。
• 定周期でBackground実行する場合は、移動量と時間のCONVERTが必要です。
• 半径5mに指定しても、イベント発生させるには50～100mくらい移動を要します。
• UIApplicationDelegateAdaptor を Appクラスで絡めるコード例もありますが、シンプルに CLLocationManager だけで構築できます。

5) 単純移動検知でbackground処理

「リージョン出入り検出」は、秒、分単位の定周期処理とすると不向きのようです。通常、リアルタイム緯度経度の検出で使用しているCLLocationManager のイベントも、よく観察するとBackground時でも動作していることに気付きました。リアルタイム緯度経度検出 と Background処理を一緒に行えば、もっと早い周期でBackground処理が可能となります。その検出部のコードは以下のような感じです。

class TestLocation: NSObject, ObservableObject, CLLocationManagerDelegate { 
  // 中略
 private var myLocMgr: CLLocationManager	// iOS Location管理 
 public var	NowLatitude  = 0.0		// 現在緯度
 public var	NowLongitude = 0.0		// 現在経度

 init() {
	myLocMgr  = CLLocationManager()		// super.init()より必ず先
	super.init( )
		
	myLocMgr.delegate = self
	myLocMgr.requestWhenInUseAuthorization()
	myLocMgr.requestAlwaysAuthorization() 			// BG中も座標取得する場合、要call
	myLocMgr.desiredAccuracy = kCLLocationAccuracyBest	// 位置精度=最高
	myLocMgr.allowsBackgroundLocationUpdates = true	 	// BG中も座標取得する場合true
	// バッテリ消費に対してtrueが推奨だが、BG中に止められる場合ありとのこと。
	myLocMgr.pausesLocationUpdatesAutomatically = false

	myLocMgr.distanceFilter = Double( 5.0 )	// 検出移動距離 単位m
	myLocMgr.startUpdatingLocation()	// 移動検出開始
    }

    //  移動検出イベント
    func locationManager(_
		manager: CLLocationManager,			// iOS Location管理
		didUpdateLocations locations: [CLLocation]	// 移動した位置情報
	) {
	if locations.count > 0 {	// Location情報あり
               // 現在座標の更新
		NowLatitude  = locations[0].coordinate.latitude
		NowLongitude = locations[0].coordinate.longitude
        }
      // background 定期処理 
              :
              :
   }

ポイントとしては、

• 移動しないとBackground実行できません。
• 定周期でBackground実行する場合は、移動量と時間のCONVERTが必要です。
• 移動距離をもっと小さくすると、秒周期でBackground内でイベント発生させることも可能。(iPadではGセンサも併用している模様)
• 日中での電池の持ち、iPadなら電池の持ちは心配ない感じ。iPhoneは厳しい感じ。
• 移動イベント中に、新しい移動イベントが発生した場合、新しい移動イベントは保留される。(保留最大数は未知)
• リージョン出入り検出と同居可能。

6) backgroundで動ける時間

Background内である程度の周期で動作できるようになったら、何秒くらい動作可能か情報が必要です。これも色々な説があるようです。以下のBackground処理ダミーコードで調べてみました。下記コード中の printLog はローカルtxtファイルへの出力付きの print 関数の自作ラッパーです。5秒置きにlogを残すことでどこまで動けるか確認しました。

  //  移動検出イベント
    func locationManager(_
		manager: CLLocationManager,			// iOS Location管理
		didUpdateLocations locations: [CLLocation]	// 移動した位置情報
	) {
	if locations.count > 0 {	// Location情報あり
               // 現在座標の更新
		NowLatitude  = locations[0].coordinate.latitude
		NowLongitude = locations[0].coordinate.longitude
        }
        BgUserpProc()    // background 定期処理 
   }

   public func BgUserpProc( ) {
	Task {
		let sttime = Date()
		var lastPassTime: Int = 0
		
		while( true ) {
			let passTimeDbl = sttime.timeIntervalSinceNow	/*単位秒、負値になになるる*/
			let passTimeInt = Int(passTimeDbl) * -1
			if lastPassTime != passTimeInt && passTimeInt % 5 == 0 {
				printLog( "<< BgUserpProc() pass time=" + passTimeInt.description + ">>")
			}
			lastPassTime = passTimeInt
			
			if  passTimeInt /*単位秒*/ > 300 /* 最大待ち秒 */ {
				break
			}
		}
		printLog( "<< BgUserpProc() out.>>")
	}
}

結果としては、

• 最小で45秒までは動けてはいた。公称値が30秒とのウワサ。
• 最大120秒程度まで伸びる場合あり。CPU使用時間が影響しているのかもしれない。
• 許容時間超過後、TASKは休止状態となり、Foregroud移行後に動き出す。
• 製品コードでのBackground処理はScokect通信です。これはうまくいきました。

MACは cappslokc がダイレクトに押せてしまう。WindowsはShiftと一緒に押さないと押せません。優秀です。MACはさらに手元に近すぎて誤って押してしまいやすいです。

そこて「MACでcapslock無効化」の設定があります。MAC Bookは有効です。capslockのLEDも点灯しなくなります。しかしMAC miniは効きません。Apple純正USB Keyborad でも効きません。他の記事には書いていなかったので、記載しました。

前回記事では、SwiftアプリをWindows上で開発することはできませんでした。

しかしWindows用のSwiftがリリースされていました。ビルド確認、単体テスト(UD)がある程度できるのかもしれません。

インストール

ここからインストーラー.exe をダウンロードして実行します。まずまずのサイズですね。

インストールするとプログラムメニューにはなにも現れず、プログラム一覧のみに現れます。

コマンドラインでたたいてみると、反応がありました。

どうもIDEはなく、言語エンジンだけのようです。インストール先をみると結構いろいろ入ってます。UNIXライクなProduct構造のようです。

ビルド

とりあえず説明はなにも見ず、MACからコピーしたXcodeプロジェクトに行って、Buildしてみます。

Xcodeの.project は対応していないようです。Swift.pakage という定義ファイルが必要なようです。コマンドラインの応答から、推測でコマンド swift package init を打ってみます。

専用のパッケージ構造のスケルトンができるようです。つまりXcodeとはなにも関係がない。Swift.pakage は自動生成されます。中身は、

ソースもスケルトン生成されているので、Xcode と同様にSwiftコードを書いて、build見ますしてみます。

Appleの基本的なオブジェクトは無い?? import Swift-UI を書くと、no sudh module になります。ちなみな実行時は、swift run です。スクリプトっぼく print(“Hellow Swift”) も、fatalError となります。

公式ページに「 we were able to use macOS as a development platform with Xcode as IDE, and then use the agility of CMake to build the same code on Windows.」 とありますので、Xcodeと互換性をもち、cmake をつかってWindows上でもつかえるとのことなので、何か設定があるのでありましょう。

今回、直ぐにも使えるものではないと分かったので、諦めてMAC上の開発で集中します。

前回は、Xcode 15.1 と visual stduio 2022 for MAC で試し失敗しました。

一世代古い Xcode14.2 と Visual Stdio 20192 For MAC での組合せを確認します。

手順は同じですが、結果は変わりました。

いずれも Visual Stduio 側でダメです。NuGet で何か他にないか探すと少しでできましたが、いずれも古くて使えなさそうです。

以上、SwiftサードパーティライブラリをXamarin に取り込むのは、簡単にはいかないようです。Flutter はどうでしょうか? しかし調査時間がありません。しかたなくXcode + Swift で進めます。