I thought I understood how custom protocol delegates worked, but I think I was mistaken.
I have an app that has four (4) tab bar buttons linked to view-A, view-B, view-C and view-D.
The view-A has a child view controller linked to it, view-a. View-a uses a custom protocol delegate that sends data back to its parent view, view-A. This works perfectly. No problem with this at all. (See green arrow below)
View-B also has a child view controller, view-b. View-b also has a custom protocol delegate whose purpose is to send data back to view-a, which is NOT its parent view. This delegate method never triggers the protocol method within view-a. (See red arrow below)
According to what I read within the excellent iOS Apprentice book a delegate method should be able to work properly provided all the details are correct. So before I lay down my code, I have attached a graphic of my app and perhaps someone could tell me if my delegate method should work or not. Perhaps delegates only work between parent and child views? I do not think this is the case at all, but I could be wrong.
As to the graphic attached below: The red arrow depicts view-b’s delegate link to view-a. The green arrow shows view-a’s delegate link to view-A. The red arrow delegate method does not trigger the delegate method within view-a. The green arrow delegate method does trigger the delegate method within view-A.
You are right - the delegate patterns works between any two classes - not just parent view controllers and child view controllers. However, for the delegate pattern to work, both class instances must be in existence. Since your delegate implementation relies on a child view controller in a tab set, my suspicion would be that view-a is not in existence when you take whatever action that triggers the delegate methods in view-b.
To test this, try explicitly opening view-A and then it’s child view (view-a), and then switching tabs to view-B and then on to view-b and then take the necessary action to trigger the delegate method. If you had not navigated to view-a before you went to view-b, view-a definitely would not be in existence. since tab bars do not instantiate their full view structure as soon as the app is started.
Even with the above, I can’t be absolutely certain that the first tab’s view hierarchy is not torn down when you switch tabs. I’d have to look at the documentation or do some checking to make sure that this doesn’t happen. You can easily check for this by overriding the deinit method for view-a and adding a log statement there to see when it is destroyed.
Thanks for your indepth response to my query, fahim.
Since I posted my thread, I have learned - just as you noted, that view-a is non-existent and thus, “not listening”, which explains perfectly this behavior. This creates a problem for me because view-b needs to send newls set user data to view-a to update the users data.
As to your suggestion - opening view-A, then view-a, I deliberately hid the tab bar in view-a so as not to clutter the view. In so doing, I did wonder what would happen if the user tried to do just that. I may have to show the tab bar and do as you suggest to test this out.
I will be traveling tomorrow so may not get to try this for a day or so.
I can’t remember at the moment whether iOS Apprentice covered the singleton pattern or not, but what you might want to do here is to have a central class (possibly a singleton) which holds the data needed by view-a. That way, you can update this class from view-b and when you get to view-a, simply refresh what is displayed via the central data-holder class. That might work better for what you have in mind than how you’re approaching it now … or not I can’t really tell since I don’t know all the details. But it’s worth a shot.
I finally succeeded. Rereading your last comments, they were spot-on, although at the time I read them, I was not aware just how correct you were. I hate to admit this, but I was already using a class that could have been tweaked to solve my data passing issue. I am much wiser now than when I began this task.
Without any doubt, this was the most difficult iOS/Swift task I have ever taken on since I began coding over ten years ago.
In short: I was trying to pass data between child views of tab bar controllers. Tab bar controllers present some unique issues in trying to pass data between them.
After a lot of work and research, I finally succeeded in passing data between the tab bar controllers. Once that code was perfected, it was not difficult to pass data between the child views.
Too bad user’s never appreciate the struggle that goes on behind the “scenes”.
Thanks for your help. Next time I will be a bit more attentive.
No worries, experience really is the best teacher You learn more by struggling than by getting the answer handed to you by somebody else - at least, that’s been my general experience. So the next time you come across this same issue, and you will, you’ll know exactly what to do now. Good luck
I can’t really tell since I don’t know all the details. But it’s worth a shot.
