I'm struggling with asynchronous code in Swift. I have to disable 2 buttons if there is no internet connection. I have 2 DispatchQueue.main.async calls in 2 different functions. 1 of them works, but the other one doesn't disable the button (the good thing is that you can click on the button and nothing happens). I am testing my code on my iPhone because the simulator does not run the SDK I am using properly.
All these functions look like this (this is the one at the end that does not work):
public func disableButton2(_ check: Bool) {
DispatchQueue.main.async{
self.button2.isEnabled = check
}
I have used this and it was working fine
DispatchQueue.main.asyncAfter(deadline: .now() + delayInSeconds) { [weak self] in
guard let self = self else {
return
}
try this you will get the result.
A kind of more accurate approach, in order to explain "why asyncAfter works instead of just async" would be that DispatchQueue.main.asyncAfter would capture the thread in order to make the UI change to happend.
But most of the times could be because your are trying to update a view element within another view, say UICollectionView inside a UIViewController. In order to solve this you should call async method inside the method that makes this UI update
Related
I'm using PencilKit sample as an example. I added a willResignActiveNotification modification. After you quit move move back and fourth between collectionView and note 3 times.
Then move the app to background, you'll observe willResignActiveNotification active 3 times. I expect to see it called once only. But why 3 times? Is there a way to avoid it?
In DrawingViewController class, I have:
lazy var willResignActive: (Notification) -> Void = { [weak self] _ in
print("Saved on willResignActive")
}
In viewWillAppear, I have
_ = NotificationCenter.default.addObserver(forName: UIApplication.willResignActiveNotification,
object: nil,
queue:.main,
using: willResignActive)
Here are the sample Xcode. https://github.com/legolasW/DrawingWithPencilKit
To reproduce the result, click the note then back. Repeat.
Then move the app to background, and you'll observe willResignActiveNotification runs multiple times.
The results are like below.
Edits:
I tried to move addObserver to viewDidLoad, problem persists.
I tried to removeObserver in willResignActive closure, problem
persists.
I double checked with the memory graph, can confirm its not a
DrawingViewController memory retain.
I tried willResignActiveNotification, willResignActiveNotification, willBecomeActiveNotificication, willEnterBackground, showed same multiple call behavior.
Move
NotificationCenter.default.addObserver(forName: UIApplication.willResignActiveNotification,
object: nil,
queue:.main,
using: willResignActive)
to viewDidLoad
I'm working with a Phantom 4 Pro drone, which have precision landing capacity. I'm using Swift and a iPad for controlling the drone. In DJI Go software, I can enable it, and it works correctly. However, in the app that I'm working on, any calls to enable it fails.
This is the code that tries to enable it:
static func setPrecisionLandingEnabled(precisionLandingEnabled: Bool, _ completeFunction: #escaping (Error?) -> Void) throws {
guard let djiKeyManager = DJISDKManager.keyManager() else {
GLog.Log("Error in Flight Controller Observer. Problem getting djiKeyManager in \(#file) \(#function)")
throw FlightControllerManager.FlightControllerError.cantGetKeyManager
}
guard let precisionLandingEnabledKey = DJIFlightControllerKey(param: DJIFlightAssistantParamPrecisionLandingEnabled) else {
GLog.Log("Error in Flight Controller Observer. Problem getting precisionLandingEnabledKey in \(#file) \(#function)")
throw FlightControllerManager.FlightControllerError.cantGetKey
}
djiKeyManager.setValue(precisionLandingEnabled, for: precisionLandingEnabledKey, withCompletion: completeFunction)
}
When I call the function, the completion function of DJI SDK returned the following error:
Error Domain=DJISDKErrorDomain Code=-1013 \"Current product does not
support this feature.(code:-1013)\"
The API in question is found here: https://developer.dji.com/api-reference/ios-api/Components/IntelligentFlightAssistant/DJIIntelligentFlightAssistant.html?search=precision&i=0&#djiintelligentflightassistant_setprecisionlandingenabled_inline
I checked, and there's no parameters passed in when issuing the "take-off" call that is related to precision landing. So, why am I getting this error when I know that the drone have this feature (as verified by DJI's own app)? Does the drone have to be flying first before enabling this? Or are there other conditions that must be met before I can enable this?
It looks to me like you should be creating a DJIFlightAssistant object, and then using the existing method setPrecisionLandingEnabled(_: Bool, completion: DJICompletionBlock)
Why are you writing your own setPrecisionLandingEnabled() method?
I'm seeing crashes that either shouldn't be possible, or are very much possible and the documentation just isn't clear enough as to why.
UPDATE:
Although I disagree with the comment below asking me to separate this into multiple SO questions, if someone could focus on this one I think it would help greatly:
When are notifications delivered to the main thread? Is it possible that the results on the main thread are different than they were in a previous runloop without being notified yet of the difference?
If the answer to this question is yes the results could be different than a previous runloop without notifying then I would argue it is CRUCIAL to get this into the documentation somewhere.
Background Writes
First I think it's important to go over what I am already doing for writes. All of my writes are performed through a method that essentially looks like this (error handling aside):
func write(block: #escaping (Realm) -> ()) {
somePrivateBackgroundSerialQueue.async {
autoreleasepool {
let realm = try! Realm()
realm.refresh()
try? realm.write { block(realm) }
}
}
}
Nothing crazy here, pretty well documented on your end.
Notifications and Table Views
The main question I have here is when are notifications delivered to the main thread after being written from a background thread? I have a complex table view (multiple sections, ads every 5th row) backed by realm results. My main data source looks like:
enum StoryRow {
case story(Story) // Story is a RealmSwift.Object subclass
case ad(Int)
}
class StorySection {
let stories: Results<Story>
var numberOfRows: Int {
let count = stories.count
return count + numberOfAds(before: count)
}
func row(at index: Int) -> StoryRow {
if isAdRow(at: index) {
return .ad(index)
} else {
let storyIndex = index - numberOfAds(before: index)
return .story(stories[storyIndex])
}
}
}
var sections: [StorySection]
... sections[indexPath.section].row(at: indexPath.row) ...
Before building my sections array I fetch the realm results and filter them based on the type of stories for the particular screen, sort them so they are in the proper order for their sections, then I build up the sections by passing in results.filter(...date query...) to the section constructor. Finally, I results.observe(...) the main results object (not any of the results passed into the section) and reload the table view when the notification handler is called. I don't bother observing the results in the sections because if any of those results changed then the parent had to change as well and it should trigger a change notification.
The ad slots have callbacks when an ad is filled or not filled and when that happens instead of calling tableView.reloadData() I am doing something like:
guard tableView.indexPathsForVisibleRows?.contains(indexPath) == true else { return }
tableView.beginUpdates()
tableView.reloadRows(at: [indexPath], with: .automatic)
tableView.endUpdates()
The problem is, I very rarely see a crash either around an index being out of bound when accessing the realm results or an invalid table view update.
QUESTIONS
Is it possible the realm changed on the main thread before any notifications were delivered?
Should table view updates other than reloadData() simply not be used anywhere outside of a realm notification block?
Anything else crucial I am missing?
There's nothing in your code snippets or description of what you're doing that jumps out at me as obviously wrong. Having a separate callback mechanism that updates specific slots independent of Realm change notifications has a lot of potential for timing related bugs, but since you're explicitly checking if the indexPath is visible before reloading the row, I would expect that to at worst manifest as reloading the wrong row and not a crash.
The intended behavior is that refreshing the Realm and delivering notifications is an atomicish operation: anything that causes the read version to advance will deliver all notifications before returning. In simple cases, this means that you'll never see the new data without the associated notification firing first. However, there's some caveats to this:
Nested notification delivery doesn't work correctly, so beginning a write transaction from within a notification block can result in a notification being skipped (merely calling refresh() can't cause this, as it's just a no-op within a notification). If you're performing all writes on background threads you shouldn't be hitting this.
If you have multiple notification blocks, then obviously anything which gets invoked from the first one will run before the second notification block gets a chance to do things, and a call to tableView.reloadData() may result in quite a lot of things happening within the notification block. If this is the source of problems, you would hopefully see exceptions being thrown with a stack trace coming from within a notification block.
I'm working on a little project in spritekit and can't quite figure something out. I am animating a sprite using SKAction.animateWithTextures and moving through and array. Works fine just like it should. The issue is that I would like to a function that starts when the animation starts and one when it ends. I see there is a .animationDidStart(CAAnimation), but because what I'm doing is not a CAAnimation I can't really use it. Is there something like this for the method I'm using? As you can may or may not be able to tell I'm still rather new to swift. Thanks for any help in advance.
I'd create a sequence of actions. First a block action to call your method you want called when the animation starts, then your animateWithTextures action, finally another block action that calls your finished method.
let startAction = SKAction.runBlock {
self.startAnimation()
}
let textureAction = SKAction.animateWithTextures...
let finishedAction = SKAction.runBlock {
self.finishedAnimation()
}
SKAction.sequence([startAction, textureAction , finishedAction])
This is all purely for educational purposes, to help me get a better understanding of how Parse as well as Swift operates.
I would like to make it so a user is only able to like an item once (not being able to hit a button multiple times), as currently, I'm utilizing an anonymous system with Parse.
Would I essentially use an if method with PFUser.CurrentUser() in the likeButton method to halt a user from hitting like again or would I use NSUserDefaults?
I'm not able to post code currently as I'm not near my laptop, however I could later if it helps. Still curious if I could get some info before that however.
Sample code I found on here from a previous question, which essentially implements the same idea.
#IBAction func likeButton(sender: AnyObject) {
let hitPoint = sender.convertPoint(CGPointZero, toView: self.tableView)
let hitIndex = self.tableView.indexPathForRowAtPoint(hitPoint)
let object = objectAtIndexPath(hitIndex)
object.incrementKey("count")
object.saveInBackground()
self.tableView.reloadData()
}
Would I call NSUsersDefaults to stunt the user from hitting it more than once?
Instead of calling saveInBackground(), you'd better call the method saveInBackgroundWithBlock: instead. So the strategy is very simple:
First of all, define a 'busy' flag for the object (For example: savingInBackground) and store it wherever you like ( If you are showing 1 item then simply declare a Bool property / If you are showing a list of Item then declare a Dictionary with format ["objectID/Index": Bool]). This flag should be set to true for the item being saved in the background.
Whenever use taps on a Like button
If current item's savingInBackground flag is true, then do nothing
Else:
Set item's savingInBackground to true
Increase Like count and Call saveInBackgroundWithBlock:
In the completion block of saveInBackgroundWithBlock:, set savingInBackground back to false.
I am on train now so I can't write example code, but I hope that it's clear enough to help you to achieve what you want.