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

71–80 of 124 posts

Re: Android platform engineer on application architecture

#71

Post by curt15 »

newjersey wrote: post #67
spbaar wrote: post #56

Earlier quoted context omitted.

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

Because you don't need to know. Permissions are sacred. If you don't have the permission, consider the capabilities aren't there and move on. How would you feel if Facebook or Instagram app refused to start if you didn't give it camera permission? Maybe I don't have a working camera in my Nexus 6.

The only real recourse against combat adversarial developers is to either trash the defective product in reviews or penalize the developers through other means. Holding functionality hostage in order to gain permissions should be instant grounds for rejection and/or further sanctions.

Re: Android platform engineer on application architecture

#72

Post by christop »

newjersey wrote: post #67
spbaar wrote: post #56

Earlier quoted context omitted.

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

Because you don't need to know. Permissions are sacred. If you don't have the permission, consider the capabilities aren't there and move on. How would you feel if Facebook or Instagram app refused to start if you didn't give it camera permission? Maybe I don't have a working camera in my Nexus 6.

Unfortunately, this is what Google's own app for the upcoming Google I/O conference does if you deny it access to your contacts at startup.

If you grant the permission only to deny it later, the app won't start again until you grant the permission again.

https://play.google.com/store/apps/details?id=com.google.sam...

Re: Android platform engineer on application architecture

#73

Post by christop »

jc4p wrote: post #35
jwatte wrote: post #13

Earlier quoted context omitted.

Have you tried putting all logic into a service, and only using fragments and activities foot display?

To be honest with you all my experiences with Services have made me never want to use them.

Binding services is pretty horrible, but I've very rarely had to do it. Using an IntentService is pretty straightforward and covers most use-cases of running something in the background.

Though RxJava has quite reduced the amount of interaction I do with Android core components like Services.

Re: Android platform engineer on application architecture

#74

Post by kodroid »

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…

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 in that direction, Im sure they would get lost in the woods somewhere and Id never see them again.

Re: Android platform engineer on application architecture

#75

Post by christop »

aphexairlines wrote: post #61
userbinator wrote: post #9

Earlier quoted context omitted.

Actually I'd attribute the difficulty to the culture of "Java-ism" that emphasises huge, complex, design-pattern-filled "extensible" architectures which happen to be extensible only in very specific ways. I wanted to take up casual writing of Android apps as a hobby, mainly because I think the little portable computer I keep in my pocket could become so much more useful, but the unusual API combined with the complexi…

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.

Re: Android platform engineer on application architecture

#76

Post by christop »

kevb wrote: post #20
zzalpha wrote: post #4

The fact that an Android platform engineer doesn't know of design patterns beyond MVC, and only knows that vaguely by reputation, explains why it's so difficult to build well designed apps for Android. Yes, technically the platform APIs don't "care" about what's going on in an app. But when the APIs are designed in such a way as to (inadvertantly) work against MVC or other design patterns, they make developer lives m…

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 (and frustrating) thing I've had to do in Android development.

At the time there were certainly zero code samples that correctly implemented a layout manager that worked in all cases. Indeed, I gave up on supporting various parts of the API. I don't imagine that has since changed.

Re: Android platform engineer on application architecture

#77

Post by fpgeek »

sievebrain wrote: post #66
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.…

That seems very unfair. 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. That meant Android was able to adapt to a range of screen sizes way earlier than Apple could. Every time Apple tried to introduce a new screen size or resolution it resulted in major pain across their en…

> The decision to support SD cards made a lot of sense back in the days when internal storage was a lot more limited.

And it still makes sense today. See: Android One (and most other handsets targeted at the developing world), manufacturers adding SD cards back after dropping them (most recently Samsung) and so on.

Personally speaking, despite loving my Nexus 7s in the past, I'm no longer interested in tablets without SD card slots. Even if it were good for nothing else, it's easy to fill up a 128 GB or larger SD card with video and music I want on hand.

Re: Android platform engineer on application architecture

#78

Post by saturn_vk »

Aaargh20318 wrote: post #68
sievebrain wrote: post #66

Earlier quoted context omitted.

That seems very unfair. 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. That meant Android was able to adapt to a range of screen sizes way earlier than Apple could. Every time Apple tried to introduce a new screen size or resolution it resulted in major pain across their en…

> 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?

Re: Android platform engineer on application architecture

#79

Post by anonymousab »

lern_too_spel wrote: post #27
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/tra…

It gets even worse when you want to download files and run into the sordid mountain of bugs that is the DownloadManager library.

Re: Android platform engineer on application architecture

#80

Post by saturn_vk »

AReallyGoodName wrote: post #8
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…

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 if I use only one activity.

Post reply on HN