Maybe this is my natually skeptical nature but is ...
# android-architecture
v
Maybe this is my natually skeptical nature but is Google's iosched repo the absolute best repo to turn to for Android archictecture best practices? Is there another repo that has...even better best practices?
m
Did you build something following that github repository? what can you tell us for getting a billion users's app?
v
I'm going to wave this off as sarcarm but I'll answer in earnest. I have not followed this repo. I'm just curious and looking to learn .
a
"good practices" might be a better way to put it than, "best practices" - there are many good architectural paths available for writing Android apps and iosched is usually following some that are reasonably recent (within ~1 year of current thinking). You might also enjoy looking around https://github.com/android/compose-samples for some more compose-focused thinking.
c
my 2 cents. theres a ton of things that should be considered with architecture. one of those things is time and time constraints. I don't think the iosched app gets a ton of developer time and it's probably worked on by a group of volunteers and so my point is that when evaluating and real project its important to keep the time allocation in mind. A project like iosched would look completely different if it was a team of 10 working on it for a year vs a team of 3 working on it for 2 months.
m
“Best architecture is architecture that is best for your app” yigit boyar. Paraphrasing 😄 but that’s the point
👍 1
and best architecture DELAYS decisions, best architecture is one with most decisions NOT made. don’t rush to marry frameworks etc.
a
Usually the iosched app is updated by the Android devrel team each year. It may not get the hours of a years-long project, but it generally represents the zeitgeist for that year pretty well. It's built with the patterns that are at top of mind for the team as they've spent the rest of the year working with the community and compiling that experience into codelabs and documented advice. The decisions made there are pragmatic and optimized for annual and late-breaking UX revamps that need to be delivered on a fixed timeline.
Delaying decisions can be highly beneficial or it can exponentially increase the cost of maintenance and building features if the outcome is building dozens of connectors and adapters that don't do anything except launder and obfuscate your data flow. Always balance delayed decisions with YAGNI.
m
👍 take a look at the app and be pragmatic, I agree
some things are just not worth abstracting anyways so…
a
Right. The benefit of delaying a decision is reducing the cost of changing your mind later. If you can lower that cost in other ways, delaying a decision becomes less important. If delaying the decision makes changing your mind later more costly instead of less, make a decision. 🙂
💯 2