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

21–30 of 124 posts

Re: Android platform engineer on application architecture

#21

Post by EddieRingle »

vowelless wrote: post #18

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

Seems many people are missing the overall point of the post: The APIs Android provides that are listed here are intended to be used as the glue between your application and the rest of the system. However you want to build your application from that point on is up to you.

In particular, Android Activities aren't simply a main() function because they are designed from a multitasking standpoint; users are going to be going in and out of apps, changing the state of the device (such as rotating the device), etc. In other application environments, you might register callbacks to fire when the window is hidden or gets resized. In Android those callbacks already exist and are set in stone to encourage apps to behave as a good citizen on a potentially resource-constrained mobile device. But as the post details, you don't have to do anything beyond properly managing heavy resources (like camera access) and saving and restoring state at the appropriate points if you don't want to.

Re: Android platform engineer on application architecture

#23

Post by EddieRingle »

kabdib wrote: post #22

You need only look as far as the large collection of flags involving the Intent object to realize how badly things went wrong.

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?

Re: Android platform engineer on application architecture

#24

Post by Benjamin_Dobell »

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 they will be used.

In general performing Async tasks (in particular networking) is excruciatingly convoluted on Android - well, at least to get it right. Many inexperienced Android developers simply get this wrong, and quite frankly I can't blame them. Such a common task should be trivial to perform and not require hours of background reading.

The issue largely comes down to the fact the "system framework" has been designed to be simple (supposedly[1]) for system framework maintainers, and not developers writing applications. Destroying and recreating activities (so you can load different resources) may be simpler from AOSP's perspective, but it's not at all logical from the perspective of an application. Sure, there are several ways to work around this, but they're all stupidly convoluted.

Frameworks should be written for consumers, not maintainers.

[1] Okay, the system frameworks definitely aren't actually well designed / simple to work with for framework maintainers either, that was just the (missed) goal. If you want to see world's worst state machine (a stupid amount of booleans), check-out: http://stackoverflow.com/questions/17847775/nested-fragments...

Re: Android platform engineer on application architecture

#25

Post by Benjamin_Dobell »

EddieRingle wrote: post #23
kabdib wrote: post #22

You need only look as far as the large collection of flags involving the Intent object to realize how badly things went wrong.

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.

Re: Android platform engineer on application architecture

#26

Post by bigtones »

Benjamin_Dobell wrote: post #24

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…

Yes, Dianne Hackborn was one of the main proponents and designers of the fragment system lamented in your StackOverflow question referenced: http://android-developers.blogspot.com/2011/02/android-30-fr...

Re: Android platform engineer on application architecture

#27

Post by lern_too_spel »

Benjamin_Dobell wrote: post #24

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/training/volley/index.html) that is promoted for general use for some silly reason, and to use it, you're supposed to copy the library's source code into your project. Pure amateur hour. There should be a team within Android building well-thought-out, properly versioned, and sanely distributed libraries to simplify Android application development. There should be, but there isn't.

Re: Android platform engineer on application architecture

#28

Post by bschwindHN »

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…

> 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 correctness of what I've written.

I ended up writing this gross code (https://github.com/bschwind/skritter-android/commit/6fdffab1...). That's probably not the recommended way to solve it now, or maybe it is. I don't know because everyone seems to have their own special solution to the problem, and we're lacking solid, idiomatic solutions to basic problems an app developer faces.

For the small Android work I do now, I just stay in my own little NDK world.

Edit: It also seems I was pretty frustrated with the android API at the time, lots of colorful print statements :)

Re: Android platform engineer on application architecture

#29

Post by logcat »

johndifool wrote: post #12

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.

Shame. Shame. Shame.

Re: Android platform engineer on application architecture

#30

Post by tuukkah »

Benjamin_Dobell wrote: post #25
EddieRingle wrote: post #23

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.

The user interface concept might be called UI subroutines, along the lines of UI continuations of this paper from an MIT research project in 2003: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.10.2...
Post reply on HN