S時計

開発日記

2026年

１
物価高対策がきました。
光熱費の割引と地域活性化クーポンが配布されるので、それらを合わせると2万円の物価高騰対策となります。

そして目玉の確定申告での戻りが、 5万円ほどになりそうです。
実質は10万円ほどになるかも。
いや、20万円かな。
いやいや30万円とも言えるかな。
やっぱり選ばれし者だったのです。

そうなんだよな、自分の場合は、年末調整ではなく確定申告です。
だから遅くなるのです。

ありがとうございます。
ウマウマ、ウマウマ、ウマウマx5、です。
みんな、ありがとう。ごっちゃんです。

マジで、幸せ。どうしても豊かになる。
政治は関係ありません。政治は自身でコントロールできないからです。
自分自身の力、即ち、能力と努力だけが時代を切り開けられる。
ま、自分の場合は能力と努力ではなく、のほほん力かも。笑
だけど、それは才能である。

ま、子供の頃のお年玉程度の金額やけど、貰えるものはすべて貰います。
もちろんプラスのモノだけやけどな。

丁度、財布がボロボロになっていたので、その購入費に充てるかな。
そんな感じですね。

高市自民党の政策はショボくて遅い。
前の岸田と石破の給付金配りの方が早かったのではないかと思います。
それよりも岸田と石田のガソリン価格政策は、今にして思えば、評価できるところだ。

高市自民党の場合は遅いので、この内閣はすべてがトロい、それで1リットル200円になったのです。
切れ目なく対策を講じるとは、それが(1リットル200円)無いってことよ。

平均170円なので、その前後10円はあるから、店頭では180円になりそう。
それでもイメージ的には良いのではないかな。
自分は1リットル300円を覚悟していたので、180円なら安く感じます。

地球温暖化を本気で思うのなら1リットル500円だろうな。
その方がレジ袋有料化よりも効果がある。間違いなし。

NISAでボロ儲けどころか億を掴んだ人が億人ぐらいいてるとのことなのだから、そんな物価高対策にチンケなことをせず、困っている層に大盤振る舞いすることだったね。

そりゃ、NISAでボロ儲けのヤツらは高市自民党にウホウホだろう。
円安でウホウホなのだからな。ウホウホ、ウホウホ、ウホウホx5、です。
ま、NISAで超ラッキー、ウホウホ、ウホウホ、ウホウホx5、みんな、だよね。

逆に、NISAを持たない人にも何かしらの恩恵を与えるべきなのです。
そもそも株を買えない貧困層なのだから、そこにも手当を与えるべきだよな。
NISA口座を持たない宣言をすると年50万円が貰えるなど。
NISA口座を持つヤツらは1800万円までタックスヘイブンの租税回避特典になるのだからね。

NISAというタックスヘイブンを高市自民党は作ったのですが、これは諸外国からはどう見られているのだろうか。
みんなの夢、タックスヘイブンです。

1800万円まで無税です。
この部分にもトランプ関税が攻め寄せてくるかも。
そもそもNISAというタックスヘイブン口座の考えは危険である。
そこから減税となったからです。

ちなみに自分はNISAをやっていません。
今のところ自分の家計は安定経済なので、それを増やす減らすはしたくないからです。

自分は常に安定家計なのです。
それで大満足しています。
好きなものを食べれるし、好きなことができている。
好きな生活ができているのです。

NISAは合法なタックスヘイブンで、無税、無税、無税x5、です。
なのに君らは増税、増税、増税x5、です。

みんなも歌おう、ウホウホソング。
ウホウホ、ウホウホ、みんなでウホウホx5、だー。
物価高騰対策で、ウホウホ、ウホウホ、みんなでウホウホx5、だー。
原油高騰対策で、ウホウホ、ウホウホ、みんなでウホウホx5、だー。
NISA政策で、ウホウホ、ウホウホ、みんなでウホウホx5、だー。
賃貸高騰で、ウホウホ、ウホウホ、みんなでウホウホx5、だー。
福祉増税で、ウホウホ、ウホウホ、みんなでウホウホx5、だー。
OTC類似薬の保険適用外で、ウホウホ、ウホウホ、みんなでウホウホx5、だー。
みんなの笑顔、みんなの幸せ、それがウホウホ政策、超ラッキー。

みんなで、ウホウホ、ウホウホ、みんなでウホウホx5、だー。
みんなで、ウホウホ、ウホウホ、みんなでウホウホx5、だー。

ウホ、ウホ、ウホ、超ラッキー。

書いてて楽しいです。こんなバカバカしいことこそ、平和で楽しいのです。

はっきり言って自民党としても圧勝は困ることがあるね。
そんなにポストがないからです。
全員を社長にすることはできない。
それと同じく全員を大臣にはできません。
まず、今までの世襲で大臣のポストは埋まる。
誰かを除かなければ大臣のポストは空かないのです。

これは藤原家からしか摂政、関白になれないのと同じです。
パッと出の輩が、身分を考えずに大臣とは、笑止千万なのです。うむ。

OTC類似薬の保険適用外でアレルギー患者を殺しに来ました。
アレルギーは病気ではない。クズの言い訳だ。
ちなみに維新の党が強力に推進した政策です。
今まで使用していた人は年間で5万円から10万円の自己負担になる。
ま、仕方がありませんね。自民党と維新の党が圧勝したのだからね。

別におかしくないです。
維新の党は、大阪都構想と副都心、国会議員の削減、 OTC類似薬の保険適用外、と公約しているのだからな。

また、高市自民党にしても、消費税減税の検討を加速する、としているので、検討を加速するだけが公約なのです。
事実、怪しげな国民会議で検討だけは加速しています。

１
S時計アプリ。
容量、7.7MB
書類データ、600KB
CPU使用率、10%
メモリ使用率、44MB
消費電力、lowとhigh

メモリの使用率は44MBの前後10MBなので、メモリリークはなし。
容量は変化しません。

軽量化に成功しました。
というか、肥大化していました。
swiftuiのバージョンでViewのコストが違う。
UIKitのときもにありました。

UIKitのStoryboardでviewを出すと15MBになっていた。
コードでviewを出すと5MBです。
そもそもStoryboardは使っていません。
確認のために一度、viewを表示したぐらい。
それで15MBになったので、これでは使い物にならないと判断しました。

自分はviewが好きなので、できれば1MBぐらいでないと、何十枚のviewを使うからな。

swiftuiはviewで考えるから自分の考えと相性が良い。
それとswiftuiのviewは、ViewModifierがあるのでカスタムしやすい。
これは本当にナイスな機能です。

overrideが画期的な機能だけど、それと同じく、 ViewModifierは素晴らしい機能です。

自分はViewが好きなので、あいうえお、にしても、一文字づつ、Viewで表示したいぐらいViewが好きなのです。

そうそう昔、10万回ループでView(フォルダー)を表示したら落ちました。
この場合、消す(フォルダーを閉じる)のも大変でした。
表示すると落ちるから、そのアプリをmacOSが起動する前に、そのアプリを起動しないとしなくてはならなく大変だったような。

２
今は、 @MainActor
@Observable
class DateClass { }
、となっているようです。

ObservableObjectと@Publishedは古い書き方。

新しい書き方の場合、変数がすべて@Publishedになるようだ。

受け取り方の@ObservedObjectと@StateObjectにしても不要で、 @Stateでよいみたい。

仕様をコロコロと変更するので困ったものです。
古い書き方はDeprecatedになるから、最新の書き方にした方が良いだろう。

@Observableで、そのクラスをすべて監視対象にする宣言。
@MainActorは、いわゆるUIの更新をするときに、メインスレッドでやらなくてはならないから、 UIを更新時はメインスレッドで行うとする宣言。

古い古い書き方でいう、これだな。
DispatchQueue.global(qos: .default).async {
//ui以外の処理、ここで写真を加工する。
//例えば写真を加工するなど。
//写真を加工するのはUIを変更していません。
DispatchQueue.main.async {
//uiの処理、写真を更新する。
//例えば加工した写真を表示するなど。
//加工した写真を今表示されている写真と差し替えるのがUIの変更です。
@MainActorで、監視対象の変数の値が変化したときに、ここの状態にしたい。
}
}

@MainActorを付けると、 ui以外の処理を気にしなくていいのだと思います。

処理が遅くなりそうだけど、そうならないから割愛しまくりの書き方になったのだと思います。

もうすべてが古い。笑
swiftのときはswift4のときに、一度、大規模なすり合わせをしたけど、 swiftuiではそれがない。
そろそろswiftuiを進化させるのではなく、大規模な調整が必要だと思います。
進化よりも安定化をさせるところではないかな。

情報が無茶苦茶になっている。
次のiOS26から先に進むためにも、一旦、落ち着くべきではないかと考えます。

swift4のときに大規模な調整をしたのは英断だったな。
だからこそswift5が一番、プログラムを書いてて面白かった。

次のswiftuiは、swfitui27になるのかも。
iOSがiOS26になり、iPhoneがiPhone26になったように、そうなりそう。

３
それで、書き換えました。

まず、いろいろと試した結果、 ObservableObjectと@Published、シングルトンが一番でした。
それが一番スムーズに動く。

@StateObjectは、シングルトンの要素があるとのことだけど、なにやら怪しい動きだったので、v30では、 ObservableObjectと@Published、シングルトンに戻しました。

なので、ObservableObjectと@Published、シングルトンから、 @MainActorと@Observable、シングルトンとしました。

それほどスムーズではない。笑
ObservableObjectと@Published、シングルトンが現状では一番スムーズかな。

@ObservedObjectを@Bindingに変更しなくてはならないし、 $が必要になる。かなり手間でした。

//@AppStorage("clock_type") var clock_type: Int = 0
@AppStorage("clock_type") @ObservationIgnored var clock_type: Int = 0
これは、@ObservationIgnored、が監視を外すとするキーワードです。
これって、今までは@Publishedが監視対象でその他が監視しない変数だったのですが、その逆になっただけなのかも。
卵が先か、鶏が先か、どっちもどっちだな。

@Publishedを付けていたのは34項目の内、24項目で、 10項目は監視対象外だった。今まで気にしたこともない。
それで、@ObservationIgnored、を10項目につけました。
その代表がAppStorageの保存項目です。

7項目の設定を保存しています。
残りの3項目はそもそもletです。
letだから@ObservationIgnoredはいらないのではないのかと思うけどね。

普通にクラスを取り込めて、 @Publishedは監視対象の変数、 @NoPublishedは監視対象外の変数のように単純にすればいいのに。
@Publishedは監視対象の変数でその値が変更されれば@MainActorが発動し、 UIの変更も伴うところで動かせる。
この場合は、すべての変数に@Publishedか@NoPublishedを付けなくてはならない。
とする自分の考えです。

これはv31からになります。
今はv30なので、以前のままです。
こんなコアな部分の仕様を変更するのだから、時間をかけてチェックしないとならない。

最新の書き方にしたけど、それを3ヶ月間は使用して、何も不具合がなければオッケーってことです。
今のところ変わりはないです。

いや、どちらかと言えば、 ObservableObjectと@Published、シングルトンの方が、滑らかな感じがしなくもない。
いやいや、最新の書き方はアニメーションが速くなったような、それで違和感があるのかな。

durationを0.5秒にしていたけど、反応が良いので、 1.0秒にしなくてはならないなど。あくまでもUIの変更のとき。
コンテンツの中身のアニメーションではない。
ビューからビューに遷移するときのアニメーションの動きが、レスポンスが速くなったので、今までの0.5秒では、パッと瞬間移動的な動きになったように感じます。

本当に些細なことだけど、気にするところなのです。
自分にとって、そこ、そのUIの動きが気になる性格だからね。

これは感覚です。
以前の書き方なら、タップする、少し間がある、 0.1秒または0.2秒でも間がある、そこから0.5秒でビューが次のビューに変更される。

それが、最新の書き方では、レスポンスが良くなったので、タップする、間がない、そこから0.5秒でビューが次のビューに変更される。
そうなると約0.15秒の間がなくなるので、速く感じる。

妙なところにこだわるよな。これイラってくる。
テーブルにコップの水滴があるとイラッとするのと同じ。

durationを0.7秒にすればいい話やん。
なんか0.7秒って中途半端やん。
なので、1.0秒とします。
そうするとアニメーションが長く感じるかも。

だから今まで通りのガラパゴスが一番なのです。
それって進歩がないことになるね。

結論は、最新の書き方の方が速くなる。レスポンスが良くなるのです。
が、全体的な動きを前の書き方で合わせているので、UIの動きに、違和感が出てくる。

違和感を感じるのは、最新の書き方で変化があるってこと。
なので、レスポンスが良くなったのは間違いないです。

この方が自分には幸せだった。
ObservableObjectと@Published、シングルトン。
@ObservedObject。
受け取りが@ObservedObject、だけなので楽だった。

これをお勧め。
@MainActorと@Observable、シングルトン。
@ObservationIgnored。データバインディング名称が長い。
@Stateと@Binding。$が必要になる。

@ObservationIgnoredのデータバインディング名称が長い。
これを@Ignoredぐらいにしないとね。
これは改善されると思います。

あと、import Observationは要らない。
標準化にして、swiftuiに内包してください。
import Combineも内包が望ましい。

今、0.7秒で試したところピッタリでした。
実際は0.65秒のようですが、0.7秒で良い感じなので、 0.7秒を採用しました。

思いの外、良い仕上がりになりました。
スムーズになるので、それにバランスを合わせる必要がある。
今、何日か試してみて気に入りました。

2026/03/20