Thank you. First, I want to give you some context. As Android developers, you know how important context is. If you don't know, there's a really good talk by Ronan Zero Schwartz. Context is magic. You should look that up. Over the years, I was writing

a lot of Android apps. And I think DRY is the most important software pattern. There is. And it should not only apply in one app, but also between apps. So this is how a typical build.gradle file looks in my projects. And I see it's a part of that.

And you see a lot of these com GitHub things there. And some people might already know what that is. These dependencies are coming via JIT pack. And that's a very easy way to share code between a lot of projects. And you can also do nice things with mighty module

builds. For example, for different flavors here, use different implementations from a mighty module build. The only thing you should consider with JIT pack is security aspect because it's then a single source of truth. So if you use it for security relevant applications, always use gradle witness. And by the way, we should replace that with

a decentralized system with true bits. If you want to talk about that, grab me later. And then you just use it like that. You add another repository. In this case, JIT pack. And then you can use these libraries. And the nice thing is you just push them basically

to GitHub. You don't have to upload to Maven central or to JIT pack, to J center and do a lot of things. You just make a tag, push it to GitHub and then your library is good to go. And JIT pack is really nice for that.

One library I use in basically all of my projects, it's KAXT. It's Kotlin Android extensions and all Java times it was just AXT Android extensions. And it's basically a thing you use around all the projects is just to make code shorter. A lot of people have these utility things around. And it's basically, you know, like if you add a text watcher, usually

it's really big and you just want to say that's what you want to do after editing a text. Or often you have this like you want to set visibility with a Boolean and not like if true, then set visible, otherwise invisible. And a lot of these small stuff

or starting an activity from a class, it's just a lot of things you often use. In old Java times I was doing it like that because you want real IDE support. I was always wrapping it in an AXT and that was giving me the right implementations for different

stuff. But nowadays with Kotlin extension functions, it's just much nicer and much nicer IDE support. So, I'm basically just using the KAXT now. Another thing I want to talk about because we're not just developing stuff for our own, we want to have users. And one library I was writing is SnackEngage. And it's helping you to engage with your

users in different stuff. Like one common thing there is that you want to get your users that they rate your app. Because if they rate your app, you get ranked higher in Google Play and then people find your stuff and use it way more often. And it's

basically making a snack bar. Before I was using discrete app rate in the old days. But discrete app rate was doing it basically with a custom view and stuff. And with snack bar, also with the coordinator layout, you can make nicer things. And so, I was writing that library. The core thing in there is every snack basically has a snack condition.

Because you don't want to show these snacks all the time, basically. And these are common conditions here. For example, connectivity aware. Because you don't want to tell your user, please rate my app. And he's offline. Because then you basically got him to rate

your app. And he's offline and that makes no sense at all. Or sometimes you just want to do it when he's on Wi-Fi. Because then you know he might be more relaxed in that situation and not on the go with 3G. So, you just want to show your stuff when he's

on Wi-Fi. Locale is also interesting because sometimes you want to get some translators for your app. So, you can make please translate my app snack and only show it to users that have a certain locale. In the end, a more complex setup looks like that. Like always

the default rate snack. Because you always want these rating things. But then also like beta testing. Yeah, you want to get beta testers and you want to get your beta testers from the pool of users that use your app very intensively. Or a translate snack and

you want that for a certain locale and never again when clicked once. And then SnackEngage is basically searching for the right snacks. You can also customize it with icons and stuff. For example, here was using it to basically promote one of my apps from another app. So, kind of cross promotion stuff. And you can also use it for stuff

like that. Speaking of advertising, because all the big companies presenting here also are making that, please install the offline survival menu. Because the shit currently is very close to the fan. And with shit, to be completely honest, I mean Trump and

all these Nazis rising up. So, please be aware. And I love how it's working here. People of all colors and everything come together for gathering knowledge. And I want use any permissions. Just install it. Better safe than sorry, you know. And speaking of

that's the last advertisement thing there. But you perhaps recognize the nice icon. It's from one of the best icon designers or the best icon designers out there. If you need a real good icon, contact this guy. Cookie icons. Very good. Another thing that repeats a lot between projects is UI testing stuff. So, you have to drink

something. And there's also repetition between the projects in there. And always when there's repetition, don't write wet code, dry code. What you often do is

basically for the test app, you replace your application class to do different injections, for example. And the application runner base makes that really easy. The whole thing is in the library. It's called trulesc test rules Kotlin. It was starting with some rules

and extended a bit. And then it's really easy because you then just have to write your own test runner and just add your own test class. What you can also see there before is the test butler. Test butler is a really nice thing from LinkedIn. I wouldn't

use the app, but what's coming from the engineering department is quite nice. If you have flaky tests on emulators, test butler can really help to mitigate that. For example, sometimes you have ANRs from the system from the emulators and something like that and your tests get red. And test butler can really help with that.

In your test app, which you use there, you can then just overwrite, for example, the injection part. I switched most of my stuff now for using Kotlin from Dagger 2 to Codeine. Codeine is a really nice injection framework. And then you just overwrite

that and the test class is used there. Another thing that's in there is the rules, which basically gave the thing the name. And you can use these rules, and they have some do before and do after stuff. And that's basically doing that also. Test butler

verify always that your animations are disabled because you don't want these flaky tests because the animations are still enabled. So it directly fails if they are still enabled. Also removing stack trace files from trace. I skipped that library because there's so

much exception handling libraries out there. But I still use my old trace because it has the advantage that you can mail to the users. Basically, I collect all these stack traces and then I give the user the option to mail them to me and that gives me the opportunity to directly engage with them. That's often with other crash tools really hard and you

want to know. Because sometimes stack trace is not really conclusive. You want to talk to your users and know really what happened there. And it also adds the failure handler. Spooning failure handler. I will get to spooning a little bit later. Yeah. And turning the screen on. That's all stuff. You constantly have

to do it. It's not much. But if you have to do it every time and sometimes you forget it and then things get messy. So do it with the library. And if you extend that there, then you have it for all your projects basically. It also contains stuff like little test helpers that you constantly use like invoke menu when you want to press

a menu button. By the way, if somebody has a better solution than that for invoking a menu when it also sometimes is in the overflow menu, please tell me. I was never finding. But it's a good thing also about the library. If I find a better solution, I just have to change it at one place and all apps benefit from that. And I basically

use it like that. That's a typical Espresso test. You use the activity test rule and do a typical test. And then you see the screenshot thing here. That's a function of Trulesc also. It's then making screenshots with Spoon. Spoon is a really nice library

from Square. Basically you can generate reports from all your tests and see all the screenshots from your tests and if they fail, why they failed at the logcat and stuff. It's really helpful to know afterwards what's happening. And you can also see screenshots between different devices. So basically compare them and stuff.

Before I was generating all these reports with Jenkins, Jenkins 2 got way better than Jenkins 1 was because you have the opportunity to write stuff and copy that between projects and you don't have to click a big setup. Because you make a lot of projects and then

always you have to click your setup with Jenkins and stuff. But I ran into some problems with Jenkins because it's trying to cover that much. For example, I got constantly out of tokens with a lot of projects and out of GitHub tokens and I used this hub tool.

Is anyone aware of the hub tool from GitHub? It's really nice from GitHub and you want to just clone a project on the command line and just look up GitHub hub tool. But that was telling I'm out of GitHub tokens because Jenkins was using all of them. And also

other problems always the reports are 404-ing because Jenkins isn't really tightly integrated with Git where you have commit hashes basically. And so it also still supports SVN and CVS and this stuff. And then you have a problem to get that in sync basically.

DDD reports and your commits. And I only use Git so I know I can tightly bundle the reports to Git commits basically. And I want really fast configuration. So basically two

options to solve that. A fight with Jenkins and get Jenkins to do what I want. Or write my own CI and basically I ended up with a second solution because it was way faster in this case. It was called GitHub integrations before. Now it's called GitHub apps. And

you get nice callbacks there. So you add integration like that. I call my integration for continuum integration. And then you get webhooks for every event that happens in GitHub. Basically, for example, a push event. And then you can react with that. So

you can use Kotlin only for Android. But you can also write nice stuff like server side stuff with that. And that's, for example, a simple web server that handles these push events where it's using Ktor. And if you've been to the coroutines talk before, you also see it's using the coroutines there. And basically then you see these answers

here. Thanks, GitHub. Always be polite, you know. Also in code. And then what's also cool about this is you can have very, very tight permissions. I only give it permission to write statuses to commits basically. And getting the webhooks. But I don't need

a lot of permissions. Like GitHub app. The old API has a very broad permission stuff. Like if you need to have permissions, you have to be very broad. And you use JSON web tokens there. And what's happening then there, you see these are the statuses at the commits

basically. And these statuses at the commits you see here then resolve in IPFS links. Is anyone aware of IPFS here? Very good. That's good. For the others, it's going away from location addressing to content addressing. And I think content addressing is really

future because you don't say my stuff is there. But you say my stuff looks like that. And basically you identify your stuff by the hash. So, I don't have this problem with the for-foring reports from Jenkins anymore. That's way better. It's not for-foring anymore.

The permanent web IPFS, look it up. It's really the future. I was also writing a little project. If you're interested in IPFS, I saw some hints there. Maybe you want to look that up. Because then you can also replace all the at the moment I'm using gateway

HTTP gateway IPFS. Because we are still in the world in between. We don't have the permanent web on every computer yet. So, you have to use the gateway. But otherwise you can then use like FSIPFS like URLs for that. And then you also I only do that

at one point. And if we are in a world where we have IPFS links everywhere, I can just replace that. And the right links will appear everywhere. Yeah. This is the stages. Like Continuum uses stages basically. And it's typical

spoon stage. So, it's really tightly bound to Android and Git. So, that makes things really easy. And that's basically what I do. Lint test and also assemble it. Then gathers all the APKs basically that finds in the project. And also puts them

in IPFS that you always find them. And with reproducible builds, like there's something happening on Android now. Then the hash also stays the same all the time. So, beautiful future there. Variant filters are also very important there.

Because then you always use a lot of flavors. For example, for Android, for Amazon, for Play. And some combinations doesn't make any sense. For example, some closed source stuff on Android would not work. So, you exclude these flavors. So, that your jobs are basically executed really fast. And let's use Kotlin for more. You have seen a lot

of Kotlin at this conference. And you can use Kotlin for way more stuff. And that's basically how the base thing from Continuum is working. The magic is basically behind

process work packages and startup server. But it's actually not that much. So, it was the right decision to do it that way and not to fight Jenkins and all these constraints I have there. It's the last day of DroidCon today. So, if you travel home, don't print

your tickets. Use Pass Android. And use your tickets with that. Because we don't want to destroy this earth. We want to keep it so that we don't need the server menu at all. Thanks for your attention. This is my URL. This is my guitar page. And have a very nice day.