Post not yet marked as solved
Hello @Masatoshi ,
Great repo!
Could you please clarify the license for this repository?
We're wondering if we could use the tool in our commercial app. Thank you!
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)))
Post not yet marked as solved
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?
Post not yet marked as solved
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
}
}
Post not yet marked as solved
I've had this similar issue and made a bug report with a sample project replicating the same issue.
FB13492170
Post not yet marked as solved
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/
Post not yet marked as solved
By any chance you're recursively setting another threshold monitoring upon threshold reached?
Post not yet marked as solved
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.
Post not yet marked as solved
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 🙄
Post not yet marked as solved
You can use
Text("Only \(Text(endDate, style: .timer)) mins left to add")
.monospacedDigit()
Post not yet marked as solved
Here's a workaround I use.
Give the Text a fixed width according to the end date.
Use minimumScaleFactor to prevent the given width truncating the text.
The downside of this approach is that the width won't update as the timer counts down to less digits.
Example code and ref: https://stackoverflow.com/a/76861806/11153088
Post not yet marked as solved
Hi!
The same issue happened to me before.
The issue happens when we return an emtpy array for the function entities(for identifiers: [String]).
In my case, I forgot to add one missing entity which was additionally added in the suggestedEntities.
This may not be the cause of your issue, but I hope it can help you find some clues. 🙂
Post not yet marked as solved
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 😓
Post not yet marked as solved
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.
Post not yet marked as solved
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.
