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

51–60 of 124 posts

Re: Android platform engineer on application architecture

#51

Post by hidro »

Rails is built on top of Ruby language, designed to be opinionated, following MVC. You like it, you use it. You don't like it, try another framework.

Using the same analogy, Android is build on top of Java language, is 'opinionated': instead of designing with Model, View, Controller components, it's designed with 'unusual' components (as in not following any classic architectures) e.g. Activity, Service, ContentProvider. You like it, you use it. You don't like it, unfortunately you still have to use it. The real issue here is a lot of developers depend on Android framework, and many of them seem to struggle with the way it's structured, with no direct replacement (not taking into account hybrid frameworks here).

The way I see it, architecture is an opinionated topic. Sure classic architectures like MVC, MVP, MVVC are proven ones, but they serve as a guideline at most. There is no right or wrong if you follow this and not follow that. You are not happy with any of them, you make your own architecture/pattern. Hell it's opinionated, you are allowed to have an opinion here! If you think MVC or some other pattern is the right way to go, then the author has the right to think her design is the right way. It just keeps going on.

Re: Android platform engineer on application architecture

#52

Post by bschwindHN »

jc4p wrote: post #36
bschwindHN wrote: post #28

Earlier quoted context omitted.

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

Yep! I think that's the exact article I settled on after running into that problem. It's been 2.5 years since I wrote that code and I haven't done any significant Android programming since then. Next time I do, I"ll give RxJava a try.

Re: Android platform engineer on application architecture

#53

Post by Aaargh20318 »

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…

Not only didn't they give a lot of thought on how apps are to be developed, they made a bunch of really shortsighted design choices that continue to harm Android as a platform today.

First is the stupidity of Activities. The basic idea was that 1 screen = 1 activity and we can remove all non-active activities from memory and restart them as needed. This was clearly designed with an eye on memory constrained systems. Nowadays even the cheapest phones have shitloads of RAM but we're still stuck with this retarded model. Worse, now we have support for tablets and phones with big screens the 1 activity per screen no longer makes any sense anymore either.

Second, the decision to go with Java as a language. After they make us jump through ridiculous hoops to fit our applications into their stupid activity model just to save RAM, they go waste it by chosing a GC'd language, combined with the performance hit you take for the VM this this has really hurt Android app performance. In return we get an OS that can run in multiple CPU architectures, unfortunately no one runs it onanything other than ARM. The 0.01% of non-ARM devices can't run half the software anyway because they included ARM JNI components to work around the slowness of the VM.

But, I hear you say, you can supply JNI binaries for multiple architectures. Sure you can, if you can fit them in your APK, which you can't because your APK is limited to 50MB because it has to be downloaded to a temp partition before installing. This brings us to the thirds major fuckup: the file system on Android, or specifically the fact that there are several filesystems instead of just the one. But hey, at least now we get to support removable storage, which is both a PITA for developers, extremely confusing for end-users (why can't I install this app when I have gigabytes of free space on my SD card ?) and after all that trouble hardly any phone has removable storage anymore.

This seems to be the big problem with Android's development: a complete lack of vision by Google. They never designed for tomorrows hardware, instead they designed for last years hardware. Android is an OS built around hardware limitations that no longer existed by the time it gained momentum. It's like they were completely surprised by the speed at which mobile hardware evolved.

Re: Android platform engineer on application architecture

#54

Post by izacus »

Aaargh20318 wrote: post #53
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…

Not only didn't they give a lot of thought on how apps are to be developed, they made a bunch of really shortsighted design choices that continue to harm Android as a platform today. First is the stupidity of Activities. The basic idea was that 1 screen = 1 activity and we can remove all non-active activities from memory and restart them as needed. This was clearly designed with an eye on memory constrained systems.…

> n return we get an OS that can run in multiple CPU architectures, unfortunately no one runs it onanything other than ARM. The 0.01% of non-ARM devices can't run half the software anyway because they included ARM JNI components to work around the slowness of the VM.

These sentences are utter lies that have no basis in reality. Most applications do not use native code and even those that can mostly do have x86 binaries available. There's also significantly more than 0.1% of non-ARM devices, not to mention the fact that Android currently runs targeting three different ARM architectures.

Also having worked on a rather huge NDK project that barely hits 15MB of native code I seriously have to wonder how is 100MB limit (not 50MB as you say, since that was lifted) a problem code-wise. Resource-wise yes (and OBB system is kinda crap), but 50MB of compressed binary?!

Re: Android platform engineer on application architecture

#55

Post by konschubert »

Aaargh20318 wrote: post #53
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…

Not only didn't they give a lot of thought on how apps are to be developed, they made a bunch of really shortsighted design choices that continue to harm Android as a platform today. First is the stupidity of Activities. The basic idea was that 1 screen = 1 activity and we can remove all non-active activities from memory and restart them as needed. This was clearly designed with an eye on memory constrained systems.…

> First is the stupidity of Activities. The basic idea was that 1 screen = 1 activity and we can remove all non-active activities from memory and restart them as needed. This was clearly designed with an eye on memory constrained systems. Nowadays even the cheapest phones have shitloads of RAM but we're still stuck with this retarded model. Worse, now we have support for tablets and phones with big screens the 1 activity per screen no longer makes any sense anymore either.

Shouldn't fragments solve this?[0]

[0] https://developer.android.com/guide/components/fragments.htm...

Re: Android platform engineer on application architecture

#56

Post by spbaar »

izacus wrote: post #37
lern_too_spel wrote: post #27

Earlier quoted context omitted.

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

There is no excuse for how hard the permissions API is to use. Why can we not know if the user has "never show again " checked directly? It literally looks like the API and ui came from different proposals

Re: Android platform engineer on application architecture

#57

Post by izacus »

konschubert wrote: post #55
Aaargh20318 wrote: post #53

Earlier quoted context omitted.

Not only didn't they give a lot of thought on how apps are to be developed, they made a bunch of really shortsighted design choices that continue to harm Android as a platform today. First is the stupidity of Activities. The basic idea was that 1 screen = 1 activity and we can remove all non-active activities from memory and restart them as needed. This was clearly designed with an eye on memory constrained systems.…

> First is the stupidity of Activities. The basic idea was that 1 screen = 1 activity and we can remove all non-active activities from memory and restart them as needed. This was clearly designed with an eye on memory constrained systems. Nowadays even the cheapest phones have shitloads of RAM but we're still stuck with this retarded model. Worse, now we have support for tablets and phones with big screens the 1 acti…

Sadly fragment API is pretty terrible - it adds a heapload of complexity due to it's async nature (see https://i.stack.imgur.com/fRxIQ.png which is NOT an exagerration), it's very buggy and filled with hard to debug device-specific issues.

Most developers have opted for one of the more popular MVVM / MVP patters that help manage UIs without use of Fragments, but pain when designing tablet interfaces is still there.

Re: Android platform engineer on application architecture

#58

Post by thecupisblue »

konschubert wrote: post #55
Aaargh20318 wrote: post #53

Earlier quoted context omitted.

Not only didn't they give a lot of thought on how apps are to be developed, they made a bunch of really shortsighted design choices that continue to harm Android as a platform today. First is the stupidity of Activities. The basic idea was that 1 screen = 1 activity and we can remove all non-active activities from memory and restart them as needed. This was clearly designed with an eye on memory constrained systems.…

> First is the stupidity of Activities. The basic idea was that 1 screen = 1 activity and we can remove all non-active activities from memory and restart them as needed. This was clearly designed with an eye on memory constrained systems. Nowadays even the cheapest phones have shitloads of RAM but we're still stuck with this retarded model. Worse, now we have support for tablets and phones with big screens the 1 acti…

Uh, fragments introduced just more of the same problems. A fragment in an activity has an insane, confusing lifecycle, then if you nest them, you basically summon Cthulhu. The more experienced part of the Android dev community is slowly transitioning into using views instead of fragments.

Re: Android platform engineer on application architecture

#59

Post by mirsadm »

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…

Poorly designed APIs are a common theme with Android. Another example is the MediaCodec APIs for hardware video encoding. They are so awful compared to iOS that it makes me think twice about buying another Nexus phone. It is impossible to design a nice real time video application while targeting a significant number of Android devices.

Re: Android platform engineer on application architecture

#60

Post by Aaargh20318 »

izacus wrote: post #54
Aaargh20318 wrote: post #53

Earlier quoted context omitted.

Not only didn't they give a lot of thought on how apps are to be developed, they made a bunch of really shortsighted design choices that continue to harm Android as a platform today. First is the stupidity of Activities. The basic idea was that 1 screen = 1 activity and we can remove all non-active activities from memory and restart them as needed. This was clearly designed with an eye on memory constrained systems.…

> n return we get an OS that can run in multiple CPU architectures, unfortunately no one runs it onanything other than ARM. The 0.01% of non-ARM devices can't run half the software anyway because they included ARM JNI components to work around the slowness of the VM. These sentences are utter lies that have no basis in reality. Most applications do not use native code and even those that can mostly do have x86 binari…

> Also having worked on a rather huge NDK project that barely hits 15MB of native code I seriously have to wonder how is 100MB limit (not 50MB as you say, since that was lifted) a problem code-wise. Resource-wise yes (and OBB system is kinda crap), but 50MB of compressed binary?!

First of all, 50MB is the hard limit, in reality you should keep it under ~30-35MB or so. Your app will fail to install on MANY devices if you don't because while the play store may accept up to 100MB, the cache partition used by the Play Store app usually doesn't have that much space, especially on low-end devices. You start running into problems way before you hit 50MB.

As for OBB's, they are a PITA to use and you can't load things like layouts from OBB neither can you load other resources from them without rolling your own system for picking out the correct (mdpi/hdpi/xhdpi/etc) version.

The only thing you should use expansion files for is content, not anything needed for the application itself. And it's really easy to hit that limit then.

Post reply on HN