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?
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.
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.
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].
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.
- 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.
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.
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.
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!
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.
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:
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.
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.
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.
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.
"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."
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.
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...
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!
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.
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.
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.
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.
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 ;)
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.
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.
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.
... 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...
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.
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.
I've dabbled in Android dev, but have always lagged due to not really liking Java. Android Studio was a pleasant experience for me when I tried it this year, and now that C/C++ NDK support is better in this release I am going to give it another go.
I almost feel like I should just go completely Android given the numbers of devices out there is overwhelming compared with Windows/iOS/OS X combined. I will keep up with my other PLs and things simply through osmosis. It's time to join the Borg!
It does a really good job at fixing java's issues and since it outputs bytecode, you can write entire Android apps with it without writing a single line of java.
Not in a year, but it wasn't different enough to me - less verbose, but the same when I long for a Lisp or ML or Haskell for Android! Scala was a thought. And I am now looking at F# again with the recent OS works by MS and the Xamarin situation.
As I wrote downstream, I just need to commit to Java (or Kotlin!) I think!
Well, Scaloid is a thing, so you might want to check it out. AFAIK, it is not really popular for Android development, but it makes some people really happy, like predictive keyboards creators.
As for Xamarin, it really depends on what you want to do. If this is just a hobby project, well go for it.
Otherwise, the only use case where it is really interesting is when you need to write an app for both iOS & Android on the cheap.
I did, and they are great. I even have the Continuous App on my iPad Pro which is an F# development environment. It's incredible, but I am concerned about having to still drill down to the Android API, which means Java.
I am thinking more and more against my wish, that biting the bullet and just going Java all the way is the key. Kotlin, Xtend, you still have to read Android SDK code in Java, correct?
In terms of books, a friend bought me "Android 6 for Programmers: An App-Driven Approach (3rd Edition) (Deitel Developer Series)" to get me off the fence. I am going to work through it as much as I can to give Java a fair shake. I used to program in Java 5 for little side projects, but never mobile except for demo or tutorial apps years later.
Is this a good Android/Java book, or should I stay on board with my interests and do an Android Game or Android AI book slant?
I don't know that book, so I cannot judge it, but it is important to try to use your interests as an idea for a possible app that you could use as learning process.
If you stay on Java side than using something like LibGDX will help on the game programing ideas. Or if you prefer to jump into the "wonders" of NDK, then something like SDL or Cocos2D-x.
For the Xamarin side, have you read the Petzold book?
Regarding about using wanted programming languages, my experience with Turbo Pascal, Delphi, Oberon, Smalltalk and many other languages is that straying away from the true path of OS SDK supported languages usually ends in pain as the productivity gains get wasted battling interoperability issues, lack of tool support from the OS vendor and writing FFI bindings.
So nowadays although I dabble in lot of languages, for production code I only use the OS SDK supported languages.
I know, since my first attempt was in Java to create a simple app. I know the NDK can be used to create OpenGLES guis, and access the sensors, but for a traditional app it's a lot of work.
Syntax is a subjective thing; I just don't like Java. I was hoping Google was going to come up with something (other than Go), for Android.
I have tried a lot of the work arounds, and simply put, Java is the way to do Android right, so I guess I need to get over it!
If no one used it, they wouldn't be adding better support for it.
The NDK is pervasively used by many many applications; that's why it's getting more support.
For some reason this seems unpopular with the android team, who seem to keep trying to avoid the issue when ever its raised at I/O...but hey, clearly at least someone is paying attention to what the statistics are showing.
Sure, it's some extra hoops to jump though; but shared business logic that you can use on any code base on any platform; that's a really really compelling reason to use the NDK, or one of the stacks based on it (eg. Xamarin, react native).
It's not just for some edge case. The biggest players in the field are doing this.
I think it's misrepresentative to try to characterize this as 'just for games'...
Personally I think they were forced to do it from the games industry, just like it happened with Windows Phone 7, which only allowed pure .NET applications.
However the Android team, which is composed by quite a few ex-Sun Java team members, seems to not share the same love for C++ as Microsoft or the even their own Google clang team do.
While I appreciate the safety we get from Java as the Android main language, Symbian, iOS and WP all managed to have native sandboxes.
> I think it's misrepresentative to try to characterize this as 'just for games'...
I don't think so, because although we are able to use the NDK for coding apps, that is clearly not what the Android team wants to allow us to do, given the list of official APIs, which are all to game development related, even POSIX is only partially supported.
Now in Android N there are changes in place to prevent linking to platform libraries written in C or C++ like libpng and Skia.
It is ironic that we are forced to use JNI to make calls into those platform libraries via their Java bindings.
Also I don't believe that if Jetbrains hadn't decided CLion would be a worthy product, the Android team would have spent any effort to improve the life of NDK developers stranded with their decision to drop Eclipse CDT without any alternative.
See my replies above, but yes, I am a fan of F#, and I wish it were that easy, but I think simply learning Java (or Kotlin as pointed out above) might be the best way in the end. Google has made it very clear they are not working on an alternative from Java dev in Android.
If your intention is to make money from selling apps, then don't let the market share fool you. It appears that it's rare for anyone to make more than 20% on Android compared to what they make on iOS.
Running a real ARM emulator is still slow but for most things running an intel emulator with haxm will be fine. An actual device will be faster but the emulator will be suitable for simple test
The Intel emulators these days are very fast, especially the ones you can create in Android Studio 2.0+. They are still resource hungry (RAM mostly) but they are now faster than developing on a physical device.
In Studio 2.0 it got much better. Just make sure you're using a recent gradle version in your project config (it'll prompt you if you open up an old project).
Haven't had to use Genymotion since 2.0. Instant run is getting better w every release, I surprised the iOS dev last time I showed it to him.
You need a pretty powerful machine to run Android Studio. It lags when I run it on my laptop with an i5 and 6 GB ram. I wonder if upgrading to a SSD will increase performance.
I spend about 80% of my day in Android Studio and It's definitely resource hungry. On my brand new MBP 13" with 16GB RAM and an i7 processor it can still make the whole thing stutter when compiling a medium to large project.
At work my desktop can handle it, but that thing has pretty unrealistic specs.
