Live data from Hacker News

Android platform engineer on application architecture

plus.google.com

31–40 of 124 posts

Re: Android platform engineer on application architecture

#31

Earlier quoted context omitted.

Most Android developers I know (and even some iOS developers) consider the Intent system one of Android's diamonds in the rough. Could you perhaps explain how you would've designed it?

The concept may be a diamond in the rough i.e. co-operative multi-tasking. The implementation, not so much.

Speaking as someone who has been writing Android software for like 4 years now as my job (but who has been in the industry for much longer than that, as a 42 year old who has programmed in just about every major environment), I agree with what you wrote here.

Intents are great in concept and they work out well for users, but the interface/API for using them to do anything can quickly become painful if you go even a step off the beaten path of "perform this operation with these parameters".

A common recurring theme with Android (and this applies to all the major bits -- Activities, Fragments, Services, etc) is that you'll easily hang yourself if you don't have a really clear picture of how they actually work but you attempt to use them. Android almost completely fails, IMO, when it comes to the concept of "keep the easy things easy". There's a huge upfront cost to understanding the major components before you can start really using them at all safely, in my experience. As a bare minimum, if you don't have an intimate understanding of the Activity and Fragment lifecycles and a full understanding of what needs to be on the UI thread when (and when different callbacks from the OS are/aren't on the UI thread) you are likely to create a terrible mess of an app that kinda sorta works on most devices, usually, but is broken in some fundamental ways you aren't aware of.

I don't personally know any day to day Android developers who haven't spent a considerable amount of time in the AOSP code trying to figure out exactly how some of these systems work because failing to understand them internally combined with lack of any sort of clear direction from the platform team (extremely open case of there being more than one way to do anything, which makes authoritative answers to the question "How should I do this?" nearly impossible without a long list of caveats) is the path to writing Android code which mostly works but has some fundamental mismatches with the operating system and becomes a complete mess to maintain.

Re: Android platform engineer on application architecture

#33

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

卡上就放假了SD卡分解开连锁店

Re: Android platform engineer on application architecture

#34

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

sldjfklsdflksdf离开的时间发来看上对方

Re: Android platform engineer on application architecture

#35
post #13
post #6

Earlier quoted context omitted.

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?

To be honest with you all my experiences with Services have made me never want to use them.

Re: Android platform engineer on application architecture

#36
post #6

Earlier quoted context omitted.

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…

> rotating the screen mid user sign-up shouldn't restart the HTTP call, etc This was the very first thing I struggled with when making my first (and to be honest, only) Android app. I was making an HTTP call in a background thread and when the screen rotated, the app crashed. Making this kind of basic functionality harder to program is such a big turn-off for the platform, and seriously lowers my confidence in the co…

I used to use AsyncTask way more, I now stick to other ways to doing background processing. What you have is pretty close to what I described as a "headless fragment", it's a pretty common (but ugly, imo) paradigm, from the looks of it you either made something similar to or followed this: http://www.androiddesignpatterns.com/2013/04/retaining-objec...

Nowadays I've pretty much drunk the RxJava kool-aid. For this kind of thing, I would make the HTTP method exist inside of an Observable which would be observed on a shared single instance Looper provided via Dagger.

Re: Android platform engineer on application architecture

#37

Unfortunately, the contents of this post are no surprise to any seasoned Android developer. It's very clear the Android engineers haven't given a lot of thought to how applications are to be developed. I'm all for them not enforcing one methodology over another. However, in order to build an Android application (following whatever pattern) we do need core building blocks that have been well thought through on how the…

You've hit the nail on the head. It's not the system engineer's job to develop a useful application framework for common use cases any more than it is a Linux kernel developer's job to do so. Still, it has to be somebody's job, and it's clear that it isn't anybody's job on the Android team. For example, there's a hacky HTTP client library built by the Google Play Android client team ( http://developer.android.com/tra…

You mean like the sets of support libraries which make multi-versioned Android development significantly easier and less time consuming?

I don't get the first-party library cargo cult that has developed on Android. What's wrong having the community develop libraries like on any other platform? There's a huge set of very good quality 3rd party Android libraries and even a great new language (Kotlin).

As a dev I'd be rather that Google focuses on developing quality core blocks which cannot be fixed by community. Sadly it seems that Google developers simply do not know how to build good APIs, even new ones like MediaCodec, BLE APIs, updated storage APIs and permissions are an utter hard to use mess.

Re: Android platform engineer on application architecture

#38

Unfortunately, the contents of this post are no surprise to any seasoned Android developer. It's very clear the Android engineers haven't given a lot of thought to how applications are to be developed. I'm all for them not enforcing one methodology over another. However, in order to build an Android application (following whatever pattern) we do need core building blocks that have been well thought through on how the…

I'd be curious to see how would Dianne respond to this, if you posted it on the Google+ page.

Re: Android platform engineer on application architecture

#39

Unfortunately, the contents of this post are no surprise to any seasoned Android developer. It's very clear the Android engineers haven't given a lot of thought to how applications are to be developed. I'm all for them not enforcing one methodology over another. However, in order to build an Android application (following whatever pattern) we do need core building blocks that have been well thought through on how the…

It's very clear the Android engineers haven't given a lot of thought to how applications are to be developed.

The best quote from the article that backs up what you just said: "Heck, I only know about MVC from school." Hmmmm...

Re: Android platform engineer on application architecture

#40

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

Dogfood, you say? I concur. I've only dabbled in Android development but (while a lot of things do feel well designed) there are some ridiculous design choices in there.

The one thing I've found really annoying is instability of the API as new versions are churned out. New features are added, deprecated almost immediately, and replaced with entirely different things (looking at you, NotificationListenerService!) It feels like they're thrashing trying to hit feature quotas or something.

Post reply on HN