Table of Contents

Hi Wolfram, please introduce yourself and tell us about your background.

Hi, thanks for this interview. Now, what to say about myself? Hm… Well, I have been a long-time geek. My first computer was this Sharp PC-1210, so I started coding 1980 and never looked back.

I fell in love with Java early on (whether it was 1.0 or 1.1, I cannot remember exactly). I was very active in the Java EE world and for a short time period committer for Glassfish. This kind of ended when Oracle bought SUN. Apart from that I’m living in Germany, am mildly enthusiastic about doing sports, and enjoy life with my partner and our kids.

How did you get into Android development?

For whatever reason I missed the early Android versions, but started dipping my toes into it while being on parental leave with our oldest son Linus. Very young kids tend to sleep for large parts of the day – and that was when I started getting into Android. When I wasn’t washing, changing diapers or cooking carrots and pumpkins I was in front of my laptop using Eclipse. My partner went back to working full-time from the day I started parental leave.

From those initial days onwards my involvement grew all the time. I started really digging into it – including diving deep into Android’s sources. Android being open source was an attraction and actually makes understanding its workings and understanding why something in my code isn’t working a lot easier. Shortly after that I started blogging about all the things I learned. Actually blogging about Android was the best way for me to really learn about the platform.

How did you become a GDE?

I have been blogging and speaking for years and also been very active in the Android community on G+ (when it still existed). This surely helped. All in all, being an active part of the community is a very important aspect of the GDE programme. You should show an enthusiasm for the technology and ideally inspire and help others.

It’s about sharing what you learn, what interests you, what bothers you, tricks you found and so on.

Note that GDEs can be (and IMHO should be) quite critical and also should and do point out flaws, deficiencies and so on on Google’s side. An example of where I do that is with Google Assistant. I do not get tired pointing out problems it has with internationalisation (of features, of skills) and supporting multiple languages at the same time. I think that’s really bad for the Assistant product line as well as for us app developers for the assistant. Stating things like that is also part of being a GDE.

What are your favorite Android APIs?

You won’t believe it – and nowadays I cannot as well, but Content Providers (while ugly in many ways) were high on my “to like” list for quite some time. Actually I liked the idea of using them to share content among apps. Alas this idea never took off. And the API, well, that always was hard to like.

I think Intents are a good mechanism to offer flexible ways to share content, to pass control to other apps and to allow users to use whatever app they prefer. Passing values as key value pairs and complex objects as Parcelables on the other hand is not that nice, but given that a context switch is necessary – understandable.

I also like XML layouts – especially the power of ConstraintLayout and the new additions to ConstraintLayout announced at I/O ’18.

What is your biggest frustration with developing Android apps?

I think what everyone says: the way vendors replace stock APIs (sometimes for good reasons). Camera and Bluetooth: Better to be avoided.

While the complaint about fragmentation nearly always targeted the big amount of screen sizes and pixel densities, that actually was rarely a problem. But vendors managed to create other problems.

Also the skins that vendors used on top of stock Android. You see, I sometimes give Android trainings, and finding specific settings can be quite surprising. That’s not so much a development problem but annoying nonetheless.

What are the biggest pitfalls in Android development?

Never think “Ah, this is a small and simple project. I don’t need a proper architecture”. Even after caring about architecture I went down that road once. Why, oh why did I do that?

Apart from that, be aware that mobile apps live in a special environment. Resources are limited, the users attention is as well and his patience even more so. With the limited amount of space available and the just mentioned constraints, UX is even more important (or maybe only more difficult) than for web or desktop apps.

What is your architecture pattern (MVP, MVVM, MVI, etc.) of choice, and why?

I use MVP with use cases/interactors to keep the presenters simple and small in size.

MVI is a very interesting approach – but I haven’t used it yet. IMHO the differences between MVVM and MVP are not that big, so take whatever you fancy. But make sure to take one.

What advice would you give to someone who wants to be an Android developer?

Might be very different depending on where those persons live and so on. I am a co-organizer of a GDG (Google Developer Group) and I learned a lot – not only about Android – while going to the meetups. So this is something I definitely recommend. Depending on your prior knowledge and whether video led training is working for you, those Udacity courses by Google might be a good way to start. I personally am very much paper-based, I used blogs, the source and the official Android docs. The latter improved a lot over the years (though the quality of those varies a lot) so they definitely are a good way to learn.

But please keep in mind that Google – and many blog posts, books or video tutorials as well – tend to use shortcuts to concentrate on a specific part of the API. Do not just copy paste them.

Be very careful when it comes to StackOverflow. Do not just use the first accepted answer. Read some more answers – maybe answers to similar questions as well. Often the accepted answer is actually not a good idea!

Apart from that: You are no Android developer until you start coding for Android. Download Android Studio, think about some app idea that you could do yourself and would keep you motivated for at least a few weeks, start sketching and designing then start coding. It’s as simple as that.

No, really, you will see quick initial progress. And only when you actually start developing, questions and problems start to pop up. And solving those, finding solutions for these is rewarding. There’s nothing wrong with googling around. But don’t just use what you see on StackOverflow or on blog posts, but think about why those solutions actually solve your problem. In what way are they different to what you tried.

What are your most used libraries?

I always use RxJava. I also use RxSwift for iOS and RxJS for Javascript based projects. So using Reactive Extensions with Android feels natural for me. Might be less in the future, depending on how much of RxJava’s workload I’m going to replace with coroutines. Not sure yet.

I also use Kotlin for new projects if possible.

Obviously Retrofit with Moshi (or Gson until recently) is the way to go for remote APIs.

For testing I use MockK and Kotlin Test, and for DI I have used Dagger 2 and Toothpick in the past. Right now I use Koin for a few projects. And even though it isn’t DI in it’s purest form, it feels good. Hope it stays that way.

I have a use/no-use relationship with DAO frameworks. I think Room is a nice compromise for someone like me who happens to like SQL. I also want to give ObjectBox a proper evaluation for one of my next projects.

In general I am a big library user. Libs have the benefit of being used by more people in more circumstances – so they tend to be more stable than “do it yourself” solutions. But of course you should do it judiciously. There’s the 64K limit for one. And you always add a dependency to something you do not have control of – and transitive dependencies on top of that.

I totally despise closed source libs. Not knowing what happens beneath it is really detrimental to a successful project. And some commercial APIs are horribly designed. I have seen interfaces that cover all and sundry. They should have been split up. I have seen crappy documentation and unintuitive method namings.

In general open source libs tend to be much better in that regard. BTW: Not being open source is a big downside of Google Play Services and Firebase. I understand why Google is doing it, but it’s still a downside!

Do you have any tips for RxJava newbies who find it hard to grasp?

I was using RxJava for a long time before it clicked with me. And I really cannot tell you what finally made it click. Just recently someone on Twitter shared this reactive.how page. That’s a good way to learn the different operators available.

Also have a look at Grokking ReactiveX (currently in MEAP but it should be published soon). I think it’s especially helpful to get the hang of it. From there on expand your knowledge using the above resources and start using it. You will soon realise that there’s more to it.

Even though I love RxJava, it is no silver bullet. So take a good look if you really need it for what you want to achieve. If it’s a good fit, use it. But sometimes it’s an overkill, or other approaches are more appropriate.

Other than Android Studio, what is your favorite tool you use for building apps?

Git? No, honestly, I’m not using that many tools. Okay, I use Genymotion (and sometimes the stock emulator – both have benefits over the other. As so often: it depends).

I like sqlite3 to have a look at the app’s local database. And Postman for accessing REST APIs. I also like to use pencil and paper when starting an app and thinking about how to deal with it – or when prototyping screens. Ideally in direct interaction with the client.

I used to use hierarchy viewer a lot. But nowadays many important tools are included into Android Studio (including Layout Inspector, which is the hierarchy viewer replacement). Google’s tools team is doing a tremendous job!

For Google Assistant projects I use Visual Studio Code, though for a current project I actually am using Kotlin for the Assistant backend as well.

If you consider it a tool: Firebase is in use in most of my projects. Sometimes only Analytics, sometimes the crash reporting (now I’m back to Crashlytics in Firebase). Well, crash reporting libs are great. But in Germany understandable privacy concerns are sometimes the reason not to use them. I also like LeakCanary.

And I love my Lenovo T460 running Linux!

What are the biggest advantages of Kotlin?

First of all, Java is twenty years old and it shows it. But still, It’s not a bad language and it’s not that you must switch. I used to use RetroLambda – luckily you can now use Lambdas without it while still using plain Java. RxJava without lambdas really is no fun.

But some things in Kotlin are simply nice: Data classes, trailing lambdas, the proper support for functions as first class members, sometimes (if used judiciously) extensions, properties. All nice to have. And they contribute to a concise – but still readable – code.

Readable code, that’s the important part here: Perl also used to use concise code – alas, often at the price of the code’s readability. I do not care about a line here or a semicolon there. I care about readability. Kotlin is good at that.

And I discovered my love for Kotlin DSLs. That’s a very nice feature – if used appropriately!

If someone who doesn’t have programming experience wants to get into Android development, should he start with Java or Kotlin?

Unless she or he has a big Java (or C#) background I definitely recommend usin Kotlin. But keep in mind that some things might feel weird for Java devs. And depending on the kind of organisation at hand Kotlin might not always be the best choice. For solo devs that’s no problem. But if you work in teams, it’s important that all agree that Kotlin is the way to go forward (at least for parts of the team). Others might have to take care of your code while you’re on vacation. If they resent Kotlin (for whatever reasons) this won’t work. Kotlin has more ways to do things and as such you need to know more to be able to understand Kotlin code. Java is simpler. Sometimes tedious, granted, but simpler.

I personally, though, think there’s no reason why new projects should continue to use Java. And I also believe it’s better to move to Kotlin for new features if existing apps are changed significantly.

There is one big downside of Kotlin: It increases the method count tremendously. You hit the dexcount limit more quickly when using Kotlin.

Single activity app or multi activities app?

I still use multi-activity apps. I haven’t look enough into those other frameworks. Maybe I’m lazy.

Do you use fragments?

Depends on the app. I definitely use dialog fragments where appropriate (I try to avoid nagging dialogs, though). Apart from that I use them only if the app lends itself to master detail or similar layouts. No need for them otherwise.

I have never used nested fragments. They are not worth the hassle.

And because I think fragments should be used sparingly I am not so fond of The Navigation Architecture Component introduced at this year’s IO. I am not willing to migrate activities to fragments. We had this once. IMHO it didn’t work out. I am actually a bit surprised Google is returning to this advice.

What hardware do you use for development (laptop and phone)?

Lenovo T460 with Ubuntu. I have been using Lenovo’s T line for years – always with Linux. A very nice and powerful combination.

With regards to phones: I still have my Nexus 5X since the large Pixel 2 simply is too large for me. And the small one was too old-fashioned with the large bezel. As the Nexus 5x won’t support Android P, the next Pixel most likely is a must. I hope that the Google hardware division will get there act together this time. Keep both sizes, get rid of the bezel and justify the high price by an all around superior experience. If they do so, I will happily buy one. In my opinion neither of the Pixel 2 phones justified the price.

Luckily with Project Treble more and more devices are getting updates way quicker. So I just ordered a Nokia 7 plus to be able to run the preview version of Android P. But it most likely will be too big to be my private phone. It probably will only be used as a testing device.

What are your go-to places to get updated with Android development news?

One good recurrent resource is of course Android Weekly. They make you aware of interesting blog posts, videos and new Android libraries. I recommend to follow the Android developers blog and to have a look at the What’s New sections whenever a new Android release is published as well.

Apart from that there is no single resource or place to go to. Of course a lot is published on Medium but there’s also a lot of uninteresting stuff published under the Android tag. Simply follow some Android devs on Twitter and you are bound to notice other interesting devs as well.

And did I mention Google Developer Groups and Women Techmakers already? Go to them. You will learn a lot and meet fellow devs to discuss with them all kind of stuff. If no GDG is nearby some other dev related meetups probably are.

Finally conferences can also be a good way to get a good overview of what is new. Alas some are too commercial and offer too little value for their money. Be choosy! Have a good look at the schedule. And with that I mean the topics, the overall mix of topics and how they are presented in the schedule.

What do you think is the minimum someone should know/do before applying for his or her first Android development job?

Oh that’s very difficult for me to tell. I think prior knowledge is often overrated. It’s important that people are enthusiastic and willing to learn. And if they are culturally a good fit they will grow quickly and can easily outpace others with lots of experience but little enthusiasm.

I also think it’s the task of the hiring company and the team to help any new employees and to bring them up to speed.

There must be some basic knowledge, of course, on which to grow. This could be  formal education, but in my opinion it could also be self study with some spare time projects or open source contributions. That’s something Germany has a hard time to adjust to. Here proper education is too highly rated. A certificate counts more that it should and real life experience and enthusiasm less that they should.

Of course experience is helpful. Don’t get me wrong. But without enthusiasm it’s not worth that much.

Luckily, I’m not in the role of hiring anyone. But I think there is no definite bare minimum one has to know. Important, though, is not to pretend to be what you are not. If you pretend to have solid knowledge and fail for basic questions that surely is a very bad sign. Better be honest. But again: I never recruited anyone: So my advice might be completely wrong.

What are the key pros/cons of Android vs. iOS development?

I am too biased to seriously answer that. Swift is definitely nice (though not as nice as Kotlin). But I personally despise some things in the Apple world. Xcode is a pain and way behind Android Studio. I for one do not like Interface Builder, but – as mentioned – I prefer the XML way anyway. I use XML even for ConstraintLayout most of the time. Many iOS devs, though, think that the Interface Builder is a big boon over Android’s way to create UIs. So I might simply use the iOS tools too seldom for them to be intuitive to me.

I think Java’s (and Kotlin’s) stack traces are nicely readable. And I managed to crash the LLVM compiler but never managed to crash javac. Seriously? A compiler that just makes “Poof!” and doesn’t give you the slightest clue of what went wrong? Should not happen. Then again: All code contains bugs. Mine as well.

How do you handle getting into projects with legacy code?

Depends on the code base.

Normally the first thing is to understand a few core use cases and how they are implemented. How is the code structured? What style is used? Which architectural principles have guided the devs, what other systems are involved, which libs are used and so on. Also very important is whether the project is based on one Android Studio module or multiple modules. And what – if any – unit tests are existing (I personally do not care much about UI tests).

The worst projects are those where each developer used her own style. That makes understanding the code base that much harder. Having said that, this also means that you cannot go around and just use your own style no matter what. Same applies to code structure and architecture: If there are architectural guidelines, you have to follow them unless you can convince your coworkers to change them for a good reason. Do not simply introduce new architectural patterns without discussing them with your co-workers!

Tell us about some of your development mistakes and what you learned from them.

Oh there are so many. As a kid (remember, that were the 80’s, we were using tapes and floppies back then), I repeatedly coded deep into the night and made the biggest mistakes during the nights. I also deleted hours of work by overwriting files. I do not remember exactly but I know for sure that I wasted many hours by doing something stupid when being very tired.

I learned my lesson the hard way. But from back then, I really hate this hard-working cliche. You cannot code for that many hours without making more and more mistakes, without creating worse and worse code. This cliche is so stupid and it gives me the creeps whenever someone talks about doing long hours week-in week-out. Occasional spikes, of course, are okay. But pretending to constantly do long working weeks, I simply do not believe that. I always think here’s someone on her way to a burn-out or someone that isn’t very good at organising herself and procrastinating the whole day or someone that is being exploited. Or maybe all three of that.

Other blunders of mine were underestimating the complexity and giving bad estimates because of that, or thinking that MVP was not necessary “for a simple project like this”. Big mistake! Never start without any of those architectural MVx patterns. Read about clean architecture (which is much more than simply MVx) and pay attention to it.

When I was still doing Java EE development I also used way too many factories and singletons and probably misused other patterns as well. You keep changing more code than you would like to change – and testability is also not helped by that. Patterns can be helpful – but only if used judiciously.

With some projects I also published updates too quickly. And had to publish a bug fix quickly afterwards. Obviously those projects weren’t guarded against regressions sufficiently – another thing to better avoid.

And one thing that still nags me, because I haven’t totally given up on that app –  I once published an app for a beta test and got some very good bug reports. Because of time pressure I had to postpone fixing those bugs. But since I didn’t use a proper issue management tool I now know for sure that there are some very bad bugs, but I do not know anymore how to reproduce them.

How do you structure the files in your projects (class type/feature/something else)?

Definitely by feature! By class type is a mess and you do not get a nice overview of what belongs to what.

I used to have a module free of any Android dependencies for interactors/use cases, repositories and the lower levels of the code. But that was while I tried to get the hang of proper unit testing. Now my tests ensure proper separation and there’s no need for that.

I’ve just read about using one module per feature. Not sure if that’s worth it. But probably sounds like it’s helpful for bigger teams. I hope to see a talk about that somewhere.

What is your approach for testing your apps? Where should one start?

I prefer using pure unit tests mostly. I do test my presenter’s public interface and also the interactors/use cases and repositories. Those are complete free of any Android specific code. If I need to use Android specific things (e.g. for preferences or string internationalisation) I create interfaces and concrete implementations of those that then make use of the Android specific code. In my tests I use test doubles instead.

I do only very few exploratory Espresso tests as some kind of end to end test. If at all.

Only a proper architecture enables proper testability. So that’s another reason for using a clean architecture.

Why did you choose to go in the freelancing route?

I found an opportunity to do so with a local company here in Münster (fileee). So working for them is how it I started.

It has many benefits: I interact directly with clients. I work on many different projects. I can work from home. I can use the tools, the machine and the operating system I prefer (well, mostly; obviously sometimes clients prefer a certain set of tools).

It has downsides as well, but all in all I like freelancing.

Can you recommend any technical books about programming?

I think there are some important classics:

Mythical Man Month” is very old but still a must read for everyone. Alas, it’s so very often ignored.

Since all systems are distributed nowadays some basics about distributed system are important. Read Tanenbaum’s book about it (while his operating system book is also good, this topic is more important for most Android projects). Another good academic but still very readable book is “Distributed Systems” by Coulouris et al. A more practice oriented book about distributed systems is “Release it!“, which was just released in a new edition. Some parts are applicable to the Android world – and others at least help you understand the backend folks better.

Growing Object Oriented Software Guided by Tests” is a bit outdated but still the best that I have seen about how to go forward with tests.

I also like “The Clean Coder” and also “Clean Code” by Robert Martin.

Since AI is all the rage nowadays, the books by Joseph Weizenbaum are a good way to put things into perspective. He’s not always right, of course, but offers thoughts worth thinking.

For Android I probably would recommend the “Android Programming: The Big Nerd Ranch Guide“. And for Kotlin the book “Kotlin in Action“.

I also think it’s very important to read a book about app design. You won’t turn into a designer by doing so – unless you had a knack for that before reading the book anyway. But it helps you keep an eye on things and avoid usability and UI blunders. A good design book is one that not only shows nice things, but keeps user experience (which is very different from design) in mind and follows the complete process starting with initial paper prototypes. Karolina Schilling’s “Apps machen” is IMHO a good German app design book (at least from a developer’s perspective). Alas, I don’t know a comparable English one.

How does your average working day look like?

Depends on what I’m working on.

The start though is always the same. Since the kids start school at 8 a.m. I usually start my work day around 08:30. Normally by checking mails. If I want to publish a blog post (which I tend to not do often enough), I do this right at the beginning of my work day. When I have the chance to work alone, I switch on some nice music and start working.

Difficult to say which amount goes into coding, which into client communication, which into testing, bug fixing, meetings, sketching and what not. That’s always different.

The least attractive part of my work is writing proposals – obviously. But that’s part of my worklife as well. Luckily seldom enough to not be annoying. Apart from this proposal thingy, interacting directly with customers is a very beneficial experience that I happen to like.

I also take time to explore new stuff, to read blog posts or books and also to write posts myself or to prepare talks.

Do you have any productivity tips?

I can only tell what works for me: I like to take shorter walks during the day, like going to a bakery nearby or stuff like that. And if stuck, I stand up, walk to the kitchen, drink a glass of water or go make a coffee and try again afterwards.

I tend to check emails only twice or thrice per work day, same goes for Twitter (or any social media).

But the best productivity boost comes from doing things that you enjoy (that’s why I’m slow when writing proposals).

What are your hobbies?

I used to go cycling for many hours a week. With the kids I had to stop that to have enough time to be around with them. Now I try to go running regularly – though right now I’m not as active as I should be. My confort zone (while running) is from 3° Celsius to 25° Celsius – so anything below or above it – and I stop running.

I listen to music a lot and occasionally go to concerts. Though with me getting older and with having kids that’s not happening that often.

I obviously spend a lot of time with the kids. I love to read to them, though that’s probably going to end soonish with them starting to read on their own. I spend quite some time watching them play soccer at the sports club. And during the nicer parts of the year my partner and I play soccer with them as well. And sometimes I tinker with them with electronics. I’m not so much into board games – something my kids would love me to do more often.

I try to find time for spare projects as well. Currently I spend a lot of time digging into the Google Assistant, for which I am also a GDE.

I also like to go to meetups. The exchange with others in the field is great. Same goes for going to and speaking at conferences. IMHO the Android community is great.

I nearly never watch telly (or Netflix, Prime or whatever). That’s why I also have time for reading plenty of novels.

Do you have any other advices for our readers?

Keep your eyes open for new things. New ways to do stuff. And new stuff to do.

What is the best way to get in touch with you?

Either follow me on Twitter (@RittmeyerW) and ping me there or contact me via wolfram-rittmeyer.de. I also always like to meet people at conferences and get feedback by them about blog posts, conference talks, new Android (or tech in general) developments and so on. Really, you cannot overestimate how motivating feedback is. No matter which. Better ways to do things, other experiences, constructive criticism? Don’t worry about that: I’m always interested to learn more!

Please, do not ask me coding related questions directly, though. Always use StackOverflow (or comparable communities) first. If you cannot get an answer, ping me with a link to your question. That’s also true if you find something on my blog that doesn’t work for you. Any coding related question needs the code of what you tried so far. I’m always willing to help, but it must be reasonable. I have a lot to do, a family I want to spend as much time as possible with and a life to live.

Categories: Interview

10 Comments

Александр Кириллов · June 8, 2018 at 8:30 am

thanks

sachin sandbhor · June 8, 2018 at 12:35 pm

Cool interview. Give me some idea about how Developer like him(Android developer) think about world of technology. Thanks for interview.

Ilya · June 11, 2018 at 9:41 am

deep material, thank you

Vasili · June 14, 2018 at 8:10 am

Very nice interview. I’m fully agree with you about comparison Android and iOS development:)

Ko Ko Pyae Sone · June 15, 2018 at 4:55 am

nice interview.I got so many new things..thanks indeed.

Silver · June 17, 2018 at 8:18 pm

Super relevant Qs and I’m glad the answers are lengthy and detailed.

Lace Frontal · August 17, 2018 at 1:11 am

Excellent way of describing, and fastidious article to get information on the topic of my presentation focus, which i am going to deliver
in university.

stone island crew neck · August 17, 2018 at 3:40 am

I was very happy to discover this site. I want to to thank you for ones time for this wonderful
read!! I definitely savored every little bit of
it and i also have you book-marked to look at new information in your web site.

zusatz versicherung krankenkasse · August 17, 2018 at 5:38 pm

Hi! Do yoou knokw if they make any plugins to protect against hackers?
I’m kinda paranoid about losing everything I’ve worked hard on. Any recommendations?

krankenversicherung baby · August 18, 2018 at 12:24 am

I used to be able to find good info from your blog articles.

Leave a Reply

Your email address will not be published. Required fields are marked *