WatchKit ならできた、full screen 指定、SwiftUI だとできない……?

できないなら SwiftUI じゃなくて WatchKit で作らないとダメかなぁ

WindowGroup 直下に対してカットしないとダメなのかも

これ、NavigationView があると、edgesIgnoringSafeArea 無視される感じなのかー。それ外せばいけるんだけどなー

正直、full screen にするのに navigation bar を非表示にしないといけないんだけど、tab の場所によって、戻るボタン出したりとかもしたいから、そうなると、結構ダサい実装になるし色々とあれ。てか、navigation bar 表示してるときに黒背景描画さえなければって感じだなぁ。

雛形できた。思ったより簡単だなーこの辺りは。さすが SwiftUI なんだろうね。まあ watchOS 7+ ってのもあるだろうけど。流石に watchOS 6 の SwiftUI はきちい;; LazyVGrid とかないし。

SwiftUI と Combine って合わせたことなかったんだけど、めっちゃ良さげやな。表示されてから 3s 後にアニメーションで消えるってやつなんやけど、画面タップで復活するっていうギミック入り。
標準ライブラリーでこのレベルできるのは、普通にいい時代になったよなー。

いい感じじゃない? 45mm だけ 12pt っぽい。
ちなみに、S1/2/3 は 8pt、S4/5/6 は 9pt、S7+41mm は 9pt、S7+45mm は 12pt って感じだった。スクロール中の角丸定義に同じ。 developer.apple.com/design/hum

TextField の横に Button 置くのにあまりにもスタイルが違いすぎたので。ちなみに透過の塗りつぶしは opacity 15%

あれでもちょっと丸すぎるかな。10pt ぐらいかもしれない

11.5pt かな?? んー なんか定義が割と杜撰じゃね? ってなるな

わかんねwww 12pt でいいや(まあちゃんと後で調べるw

一応アクションメニューのモックできた。配色とかローカライズとかまだの部分あるけど今日はここで力尽きた…
真面目な話、SF Symbols と SwiftUI でこういうモック作るの、とっても工数減ってるの良い。

ちゃんと watchOS のテーマあって作ってるので、モックの全ての機能は最初から実装するわけじゃないけどね。
そもそも watchOS で動かすので、ローカルデータベースそこまでリッチな機能持たせられないし、基本軽く楽しんで、軽く返信するみたいなことテーマにはしてる。

そもそも postone そのまま持ってきても watchOS には重荷にしかならねーロジックしてるし、lightweight 前提でコード書いてる部分はあるからなぁ。
まあ、SwiftUI だから、似たようなアプリを tvOS/macOS/iOS/iPadOS に移植するのは全然できるけど、そもそも watchOS の小さい画面で最大限に楽しむのがテーマだから、フルレベルアプリじゃないからねー。強いていうなら一番 tvOS がそのテーマにしっくりくるから移植ありだと思ってる。

でもさ、人間欲深くて、ある程度実装したらフル機能欲しいなーってなりそうなんだよなぁ。あくまで一つのテーマに沿ったアプリだから、プッシュ通知サポートする気もないからね。
でもあれだね、簡易返信実装したら、戻ってきた返信に対して返信したいよね(現状の設計だと見れない予定w)

でもこれはひどいと思うわ。期待した動作にならないの bad すぎるこれは。

これ、Section なかったら死んでるんだな。つまり Apple は Form に Slider を入れることは想定していないと…wwww

流石にこれはデバッグ不足じゃね? ってレベルの不具合な気がするが

ごり押し方法ふと思いついたのでやってみたらいい感じで草。これでいいやん。

ふと気づいたんだけど、これ、左右のボタン幅違うくない? 右側の方が余計に 8pt 多く余白入ってる感じ。
自作した方がいいかもなぁ。純正コントロールなはずなのにクオリティー低い。

ちなみに純正の見た目がこういう風になってるからこういう線入れてたんだけどそこで気づいたんだよね。左は 32pt translate、右は 40pt translate

Core Data (内部は SQLite) 初めて使うんやけど、Swift 固有の関数読み出しとかしたら一部 constraint 検証スルーされたりとか落とし穴あったけど、まあ割と問題ない感じやな。
まだ一つのクラスしかテスト書いてないから他のクラスも書かないといけないけど。

てか、Realm 使う理由ってあんまないな。コード量が減るだけで使うなら圧倒的にユーザーにとってダウンロードが早い Core Data 使った方がメリット大きい。Realm は Realm だからこそのユーザー体験ができるなら使うべきだけど。

あれ…… Minimum の Validation 無視されるんだけど…w

無視じゃなくて Assert が拾ってなかったわwww

Result<T, Error> で作っちゃったけど、普通に throws -> T の方がいいな。

とりあえず Core Data 部分の設計終わり。テストも雑だけどおk。
意外とちゃんとしてるから、雑なことすると、validation 引っかかって落ちそう

TestFlight 経由で Apple Watch Series 7 に入れてみたけど、満足感高いわ。ただシミュレーターより画像のロードは極めて遅い。

しかし、次、ローカルキャッシュ実装するか、OAuth 2 やるか悩んでる

Entity が実質定義リストも兼ねてる実装、すごく見通しいいな。
普通にいつもは外部ライブラリーとして使えるみたいな実装してたけど、それより遥かに結合してる方が後々の更新に良さそう。

SwiftUI、既存 UI に追加でこういう線入れるのも楽。

SwiftUI、Router 的なことするの、これでいいのマジで強い。
xaml はこういうのはなかったな。MAUI ってこんな感じの書き方将来的にはできるようになるのかな。

本当に watchOS? って感じになりつつある気がする。
普通にフルレベルアプリとして iOS 移植できそう。まあそれやり出すと、一気に作るパーツ増えるから、ひとまずは組み込めてからかなー。
キャッシュ基礎ライブラリーは作ったけど、まだ本体と繋げてないから、大仕事としてはあとそこ残ってる感じするなー。
まあやっと内部エンジン部の設計定まって、ハードコードで動くようにはなったし、よき。
それと、古いコード断片がまだあるから、そこの全面的リファクタリングぐらい。

watchOS 版の SwiftUI はわざわざコンポーネントを Metal で作ってそうな痕跡も見つけた。実際のところどうなのかは知らないけれど、明らかに WatchKit の UI よりできること増えてると思うんだけど実際のところどうなのかは知らない(WatchKit のアプリは作ったことがないので)

自分がアプリ作ると無限に機能増やしちゃって開発終わらない問題発生するから、watchOS ぐらいの制約があるとゴールが近いからスムーズな気がする。制約がないってやっぱ無限に広げられるからダメ🙅‍♂️

SwiftUI、こういうデバッグ表示、簡単に追加できるようになったのええなー

Follow

あの Apple も騙すことができる戻るボタン mntone.hateblo.jp/entry/2021/1

· · Web · 0 · 0 · 0
Sign in to participate in the conversation
mstdn.jp

Mastodon日本鯖です. よろしくお願いいたします。 (Maintained by Sujitech, LLC)