vesp

    vesp

    10 months ago
    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?
    marlonlom

    marlonlom

    10 months ago
    Did you build something following that github repository? what can you tell us for getting a billion users's app?
    vesp

    vesp

    10 months ago
    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 .
    Adam Powell

    Adam Powell

    10 months ago
    "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.
    Colton Idle

    Colton Idle

    10 months ago
    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

    Marko Novakovic

    10 months ago
    “Best architecture is architecture that is best for your app” yigit boyar. Paraphrasing 😄 but that’s the point
    and best architecture DELAYS decisions, best architecture is one with most decisions NOT made. don’t rush to marry frameworks etc.
    Adam Powell

    Adam Powell

    10 months ago
    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

    Marko Novakovic

    10 months ago
    👍 take a look at the app and be pragmatic, I agree
    some things are just not worth abstracting anyways so…
    Adam Powell

    Adam Powell

    10 months ago
    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. 🙂