Journey to finding the perfect app architecture.
updated about 1 year ago; latest suggestion about 1 year ago
This proposal has been withdrawn...
When it comes to mobile apps, I think we can all agree apps should be fast, fun, and easy to use. To do this, apps should be built (1) offline first, (2) not ask the same questions twice, (3) when an error occurs, help the user actually resolve the issue (instead of the dreaded, "Error occurred, please try again" message), (4) keep data fresh for the user to get their job done faster. All while (5) keeping the developer experience high by making your apps less prone to bugs.
Sure, these are the best practices, but as iOS devs who have been at this for a while, we know this can be difficult. We tend to care about our deadlines and make shortcuts or excuses to meet them.
Over the past 5 years of my mobile app development, I have been on a continuous journey. A journey to create the perfect app architecture that removes all of these excuses for myself. In this talk, I want to go over the current app architecture that I use for all of my Android & iOS apps (specifically iOS) that I have continuously redefined over the past couple dozens apps I have built.
This talk goes over each the best practices I mentioned above with my thought process and code behind each solution.
This intermediate to advanced level talk will cover technical topics such as, * MVVM using Rx/Realm * Offline functionality via a Core Data Database and syncing library I wrote * Data driven UI via "State data" library I wrote (closely resembles Groupon's Grox lib)
I want to deliver a talk that gives developers the "how" to solve each of these best practices to help them to go home and make great apps with no more excuses. We have been building apps for a long time and apps still seem to be built without these best practices?
It sounds like you're planning to cover a lot of topics in a short amount of time, which means you're not going to be able to get into a great deal of depth. Is that your intent?
Clearly there isn't one perfect app architecture, which suggests that you might be promising more than this talk could ever deliver.
If I go to an architecture talk I want to hear the lessons learned, and an honest depiction of both good and bad points. That way I can make an informed decision on whether it would work for me in the context of my day-to-day work.
There are also a lot of aspects to assessing architecture patterns that your description is missing. Specifically, I'd like to see mention of maintainability, testability and the SOLID principles.