Skip to main content

Posts

Basics of RxSwift & Reactive programming

RxSwift is a popular third-party library for the Swift programming language, written by Krunoslav Zaher. It enables reactive programming , providing a way to work asynchronous and event-driven code. It helps developers write a clean, easier to manage code, allowing to work with async data streams more effectivly. Reactive programming Reactive programming uses so called declarative paradigm, focused on handling asynchronous data streams and event driven programming. This paradigm allows developers to write in style as to how should application react to state changes dynamically. Key concepts Streams and Observables : Data flows continuously while app reacts to events in real time Event-driven architecture : Instead of polling for updates, reacts to them Backpressure handling : Option to implement various techniques to ensure that the system don't get overwhelmed by excessive data Publisher/Subscriber pattern: Components communicate efficiently without blocking ...

Optional types in Swift

Quick overview of optional types... In Swift, Optinal is an Enumeration type consisting of two cases: none and some(Wrapped) . Wrapped parameter represents the underlying value. none case is when there is no value. Code example: enum Optional { case none case some(Wrapped) } let optonalNumber: Int? = 5 switch optionalNumber { case none: break case some(let number): print(number) } To summerize, optinal in Swift in an enumeration, consisting of two cases: .none and .some . Provides a safe way and expressive way of handling the types that might not have a value. They are integral part of the Swift Programming Language that ensures a safe and readable code by explicitly handling absense of values. They are especially useful when dealing with types that might not have a value available at a given time. By using optionals, Swift enforces good practices of handling with a missing value. The main reason that the optinals are there is to pre...

Pro Tip: Approaches to improving performance

On improving performance and avoiding bottlenecks... Network requests are "expensive" or "slow". They affect performance greatly in iOS. Try combining results and refreshing the UI once multiple requests are finished from background. Good practice is to keep track of each of the asynchronous request and be able to cancel them if needed, to avoid unnecessary consumption of resources. Efficient memory management is also essential. Avoid retaining large data structs if they are no longer needed. This will relieve memory pressure. Prevent memory leaks. Optimize UI updates by combining them. UI updates run on main thread. Many UI updates occurring successively can make user interaction with the app unresponsive. Try implementing so called "batch" updates. This is achieved by collecting multiple UI update data from background and then dispatching them on the main thread in larger set time intervals. Utilize data structures by using indexes or sets for mor...

Pro Tip: Comparison between static and dynamic libraries in iOS

Difference and size footprint... Static libraries are built (compiled) and linked at a compile time. Dynamic Libraries are compiled separately and linked at runtime, usually when application is launched. Dynamic (shared) libaries exist outside of the main executable. Static libraries can increase the size of the final executable, because they are duplicated for each binary that uses them. Dynamic libraries do not increase final executable size becuase they are shared between all binaries. Advantage here goes to dynamic runtime libraries because of less redundacy. Each application that uses static libraries, needs it's own copy of it. This increases deployment size. Dynamic libraries have dependency to other libraries and they are allocated dynamically at runtime. Static libaries are faster, because they are pre-loaded at compile time, while dynamic libraries are a bit slower because of a runtime loading and symbol resolution. Big disadvantage for the static libraries i...

Pro Tip: Most effective ways of writing clean code in iOS

Single Responsibility Principle Single Responsibility Principle (SRP) is the first principle of Uncle Bob's SOLID principles. Each class, module or function should focus on just one thing. And do it correctly. This produces focused, simple and easy to read and understand code. Don't repeat Yourself (DRY) Avoid duplicated code. Reuse common code. This greatly improves code base maintainability and reduces new bug introduction or more places when making changes. Use Meaningful names This one is straight from the "Clean Code" book from our "Uncle Bob". Everyting is in the name. Use self-explanatory naming conventions for functions, classes or modules. This improves understanding the code base without having to dig deep into the implementation details. Open-Closed Principle Design code to be open for extension, but closed to modification. Use techniques such as inheritence, protocols and composition. This allows to introduce new functionality that w...

iOS Application States

There are 5 App sates in total, which can be categorized further like App’s Foreground and Background states. Not running / Terminated state Inactive state Active state Background state Suspended state Cycle between the app states. (Image credit: InterviewBit) NOT RUNNING / TERMINATED STATE App (Process) does not exist in memory, it is not visible, not running, there is no CPU/GPU or other resource consumption, not a trace of activity. INACTIVE STATE The App (Process) does not receive events, this state can be triggered by system interruption, like when Incoming call arrives, or by other user actions like when user locks the device. It's worth noting that this state happens only in the foreground . This state occurs for a brief moment, as well, when the App is being launched to active foreground state or from the background state. ACTIVE STATE This is the main Application state when the App (Process) is running in the Foreground, UI is visible and the App is receiv...

Memory Management in iOS

Strong Reference Cycle in IOS, a brief Overview and how to avoid them In iOS, memory is managed by a mechanism known as ARC, or Automatic Reference Counting. In laymen’s terms, Automatic Reference Counting mechanism works as follows: An Object exists in memory if its reference count is greater than 0 . Each Object instance has its own reference count. Under the hood, it’s simply a number with a default value of 0. If another object or function holds a strong reference to that object, its reference count increases by the number of strong reference “holders”. For example: If an object is initialized from a function, the function references strongly to that object until the program leaves the scope of the function. func instantiateTableView() { let tableView = UITableView() } So, the UITableView object is instantiated in a function, it’s reference count is now 1. When the program exits the scope of the function, that table view object will be deallocated, since it’s refere...