“When I became an Android developer, there was still no place to look for examples”: interview with David Gonzalez

Android developers may know David Gonzalez due to several different things. For example, he participates in the open source project of Android Architecture Blueprints , where different architectural approaches are demonstrated with specific examples (the project has recently crossed the boundary of 25,000 GitHub stars). He also delivers reports, is engaged in the Belgian Kotlin User Group, previously actively wrote blog posts - in general, it helps the community in many ways, and the title of Google Developer Expert is not surprising.

So in an interview, we also asked David about several topics at once: we started with Android Architecture Blueprints, switched to Kotlin, and ended up authenticating with Android, which his new report is about.

- The main details about the Android Architecture Blueprints can be found in your 2016 report . What has changed in the project since that report?
')
- The project has grown, now it has more samples of different approaches. At that time, the RxJava and Dagger samples had not yet reached the stable state, and there was not a single version on Kotlin at all.

I am no longer active in the project code, but now I’m helping people more to figure out the project. Now more people are involved in it, and they have many more questions. New members help a lot.

In addition to the main project, there are still "external" examples of architectures, and I took part in this: Benoit Quendon helped with his example MVI-RxJava-Kotlin .

- Do you have to hear, “Well, in Blueprints, licked samples of architectures look good, but I tried to do the same in a real project, and everything immediately fell apart”?

- You are right, it is necessary. But Blueprints are just examples of the implementation of the architecture, and not "the only sure way to implement it, you must copy and paste everything from here." This is more a guideline than the Bible.

If you already have an app on Google Play, you have been working on it for a couple of years, use one architectural approach, and then decide to change it - this, of course, will not be such a straightforward task as simply copying and paste.

Much depends on the team in which you work. Singles can be easier. And if you are in a big team, then dialogues and discussions become important, as a team you need to decide how you will move forward and how to begin to implement these changes.

- The curator of Android Architecture Blueprints is Google. Does it not happen that they reject something useful because it is at odds with the interests of the company?

- No, absolutely. For example, there is a sample for RxJava, although Google may not use it inside. This is where the power of the community helps: we can take it on our own. This is an open source project, so you can lead its components. The situation is different with Dagger: this is a Google product used internally, so more Googlers are involved in its implementation. But they do not tell us what to do or not to do, the approach is completely open source.

- Do participants often disagree on the implementation of a particular architecture? Are there any differences when it is not clear what to include in the project?

- Usually, when discussing a new example, controversial issues are discussed on GitHub, helping each other. For example, when Benoit wanted to do RxJava with MVI, I expressed a desire to help, and we communicated. It looks more like a benevolent dialogue than two completely different versions of the same example, when you do not know which one is preferable.

- Android Architecture Blueprints differs from most projects: it is divided into several example branches, each of which can reach the “finished” stage. Does this mean that work on the project is going on in “waves” as new branches appear?

- Well, although in fact there is always the same to do-application, sometimes in some example new features may appear, and then they must be implemented in all other branches too. Besides, Jose is now sorting out what other application can be implemented using blueprints.

But there is an increase and decrease in activity, yes. When a new, popular architecture appears, many people write blog posts, it all comes to Blueprints, and new tasks appear.



- In the feedback that you see, the demand for Kotlin examples in Android Architecture Blueprints is already higher than in Java examples?

- I think yes. Already next week after the announcement of support for Kotlin on Google I / O, a lot of people wrote “Hello, and when can we get it?” And then people started contributing: “I think you need to say this?” helped with kotlin-examples, it was very useful, these guys know how to.

- Is there a feeling that Kotlin will soon become the definitive leader of Android development, or do conservative legacy companies mean that the majority will be in Java for a long time? This, of course, is a speculative question, but you, as the organizer of the Kotlin User Group, should see the trends.

- Well ... In the world there are still companies that have COBOL in production. And we still need people writing in COBOL to support this. But such systems are about 20 years old. I don’t know if anyone will use the mobile application 20 years ago. And it seems that mobile developers like to refactor all the more often, you can see how applications rewrite every 2-3 years. So the lifetime of the code here is much less compared to the old enterprise. And if in three years a new language appears, then new blog posts and reports on migration from Kotlin to this new language will be launched immediately.

- Since you lived in London, and now you are organizing the Kotlin User Group in Belgium, it is interesting to compare: how is the situation with Kotlin in the Belgian Android community and not only, what is the difference from London?

- The difference is felt. There are a lot of developers in London, they constantly hold meetings. Belgium is another country, here in this respect everything is much slower. Even the number of people attending events: it is gradually increasing, but very different. And convincing Belgian companies to switch to Kotlin is a much slower process compared to London.

But the developers are inspired by Kotlin, it’s exciting to work with, and everyone wants an exciting job. When you spend at work for 8-10 hours every day, he wants to enjoy it, and I think that Kotlin brought this stream of fresh air, allowing him to get carried away again with Android development or even a backend. I think now is a great time to develop.

- Speaking in the report on the Help Scout application, you mentioned how you created it from scratch: “Should I write to Kotlin? But what if I leave the company in six months, and someone else will take care of them? Java is more reliable. Then it sounded very reasonable, but now the situation has changed. What is the result, now rewrite all this to Kotlin? :)

- The situation has really changed: now you can not worry about Kotlin, when the developer leaves the company, it’s easy to find another one with knowledge of the language. Today, if you invest time in Kotlin, for the company it will not be a problem.

But I see no point in rewriting the entire application code on Kotlin just for the sake of Kotlin. I think it's more important that new features write to Kotlin. And if there is a problem with the old component, then you can rewrite it.

We are also working on a new project, it is written in Kotlin from the very beginning.

- You paid attention to the emergence of the library ΛRROW , designed to write to Kotlin "more functional" - but how do you think this is in demand?

- I think yes. Its creators did an excellent job. First, they merged two existing libraries into one. And secondly, they devoted a lot of time and effort to the documentation, site and examples. In the end, it attracts people.

And I think, although Android does not look like the best platform for a functional style, it also allows people accustomed to other languages ​​to come to this platform. If you are a Scala developer and are used to the appropriate style, it’s now easier for you to get into Android.

Ultimately, this is another tool to achieve the same result - in the end, you can still write an application. And what really matters is whether users like it. But in the process you can get a lot of fun.

- You have long been in Android development, your first device was the HTC Magic. In your opinion, what are the main differences between the development of "then" and "now"?

- I would say that when I started doing this, there was really no place to look for examples. There were only 3-5 blogs about Android development. Today there are breakthrough blogs, courses and examples. Any counter code on GitHub can be read and learned. You can read a book, take an online course or a course with a personal visit, conferences around the world take place almost every week. Constantly something happens. Now it is definitely easier to integrate into Android-development because of the abundance of available information.

And the devices have changed a lot. Then we could not even think about modern multi-core smartphones with several gigabytes of RAM. Now, not so much time is devoted to fine tuning of your application, because on Pixel 2 you will never encounter a lack of memory - well, unless something is completely wrong at all.

“Today, Android developers often say“ I’m waiting to finally be able to drop such and such a version of the API. ” And then the change of versions was even more important and painful?

- Then there was no developer previews, as now, when months before the release of the new version, you can already test the application with the new SDK.

And when Honeycomb 3.0 came out, it changed everything. Fragments appeared. What do we do with them? Why do they need us? API changed where more radically, than now.



- I would like to ask a few questions about authentication. On Habrahabr wrote not so long ago that many use the Account Manager, not because of himself, but because of the Sync Adapter. Do you see the same picture? Do you think this is a problem?

- Yes, the same, it is all because of how the framework works. Sync Adapter needs a Google account. And this account is visible in the framework only through the Account Manager.

This is sad because it has nothing to do with authentication, it’s about the need for a Sync Adapter itself. And so many people have stopped using it: you need a bunch of boilerplate-code only to synchronize data, and it hinders.

But, fortunately, there are now other options for synchronizing data between the device and the server, not requiring the Account Manager. There is an Android Priority Job Queue from Google, there is an Android Job from Evernote.

- In the same hackup, the Account Manager was also praised for general authorization for several applications. But praised the employee "Yandex", where the whole bunch of applications, but it is still an atypical situation. Since the Sync Adapter has decent alternatives, and the average developer does not work for the giant company, how relevant is the Account Manager for such a developer?

- It is true that for large companies it is especially useful, allowing you to make a single point of authentication for all their services. If you are Google and you have Gmail, Google Maps and so on, then it is much more convenient when the user does not have to log in to each separately.

But even if you have only one application, the Account Manager can still be useful. The main thing is that then you get from him - secure storage of user information. I will discuss this topic in more detail in the report on Mobius.

- Remembering that you have been in Android development for a long time: how much did authentication change over time?

- The basics have remained the same, the same methods have been available to us for years. But now we have more tools that make life easier.

For example, when you open an already used application on Android TV or somewhere else, you will not have to face authentication again, because Google will store tokens and allow access.

And authentication using Firebase has evolved and become more popular. A few years ago, if you wanted to use Facebook or Twitter as a way to login, you had to use their SDK. And now you can rely on Firebase, and this makes life easier by removing the dependency on Facebook and Twitter. This is very attractive for many developers.

And it makes me happy: although authentication is not the most attractive topic for a report at the conference, I think we all have to deal with it in our applications. So it's always nice to see ways to make it less boring than just two text fields for a login password and a button.

- But with all this development, you do not consider any way to be the “best”, it all depends on the specific scenario?

- Yes, the authentication method is very dependent on the company and its size. If you are a small company that already uses services like Firebase, which allow you to figure it out at the same time with authentication, this will make your life much easier.

There are other factors. For example, the Fingerprint API looks very attractive, but in reality, not all devices have a fingerprint scanner. Therefore, if you are developing an application for one particular country, see what percentage of users there will be able to use it.

- Since there is no better way and it is necessary to compare, it might be useful to create Android Authentication Blueprints by analogy with Android Architecture Blueprints? :)

- This is a very good question! Never thought about it. It may be worth asking during the report and see how people are interested in this. A good idea!

A minute of advertising: we will organize the Mobius conference in St. Petersburg, at which David's report “Android Authentication made simple” will be presented, as well as many other things. You can see all the already known details and buy a ticket on the conference website .