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

111–120 of 124 posts

Re: Android platform engineer on application architecture

#111

Post by HillaryBriss »

chickenbane wrote: post #106

One of the biggest challenges for building on Android is its complexity, and the team must successfully integrate with a lot of surface area conceptually (the fundamental building blocks Dianne explains is just the start). This unusually negative comment thread (for HN, I think) is probably illustrative of how frustrating Android development can be. On the other hand, it's been clear to me that Google is investing he…

I agree that moving to AS+Gradle was a net improvement (even though Gradle is not always so quick) because it let us exactly reproduce the individual developer's build on the CI server, as you say.

OTOH, I wonder how many devs really grok the Android gradle plugin and feel comfortable just writing tasks themselves without carefully copying/pasting/modifying some magical incantation from somewhere.

I feel like the verdict on Instant Run is still out though. We need to get used to the complexity of IR's choices to restart the Activity or stop the entire app and reinstall the apk etc and gain solid confidence that we can just trust IR to truly reproduce our code changes in its special, optimized way.

Re: Android platform engineer on application architecture

#112

Post by m_fayer »

grendozy wrote: post #88

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

I spend a lot of time in Xamarin so I'm biased in that direction, here's why I think it might bring more of an advantage than you think.

C# is IMO a significant step up from whatever Java is running in Android. It's a much richer language as far as syntactic sugar (see properties, type inference), and fundamentals - optional dynamic typing, better generics than Java, and gotcha-free lambdas. The biggest advantage though is async/await, which puts c# miles ahead of Java when it comes to concurrency, something that's oh-so-important in mobile land. And of course Xamarin opens up F#, which is a whole different story.

Also, C# opens up some frameworks that will give you significantly more modern techniques than what can be easily done in vanilla native Android dev. Take a look at ReactiveUI and MvvmCross, and a recent favorite - https://github.com/RolandPheasant/DynamicData

Now that it's free and doesn't require Windows, I definitely think anyone trying to build significant native Android apps should at least take a look.

Re: Android platform engineer on application architecture

#113

Post by HillaryBriss »

christop wrote: post #75
aphexairlines wrote: post #61

Earlier quoted context omitted.

26min into the 2014 Google I/O Android fireside chat: https://youtu.be/K3meJyiYWFw?t=26m Q: So I was wondering if you guys at any point considered the support -- the official support -- of the Scala programming language. I'm asking this question especially now that we all saw that Apple released Swift after 4 years of work. And I think that Swift allows for things for iOS developers that we can't do in Java with the…

I gave up on watching those Android Fireside chat sessions because of the horrible jokey way in which so many valid concerns end up getting dismissed, every time.

It's been interesting to see the emergence of the Android Developer-Advocate-Comedian in Fireside chats and at Google I/O sessions.

Maybe some of these folks are bored with their jobs, or just tired of trying to do the impossible: convince the developer community that the Android SDK is a great and well designed thing that makes creating great, robust, secure apps easier and faster.

"We know we can't give them world-class, visionary, insanely great engineering, but we can try to give them something entertaining."

Bread and circuses ...

Re: Android platform engineer on application architecture

#114

Post by HillaryBriss »

christop wrote: post #76
kevb wrote: post #20

Earlier quoted context omitted.

She mentions that we should think of the android apis as a "system framework", and I remember a different Google Android engineer saying something similar about the RecyclerView, that right now the focus is on making the technical functionality and API solid and stable, even if not so developer friendly. Someone else, or future Google, can make a more developer friendly API on top of the awkward RecyclerView API. The…

Unfortunately, 18 months since its release, I'm not sure if anybody (certainly not Google) has come up with some nicer abstractions on top of RecyclerView. It works well for basic lists, but out of the box it comes with very little — not even a click listener for items in the view. Having written a custom LayoutManager for RecyclerView a year ago (and then a matching ItemDecorator), it was probably the most difficult…

Probably because the RecyclerView is so frikkin' complicated, as Chet Haase and Yigit Boyar explain here: https://youtu.be/imsr8NrIAMs

After watching this for five or ten minutes, I gave up. It didn't seem like it offered a good return on time invested.

Re: Android platform engineer on application architecture

#115

Post by bitmapbrother »

curt15 wrote: post #70
Aaargh20318 wrote: post #68

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.

No it doesn't. One look at the Windows Phone reddit will tell you otherwise. Windows phone jank is masked by superfluous animations, capped scrolling speeds and other tricks to hide it. Unfortunately, those tricks don't do the job.

Re: Android platform engineer on application architecture

#116

Post by st3v3r »

saturn_vk wrote: post #78
Aaargh20318 wrote: post #68

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…

What's wrong with intents now?

Intents are a great idea for communicating between apps. They are complete and utter garbage for communication within the app between screens.

Re: Android platform engineer on application architecture

#117

Post by st3v3r »

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…

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

You mean the ones that seem to change between Android versions, and get weird bugs between versions?

"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)."

Because those can't be counted on not to break between versions of Android.

Re: Android platform engineer on application architecture

#118

Post by st3v3r »

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 intent system is great for communicating between apps, or just saying, "I need to do X, but I don't care what provides it." It is an absolute abomination for communicating within the app, though. There is absolutely no reason why I should have to go through the trouble of serializing an object just to pass it to the next screen. (Yes, I have read the technical reasons why not. I consider that a huge fucking design flaw)

Re: Android platform engineer on application architecture

#119

Post by st3v3r »

jmfayard wrote: post #49
petra wrote: post #32

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

Because I shouldn't have to go somewhere else to have a sane framework for writing Android apps.

Re: Android platform engineer on application architecture

#120

Post by ffiw »

ocdtrekkie wrote: post #85
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.

I met her once at Google I/O, and it wasn't a pleasant interaction. I was lamenting how the recent (at the time) switch from USB Mass Storage to MTP made file transfers to and from computers very iffy. (And it's still pretty iffy today.) I was asking why the change was made, and if there was a chance at the option for it being restored, as devices used to allow both. A lot of times, files on the Android device don't…

I see Android guys lack commonsense and I am not surprised. How did they think you are pirating apk's after attending I/O event that costs fortune to enter ?
Post reply on HN