ios - Like feedback using firebase crash. Fast click like-remove like -

i have application instagram. has feedback page.

when user likes post, add , feedback (with own key (.childbyautoid) like.

static func add(_ newlike: likeitem) {   // add id user feedback implementation   var = newlike   let likeref = ref.child("/userslikes/" + newlike.userid + "/onposts/" + newlike.postid).childbyautoid()   like.key = likeref.key    var updates: [string: any?] = [      "/userslikes/" + like.userid + "/onposts/" + like.postid: like.toanyobject(),      "/postslikes/" + like.postid + "/"         + like.userid: like.toanyobject()   ]    if like.userid != like.postaddedbyuserid { // dont add own likes      var likeforfeedback = like.toanyobject()      likeforfeedback["isviewed"] = false // when user open feedback -> true      updates.updatevalue(likeforfeedback, forkey: "/feedback/" + like.postaddedbyuserid + "/" + like.key)   }    ref.updatechildvalues(updates) } 

it's ok. , have remove function. going node, getting , feedbackid like. , make multi-part update.

static func remove(with userid: string, _ post: postitem) {   var updates: [string: any?] = [      "/userslikes/" + userid   + "/onposts/" + post.key: nil,      "/postslikes/" + post.key + "/"         + userid:   nil   ]    // deleting feedback node   getlikefromuser(id: userid, postid: post.key) { in      if like.userid != like.postaddedbyuserid {         updates.updatevalue(nil, forkey: "/feedback/" + like.postaddedbyuserid + "/" + like.key)      }       ref.updatechildvalues(updates)   } }  static func getlikefromuser(id: string, postid: string,                            completion: @escaping (_ likeid: likeitem) -> void) {   let reftolike = ref.child("/userslikes/" + id + "/onposts/" + postid)    reftolike.observesingleevent(of: .value, with: { snapshot in      let = likeitem(snapshot: snapshot)       completion(like)   }) } 

so, when user taps "remove like" have delay (it fetching entity feedback id @ time).

and problem: if i'm spamming like-removelike button (like - remove - l - rl - l - rl etc.), feedback node duplicating (with different keys ofc. has not removed old node) , not adding (in situation crashing if try remove in future).

how fix it?

my humble opinion, first of fix ux limitations. user shouldn't able spam button in application. must delay between events. can add max. switch between user decisions... wait while , make free again (maybe).

like said on comment, it's idea , ux wait user until finish write operation. way can eliminate bad ux.

you can use userinteractionenabled property of uiview.

when set no, touch, press, keyboard, , focus events intended view ignored , removed event queue. when set yes, events delivered view normally. default value of property yes.

during animation, user interactions temporarily disabled views involved in animation, regardless of value in property. can disable behavior specifying uiviewanimationoptionallowuserinteraction option when configuring animation.

of course there many alternatives, sky limit ux scenario.

also can check apple's user interface guidelines loading:

https://developer.apple.com/ios/human-interface-guidelines/interaction/loading/

show content possible. don’t make people wait content load before seeing screen they're expecting. show screen immediately, , use placeholder text, graphics, or animations identify content isn't available yet. replace these placeholder elements content loads. whenever possible, preload upcoming content in background, such while animation playing or user navigating level or menu.

and indicators maybe:

https://developer.apple.com/ios/human-interface-guidelines/ui-controls/progress-indicators/

if it’s helpful, provide useful information while waiting task complete. include label above activity indicator give context. avoid vague terms loading or authenticating because don’t add value.

another option

like said in comment below there option keep like/dislike until user lives viewcontroller. there ux problem when user try close modal or previous view controller wait until background job finish. issue if user kills application have 1 change left save data , it's appdelegate's applicationwillterminate. it's bad practice save data there because 5 seconds limit:

https://developer.apple.com/documentation/uikit/uiapplicationdelegate/1623111-applicationwillterminate

this method lets app know terminated , purged memory entirely. should use method perform final clean-up tasks app, such freeing shared resources, saving user data, , invalidating timers. implementation of method has approximately five seconds perform tasks , return.

if method not return before time expires, system may kill process altogether. apps not support background execution or linked against ios 3.x or earlier, method called when user quits app. apps support background execution, method not called when user quits app because app moves background in case. however, method may called in situations app running in background (not suspended) , system needs terminate reason. after calling method, app posts uiapplicationwillterminate notification give interested objects chance respond transition.

hope helps.