HapticService with named patterns
Semantic haptic API independent of UIKit details — callers invoke named interactions, not raw feedback types.
Problem
Calling UIImpactFeedbackGenerator or UINotificationFeedbackGenerator directly at each call site scatters UIKit dependencies throughout view and ViewModel code. Changing the feel of an interaction requires hunting every call site rather than editing one place.
Solution
Create a HapticService that exposes semantically named methods: shake(), reveal(), tap(), cardDraw(), crack(). Each method owns its own generator lifecycle internally. Callers express intent, not implementation. Generators are lazy-initialized on first use, eliminating startup overhead.
In FortuneTeller, lazy generator initialization replaced the prepare() call pattern, reducing boilerplate while remaining sufficient for the use case.
Usage
Use whenever haptics appear in more than one feature or interaction type. Name methods after the user-facing gesture or moment, not the UIKit type. Inject HapticService as a dependency or expose it as a singleton — either works; singleton is acceptable for global UX concerns like haptics.
Trade-offs
- Pro: Single source of truth for haptic feel; updating the sensation of “reveal” touches one method; UIKit isolated to one file.
- Con: Lazy generators add a tiny first-use latency (imperceptible in practice);
prepare()gives more control over timing if sub-millisecond precision matters.
Context
shake(), reveal(), tap(), cardDraw(), crack().
Reusability
- Score: 3/5
- Used in: FortuneTeller
Source
Synced from ops-core learning data. Original source: FortuneTeller