Android platform engineer on application architecture • Hacker News Board

Re: Android platform engineer on application architecture

#121

Post by vorg » Mon, May 16, 2016, 9:24 PM UTC

HillaryBriss wrote: post #111

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

> how many devs really grok the Android gradle plugin and feel comfortable just writing tasks themselves without carefully copying/pasting

That plugin uses Apache Groovy for its syntax, though in reality only a tiny non-Turing Complete portion of Groovy's syntax is used in virtually every build script out there. The main difficulty with Gradle is really the complex API it exposes to Groovy, e.g. not knowing whether to use an = like in

    depos = {
      //stuff
    }

or

    depos {
      //stuff
    }

Re: Android platform engineer on application architecture

#122

Post by shade23 » Mon, May 16, 2016, 9:52 PM UTC

Tldr: that's how the system interacts, you are free to do what you want and just use the framework for system interactions if you need them.

I guess this is a late reply but I feel the need to add in here considering I began my career with Android devices and because of that have looked at everything from that perspective(I write code for web apps, analytics, devops too). What everyone seems to be focusing on is how broken the android platform is. But no one sees the main theme of the post being that your code is really not necessarily a part of the design. Take the entire Android environment , Android currently works on at least a million distinct devices which vary massively in configurations (I include tv/wear/auto and maybe upcoming platforms here too). This with a 6 month major release cycle (if you want to argue about the necessity of this, it's a another topic). You really cannot break everything in the next api level and neither can you make a simple framework for the comfort of the newer programmers or people from other environs. If you really want to get to the main bit of development, there are several starter packs which can help you in the same. This would also explain the sheer number of Android libraries available. this how the system works,not your app. And unless you are building a system app you are free to do what you want and interact with the system as it dictates, because more than the Android system is designed to cater to the end user. It's not a product for developers (I look at the ios development as a a product for devs and end users).

Android development is frustrating and I have had my fair share of pointless arguments on bugs which the Android team refuses to recognize. But when you go through the AOSP code you see how much of can be done with the system. The bitmap provider implementation for example is my go to code for whenever I have to perform intensive processing.

The new memory manager is also an interesting piece of code which Android devs should read. And all these were written while interacting with the same framework.

Re: Android platform engineer on application architecture

#123

Post by AReallyGoodName » Tue, May 17, 2016, 12:58 AM UTC

saturn_vk wrote: post #80

AReallyGoodName wrote: post #8

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

Well it's easy enough to transition into arrow and hamburger

ObjectAnimator arrowRotateAnim = ObjectAnimator.ofFloat(mDrawerArrowDrawable, "progress", 0.0f, 1.0f);

arrowRotateAnim.setDuration(Constant.NAV_ARROW_TIME);

arrowRotateAnim.start();

and vice versa on progress where mArrowDrawable is a DrawerArrowDrawable object. I set NAV_ARROW_TIME to 300 and it seems the same as what google has.

Re: Android platform engineer on application architecture

#124

Post by Aaargh20318 » Tue, May 17, 2016, 9:35 AM UTC

curt15 wrote: post #102

Aaargh20318 wrote: post #84

Earlier quoted context omitted.

Intents don't work because they were designed to be too flexible. Say I want to be able to share something on social media from my app, seems like the exact use-case Intents were made for. So I create an intent of type ACTION_SEND because that's the only one that sorta does what I need and now my user gets a HUGE list of options, half of which are irrelevant and/or don't work at all. I cannot limit the Intent to 'sha…

From a user's perspective, I consider Intents the strongest feature of Android as it let the system make no assumptions about my preferred apps. If it is important to closely control the user's flow, as in your second example, then you're probably better off hardcoding a list of other apps that your app can interact with using explicit intents like how sharing works on iOS. General intents like ACTION_SEND are design…

> From a user's perspective, I consider Intents the strongest feature of Android as it let the system make no assumptions about my preferred apps.

Half of the time the apps listed make no sense for an intent. There needs to be a mechanism for more fine-grained categories. For example, it should be possible to create a 'social media' intent for sharing on social media. It makes no sense to include Dropbox or Google Drive in that list.

And while it may be a nice feature for power-users, it's a horrible feature for the average user. Why would the user want to be presented options that don't even work ?