iOS & Android Development

Database-Drive UI - Database-driven Logic Rather than managing dozens of independent features and having each pull information and build its own cache on the app, we leveraged the SQLite database as a universal system to support all the features. Compared with the previous iOS version, this new Messenger is twice as fast to start and is one-fourth the size. We reduced core Messenger code by 84 percent, from more than 1.7M lines to 360,000. We accomplished this by using the native OS wherever possible, reusing the UI with dynamic templates powered by SQLite, using SQLite as a universal system, and building a server broker to operate as a universal gateway between Messenger and its server features. Native Code When building a new feature, it’s often tempting to build abstractions on top of the OS to plug a functionality gap, add engineering flexibility, or create cross-platform user experiences. But the existing OS often does much of what’s needed. Actions like rendering, tran...

How Amazon builds and operates software There’s no question the world will be a better place if everyone can innovate more quickly and efficiently. And if stuff just works better. For that reason, I’m excited that we are sharing what we’ve learned with you in The Amazon Builders’ Library. -Charlie Bell, SVP, Amazon Web Services Available so far: Avoiding insurmountable queue backlogs Challenges with distributed systems Going faster with continuous delivery Ensuring rollback safety during deployments Static stability using availability zones Avoiding fallback in distributed systems Caching challenges and strategies Leader election in distributed systems Timeouts, retries and backoff with jitter Using load shedding to avoid overload Implementing health checks Workload isolation using shuffle-sharding Instrumenting distributed systems for operational visibility Amazon

I would like to talk about the alternative to VIPER — Clean Swift. At first glance, Clean Swift is similar to VIPER; however, the differences become visible after looking at the way the modules interact. The interaction between them happens in cycles. Data transmission is based on protocols (again, similar to VIPER), which allows for replacing one of the components of the system with another one. Generally the interaction process looks like this: the user clicks on a button, the View Controller creates an object with a description and sends it to the Interactor. Interactor, in turn, launches a specific scenario following its business logic, then produces a result object and transfers it to Presenter. Presenter generates an object with the data formatted for presenting it to the user and sends it to the View Controller. Clean Swift (as opposed to VIPER) has a unidirectional flow of data processing and decision making . There is always only one cycle — View Controller— Interactor — ...

module.exports = function (model, view, intent) { if (view) { view.observe(model); } if (intent) { intent.observe(view); } if (model) { model.observe(intent); } }; The first thing to notice is regarding the communication, as you can see from the schema above the communication is unidirectional. In MVI, the view is exposing an observable for the intent to capture all the user interactions from the view and passing the data through an observable to the intent. The intent is preparing the data received for the model, and these data are passed to the model via an observable again. Last but not least the model save these data and update the view exposing an observable to the view. The view is not changing directly, but it’s just preparing the virtual tree to be rendered by any renderer. Bear in mind that one peculiarity of an MVI architecture is that an object shouldn’t manipulate or directly call any method of another object; the only communication allowed are through observab...