If this is so terrible, why isn't there some Java framework on top of this that's designed to make sense for developers?
I hear Oracle has something available for that.
Android platform engineer on application architecture
41–50 of 124 posts
Re: Android platform engineer on application architecture
#42Recently 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…
You might consider this book: http://www.amazon.com/Android-Programming-Ranch-Guide-Guides... I've read some of their books before, and they have good understanding (and presentation) of architecture.
Re: Android platform engineer on application architecture
#43Unfortunately, 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…
Android 4.4 and later uses the core of OkHttp underneath HttpUrlConnection, which is the library you should be using. If you want fancier features, or don't like using AsyncTask everywhere, just use the full OkHttp from Square and you'll get those.
Volley is just a small abstraction atop HttpUrlConnection, so I'm not sure why you consider it so hacky. It also is available on JCenter, so just compile it into your project using Gradle: "com.android.volley:volley:1.0.0". You're entirely wrong about having to copy the source into your project.
Re: Android platform engineer on application architecture
#44Unfortunately, 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…
One could say the same thing for Win32 API. That's why you had Microsoft MFC, Borland VCL, wxWidgets, etc. running on top of it and making it more user friendly. The real problem seems to be that Android API is moving so fast, that it's risky to build such tools. The other problem is that these days most developers expect to get it for free, so there's no financial incentive to build it.
Re: Android platform engineer on application architecture
#45Unfortunately, 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.
You're welcome to post a link here. It does seem like something the Android engineering team should hear (even if they have heard it before).
Nonetheless, it's worth adding that my comment was written for the HN community. I'd usually be a bit more tactful (sic polite) when corresponding with someone directly. Also, my critique applies to the Android engineering team in general; singling Dianne out is probably a bit harsh.
Re: Android platform engineer on application architecture
#46They 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.
What would staying with the main entry point solve, aside from being familiar?
Your application would still have to directly manage binder callbacks and register for lifecycle events. Re-using the old Java/POSIX entry point actually increases the complexity significantly.
Re: Android platform engineer on application architecture
#47One 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.
What a platform engineer needs to do is to listen user's feedback early and often in order to improve the API. An API is a product,and like every products there should be usability concerns. I wouldn't say Android SDK is bad, it's just so convoluted it doesn't feel like it was written in this century.
It's like someone wanted to impose something regardless of its usability, a lot of design decisions seem to have been taken unilaterally because of one engineer's ego.
Re: Android platform engineer on application architecture
#48Earlier 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…
Likewise. Pulling the rug from your entire application because the user changed the device's orientation is a braindead action on the OS's part, and the justification (that it 'makes it easier for applications to handle orientation shifts') is pure bullshit. You can relay a layout without tearing down the associated Activity.
I think the real reason they did it this way is to make developers deal more directly with Android's larger philosophical choice of "the system can start and stop any activity at any time". Which stinks, IMO - it's fine if you're displaying a property page or an image from a gallery but is a terribly hostile environment to any process which interacts with the (stateful) real world and necessarily must also be stateful.
Re: Android platform engineer on application architecture
#49If this is so terrible, why isn't there some Java framework on top of this that's designed to make sense for developers?
They do exist.
Check out rxjava from netflix, dagger and butterknife and okhttp and retrofit and picasso (and and....) from square, MVP libraries, kotlin and anko from jetbrains
What is truly holding back many developers is the above cargo cult that the path mentionned in android.developer.com is always the right one.
There have been some harsh comments on Dianne Hackborn, but I find that she is actually doing us a great service here by dissiping this myth. I find she does a great job at explaining what is the scope they really care about, and the one where you are free to discover better alternative that do not have the "Google" label on it.
Re: Android platform engineer on application architecture
#50I think it's fine for the Android team to take this approach like so many framework authors before them. I think the problem is that Android developers are seeking patterns and prescriptivist documentation because that's what many other platforms offer these days.
On iOS, the message has always been clear: "Use MVC, delegates & data sources, storyboards, etc. /We use them internally/ and you should too. Don't go re-invent UIViewController!"