[kyriakos]

I tried many times to get into android development but everytime I get put off by the complexity of the api. The amount of digging in documentation you need to do in order to implement the simplest functionality scares me. Is anyone else feeling the same way? And does anyone know if it gets better with time or is it a constant struggle?

[habosa]

I've been doing Android development for ~6 years now. For the last 2 years I've been doing it full time at Google (not on the Android team).

Your first impression is correct. There is a LOT to know and I am still learning new bits every day. And yes you do find most of it out by digging around in the docs or on StackOverflow.

That said, it's an amazing platform to explore because no door is fully closed. Android will let you do practically anything if the user wants you to. That leads to a really gratifying hacking experience where if you just keep digging you can achieve really fun and crazy things that you'd never be able to do on any other platform while working with mostly high-level APIs. It has its own strange logic that I have grown to love.

[cguess]

That's true, as long as you don't have to support >50% of the users of Android. As someone (at this moment) still dealing with the very healthy supply of Android 4.4 phones being sold as "new" in Europe, I can only dream about actually using the fancy APIs someday.

Apple may be closed down, but I've never had to target anything less than current_version-1.

[passivepinetree]

Can you offer some examples?

[habosa]

Sure. My personal favorite example of an app that would only work on Android is Link Bubble [0]. Not only is the UI creative but it makes amazing use of Android extensive Intent-based sharing system, which is the one thing Android had right from the start.

Google also maintains a whole page of creative Android apps [1].

[0] - http://linkbubble.com

[1] - https://www.androidexperiments.com

[cageface]

Some things are much more sane and well thought out than iOS. Styling and layouts, for example, are so much better than Interface Builder, which is pretty much just a toy for demos.

Other things like the way events are handled and some of the native widgets are clunky. Some of us are fed up enough with all the incidental complexity Apple puts in your way every day as a developer (provisioning, in particular), that we prefer to put up with Android's warts.

That said the native app market is feeling pretty saturated these days and I'm not sure that boning up on building responsive/progressive web apps isn't a better long term bet.

[sosborn]

IB is perfectly fine for most apps. When you feel constricted it is easy enough to accomplish what you want in code.

[cageface]

IB is a mess:

  - No way to define reusable styles. 
  - No way to compose layouts out of other layouts.
  - Trait classes are way too coarse to be useful.
  - Versioning of Storyboards is a nightmare.
  - Anything beyond trivial auto layout editing is useless.
  - Segues force you into stringly-typed APIs.
  - @IBDesignable is still super buggy.

I've been much much happier since I dumped it and started doing everything with SnapKit.

[Nullabillity]

What happens if you try to open an iPhone app on an iPad? What happens if you try to open an Android phone app on an Android tablet?

That's the difference between IB and Android's layout system.

[JimDabell]

It's really not – I think you're working with outdated knowledge from several years ago. An "iPhone app" is one specifically built for iPhones. That's not the norm these days. Normally you would build an iOS app with universal storyboards that would work for both iPhones and iPads. Normally opening an iOS application on an iPad would result in a layout that works well for iPads.

[veeti]

Phone layouts automatically blowing up to a 10 inch screen and allowing developers to be lazy is not an advantage. The tablet apps on Android are still garbage after all these years.

[agildehaus]

Modern iOS development uses Autolayout, which uses a constraint solver. This hasn't been a problem for years.

[dan1234]

Auto Layout[0] can give you incredibly flexible designs from within IB.

[0]https://www.raywenderlich.com/115440/auto-layout-tutorial-in...

[eggy]

Android vs. Web Apps is exactly where I was sitting on the fence, but then I just looked at the sheer number of Android devices out there, and it doesn't seem to be stopping!

[pawadu]

And the web apps all run on the same machine?

[eggy]

If I understand you to mean I would be able to deploy to all types of devices with browsers or webkit, you're right.

There are more Android OS devices shipping and out there than all of the other OSs combined. By focusing on just Android, I can be assured it will look and perform more uniformly than the web app route. Even ART has closed the gap with NDK on some HPC or numerical use cases vs. the older Dalvik.

I don't like Java compared to other languages, even JavaScript ;) But it's not too bad, and Android documentation is great as well as the number of answers you can find on SE for any given question.

[jmkni]

> Interface Builder, which is pretty much just a toy for demos

As somebody currently learning the basics of iOS development, what do people use as an alternative?

[cageface]

IB is ok for getting started but it will eventually hold you back. If you get to the point where you feel like you're fighting it as much as using it then look into doing your layouts in code with one of these libraries:

https://github.com/SnapKit/SnapKit

https://github.com/robb/Cartography

It may take a little getting used to but, especially for the kind of dynamic apps people want to build today, it will save you a lot of time and headaches in the end.

Also make sure you get your head around UIStackView. It's a little tricky to learn at first but makes a lot of common layout problems easier to solve.

Also, start using this library ASAP:

https://github.com/mac-cain13/R.swift

[vlozko]

As someone learning the basics of iOS development, I'd suggest you stick with IB. I get that most people either love it or hate it but there will never be a WYSIWYG editor that everyone will be happy with and there are ways it's lacking. But to call it a toy for demos is simply over the top. I've personally made pretty complex interfaces using iOS's auto layout using very little UI code.

[blihp]

I'm a grumpy geek who went down this path a few years ago and here's my $.02... It is a fairly complex, and in some cases downright convoluted, API for the functionality it offers and the tools are pretty crude. The good news is that it is logical and you can get used to it, the bad news is it is a constantly moving target (i.e. API bit rot can progress at an amazing rate on Android if you try to keep current with the SDK revisions. I've lost count of the number of policy changes and reversals on subsequent releases) Unless you have a professional need or burning curiosity, I probably wouldn't bother with it.

[alexkcd]

The graphics stack in Android is badly designed. It is that way for historical reasons. Android used to do CPU-based blitting -- similar to other mobile platforms at the time: Symbian OS and Windows Pocket PC. Then the first iPhone launched & it became clear that GPU rendering was the way to go for mobile UI drawing.

Rather than rebuild the graphics stack from the ground around GPU rendering, GPU support was tacked on to the existing graphics stack. Resulting in this franken-architecture: http://source.android.com/devices/graphics/architecture.html

That guide has such gems as:

"Once upon a time this was done with software blitting to a hardware framebuffer (e.g. /dev/graphics/fb0), but those days are long gone."

"While this section uses SurfaceFlinger terminology, WindowManager uses the term window instead of layer…and uses layer to mean something else. (It can be argued that SurfaceFlinger should really be called LayerFlinger.)"

"Some things that work with Surfaces want a SurfaceHolder, notably SurfaceView. The original idea was that Surface represented the raw compositor-managed buffer, while SurfaceHolder was managed by the app and kept track of higher-level information like the dimensions and format. The Java-language definition mirrors the underlying native implementation. It's arguably no longer useful to split it this way, but it has long been part of the public API."

etc.

[yincrash]

For beginner use cases of the Android API, this isn't really a problem they would encounter.

[pawadu]

But that stuff is mostly relevant for manufacturers, not developers.

[victornomad]

after 6 years writing Android code I still struggle, specially with anything UI related. I do as well web and Qt which I find vastly superior in terms of user interface creation. If you stick to "material templates" you are ok, but as soon as you want to do things a bit differently is a pain in the ass... Theming is just horrible, and having xml files and images scattered everywhere using flat herachies is a bit annoying.

And the audio subsystem is still really bad, lots of lag which prevents android having any serious sound / music app... if you dig the forums you will find lots of really upset people complaining and willing to help improve the sound subsystem and the Android team just keep ignoring... Just to give you an example, my raspberry pi gives me 3ms of sound latency while my current flagship Android phone with Android 6.0 gives me 100ms, totally unaceptable for music related apps :(

In terms of Android Studio I use it, but I find the interface really bloated which interferes with my desktop zen. I tweaked but still dont like it, somehow i miss my tuned Eclipse of some years ago. Biggest thing since the transition to Android Studio is Gradle which I find it really good.

I just wish Android was a truly open ecosystem where we developers have more voice than asking for help in stackoverflow and using a limited set of tools. Web development might be chaotic, sometimes feeling overcomplicated but Im truly amazed and thankful by the quality, quantity and variety of tools that the comunity produces. It just feel fresh and you can do it the way you want, from a simple html and css in a single file with a notepad to the most advanced framework with linters everywhere.

[Grazester]

Maybe it was 100ms once upon a time but that is simply not true now. http://www.androidpolice.com/2015/11/13/android-audio-latenc...

[victornomad]

it keeps been true. that article refers to "superpower" which is a technology developed by a third party that hacks the android audio subsystem for certain models, so its not general. I have like 30 android models ranging 2.1 to 6.0 for testing and never saw any working below 100ms and the majority of them going to 200 or 300ms...

[andretti1977]

I've been developing both android and ios apps for the last six years. Both the platform are quite complex and yes, you need to learn and get experienced a lot even if you could do "basic" apps without much troubles. And remember that if you think android is a difficult environment, you will have really harder times on the io platform!

[johnkchow]

It'd be helpful to have more context about your development experience. I've done some iOS development in the past, and as spapas82 mentioned once you understand the core Android concepts it's easy to pick up. The docs are good, and there's a lot of tutorials and small articles to get you going.

If you've never done native mobile app development (e.g. you only have background in web dev), then regardless which platform you start off with, the initial learning curve will be a bit steep. Most APIs are "lower level" than the web counterparts and there's more ceremony to piece things together since you're working in such a constrained environment (memory, CPU, battery, network speeds, inconsistent internet access, disk space).

All that said, I think Android is a _taaaad_ easier to start off with vs iOS if you're a web dev. There's the GC, the Activity model is similar to web pages and their View XML abstraction is not that far off from HTML/CSS.

[wingerlang]

I misread thinking he said iOSs XML system and not Androids. Original comment below.

-----

> .. View XML abstraction is not that far off from HTML/CSS.

Do you mean the underlying structure of xibs and storyboards? I don't think this is something anyone looks at willingly, much less actually work with.

[spacehunt]

The parent seems to be talking about the Android layout XML, which is a much saner format than xibs and is actually quite nice to work with by hand.

[leviathan]

I think the parent is talking about android views. which are XML documents and almost everyone writes the XML instead of mucking about with the visual editor.

[yoz-y]

I think this is mostly due to the lacking visual editor rather than virtues of the underlying XML format.

[pawadu]

Seriously? In a thread about Android Studio of all places??

https://developer.android.com/studio/write/layout-editor.htm...

[yoz-y]

I was using Android studio from beta until the early 2.x series. It has been some time but there were indeed many cases in which I had to go dig in the XML representation of the UI file. I do hope and believe it is getting better.

[spapas82]

I may have felt like this when I started playing with android (4-5 years ago), but not anymore. It definitely gets better. Notice that I am not a full-time android developer however I have developed a bunch of part-time projects for Android.

The API is not really complex if you know a few basics (services/ activities/ broadcastasts/ lifecycle/ intents/ handlers/ ui/ ui thread/data storage) and then just know where to look for the answers(the android docs and tutorials are good and there's an answer to everything in SO).

Also you need to have a solid understanding of Java or you'll definitely have problems. So my proposal is to grok the (few) needed basics and the just go all-in and try to implement a full application so that you'll get the needed friction with the android environment.

[omegaworks]

2.2 introduces constraint layout support in the ide so you get drag and drop ui design like Xcode. Still have to wire things manually but libraries like butterknife are making that less painful.

Theres a reason android developer avg salary is higher then iOS ;)

[taneq]

I don't think the API is that complex (although yeah, there's a lot in it). What really puts me off is the rate of churn of API 'best practices'. It's alleviated somewhat (in an ugly way IMO) by the XxxCompat classes but it still feels like you're running the Red Queen's race just to keep an app running on a decent range of devices.

[2bitencryption]

You're going to call me crazy. But using Xamarin to develop Android apps in C# via Visual Studio is seriously a better experience than using the Android Studio. At least, that's been my experience with simple personal projects -- perhaps if you are Facebook or Instagram that's not the case.

The API is almost the same, sure. But things like class attributes, null-coalescing, lack of Gradle, automatically generated getters and setters which can be overloaded... I had more fun writing a personal app for fun in Xamarin than I ever did in Android Studio, which only ever frustrated me, even though I love the IDE it is based upon.

[jmkni]

I've been really enjoying Xamarin Android recently.

What's nice is that most of the regular Android tutorials/SO answers are easily translatable to Xamarin Android.

I have found myself just leaving the word Xamarin when I google something, as the ordinary Android resources are good enough.

[h1d]

Want to hear others' overall experience on Xamarin too.

It looked like it's just a middle ground that does neither as good as the native solutions. Was hoping MS will accelerate it to be more competitive.

[flukus]

Every time someone complains about the complexity their only solution seems to be to add more tooling and IDE wizards instead of simplifying things. It's like watching them repeat all the mistakes of Visual Studio in the 00's.

> And does anyone know if it gets better with time or is it a constant struggle?

I'm not super experienced, but I did invest quite a bit of time a few years ago and never got to the point where it was getting any better.

[neals]

... and than you need to do the same thing for iOS, which is a totally different eco-system. I've been using the known multi-platform tools for a few years now, like Cordova and Haxe+OpenFL. Haven't typed a line of Java since...

[yoz-y]

That works if you can throw the performance down the drain. I had to develop an interface to do a real time display of a hardware component. No chance, the Cordova API is completely unusable. Maybe if somebody wrote a native plugin interface like Electron has it would become usable.

[arvinsim]

I am starting my first mobile using React Native now. I couldn't get into native Android programming because it seems that you need to learn a lot of scaffolding just to get to what you want.