This is great. We discussed using the test branch for test code and we've both understood the circumstances to why we have this pull request filled with commits of varying purpose. Looking forward to the continued use of pull request as the app develops.
Just a reminder when moving forward when we create new pull requests, ideally we would want to have specific feature branches that group up the functionality we are trying to build. For example, one feature branch on strictly google maps changes and work on that feature, once the commits are completed we create a PR for that merge. This also allows us to work on different branches simultaneously in a more organized manner without conflicting.
====================================================================================
Brief thing to note, once completed with debugging and the feature is known to work, please remove the NSLog statements from code.
Can also add UI alerts, however that would disrupt the flow during development
If you really want accessible logs for development purposes, a cleaner way could be to create a logging system that can be turned on and off with a flag depending on if you are testing/debugging. This is optional and not required at all.
In response to observers, if applicable delegate methods and chaining is a straightforward to let child views communicate with parent views and VCs, and perform actions. Event listeners and observers are great at handling arbitrary events when a view has no reference to another view, however it generally acts as global scope. The more features touch the same event listener and, the app can be prone to some side effects and it is not recommended as it can broadcast to every class. And we probably only want send notifications for a specific case.
Great work on understanding how to use notifications and no complaints in your implementation of notifications, and moving forward lets evaluate if we need the use of event listener pattern or if we can leverage delegates!
Feature Branches! I'd love to see Google Maps Feature branch, and other branches when you get to different parts of your app!
This is great. We discussed using the test branch for test code and we've both understood the circumstances to why we have this pull request filled with commits of varying purpose. Looking forward to the continued use of pull request as the app develops.
Just a reminder when moving forward when we create new pull requests, ideally we would want to have specific feature branches that group up the functionality we are trying to build. For example, one feature branch on strictly google maps changes and work on that feature, once the commits are completed we create a PR for that merge. This also allows us to work on different branches simultaneously in a more organized manner without conflicting.
==================================================================================== Brief thing to note, once completed with debugging and the feature is known to work, please remove the NSLog statements from code.
In response to observers, if applicable delegate methods and chaining is a straightforward to let child views communicate with parent views and VCs, and perform actions. Event listeners and observers are great at handling arbitrary events when a view has no reference to another view, however it generally acts as global scope. The more features touch the same event listener and, the app can be prone to some side effects and it is not recommended as it can broadcast to every class. And we probably only want send notifications for a specific case.
Feature Branches! I'd love to see Google Maps Feature branch, and other branches when you get to different parts of your app!