Android platform engineer on application architecture
plus.google.com
plus.google.com
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 they will be used.
In general performing Async tasks (in particular networking) is excruciatingly convoluted on Android - well, at least to get it right. Many inexperienced Android developers simply get this wrong, and quite frankly I can't blame them. Such a common task should be trivial to perform and not require hours of background reading.
The issue largely comes down to the fact the "system framework" has been designed to be simple (supposedly[1]) for system framework maintainers, and not developers writing applications. Destroying and recreating activities (so you can load different resources) may be simpler from AOSP's perspective, but it's not at all logical from the perspective of an application. Sure, there are several ways to work around this, but they're all stupidly convoluted.
Frameworks should be written for consumers, not maintainers.
[1] Okay, the system frameworks definitely aren't actually well designed / simple to work with for framework maintainers either, that was just the (missed) goal. If you want to see world's worst state machine (a stupid amount of booleans), check-out: http://stackoverflow.com/questions/17847775/nested-fragments...
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 rather that Google focuses on developing quality core blocks which cannot be fixed by community. Sadly it seems that Google developers simply do not know how to build good APIs, even new ones like MediaCodec, BLE APIs, updated storage APIs and permissions are an utter hard to use mess.
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.
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...
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.
Volley is just a small abstraction atop HttpUrlConnection, so I'm not sure why you consider it so hacky. It also is available on JCenter, so just compile it into your project using Gradle: "com.android.volley:volley:1.0.0". You're entirely wrong about having to copy the source into your project.
Nonetheless, it's worth adding that my comment was written for the HN community. I'd usually be a bit more tactful (sic polite) when corresponding with someone directly. Also, my critique applies to the Android engineering team in general; singling Dianne out is probably a bit harsh.
The best quote from the article that backs up what you just said: "Heck, I only know about MVC from school." Hmmmm...
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.
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?!
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.
Shouldn't fragments solve this?[0]
[0] https://developer.android.com/guide/components/fragments.htm...
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.
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.
</rant>
The conclusion is that it almost doesn't matter what language you choose for a platform if you have enough man-power and resources and you can force developers to use it. :)
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 entire app ecosystem, something many Android apps avoided.
Phones are still memory constrained. Yes they have "shitloads" of RAM compared to previous devices but they still don't have a swap file of any kind. The activity model allows phones to have an apparently infinite number of apps open, without the UI ever stalling due to hitting a paging storm like desktop apps can. Simply increasing the amount of RAM doesn't solve the problems the activity model was designed to solve, and it's worth noting that when Apple introduced multi-tasking into iOS, they ended up with something quite similar to activities.
The choice of Java had complex effects on memory usage. Whilst Java heaps can be kind of piggy, a lot of memory usage comes from loaded code, and bytecode is a lot more compact than native code is. That's why they're reintroducing JIT compilation in Android N - having moved to fully AOT when ART was introduced they are now going back again to reduce memory pressure.
The decision to support SD cards made a lot of sense back in the days when internal storage was a lot more limited.
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 toolkit I made for J2ME back in the day. Desktop apps have been doing it for decades. iOS by contrast uses a much more complicated system (not saying it's better, just more complex).
Also, I vastly prefer iOS's sytem with just a handful of resolutions so you can fine-tune your designs to the exact screen dimensions. In practice I've found it very hard to explain Android's layout mechanisms to designers and to get good designs from them that scale well. Most designers I know prefer being able to make a pixel-perfect design like you can on iOS. Sure it works fine for business-style apps but if you want to make something spiffy, you're fucked on Android.
> when Apple introduced multi-tasking into iOS, they ended up with something quite similar to activities.
iOS has nothing even remotely resembling activities. Background apps can be suspended and possibly killed, but that's as far as the parallelels go. Don't even get me started on the insane idea of Intents (sounds like a great concept but horrible in practice and badly implemented too).
> The activity model allows phones to have an apparently infinite number of apps open, without the UI ever stalling due to hitting a paging storm like desktop apps can.
Then why is this not an issue at all on iOS. In fact, my 6S pretty much never kills background apps and even when it does that does not affect foreground performance. And if they were so concerned about the UI stalling, they should have stayed away from Java. It has improved a little bit but especially in the early days the GC would regularly freeze the entire JVM for 100+ ms. Try hitting 60fps like that.
> The choice of Java had complex effects on memory usage. Whilst Java heaps can be kind of piggy, a lot of memory usage comes from loaded code, and bytecode is a lot more compact than native code is.
Wut ? Loaded code is a completely negligible part of an apps memory usage. And again, not an issue on iOS. In fact memory is far more constrained on Android than on iOS even when Android devices have more physical RAM. Android severely limits the amount of RAM an application can use (the heap size limit). I've never run into problems with RAM usage on iOS and regularly on Android. On a 1GB iPhone you can easily use 700-800MB RAM for your app if you wanted, while you're lucky if you can get 192MB on a 3GB Android phone.
Furthermore, garbage collected languages use about 3 times as much RAM as a non-GC language for similar performance (tradeoff between how often the GC runs vs performance) negating any and all gains of a smaller code size. There is also this thing called the ARM Thumb instruction set which results in smaller binaries if that really is an issue.
> The decision to support SD cards made a lot of sense back in the days when internal storage was a lot more limited.
And this goes to the heart of my criticism: yes internal storage was a lot more limited back then. Both Google and Apple knew this. They both also knew (or should have) that internal storage was going to improve a LOT and very quickly at that. This is the point I'm trying to make: Google develops for yesterdays and todays constraints while they should be developing for tomorrows. In fact, Google should look farther into the future than Apple does because it takes so long for their software to reach consumers, it's taking 2-3 years for any new Android release to gain any significant market share. Android N should be built with 2019's phone hardware in mind, instead it's being built for 2015 hardware.
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 'share on social media' because it has no such category. You cannot filter the list yourself because that would mean having to know the package name of every possible social media app.
Worse, even the well known social media apps do not work. No one agrees on what fields should mean what and how to interpret them. For example: you can create an intent that prefills the text and attaches a photo and it will work when you use it to open Twitter but not Facebook, facebook ignores the pre-filled text. Another app will ignore the photo, etc. you can't test every possible target app so the whole mechanism is unusable if you want to deliver a good UX. In the end you give up and just add the Facebook and Twitter SDK's to your app.
Another example: we have an app that deals with privacy-sensitive information. We want the user to be able to e-mail this to him/herself but nothing else. Or rather: we don't want our users to accidentally share this information on social media. You cannot create an Intent that will only open the users preferred email client and excludes everything else.
Intents are pretty much worthless if you care about a good UX at all.
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 ?
I'm using my phone much less for certain activities. For instance, I share to instagram less because it's not in thr iOS share drawer for some reason.
I think the arguments leveled against Android elsewhere in this thread are solid...maybe even the UX one against intents. I certainly don't suggest an Android to anyone in my parents' generation, except my former-programmer uncle.
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.
Welcome to Worse is Better. This is literally what Unix went against. People used to write that way before; now it has to be easiest for platform developer/maintainer.
Doesn't contain a TextView, inherits. Ugh.
My main quibble with Android is that since everything is tied to the activities it is impossible to build an MVC style app. You are better off using the NDK or an engine. Then you can build your software correctly.
> 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.
Sadly, I have a half dozen different ways activities have found to explode themselves. It makes me sad!
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?
This is especially true for Android platform team, to be honest.
The one thing I've found really annoying is instability of the API as new versions are churned out. New features are added, deprecated almost immediately, and replaced with entirely different things (looking at you, NotificationListenerService!) It feels like they're thrashing trying to hit feature quotas or something.
It's like someone wanted to impose something regardless of its usability, a lot of design decisions seem to have been taken unilaterally because of one engineer's ego.
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 fragment would initiate with a reference to the parent activity as a context, and would be responsible for view-centric things like displaying content and adding event handlers, which would more often than not use the context reference to call some remote API.
I suppose you could think of it in terms of Model/Controller/View-Controller but I'm sure there is a more correct model for thinking about it (and it probably is more straight MVC anyways).
The problem I've found with Android is that Google has created almost it's own language when it comes to Android app architecture, which creates a lot of confusion, especially for developers who just assume that all frameworks use the MVC concept (laugh if you will, but this is a thing).
Even though google is quite behind when it comes to the app market, I think there is still time for them to come out with a new set of documentation which outlines the "correct" (the "Google-blessed" one at least) structure for Android apps so that we as a development community can start moving away from the "everything-and-the-kitchen-sink goes in the current activity" style of Android development.
This works well, and I'm at the point where I develop it without thought while creating new apps, but I've been playing with a less constrained DI flow instead using Dagger 2.
The more business logic and multiple copies of shared UI elements in different Fragments are directly connected to their parent Activity, the harder it is to re-arrange and re-use them. I've been working on migrating all core elements of our application into a shared library project, and that would've been impossible with a closely tied codebase.
Though RxJava has quite reduced the amount of interaction I do with Android core components like Services.
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 correctness of what I've written.
I ended up writing this gross code (https://github.com/bschwind/skritter-android/commit/6fdffab1...). That's probably not the recommended way to solve it now, or maybe it is. I don't know because everyone seems to have their own special solution to the problem, and we're lacking solid, idiomatic solutions to basic problems an app developer faces.
For the small Android work I do now, I just stay in my own little NDK world.
Edit: It also seems I was pretty frustrated with the android API at the time, lots of colorful print statements :)
Nowadays I've pretty much drunk the RxJava kool-aid. For this kind of thing, I would make the HTTP method exist inside of an Observable which would be observed on a shared single instance Looper provided via Dagger.
I think the real reason they did it this way is to make developers deal more directly with Android's larger philosophical choice of "the system can start and stop any activity at any time". Which stinks, IMO - it's fine if you're displaying a property page or an image from a gallery but is a terribly hostile environment to any process which interacts with the (stateful) real world and necessarily must also be stateful.
It's a general problem in the Android world. Some things can only be done as an activity whilst others as fragments.
In fact this is a problem even on Googles own apps. Right now if i tap things in the nav panel of the Gmail app it's a crap shoot whether i open a fragment or activity. Things like inbox/sent are loaded as fragments. Things like settings are loaded as activities with a completely different loading in animation. Help is different again. Lots of different ways of loading in a view all coming from options in the same menu. It's pretty fucked up form a UI perspective.
I haven't even found an easy way to control the state of that animation, even if I use only one activity.
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.
Let's say it all together: Implementation inheritance is a mistake, and interface based design is a clearer option.
Plenty of examples on developer.android.com use Activities, Services, BroadcastReceivers for things that go beyond what Dianne Hackborn is recommending here.
It's like the Android SDK team want to have their cake and eat it too:
"We've built a tremendously powerful and useful SDK. It really helps you build great apps quickly and easily."
vs.
"Oh, and, by the way, be careful not to misuse our main components. They were never designed to help you build great apps quickly and easily."
I cannot seem to reconcile these two statements:
> Should you use MVC? Or MVP? Or MVVM? I have no idea. Heck, I only know about MVC from school and had to do a Google search to find other options to put here.
And
> In Android, however, we explicitly decided we were not going to have a main() function, because we needed to give the platform more control over how an app runs.
So this person claims to not know or care about design patterns; but then explicitly enforcing a design pattern?
She does say:
> Android could feel like it has strong opinions on how apps should be written. With its Java language APIs and fairly high-level concepts, it can look like a typical application framework that is there to say how applications should be doing their work. But for the most part, it is not.
But after reading through the post, it does seem like a particular set of design patterns is being propagated.
In particular, Android Activities aren't simply a main() function because they are designed from a multitasking standpoint; users are going to be going in and out of apps, changing the state of the device (such as rotating the device), etc. In other application environments, you might register callbacks to fire when the window is hidden or gets resized. In Android those callbacks already exist and are set in stone to encourage apps to behave as a good citizen on a potentially resource-constrained mobile device. But as the post details, you don't have to do anything beyond properly managing heavy resources (like camera access) and saving and restoring state at the appropriate points if you don't want to.
Could you perhaps explain how you would've designed it?
Intents are great in concept and they work out well for users, but the interface/API for using them to do anything can quickly become painful if you go even a step off the beaten path of "perform this operation with these parameters".
A common recurring theme with Android (and this applies to all the major bits -- Activities, Fragments, Services, etc) is that you'll easily hang yourself if you don't have a really clear picture of how they actually work but you attempt to use them. Android almost completely fails, IMO, when it comes to the concept of "keep the easy things easy". There's a huge upfront cost to understanding the major components before you can start really using them at all safely, in my experience. As a bare minimum, if you don't have an intimate understanding of the Activity and Fragment lifecycles and a full understanding of what needs to be on the UI thread when (and when different callbacks from the OS are/aren't on the UI thread) you are likely to create a terrible mess of an app that kinda sorta works on most devices, usually, but is broken in some fundamental ways you aren't aware of.
I don't personally know any day to day Android developers who haven't spent a considerable amount of time in the AOSP code trying to figure out exactly how some of these systems work because failing to understand them internally combined with lack of any sort of clear direction from the platform team (extremely open case of there being more than one way to do anything, which makes authoritative answers to the question "How should I do this?" nearly impossible without a long list of caveats) is the path to writing Android code which mostly works but has some fundamental mismatches with the operating system and becomes a complete mess to maintain.
https://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.
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 big time
Qt? Google discourages use of the NDK for developing apps, can't figure out anything from their crappy website
Xamarin? C# doesn't look like a significant step up from Java, from Microsoft
Delphi? Proprietary, Windows-only and costly
Clojure/Kotlin/Scala? It seems you need to be a master Android developer to use them, still doesn't get you out of the horrible Android architecture.
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.
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.
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 great service here by dissiping this myth. I find she does a great job at explaining what is the scope they really care about, and the one where you are free to discover better alternative that do not have the "Google" label on it.
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.
p.s. If you know such book I would be grateful .
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.
You always have the option of falling back to OpenGL-rendered widgets and using a framework with MVC if you want to. Qt supports this, for instance.
On the other hand, it's been clear to me that Google is investing heavily in making Android an easier platform to develop for.
First, the tooling: Moving to Gradle for the build system was a huge improvement. Making a repeatable, extensible build is the vital with teams moving towards the DevOps world with CI/CD. Android Studio has also been a welcome change; all of the separate components of the build being integrated together makes for a much better development experience. The best example of this is Instant Run, which is a great accomplishment for the tooling team.
The Support Libraries are also a solid investment for implementing good patterns - particularly patterns that can be tricky to implement yourself like the separately sliding appbars. Getting more developers to adopt the support libraries also allows more compatibility, since Google can release the fixes independently from platforms.
YouTube has also been a great resource for Android developers as Google has been constantly releasing content about how to build better apps. Jo and Ian are really great.
Anyway, I would watch this space. It might be a coincidence that Dianne made this post, or the most recent videos ("concurrent tasks with multiple documents" and "tasks and back stack", respectively) were also about basic Android features. Maybe Googlers are reflecting on what Android is due to the current news of Oracle v Google. Or maybe it's because IO is this week. I'll be watching!
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.
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
}
depos {
//stuff
}On iOS, the message has always been clear: "Use MVC, delegates & data sources, storyboards, etc. /We use them internally/ and you should too. Don't go re-invent UIViewController!"
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.
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.
A lot of times, files on the Android device don't show up properly in Windows Explorer. She asked what I was doing, and I said copying APK files. (I regularly used to backup APKs so I could revert software updates which degraded the experience.)
She immediately stated that they "didn't support piracy" and walked off. As if the process of sideloading APKs or transferring them to and from a PC was somehow automatically illicit activity, rather than... something a lot of developers probably do regularly.
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 more difficult. And you can expect that to happen if your platform engineers aren't familiar with these concepts.
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 complexity and general baroqueness of the architecture was a big turn-off. I don't get the whole "design patterns" thing either, but I do have extensive experience with writing Win32 apps, and a little bit of X (which is not all that different.)
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 Android SDK. So my question was: have you ever thought about it before -- the release of Swift? Have you thought about it after that? Is there any plan?
Android answer 1: Well, so, I like Cocoa, but Objective-C is based on C, which is 40 years old, so I think Apple sort of had to, like, update it a bit. Umm, so, yeah [laugh], I don't know. Scala -- I don't know. Anyone want to take that? [Android team laughs]
Android answer 2: [loudly] No. [room laughs, claps] Alright, seriously, it's -- Java is the programming language for Android. I don't really think there's a lot of benefit to -- the entire framework is built around the Java programming language and I don't really -- I don't think there's much benefit for us to try to support another whole -- another different language.
Person from answer 1: What about Swift? [room laughs]
Person from answer 2: [jokingly] I'll think about it.
Person from answer 1: [mockingly] It's got optional semi-colons.
Person from answer 2: You have the NDK so you can throw something there. But the NDK -- it doesn't have access to the framework, and that's kind of the challenge. If you want to do a different language, if you want to have it as a first-class language equivalent to the current framework you've got to have either a whole new framework or some bindings to it, which is going to make it a really bad experience because it's going to be Java and this other language.
Q: I want to work with Scala because Scala is compiled to the JVM, so it can run on Android. So there are currently ways to do that -- to work with Scala -- but it's using third-party libraries. So you have classes -- that's what I meant by people to wrap their Java classes, but then it becomes tricky to integrate that cleanly with Android Studio. That also evolves quickly. I'm not sure if it's as complicated as creating a whole new language like Apple did, but my question was just if you guys were considering any...
Android answer 3: From the tool perspective, probably later this year or early next year, there are some changes going on inside Gradle right now that will make things easier to you to just have a module that's originally written in Scala that you compile down to bytecode and then we can just dex that and package that with your application. But it's not going to help you access the activity API through Scala code. It would be -- if you have some code that -- your business logic or whatever that you want to write in Scala because it's easier for you, you should be able to do that. Because as you said, it's compatible. It just generates regular bytecode and then just dexing it. But that's very different from saying "you can code Android in Java" where you have access to all the framework APIs.
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 ...
It already seems to be the goal to make all Java apps work on Native Client on Chrome OS. But once that's done, couldn't they just allow anyone to write apps in Go, Rust, Python, etc for Native Client directly? (and thus eliminating what will probably be some performance penalty of running Dalvik apps on Native Client).
That way Google gets to deprecate Java apps in the next 5-10 years and be done with Oracle forever, and developers would have a choice of some really good and safe languages as well.
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.
After watching this for five or ten minutes, I gave up. It didn't seem like it offered a good return on time invested.
Your application would still have to directly manage binder callbacks and register for lifecycle events. Re-using the old Java/POSIX entry point actually increases the complexity significantly.