Post

Replies

Boosts

Views

Activity

Reply to DeviceActivityMonitor Schedule Pause
The answer actually lies in the recoverySuggestion when you convert the DeviceActivity.DeviceActivityCenter.MonitoringError.intervalTooShort error to LocalizedError (I don't know why they hide it there πŸ˜‚) "The minimum interval length for monitoring device activity is fifteen minutes. Consider using the warningTime property of an activity’s schedule to receive callbacks that are more granular than fifteen minutes." Doc of warningTime: https://developer.apple.com/documentation/deviceactivity/deviceactivityschedule/warningtime e.g. For a one-minute break, we can set the end time to be 15 minutes later and set the warningTime to be 14 minutes. Then intervalWillEndWarning will be called and we can treat it as the end time to end the break directly. let now = Date.now let start = Calendar.current.dateComponents([.hour, .minute, .second], from: now) let fakeEnd = Calendar.current.dateComponents([.hour, .minute, .second], from: now.advanced(by: 15*60)) try deviceActivityCenter.startMonitoring(.breakTime, during: .init(intervalStart: start, intervalEnd: fakeEnd, repeats: false, warningTime: DateComponents(minute: 14)))
Mar ’24
Reply to Hangs with non-busy main thread using Instruments
Hi! Thank you so much for confirming it's a blocked main thread! It turns out I was silly enough not to realize I need to toggle the Thread track button to see the Thread graph. So it IS a blocked main thread. However, the Narrative view only shows one of my function causing the issue but doesn't specify which line is the cause. I've scratched my head for hours, but couldn't understand why. The function is basically reusing the WKWebView for using it in SwiftUI UIViewRepresentative, which should only use the main thread, isn't that it...? Is there a way to let the instrument tell us which line is causing the blocking?
Feb ’24
Reply to SwiftData: "Illegal attempt to establish a relationship 'item' between objects in different contexts
I can confirm that the issue exists for iOS17.0.1 and macOS14.0. However it is fixed for iOS17.1.2. (I didn't update my mac to test.) So if we are targeting iOS17, we must make our relationship instances optional and set the values after the instance is initialized as Diethus showed in code. Additionally, we can combine implicit unwrapping, so the callers won't notice it's an optional. class MyItem { var name: String private(set) var item: Item! init(name: String, item: Item) { self.name = name // relationship attributes must be set after the instance is initialized. self.item = item } }
Dec ’23
Reply to How to use transformable in SwiftData?
It's now possible to use transformable(by:). @Model final class Profile { @Attribute(.unique) let id: UUID var name: String @Attribute(.transformable(by: UIColorValueTransformer.self)) var uiColor: UIColor var color: Color { get { .init(uiColor: uiColor) } set { uiColor = .init(newValue) } } init(id: UUID = UUID(), name: String, color: Color) { self.id = id self.name = name self.uiColor = .init(color) } } @main struct MyApp: App { init() { UIColorValueTransformer.register() } } The transformer code can be found here: https://www.avanderlee.com/swift/valuetransformer-core-data/
Dec ’23
Reply to DeviceActivityMonitor - eventDidReachThreshold Callback Not Triggering Properly
I'm not sure why issue1 and issue3 are caused. But as for issue2: You mentioned: "In addition, I should mention that, with each iteration through the eventDidReachThreshold callback, I increment the threshold by 2 minutes and restart the monitoring. " Note that the activity duration is calculated using the given time interval. (00:00 to 23:59 in your case) So if the the the duration has exceeds the given threshold when you call 'startMonitoring', the eventDidReachThreshold callback will be called immediately. This may be why you see the eventDidReachThreshold callback got triggered multiple times since you're monitoring recursively.
Dec ’23
Reply to ShieldConfigurationExtension not working
Perhaps try to check your deployment version. This could happen if your iPhone iOS version is below iOS17.0, while your app targets iOS16.0 and the app extension targets the latest default version, which is iOS17.0. The extension wouldn't run because the deployment version not matched. Happens to me all the time πŸ™„
Nov ’23
Reply to "No options were provided for this parameter" in Edit Widget menu
I've encountered the same issue twice. The first time is the same as others, the iOS versions of targets don't match. The second time happens after I merged my intent handler targets into one. I accidentally typed SelectTimerIntent() instead of SelectTimerIntentHandler() when redirecting which handler to use, and the compiler still compiles so it took like an hour to find out after using the breakpoint πŸ˜“
Aug ’23
Reply to PDF View Scrolling
After some digging, I noticed that it's due to the pdf.scaleFactorForSizeToFit changes after viewDidAppear. That gives us two incomplete workarounds. Solution1. Save the pdf.scaleFactor after viewDidAppear and apply it from then on. So the display can be normal for the second time and so forth. Solution2. Disable autoScale and set pdf.scaleFactor = pdf.scaleFactorForSizeToFit manually. The downside is that the scale won't be perfect.
Nov ’22
Reply to PDF View Scrolling
This problem still persists in 2022. For an incomplete solution, we can set the document after viewDidAppear. private var isFirstAppear = true if isFirstAppear { isFirstAppear = false if let documentURL = Bundle.main.url(forResource: "Acupuncture Intake", withExtension: "pdf"), let document = PDFDocument(url: documentURL), let pg = document.page(at: 0) { pdfView?.document = pg.document pdfView?.autoScales = true pdfView?.backgroundColor = UIColor.lightGray pdfView?.displaysPageBreaks = true; pdfView?.displayMode = .singlePage } } The downside is that there will be a brief moment when the pdf view is empty until the document is set.
Oct ’22