Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Android platform engineer on application architecture

plus.google.com

Post reply on HN
Print view View original

11–20 of 124 posts

Re: Android platform engineer on application architecture

#11

Post by steplee »

lanestp wrote: post #3
twotavol wrote: post #2

Eschewing 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.

How would the ndk help, doesn't it run within an activity?

Re: Android platform engineer on application architecture

#12

Post by johndifool »

I remember her name. Wasn't she the one who vehemently was defending activity lifecycle and other broken multi-threaded API, something every Android developers I talked to would consider totally broken?

To be fair, developing on Android has become so insane releases over releases that her crazy write up about no engineering design hardly comes as a surprise...

Shame on Google for forcing us to use that POS.

Re: Android platform engineer on application architecture

#13

Post by jwatte »

jc4p wrote: post #6
shruubi wrote: post #5

After 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 co…

Have you tried putting all logic into a service, and only using fragments and activities foot display?

Re: Android platform engineer on application architecture

#14

Post by HillaryBriss »

This makes my head spin.

Plenty of examples on developer.android.com use Activities, Services, BroadcastReceivers for things that go beyond what Dianne Hackborn is recommending here.

It's like the Android SDK team want to have their cake and eat it too:

"We've built a tremendously powerful and useful SDK. It really helps you build great apps quickly and easily."

vs.

"Oh, and, by the way, be careful not to misuse our main components. They were never designed to help you build great apps quickly and easily."

Re: Android platform engineer on application architecture

#15

Post by 0xFFC »

Recently I was looking for one book desperately , a book that shows android (and its apps) architecture, form low-level to high-level, design decision which you should take when you design your app architecture. I hate how all books are kind of reference manual. If I want to see what an API doing , I will look at it documentation I don't need another book.But sadly most of books written about android is just talking about API details.

p.s. If you know such book I would be grateful .

Re: Android platform engineer on application architecture

#16

Post by fighting »

They really should have stuck with int main. What's unfortunate is the quantum leaps they've been taking in terms of complexity to just get an app up and running on their platform. But I guess that's the only way their engineers can justify their salaries/bonuses. Same as with that horrific nightmare of an app Facebook puts out.

Re: Android platform engineer on application architecture

#17

Post by EddieRingle »

lanestp wrote: post #3
twotavol wrote: post #2

Eschewing 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.

Do you mind expanding on some of your statements? Especially:

> 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.

Re: Android platform engineer on application architecture

#18

Post by vowelless »

Disclaimer: I am not an Android developer.

I cannot seem to reconcile these two statements:

> Should you use MVC? Or MVP? Or MVVM? I have no idea. Heck, I only know about MVC from school and had to do a Google search to find other options to put here.

And

> In Android, however, we explicitly decided we were not going to have a main() function, because we needed to give the platform more control over how an app runs.

So this person claims to not know or care about design patterns; but then explicitly enforcing a design pattern?

She does say:

> Android could feel like it has strong opinions on how apps should be written. With its Java language APIs and fairly high-level concepts, it can look like a typical application framework that is there to say how applications should be doing their work. But for the most part, it is not.

But after reading through the post, it does seem like a particular set of design patterns is being propagated.

Re: Android platform engineer on application architecture

#19

Post by bigiain »

userbinator wrote: post #9
zzalpha wrote: post #4

The 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 complexi…

I've scratched that same itch - and ended up with a bunch of Python code on a server and using my pocket-computer just for it's web browser... For "casual apps in my pocket" it's often "good enough". (This just moves the playing field, but I'm comfortable in html/javascript and FE Dev, so it works for me...)

Re: Android platform engineer on application architecture

#20

Post by kevb »

zzalpha wrote: post #4

The 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…

She mentions that we should think of the android apis as a "system framework", and I remember a different Google Android engineer saying something similar about the RecyclerView, that right now the focus is on making the technical functionality and API solid and stable, even if not so developer friendly. Someone else, or future Google, can make a more developer friendly API on top of the awkward RecyclerView API. The problem with designing APIs that aren't really meant for app developers, but instead for higher level framework developers, is that those higher level frameworks don't actually exist, and even if they did, there's no clear message for developers to follow. Less choices, or at least a "recommended" approach, would be valuable.
Post reply on HN