2024/7/25
laprasdrum.icon 帰省中 🛬
/icons/hr.icon
Swift migration guide jpにPR送った
個人開発のコードをSwift Concurrency/Swift testingに移行する最中、該当のrepoを眺めてたらtypoに気付いた。
サクッと修正してPR送った。
Now that you mention it, ...
言われてみれば確かに。めっちゃ使いそう。
XCTestからSwift testingへ置き換え中
Swift testingで非同期テストのチェックに困り、Closureベースのテストは全てConcurrencyに変えないといけないのかなと悩んでた。
というのも、XCTestのexpectation/wait相当の関数がなかったからだ。
どうしようかなーとMastodonで呟いた（先のpost）ら、「Confirmation使えばいいんじゃない？」と教えてもらった。
存在は知ってたのに、確かに言われるまで思いつかなかった。
code:before.swift
import XCTest
class Car {
enum Result { case stop, run, terminated }
func run(_ completion: @escaping ((Result) -> Void)) {
completion(.run)
}
}
final Class CarTest: XCTestCase {
func test_run_returnsValidResult() throws {
let sut = Car()
let exp = expectation(description: "Wait for completion")
sut.run { result in
switch result {
case .run:
break
default:
XCTFail("Unexpected result: \(result)")
}
exp.fulfill()
}
wait(for: exp, timeout: 1.0) }
code:after.swift
import Testing
class Car {
enum Result { case stop, run, terminated }
func run(_ completion: @escaping ((Result) -> Void)) {
completion(.run)
}
}
struct CarTest {
@Test func runCar async throws {
let sut = Car()
await confirmation { confirmation in
sut.run { result in
switch result {
case .run:
break
default:
Issue.record("Unexpected result: \(result)")
}
confirmation()
}
}
}
}
てことで問題解決。困ったことは英語コミュニティで聞いた方が速く解決することが多い。
モバイルクライアント設計とWebクライアント設計の違い
限られた画面スペースを考慮しながら複雑なフローを設計する
PCのディスプレイほど大容量に情報を載せられないので、ユーザーの関心・目的を達成する情報設計が必要
Safe Area、Dynamic island、通知UIなどのエリアを考慮する
機能をオフラインで動作させながら、バックエンドとデータを同期させる
オンライン想定のWebアプリケーションと同じペルソナを期待してはいけない
特に海外のネットワークは日本よりも圧倒的にパケット転送量が小さく、接続できないことも多い
大量のデータをダウンロードする際にサーバーの負荷を回避する
上記のネットワーク事情と一緒
受信だけでなく送信も考慮する
ネットワークとローカルキャッシュの無効化を処理する
キャッシュと最新のサーバーデータの不整合を解消する
通信状態の変化に対応する
複数のデバイスやプラットフォーム間で機能を再利用できるようにする
iCloud sync
アプリケーションサーバーによるデータ同期
polling
stream subscription
システム設計 = ビジネス要件を満たす技術ソリューションの設計と捉えると、上記はどのビジネスのモバイルアプリでも満たすべき非機能要件だと考えてる。
日本だけに提供するアプリケーションの場合あまり考慮していないとこが多そうではある。（特に困る場合が少ない）
加えて、アプリとチームの規模が大きくなるほど下記についてチームで取り組む必要が出てくる。
企業全体の要件を満たす必要がある共有コンポーネントの提供
各プロダクト共通の技術仕様を束ねたモジュール・システムコンポーネント
CI/VIに関係することもある
抽象化を抑制し、複雑さを低く抑える
過剰な抽象化もチームを混乱させる要因になる
過剰なエンジニアリング
チームに不適な技術投与を避ける
コードの重複が多すぎる、または少なすぎる
多すぎる場合はイメージしやすい
少なすぎる場合は各機能ごと共通化できるはずの処理をそれぞれ特殊解にしてないかチェックする
複雑なコードベースの危険性
エンバグを生みやすい
ビジネスの損失