Start by mentioning Zalando. They were very kind, giving me time to work on this presentation during work hours. So that's cool, and I'll have a link at the end if you're interested in finding out more about jobs there.

So before we dig into the specifics, I wanted to ask if anybody here has looked into either React or React Native. Familiar with the React architecture? Okay, some of you. Okay, so I'll start with a quick overview of what React is and how it fits together.

So in Android, most of our apps are using some sort of presentation pattern like MVP or MVVM. And typically, that means your models and state changes and UI logic. They're all separated, but it's up to you to decide how and when your UI gets updated. With React, that's pretty much decided for you.

You have a UI component that is the UI. Pressing a button or something like that will generate an action. That will in turn modify the state. And then that will call your render method again to redraw your UI.

So that makes state a first class citizen here. And the UI gets re-rendered any time it changes. You have unidirectional data flow. And with that, you can build reusable blocks with a well-defined pattern. And not really have to worry about

a lot of the moving parts that you get with traditional Android development. So with that, we can move into looking at a sample app to visualize how some of these things fit together. Let's see here. All right, just making sure that looks okay. So this probably looks familiar to a lot of you,

even if you haven't done any JavaScript. It's the imports where you just list all of the things that you're gonna be using in the component. And over here, you see there's no braces around the React. That is what's called a default export. So this React package or component here exports that.

And then these in parentheses are named imports. So yeah, we're importing React itself and the component class. And then here's a bunch of things we're importing from React Native. You'll notice things like text and text input and view.

They sound very similar to things on Android. And in the end, they are displayed as views, but they're React specific implementations of those. We'll see how some of those work in a second. There's also a style sheet and this app registry, which is kind of where you connect into Android itself.

So yeah, imports, fun stuff. And then below that, we actually have the declaration of our component. Anybody who's done JavaScript in the past might think it's weird to see that we're extending anything, cuz hey, JavaScript doesn't have classes. But yeah, it does now. You've probably heard of ECMAScript.

I guess currently ECMAScript 6 is the current version of JavaScript. And it brings a lot of things that we've become accustomed to in Android, like inheritance and lambdas. I'll have some examples of that in a second. So yeah, then even if you're not familiar with JavaScript, you can kind of tell what this is doing. The component has a constructor.

Properties get passed in. Those are basically read-only things that you get from your parent. And then we have state, which I mentioned before. It's kind of the thing that drives React. And it's generally a map or an object of some sort. So here, this is just a greeting that we're defining with an empty string.

And now we move to the much more exciting stuff here. I mentioned in the talk description that there's HTML in the JavaScript, which is very weird, but it's perfectly normal in React.

And so the render method, this is the one that does all the work of displaying our UI. It's kind of like a XML layout file in Android, especially if you've done data binding, it's kind of the same concept. So here we've got a outer wrapper that's our container for the UI.

And then we've got a text input. And you can see I'm just assigning styles here. I guess they basically look like data binding tags. And then placeholder, just like a hint in an edit text. And then here's where I guess some magic happens. You've got the change text, and here's one of those lambdas.

Take the text that's input and we just set the greeting to that text. And then if the greeting is non-empty and non-null, we're going to show hello whatever you typed, otherwise null. So pretty simple.

And then to round this example out, here's what styles look like. If you've done any CSS for the web, it's very much the same, except the kebab case, if you wanna call it that, with the dashes in between it is just converted into camel case. There's also some React and React Native specific styles here, but

in this case, these are all just using the standard CSS attributes. And then finally, this little bit down here at the bottom registers the component with React Native itself, so we can interact with it on the native side. And since we have internet here, I should be able to show you this example.

Except it's not on the right screen, so, and this is a really cool site, by the way, you can just write some React Native code and run it right there. So if I type droidcon, yeah, so.

This slide will have this link if you wanna look at it and play with it, but yeah, that's basically what that does. Okay, let's see, something else to mention. You see these dimensions. These are DPs on Android and Pixels in iOS.

I know iOS is moving away from Pixels, so I don't know what to say about that. But yeah, on Android those are DPs. So now that we have a basic understanding of how a React Native app fits together, I wanna tell you a bit about my experience integrating with

React Native in our app. I'm not gonna go through all the steps of setting this up, cuz there's some really good documentation on the React Native site. And tons of tutorials and even generators that'll create a new app for you. So this is specific to integrating with an existing app. First you have this package.json file that you'll create.

You can think of it as similar to your build.gradle file. And that's where you're gonna put all your dependencies that you're pulling in, both dev and release. And then also various scripts for things like building and debugging and all that good stuff, running your tests. Very much the same as build.gradle.

Then the next thing you do is, this is where it kinda starts to get weird. You have this node modules directory where all the JavaScript stuff lives. And you add a project to your settings.gradle that points to that node modules directory. So the React Native dependencies are coming from NPM and

being compiled into your app via Gradle. So that's how that piece gets in there. And then finally you're gonna have one or more activities that actually load that component that we saw registered at the bottom of that example a second ago.

And that's how React Native is up and running in your app at that point. Let's see here. And then, yeah, another last little piece. You have to actually run a command when you're developing to start the process that bundles the JavaScript into your app.

This is what allows you to make those, you saw as I was typing and it was instantly showing up on the screen, that's the magic that happens. You edit a file, you save it, it's immediately available to your app. And you can even use hot reloading to just see it on the screen instantly.

So yeah, it's basically how all that works, so simple enough, right? No. Does anybody have any guesses what my problem was? Okay, well, that's why I'm here. Okay, so yeah, when I tried this,

their React Native was using a different version of OK HTTP than our app was. We were using something newer. And they were still using 3.4. This was a few months ago, by the way. And if you're playing Square Library, bingo. Yeah, there's your Square Library mentioned for this talk.

So yeah, without going into all the details, there was between OK HTTP 3.4 and I guess 3.6, a bunch of breaking changes. Some packages got added and moved and all this good stuff. So that meant we couldn't just put React Native in our app and

proceed with all the fun stuff. Let's see here. So it's open source, somebody's probably solved the problem, right? First thing I did when I ran into this was go to GitHub issues for that repo and start reading through. And yeah, some kind soul had opened up a pull request to update React Native to

OK HTTP 3.8, awesome, let's see how that discussion went. Yeah, so let's see, I'm not gonna read this whole thing to you. But this part here, all apps that use OK HTTP and React Native need to be updated at Facebook. Okay, so we're gonna wait for Facebook to do this before we can, yeah, use this open source project.

It's not a simple drop in replacement, all this needs to be coded and tested. Someone will have to volunteer, we're not even gonna pay them. Yeah, someone will do this eventually. Yeah, that was like alarm bells for me, like whoa, should we stop here? Well, the people on the pull request didn't think so.

So then they're like, hey, why don't we just basically shade the dependency? So I don't know, I thought I'd see what's actually involved in that. There's a plugin called Gradle Shadow that will let you, in your build.gradle, say, okay, take all these OK HTTP packages and

put them in this other package. And then if you were crazy enough, you could change your app's dependencies to point to the shadowed one, and then React Native could still use its version. I think peer there was suggesting doing that internally in React Native, not in your own app, but yeah, it's pretty wild, just beat it into submission.

So yeah, at that point I was really kind of freaking out. So it's just these kind of things you have to remember to explain to new team members, and no library is worth all of this. So anyway, I thought, well, I'll just wait.

And four months later, it got merged. But then shortly after that, it got downgraded again. And basically there were some issues in OK HTTP 3.8 itself. And they downgraded to 3.6, and 3.8.1 fixed it. So yeah, and then it's, yeah, pretty ridiculous.

So yeah, eventually it got it all worked out and cruising along. And then some of you might have heard about this the last couple of weeks. Basically Facebook clarified their position on their open source licenses.

And it basically amounts to, you can use our software, our open source software. But if you sue us for patent infringement, you lose the license. Basically taking their toys and going home. So, and this also applies to GraphQL, by the way, not just React Native. So it's interesting, cuz a lot of people I've talked to aren't so

concerned about this, but it sounds pretty scary to me as a non-lawyer. So yeah, basically if your company does anything that Facebook might be interested in doing in the future, this could be kind of a legal gray area. And I kind of like to think of it as a digital version of the old mobster line.

Yeah, nice app you got there, it'd be a shame if anything happened to it. So either way, this brings us to our first consideration when deciding to use React Native, that it's just a really big dependency, especially if you're putting it into an existing app.

If you've got a lot of native code that's using a bunch of popular open source libraries, it could limit your ability to upgrade to them. And I use this picture, which some of you may recognize from Office Space. Is this good for the company? Because we gotta keep this in mind, these large companies that are open sourcing software,

they're building this stuff for their own needs, and rightly so. It's nice of them to share it at all. So these libraries kind of serve as a recruiting tool and it solves their needs. So you kind of have to take that into account when you're trying to decide if you're gonna use a library. And while you could fork any open source project,

something this size, it's probably not very wise to do that. So, assuming I haven't scared everyone away and have you saying, hell no, React Native. Let's talk about what it's actually like to use it. So, you could certainly use Android Studio to edit your JavaScript files,

but it's not gonna give you any native support. You'll probably see a lot of syntax errors and everything else. You could also use IntelliJ or WebStorm, but for me, I think it's just as easy to use your favorite text editor. Facebook has one called New Clyde, which is just a wrapper around Adam that adds

some React Native friendly stuff, and Adam itself is also good. That's what I started out with, and actually recently just switched to Microsoft's Visual Studio code, which is really weird to me cuz we're in an Android talk, we've mentioned Facebook, now we're talking about Microsoft. So yeah, the JavaScript world is very interesting if you haven't checked it

out in a while. So let's see here, I'll go into more about why VS code in a minute. Debugging, I've had varying success with hooking up break points and actually hitting them in my text editor.

If you've done web development and you're comfortable with the Chrome dev tools, they're fine. You can add this debugger statement anywhere and the Chrome debugger will be nice enough to stop there for you and let you inspect things. And then something you would definitely have to get used to if you're coming from Android is there's a bit more typing.

You have to add the imports I showed earlier, like a caveman just manually. Visual Studio code is probably the closest I've seen to making this a little easier. They have, you can import some type definitions from other kind souls on the Internet, and you'll get auto-completion very much like you would see in Android Studio.

And another reason, which I'm coming to, is I don't know if any of you have seen this before, but it's pretty true. Like JavaScript and Java semicolons and curly braces and that's pretty much where the similarities end. And it's pretty wild because JavaScript itself is like 20 years old and

we're still talking about it, which is pretty interesting. jQuery was making it more palatable for quite a while. And I was surprised when I got back into JavaScript to find out nobody uses jQuery anymore. So yeah, a lot has changed.

And one of probably the most exciting changes for those of us used to Java and static types, is you now have a couple options for bringing types into JavaScript. These are basically for your use as a developer, it doesn't really change the resulting code.

Flow does, this is another Facebook library, BSD plus patents, if you're wondering. No, I don't know. I think so, I guess it's considered open source as well. So Flow gives you some type checking, but it's still JavaScript. TypeScript is actually, you could think of it as another language.

It compiles down to JavaScript. You don't ever have to look at that JavaScript, but if you do, it's quite readable. TypeScript's what I've been using, and if you're gonna use TypeScript, then Visual Studio Code plays well with that, because they're both from Microsoft. Then the next thing you wanna do is configure a linter.

Definitely, especially if you're trying to learn JavaScript, or you haven't done it in a while, cuz the linter is going to clue you into a lot of the style rules. Airbnb is a big name in the React Native space. They have open sourced their TypeScript and JavaScript style guides. So if you configure a linter and use theirs,

you're kind of on your way to writing at least better JavaScript than you would without it. And then there is a library called Prettier that will format your code when you save it. So if you set up your code to auto format when you save it,

I know a lot of us have this for Android code as well. You can eliminate all those debates you have in pull requests about where the spacing is, where the line breaks are. This just makes sure everybody's code is written the same way. It'll handle auto indenting and even some small things like

adding commas at the end of a list and all of that when you save it. Sometimes semicolons, it just depends. Okay, so talk about some more not so great things this time from the development side. So as you can see from the previous slides, there's quite a few new concepts to learn if you're getting into this.

And there's a few less than ideal things. The first one, which is kind of mind blowing, is that this hack for handling orientation changes, as far as I could tell, that is still the best way to handle orientation changes in React Native. There's no save instance state, restore instance state, or

you could lock to portrait, I don't know which of those is better. And actually, I should also mention, if any of you are like React Native experts and you hear me say something, and you're like, that's not right, please come tell me cuz I'm looking to learn some of this. This is, yeah, what I've seen so far.

And then there's some, the other interesting thing is there's third party solutions for everything you need to do. But some of them are things that you would kind of expect to be built in, like material design or even multi-language support. So a lot of it becomes a game of finding what's the library of choice for

this given problem. And there's usually one, sometimes there's two, but usually there's a clear leader. So yeah, this brings us to our, sorry, yeah, last thing. So you can enter up with native code, and I'll talk more about that in a little bit. Completely possible, but

you do have to write a few extra classes to make that work. You can think of it very much like the same boundary between API server and your app. There has to be a clearly defined contract in order for that to work. So yeah, this brings us to our second consideration. It's totally different than normal Android development.

So if you have a team of JavaScript developers and you wanna build a native app, great, they'll be right at home. But if you have a team of long time Android or iOS users, React Native's probably a harder sell for a lot of them. Especially now that we have Kotlin on the Android side,

things are looking up. But yeah, and for some this might actually be a good thing, cuz maybe you're wanting to learn something new. But yeah, it's still something you should definitely consider. Yeah, so then, as I mentioned in the talk description, one of the killer features of React Native is the ability to change code and

see it on a device almost instantly. But yeah, this kinda puts a darker spin on that. And as luck would have it, right after I found out I was gonna be giving this talk, I saw this tweet and I was like, that has to go in there, it's great. So yeah, I mean, it's kind of obvious.

If you build anything too fast, too quickly, with any technology, without fully understanding the fundamentals, then you're gonna have technical debt and React Native's no different. So there's tons of great books and tutorials to help you with that. But definitely something to keep in mind. This isn't gonna make it to where you don't have to think about writing

quality, well-tested code. And speaking of testing, definitely one proven way to ensure that you've written quality code. And on React Native, we have a couple frameworks to help with that. The first one, another Facebook product, Jest.

This uses what they call snapshot testing. So I don't know, this may be a stretch. When I was doing Ruby on Rails, there was a gym called VCR that would take essentially a snapshot of your API request. And then you could run your test against that and kind of simulate that request.

Just kind of the same concept, it renders your UI component and saves that. And then you can write test to assert that as your code changes, the UI is still the UI that you expect. So if a Jest test was failing, you would have to ask yourself,

did I change this on purpose, or is this a regression? So it's there to help with that. Then another Airbnb library, this one's called Enzyme. To me it's very much like Espresso or Robo Electric in that it mocks out the rendering and you can do the same stuff you would

do with Espresso, clicking things, asserting things, and so on. And in the process of working with those, I came across something very important. Enzyme is currently only supporting, it's a React, I should have mentioned,

it gets really confusing with React and React Native. Enzyme is a React testing library and they've committed to only supporting release versions of React. An interesting thing about React Native is they're using an alpha version of React. So, and I'm not gonna show pictures of the GitHub issue here,

but same kind of discussion as we saw with the React Native pull request. The solution is basically stay on a lower version of React Native that's not using an alpha version of React. So yeah, interesting stuff. So moving on to cross platform, that's another benefit you'll routinely hear people mention about React Native.

We've been able to have the same code running on both Android and iOS, but there's things like keyboard behavior and other platform specific things. So you're not gonna write code that's like 100% cross platform. Kind of just have to figure out the best practices there.

I think over time we'll start to see there's certain things that lend themselves well to cross platform and other things like no, don't do that cross platform, do that native. So yeah, how much stuff to share, what's okay to duplicate. These are all, I still think for the most part, open questions. You can find a lot of blog posts out there doing their best to guide you in

that, but yeah, it's still evolving. And then my advice would be to stick to native code where you need it, especially if you've got an existing app with a bunch of well-tested native code. As I said, you can call through back and forth between them as necessary. So let's see, there's a couple ways to

specify the platform specific behavior. This first one is basically the same as our OS version checks in Android, but sprinkling this all throughout your app is gonna make it a lot harder to maintain, especially since these are kind of important platform specific things.

You don't wanna just have this all over your app. Another little more explicit and declarative way to do this is these extensions. So by default, React Native, you could just have a component.js and it would load it on both platforms if you had, and

component's just a generic name here, by the way. So if you name them with these extensions, it will load the appropriate file for that platform. And then you can have shared files that those two would reference. So that brings us to our third consideration, which is the sharing

code between platforms while keeping it maintainable, something that your whole team has to commit to. Lady and the tramp seem like a good sharing picture. Okay, so another feature that you'll hear about React Native that's not available to traditional mobile apps is

the ability to push dynamic code updates with Microsoft's code push service. So you can actually deploy new code and your users will receive that update without having to go install an app. You can even do it quietly where they don't even know that it happened.

Which sounds kind of shady, but I mean the idea is they get new features without having to do anything. I'm not gonna read this whole thing, but this is the justification on the code push site about why this is okay. Cuz at first it sounds too good to be true. Anybody knows about the iOS app review process, or anybody who's gotten one

of those scary terms violation emails from Google Play. You'd be kind of skeptical that this could really work. But yeah, they're supporting their case with what seems to me a single piece of anecdotal evidence that they updated an app to the app store and it didn't get taken down.

So hopefully that makes everyone feel comfortable. But yeah, it's still out there and it's still a thing. And it is one of the bigger selling points of React Native, depending on your needs. So yeah, they also outline some best practices for using code push. Cuz it's a pretty heavy hammer and

you wanna be careful with how you use it. So in general, they recommend that you check for updates on app start. But you don't apply them until the subsequent session. The idea is that you're not surprising the user. And then you wanna test your updates pretty thoroughly, as with anything. And there is rollback functionality.

In fact, it's automatic. And if they detect that an update failed, it'll just roll back to a previous version. So there are some safeguards, but yeah, still smart to test it. And then, yeah, as I mentioned, don't surprise the users, kind of the biggest point to make there.

And yeah, so then this would be our fourth consideration. The pushing updates without an app release is obviously a great power, but it should be used responsibly, the so-called Spiderman rule. Let's see here. So yeah, now you know a bit about the pros and cons of React Native, and

have some tips to help you decide if it's right for you. Assuming it is, I can show you next how to get some of these benefits and minimize the weirdness. So as I mentioned, one of the primary benefits of React Native is the ability to quickly prototype a UI and see it on the device right away.

But if you have some existing code and you wanna make the UI in React Native, but not rewrite your whole app in it. Yeah, here's an example of how you could connect React Native to live data, which Google announced at IO this year. So I use beer in most of my examples, as you can see.

So the first thing you do, and this is Kotlin, yeah. So you extend this React context-based Java module. This is your signal to React Native that you've got some native code that it needs to be aware of, and yeah, injecting some stuff.

We've got a repository and some Gson, or an instance of Gson. And live data, which in this case is just gonna give you a list of beers. I don't know, popular beers or something. And I've omitted kind of the non-React stuff. You have to override this getName function, which is the name that you're

gonna expose this as on the JavaScript side. And this React method is a method you're going to expose on the JavaScript side. So when you call this, it's just going to observe this live data until you tell it not to.

And so moving to this next slide. Then here's the corresponding unsubscribe method. I found out that, yeah, this has to happen on the main thread, otherwise you'll get an exception. So you have to unsubscribe from the live data. And then any time the live data changes,

we're going to pass that data back to the JavaScript side with this. This arguments createMap is part of React Native. So it's kind of like creating a bundle. You're gonna just, in this case I'm just gonna serialize that to JSON and pass it back as beers. And then this is where you're actually handing it off. You'll see this device event emitter in a second.

So it emits this beer changed event with that JSON that we saw up above. And yeah, here's the JavaScript side. I didn't go through the React Native component life cycle, but you can tell from componentDidMount and componentWillUnmount that,

one, it has a life cycle, and two, the person that wrote it probably did iOS. So yeah, same kind of thing here, extend the component. So when the component mounts, we're going to register this change listener to that beers changed event that we saw in the previous slide. And yeah, you'll see this down below.

And then yeah, when it unmounts or when it's kind of going off screen, we're going to remove this listener and unsubscribe from our live data observing on the other side. Sorry.

Actually, I guess I don't show the implementation of this onBeersChanged, but it would work the same as we saw in that first sample where you're typing and you're setting the state when that occurs. So yeah, that's, okay, so now here we are. Basically, is it worth it?

Of course, the answer is you probably just figure it out as it depends, especially on your needs, specifically. But yeah, to recap, it's a really big dependency, so you have to decide if that's something you're willing to live with. And it's way different than normal Android development, which may or may not be a good thing, depending on your perspective.

And yeah, you can share code between platforms, but it requires some work and discipline. So definitely keep that in mind. And finally, yeah, pitching the app updates is pretty powerful, but it's a big hammer you have to wield carefully.

So yeah, I guess I went a little fast. I've got some links here. My blog, I mentioned Zalando jobs, some coworkers and I have this publication on Medium where we attempt to have high quality Android development articles, if you wanna check that out or submit to it.

And there's me on Twitter. So yeah, I have plenty of time left for questions if anyone has any, or advice, suggestions, whatever. First of all, thanks for letting us know that we shouldn't use.

Ah, that's not the point. Okay, about the Google and the updating you mentioned, I read in Google Play documents that any app that update itself from other ways than Google Play would be banned. Update the functionality, but I'm not sure if it's the case or not.

My question is, right now, Kotlin exports some JavaScript. Is there any way to use Kotlin for this React code, or? I haven't looked into that, it's probably possible. It depends how many layers you want, cuz I'm a fan of Elm,

which is similar to React as far as architecture. And someone also made an Elm native, and it was really intriguing until I found out it's Elm sitting on top of React Native, which yeah, it depends how many layers you wanna put up with. Okay, thanks.

Can you share what you were evaluating React for, and what you are using it for now? At this point, it's still in the exploration phase, but I think what attracted us to it is the rapid UI development and the dynamic code push updates.

And yeah, also making it easier for non-native developers to develop. Since you used Kotlin and JavaScript both, and since Kotlin is compiled to JavaScript, have you tried to actually write DR up in the Kotlin fully?

No, something I need to look into. But yeah, I haven't even tried the Kotlin JavaScript stuff yet. We're checking out. Yeah, thank you, great talk. I have to say, I'm still pretty excited about some cross-platform stuff,

and also about React Native. But not so much a question, but still maybe you wanna comment that I understood this as a big no. So I'm a little bit disappointed not by your talk, but by my expectation maybe, maybe you can. Well, so even my perspective on this has changed in the course of

the last several months, cuz at first I was very much like no, and I was constantly trying to find a reason why not. And it's kind of changed to, well, there's a lot of weird stuff as I showed here. And part of my reason for presenting this was to hopefully start a conversation with other people, cuz I've gone to a lot of meetups and people talk about React Native, but I usually kinda hear that everything's great.

And I know there's obviously some rough spots. And yeah, it'd be nice to share ideas and talk to people who are also trying to use it, and yeah, find out what works and what doesn't. So in short, I guess it has a place, and I'm still trying to figure out where that place is, and where it makes sense to use it, and where, yeah,

where to draw that line. Maybe I also was only looking for a big yes. And I'm disappointed I didn't get that. Anybody else? If not, I will be up here for a few minutes. Thank you. Thank you.