VIPER is one of the hottest architectures back then because of its separation of layers that isolated between each other which is also debatable. Some argue that VIPER is over-engineer and an overkill architecture, some argue that VIPER causes too many boilerplates of code and some argue that VIPER is one of the best architecture for iOS Development. All of these opinions are valid, we definitely can use VIPER depends on how complex is our project and other undefined constraints.
Recently I have a problem in my team whereas the analytics function become scattered. Some other team create their own function and handling their own caching for tracking the events, and some even create multiple similar function across the modules only for analytics, until then a problem arises.
Since my company heavily depends on A/B Testing and data-driven culture, at some point we have found a lot of biased data as well missing parameters, then I start to investigate the issues.
During development, we will come into a phase where we would like to test out our In-App Purchases. However, most likely we ever heard a myth that IAP only works with devices to test it out with an internal tester account. Turns out during the process of the creation of Tripzy, I found a way to test our IAP in a simulator without any hassle. Keep in mind there will be some limitations of course if we are testing against the simulator.
Factory pattern is one of the common patterns in a programming language. It is one of the creational design patterns that provide a high level of flexibility for your code. One of the interesting use cases that could make Factory pattern become a handy tool to use is Dependency Injection. Normally whenever we want to inject an interface as a dependency on an object, we could easily pass it through the initializer or set it from the property.
The proxy pattern is one of the few underrated patterns that nobody really talks about in iOS. A proxy pattern is one of the structural design patterns that lets you provide a substitute or placeholder for another object. A proxy has total control and access to the original object, and let the proxy object do some magical stuff with the original object and restrict the access to it, however, the one who uses a proxy object, won’t have any knowledge behind the scene.
After we have understood the basic concept of LLDB commands now it is taking time to understand the full GUI of Xcode debugging.
Let see the picture above. Once you have put a breakpoint on any lines of code in your applications, you will see a similar screen as above.
The top one is our code panel, which indicates where is our breakpoint located
The bottom left panel is our quick look panel, we can see our current state of the object in either class or function level at the moment the code is being halted
Have you ever wonder how to debug your entire code in the proper way? But sometimes we don’t know in-depth detail about how does it work behind the scene? In this multiple series of articles, I am trying to spread multiple articles into specific chunks of debugging part, start with the basic / foundation part of debugging in iOS. Normally we will have multiple topics covering all areas, start with LLDB debugging and end with Logging.
Do you know that we can actually simply share our breakpoints with our colleagues at work? Xcode provides us with the capability to share it. This share function is very handy if we want all colleagues to have a similar breakpoint. Some breakpoints that worth sharing are Exception breakpoint, Runtime breakpoint, and some Symbolic breakpoints. Let see how it works
Go to your debug navigator panel on the left panel
Once upon a time, while I was debugging my code, I found out an annoying warning comes up like below
[TableView] Warning once only: UITableView was told to layout its visible cells and other contents without being in the view hierarchy (the table view or one of its superviews has not been added to a window). This may cause bugs by forcing views inside the table view to load and perform layout without accurate information (e.
