Earlier quoted context omitted.
> Android invested up front in more complex technology that would allow adaptation to future hardware devices. Most obviously, by using layout managers instead of pixel positioning like iOS did. Layout managers are complex technology now ? The layout managers Android uses are pretty much identical to what Java used in AWT and Swing and is trivial to implement. I know because I implemented just such a thing for a UI t…
Regarding GC, Windows Phone apps are garbage-collected, yet Windows Phones has a great reputation for smoothness and responsiveness on anemic hardware like the Nokia 520.
Android platform engineer on application architecture
91–100 of 124 posts
Re: Android platform engineer on application architecture
#92Android noob here. I've been teaching myself Android programming for the past couple of months and I've found it overall a messy and unpleasant experience for the reasons many of you have already mentioned. So much, in fact, that I'm looking for alternatives. So what's the best option? Kivy? Python is slow, adoption seems non-existent, not suitable for every kind of app Cordova? Web apps are slow, JavaScript sucks bi…
Web apps don't suck that much as long as each screen does one thing well. Xamarin is for getting a slightly more elegant language (since Java 1.8 isn't supported) into the mix while providing a reasonable cross-system platform. Clojure/Kotlin/Scala do require you to master Android first because they are built on top of it. Each provides is own abstraction, even if it's just a language.
In the end it's about trade offs and acceptance. Raw Android is like working in a better assembly. It's got decade's old abstractions. It's powerful, but annoying. For everything else, there's the complexity of working with the various abstractions over a system that does not want to be abstracted.
Re: Android platform engineer on application architecture
#93Earlier quoted context omitted.
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.
I work on a very popular app in Latin America. That means we get to experience every single edge case in the eco system. My favorite quirk has been that for some reason I will never understand when an app goes into a full screen ad it can make your main activity eligible for GC. That means that you don't get any of your Activity life cycle events. Just a lone finalize and your app is gone. Then when the video ad is d…
Also, I'd imagine video ads are also quite memory intensive, so if a low-RAM device is playing one I wouldn't be surprised if Android has to kill some processes (like your activity that was sent to the background) to make space.
Perhaps you should look into what these video ads are doing and what sort of resources they eat up?
Re: Android platform engineer on application architecture
#94Unfortunately, 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…
Doesn't contain a TextView, inherits. Ugh.
Re: Android platform engineer on application architecture
#95https://corner.squareup.com/2014/10/advocating-against-andro...
Also, if you are doing any substantial Android development, you are bound to run into many issues (say, for instance, it's horrible soft keyboard management system). Hackborn can be found on many of these issues trashing developers asking those questions.
https://groups.google.com/forum/#!topic/android-platform/Fyj...
Non productive vitriol is the norm for this person.
Re: Android platform engineer on application architecture
#96If 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 g…
Yes. I sometimes think we need to embrace an "Android-free Android programming" approach where we use builtin Android components as little as possible and better written 3rd party components and libraries for everything else.
Re: Android platform engineer on application architecture
#97Earlier quoted context omitted.
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 g…
I agree with your last two statements, but the idea the RxJava and Dagger make things _easier_ to understand for developers (I'm inferring this relates more to newcomers to Android as they are the once which have a hard time grokking this stuff) is a joke. RxJava and Dagger only increase ramp up time and the amount of stuff to learn, regardless of how useful they are. If someone came to me confused and I pointed them…
Re: Android platform engineer on application architecture
#98Unfortunately, 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…
My favorite one is Button, it inherits from... TextView. Doesn't contain a TextView, inherits. Ugh.
Re: Android platform engineer on application architecture
#99Earlier quoted context omitted.
There's a few issues with this though. Take various animations such as the one on the toolbar that some Google apps have (the arrow that spins into a hamburger and back again). Easy to do if you're just loading different fragments into a Framelayout, impossible to do with activities as you reload the entire toolbar on an activity change. It's a general problem in the Android world. Some things can only be done as an…
> There's a few issues with this though. Take various animations such as the one on the toolbar that some Google apps have (the arrow that spins into a hamburger and back again). Easy to do if you're just loading different fragments into a Framelayout, impossible to do with activities as you reload the entire toolbar on an activity change. I haven't even found an easy way to control the state of that animation, even…
Re: Android platform engineer on application architecture
#100Earlier 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…
IMHO, Fragments didn't simplify my work or make it more manageable. Fragments mostly added new weird things to remember, and, for all that complication, I don't seem to reuse them all that much.
Fragments have their own lifecycle events which are like those of an Activity, but not exactly. They also interact with the Activity lifecycle in ways that I found a bit confusing, personally.
To get access to your Fragment instances, you're supposed to rely on the FragmentManager (and/or FragmentManagerCompat, depending on what minimum version of Android you support), which puts you at arm's length from them, making life a bit awkward. Fragments also exist in another flavor, from the compat library, so that sometimes results in mismatched types which can be confusing.
Then you have to get used to the idea that you're only supposed to create trivial constructors for your Fragments.
If a Fragment needs to know something interesting, you're supposed to pass parameters to it, not through a constructor, but, with setArguments. That way the system can resupply those arguments if it has to destroy and recreate your Fragment on your behalf in certain circumstances. This could be better documented, IMHO.
But wait, there's also a lifecycle callback named "onViewStateRestored" which supplies a savedInstanceState Bundle to your Fragment which it can use to bring itself back to the desired state. This is more like what Activities do, kind of. But it doesn't seem to interact usefully with Activity state restoration, which I found counterintuitive.
And when I think about how smart these Android SDK programmers are (and I have no doubt that they are super bright people), I wonder why this is what they came up with. It makes me feel dumb. And if your goal is to create a product your customers will love, maybe you should avoid making them feel dumb.