Android platform engineer on application architecture
plus.google.com
Android platform engineer on application architecture
1–10 of 124 posts
Re: Android platform engineer on application architecture
#2Eschewing the traditional application architecture has made for both a terrible development experience and poor quality applications in general. The application lifecycle is convoluted with even the Android developers joking about how confusing it is. Everything about the model has made it far more difficult to port existing software to, and native development for me personally has been an absolute nightmare. No clean exit strategy for applications, half the methods in the lifecycle don't even get called, etc. I can't imagine the completely naive and oblivious thought process that led to the mess they created. Good thing Android is backed by Google though, so no matter how terrible it is it'll still be popular.
Re: Android platform engineer on application architecture
#3Eschewing the traditional application architecture has made for both a terrible development experience and poor quality applications in general. The application lifecycle is convoluted with even the Android developers joking about how confusing it is. Everything about the model has made it far more difficult to port existing software to, and native development for me personally has been an absolute nightmare. No clea…
I agree. Android architecture is a mess. Activity life cycling is actually impossible. There are certain actions the OS takes that will cause crashes no matter how well architected the app is.
My main quibble with Android is that since everything is tied to the activities it is impossible to build an MVC style app. You are better off using the NDK or an engine. Then you can build your software correctly.
Re: Android platform engineer on application architecture
#4The fact that an Android platform engineer doesn't know of design patterns beyond MVC, and only knows that vaguely by reputation, explains why it's so difficult to build well designed apps for Android.
Yes, technically the platform APIs don't "care" about what's going on in an app. But when the APIs are designed in such a way as to (inadvertantly) work against MVC or other design patterns, they make developer lives more difficult. And you can expect that to happen if your platform engineers aren't familiar with these concepts.
Re: Android platform engineer on application architecture
#5After developing a few Android apps as an agency dev, we settled on a common structure that helped keep our code relatively clean.
Each activity would have an associated fragment, the idea was that the activity would be responsible for loading the fragment as the current view and other lifecycle functions as well as being the entry-point for any external data-loading (through creating and calling of services).
The fragment would initiate with a reference to the parent activity as a context, and would be responsible for view-centric things like displaying content and adding event handlers, which would more often than not use the context reference to call some remote API.
I suppose you could think of it in terms of Model/Controller/View-Controller but I'm sure there is a more correct model for thinking about it (and it probably is more straight MVC anyways).
The problem I've found with Android is that Google has created almost it's own language when it comes to Android app architecture, which creates a lot of confusion, especially for developers who just assume that all frameworks use the MVC concept (laugh if you will, but this is a thing).
Even though google is quite behind when it comes to the app market, I think there is still time for them to come out with a new set of documentation which outlines the "correct" (the "Google-blessed" one at least) structure for Android apps so that we as a development community can start moving away from the "everything-and-the-kitchen-sink goes in the current activity" style of Android development.
Re: Android platform engineer on application architecture
#6After developing a few Android apps as an agency dev, we settled on a common structure that helped keep our code relatively clean. Each activity would have an associated fragment, the idea was that the activity would be responsible for loading the fragment as the current view and other lifecycle functions as well as being the entry-point for any external data-loading (through creating and calling of services). The fr…
What you described sounds a lot like what I used to do for years. It works fairly well, and you can tack a headless Fragment onto it for things that you don't want directly connected to an activty's lifecycle (rotating the screen mid user sign-up shouldn't restart the HTTP call, etc).
This works well, and I'm at the point where I develop it without thought while creating new apps, but I've been playing with a less constrained DI flow instead using Dagger 2.
The more business logic and multiple copies of shared UI elements in different Fragments are directly connected to their parent Activity, the harder it is to re-arrange and re-use them. I've been working on migrating all core elements of our application into a shared library project, and that would've been impossible with a closely tied codebase.
Re: Android platform engineer on application architecture
#7One thing platform engineer should do is to rotate into app engineer role and experience it for a couple month at least, without doing it you don't really understand all the pains the app engineers are suffering due to platform design. At very least you can make your doc so much better by knowing which part you absolutely want to cover in details.
This is especially true for Android platform team, to be honest.
Re: Android platform engineer on application architecture
#8After developing a few Android apps as an agency dev, we settled on a common structure that helped keep our code relatively clean. Each activity would have an associated fragment, the idea was that the activity would be responsible for loading the fragment as the current view and other lifecycle functions as well as being the entry-point for any external data-loading (through creating and calling of services). The fr…
There's a few issues with this though. Take various animations such as the one on the toolbar that some Google apps have (the arrow that spins into a hamburger and back again). Easy to do if you're just loading different fragments into a Framelayout, impossible to do with activities as you reload the entire toolbar on an activity change.
It's a general problem in the Android world. Some things can only be done as an activity whilst others as fragments.
In fact this is a problem even on Googles own apps. Right now if i tap things in the nav panel of the Gmail app it's a crap shoot whether i open a fragment or activity. Things like inbox/sent are loaded as fragments. Things like settings are loaded as activities with a completely different loading in animation. Help is different again. Lots of different ways of loading in a view all coming from options in the same menu. It's pretty fucked up form a UI perspective.
Re: Android platform engineer on application architecture
#9The fact that an Android platform engineer doesn't know of design patterns beyond MVC, and only knows that vaguely by reputation, explains why it's so difficult to build well designed apps for Android. Yes, technically the platform APIs don't "care" about what's going on in an app. But when the APIs are designed in such a way as to (inadvertantly) work against MVC or other design patterns, they make developer lives m…
Actually I'd attribute the difficulty to the culture of "Java-ism" that emphasises huge, complex, design-pattern-filled "extensible" architectures which happen to be extensible only in very specific ways.
I wanted to take up casual writing of Android apps as a hobby, mainly because I think the little portable computer I keep in my pocket could become so much more useful, but the unusual API combined with the complexity and general baroqueness of the architecture was a big turn-off. I don't get the whole "design patterns" thing either, but I do have extensive experience with writing Win32 apps, and a little bit of X (which is not all that different.)
Re: Android platform engineer on application architecture
#10I worked with Dianne fifteen years ago, and she was good. However, hearing from others who were involved in early Android, and then left in disgust, the designers who set out the initial form did boot have extensive application framework/developer experience, and we're still hiring to this day because of it.
Let's say it all together: Implementation inheritance is a mistake, and interface based design is a clearer option.