Hey, everyone, and welcome to Developer Team. My name is Jonathan Cottrell, and in today's episode, we're going to be talking with Tony Hillerson. This is part two of the interview. It's kind of a long interview. I really appreciate Tony taking out the extra time to detail all of these mobile app frameworks that he has written about in his book, Seven Mobile Apps in Seven Weeks. If you haven't read any of the Seven in Seven series, make sure you listen to the first episode in this interview, by the way, but go and check out the Seven in Seven series. It's really cool, but Tony's book, Seven Mobile Apps in Seven Weeks, has a really interesting take on mobile application development, specifically diagnosing what type of framework you should use, which one you should pick. We left off in the last episode talking about... Android, and we'll pick up right there in this episode. Today's episode is sponsored by FreshBooks, the ridiculously easy-to-use online accounting software designed to help people like you, creative entrepreneurs, get organized, save time, and perhaps most importantly, get paid faster. We'll talk more about what FreshBooks has to offer to Developer Team listeners later on in the episode, but let's dive right in where we left off with Tony Hillerson. Right, so I didn't get to use Swift, and I have played around in the past with using things like Scala on Android, but this is just plain old Java. But I will say this, maybe a little bit out of turn. If you've ever worked with Java, Enterprise Java or something like that, got a bad taste in your mouth and thought, Android's not for me because it uses Java, it's a really different experience using Java on Android. You're really developing Android. You're developing Android to the Android APIs and SDK more than you are writing Java, I think it feels like. And there's lots of things to make it more palatable if you think that Java is kind of a showstopper there. So yes, don't let that stop you investigating Android. What I did for the Android app is, like you said, it's a currency conversion app, so I take a floating... I got a floating point number, and I got taken to task by this by a reviewer, but I didn't want to deal with big decimal and confuse people. So yes, you take a floating point number from a text input and convert it through a currency conversion API, which I believe is also hosted on Yahoo's APIs. What we get to do there on the Android platform is the same thing. We make a web request. So I struggled with this, too. Should I use third-party libraries, or should I not and try to do it as close to the bare bones as possible? Finally, I came down on the side of using third-party libraries for Android, because it's just what everybody does for things like the web request. So I believe I used OKHTTP, which is developed by Square. I actually used Square just before this interview. I was paying a friend of mine. It's opened up a lot of small businesses to give a better user experience for payments to people. I think it's pretty cool. And they've got a really cool technology team who have controlled... They've contributed a lot to different projects, like Android code. There's a lot of cool Square libraries. So I believe that I used OKHTTP. Yeah, yeah. You're welcome, guys. Talk to me after the show. Let's see. I did an interesting thing there that the reviewers seemed to like and I liked, but I wasn't able to really replicate on any of the other platforms. I went through a series of messages. Mistakes of rookie mistakes, I called them. Like, here's things that it's going to, as a new Android developer, seem like the right thing to do, but it's not. So let's do them and just get this all out of the way. Do this, do this, do this. Now, here's why those things don't work and your intuitions might get in your way to learning Android. And that was a fun little exercise there. For anybody who's ever done Android development, you know how hard it is to deal with. How surprisingly hard, not necessarily actually that hard, but still surprisingly difficult it is to deal with rotation when you're rotating the phone through different orientations. What Android does is completely tear down the context of the thing that's sort of like a view controller and throw it away and give you a new one when you rotate the phone, which is like, what? I didn't hear that. I couldn't have heard that right. Is that really what they do? And you have to deal with that as a developer. And it's kind of surprising for new developers. So that's one of I wanted to hit that for Android. OK. On to the next one. I this one was was an interesting one to pick, but I wanted to stick with this theme of of covering native platforms. So it just kind of made sense to me at some point. I got my head around it. I'm going to do a Windows phone app. Why would I ever do a Windows phone app? But I did. And and it was kind of fun. But what was interesting, there was a lot of cool stuff. It's still weird for me when I talk about this. You know, Microsoft used to be the evil empire and all that kind of stuff. And now they're really an underdog and doing cool stuff. Like like going back to when Windows phone first came out, like the Metro design and all that, people were like, wow, that's actually pretty nice. We never would have expected that Microsoft to come up with that. But it's it's it's got a leg up on the other ones. And they had to kind of race. To to to catch up, you know, visually and with ease of use and that kind of stuff. So I thought, you know, that's enough of a reason to to see what Windows phone is up to to these days. And, you know, Windows phone hasn't sold that well. So I don't know how many people are really thinking about getting on the Windows phone platform. But what was interesting when I dug into what is now the Universal Windows platform. So that's what this chapter is about, actually, is. Nowadays, when you develop, you don't develop a Windows phone app separate from a I hope I'm saying this right from a from a desktop application, the same code base, the same APIs and all the tools and everything for developing a Windows desktop app and a Windows phone app are identical. And really what you're doing is a lot more like I think, like like responsive design for the Web. You're thinking about screen. Size and maybe some capabilities of the machine that you're on. But it's the same code base, the same code, the same app. And that's that's new. That's brand new with the Universal Window platform, Universal Windows platform stuff for Windows 10. And that was a lot of fun. So what I did did for this application, which is a stock, a stocks application, so you can put in some symbols and see what the current price is. And it starts out with a couple of indices like the. I think. Like the NASDAQ or something like that. What I did was make that application. Work on a phone size screen and also a desktop size screen. So we dealt a little bit with how to how to do what the thing that's kind of like responsive design for that platform. And that was that was actually fun. So I had fun with that. I had to deal with, you know, not not being a. Not having developed on a Windows machine for a long time and all that kind of stuff. But the tools are pretty good. So I think that that the fact that you can develop a Windows desktop app and have it run on a phone or think, you know, if you do a little bit of extra thought and planning up front, have it be either a phone app or a desktop app is, you know, I hope more compelling for that platform than just Windows phone, which, you know, may or may not have been compelling now. But now it's a it's a wider world that you can reach. So I think it was worthy of inclusion in the book because of that. Sure. Yeah, absolutely. I think just the fact that they have they have kind of held on to that one third spot. Right. You know, we've basically seen pretty much everyone drop out of this race and the Universal Windows platform. I think it actually has a lot of interesting. advantages. And I'm excited to see what happens next. And in the competition, quite honestly, that they that they provide for Apple, especially when it comes to this universality, and also to to Android, the universality of a given app. Yep. And now, you know, as things get into the home, I don't know quite because I haven't looked into it. What do you have to do to develop an app that's a little bit different for TV OS? For for Apple's TV. But there is some difference. And I know, like you have to, you have to jump through a little bit more hoop, hoop, development hoops to develop an app for the Mac desktop, as opposed to an iOS app, like instead of you've got to break something out that's that's shared between them, you don't get to do it all in one project. I assume it's the same for TV OS, although I haven't looked into it. Yes. Yet, I actually have looked into this. And TV OS is an entirely different setup. And it's based. on JavaScript. And it's, it's a totally different thing than if you were to go and build an iPhone app 100% different. Okay, then I'm way, way off there. But I mean, at some point, let's assume that they give you native apps on on Apple TV, like an app store or something, right? Yeah, then then, you know, the question is, what, what's development like? Well, for Windows, and for Windows desktop, Windows phone, and for the Xbox, I forgot to mention that that's also an app, an app, I guess, destination. That's, that's, that's their answer. And it's already you just develop the app, and you think about screen sizes, and the rest is handled by us. Yeah, definitely. Okay, so that covers the the native platforms. And now we can, we can talk about the cross platforms. And just touch on each one of these and kind of what your experience was developing for Ruby motion, Xamarin and React Native. Yeah, so again, I broke the book into what I called platform native. Which was my own word, or own own phrase for this, I had to distinguish between the different native natively running apps for either built by a cross platform tool or or built by the official tools. And I forgot to call this out earlier. But this was one goal of mine for the book, too, is I didn't want to deal with web view type frameworks, I'll call it out. I like no, no hater. And you can I think that's a good thing. But like, Cordova and phone gap, those types of things. I don't, I don't think they're the I think they're the right answer, maybe for for prototyping and proofs of concept apps or something like that, possibly, if all you've got is web technology or web web background. But I really want to focus on the user experience is, is so much better. And you're never gonna, you're never gonna catch the web up on on a mobile device, to native performance, all those things. All those things, like, I just wanted to focus on apps that can bile down and run natively, and instead of apps that are that are run inside of a web view to get the cross platform. Sure. So that's why that's why I had to come up with this, this, this idea of platform native, those are the official natives or whatever, iOS, Android, UWP, and now cross platform, this is the second section of the book. So I think it was just a no brainer, I had to get Ruby motion in there. And it's really, it's really cool to play around with, I played around with it when it first came out. I think it was called Coco something, I can't remember what it was called. It was cool. I think one of them was called, was Ruby mind is the wrong thing. That's the ID, isn't it? Yeah, that is an IDE. It was like, I'll have to look it up. Yeah, I don't remember. But the guy who built Ruby motion came from Apple, and he, he'd done some work there getting, you know, Ruby working for building Coco apps was. Yeah. So that was pretty cool. But then he turned into a business. And it looks like it looks like Ruby motion can also do tvOS and watch OS as well now, by the way, and OS 10. Yeah, so what you're doing is all I mean, underneath, it's still it still uses the, the, the same tools. That an iOS app uses. So for building, so when you're writing an Xcode, when you're writing an iOS, there are some tools now that have kind of been broken out, you can compile from the command line, using something called Xcode build. And there's different tools that you can look at as like a tool chain. And he, and I are he, I guess there's probably more people on board now than just the original creator. But those tools are used underneath the covers by Ruby motion. So with Ruby motion, I built a to do app, which is like a good, you know, that's, that's, at some point, that's probably what you're going to build as a Hello World app on on whatever technology you try out. So I figured why not do the same for a room motion. So that's a, it's a to do app that runs on both iOS and Android. And it started out on iOS, originally and went for, you know, got fairly popular with people who, who like Ruby, as I do. And wanted to use that to do iOS applications, but then it became truly, or at least got into the game of being cross-platform when it released support for Android. I believe, I might get this wrong, it's either 2012 or 13. So that made it possible to include it in the book, although I probably would have done it even if they still only did iOS as kind of a comparison point. But so with RubyMotion, you write in Ruby, you structure your project as a Ruby project. It is running in a Ruby interpreter on the native platform, but it's not Maps's Ruby. It's not the official Ruby. There are some APIs that are missing that you might be surprised about. So that's one of the things that I looked into is how do you, again, how do you pull something down from the web and deal with it and write away like you don't do it with whatever native Ruby library that you would... Yeah, NetHTTP I don't think is available. I think you have to use something like, I believe it's called BubbleWrap. Is that right? Well, so this is where I made a choice not to get into the third parties. I didn't do any third party code with RubyMotion, although that would be the first smart thing to do is to look into that community because there's a lot of... There's been a lot of stuff that's built up by the community to solve these kind of problems. Sure. Yeah. I wanted to stick with what I can do without getting into that because right off the bat, I would be faced with, well, which one do I pick? And is that going to be the wrong choice in some people's minds and all that kind of stuff? I didn't want to wade in that water and make it a... Yeah. The book reader's problem yet. That's something that they should go on and do next, I think, is figure out what third party platforms or third party tools they want to use for things like that. But I still did want to try to make as... So the stretch goal for RubyMotion in this book is to try to make as much of a cross-platform code base as I could. And it turns out the answer is not a ton. It's not super cross-platform. The code shareability, is kind of limited by the fact that Ruby is running locally in an interpreter and you don't get things like net HTTP. So you have to... Let me take a step back, I guess. What's happening when I call a Ruby function or make a Ruby class or call a underlying API on the native platform with Ruby? Yeah. So what I did was I used... So what I did was I used a... So what I did was I used a... So what I have to do to make an HTTP call is to figure out whatever I would do anyway on that platform and then call those libraries. So what I actually did was to... I believe I used... Actually, I can't remember which one I used on Android, but I used another third party on Android so that it showed how to use some native dependencies. And then I used... I used NSURLSESSION, I believe, whatever it is on iOS and showed how to make that call through from Ruby for that particular problem, like pulling something down from the web. So that means that it's hard to abstract. Here's my web request library across all the platforms because you have to, at some point, get down to what platform am I on and what am I going to do to fulfill the request here. But I tried to make that as abstract. So that's what I did. So what I did was I used a... So what I did was I used a... So what I did was I used a... So what I did was I used a... So what I did was I used a... So what I did was I used a... And you can judge as the reader how far I was able to get and how good that is to match the needs of your project. But just like you've already mentioned, there's a big developer community, which is one of RubyMotion's big strengths, I believe, who have looked at these problems and came up with some solutions. Yeah, there's some interesting trade-offs. I've done a little bit of playing around with RubyMotion myself, although it was a few years ago. And there's some interesting trade-offs. I've done a little bit of playing around with some interesting trade-offs. Obviously, some of the stuff that you can do with the built-in array or the enumerators, a lot of that stuff is preserved. So if you really enjoy writing Ruby for the bulk of the code, it's going to feel very much like Ruby. But when it comes to the rubber meeting the road on some of the APIs and even some of the extended module stuff that you're used to bringing into Ruby, some of that stuff just isn't going to work. And it's not necessarily the fault of RubyMotion. It's that that stuff is just not portable into that iOS bridge environment. I'm not really totally up to speed with exactly what is going on there. But you can't just bring that Ruby code in and expect it to be able to translate over to that compiled code that you'll need on that native environment. So there are some trade-offs. There are some trade-offs. There are some trade-offs. There are some trade-offs. There are some trade-offs, obviously. But if you really, really love Ruby a lot, and if that's kind of your favorite language of all time, then it's certainly something to consider. Yep. And I think I ran into that right away. And I don't know if this comes across explicitly in the chapter at all. I'm pretty sure it doesn't. But this is one of the things that you're going to want to know as you try out these cross-platform tools. What? Not like, is there a way to get it done? The question is, how long is it going to take you who have a deadline, who has a deadline, your team has a deadline? How long is it going to take you to figure out what needs to be done? And how comfortable is that going to feel? So is there a convention to do something cross-platform right off the bat? And do you have to think about it hard? Or are you going to have to take some false starts and then, and then take a step back and say, okay, here's what we've got to do instead. And, you know, maybe those resources aren't on the web, but you just didn't find them. How, you know, how long is it going to take you to be an experienced Ruby motion developer because, or Xamarin or, or whatever, because that's, that's something that you have to, you don't just, this, this is a big point that I always have made about cross-platform tools. You don't get an extra platform for free. It's not that that's not what you're getting. It seems like it, and that's the selling point into a manager or a product owner who's saying, well, let's just do, let's just use this tool. And then we'll get this extra platform for free. The devil's in the details. You have to not only be an expert on iOS and Android and whatever other platform that you want to work with, because you can't hide that. You have to know what the platform can do. You also have to become an expert in this cross-platform tool. And you also have to, there's some hidden cost in there for you to discover, oh, well, this is the right way to do it on this platform. And over time, you might get, you might be, you know, a great Ruby motion developer and know exactly what you need to do to solve a certain problem. But until you get to that point, there's going to be friction. So it's not just with any of these crops, cross-platform tools for free. Yeah, absolutely. It's, it's one of those things. There's always going to be trade-offs with any abstraction. It's not just when you're talking about native to, you know, it's not just transpiling or, or, or even just polyfills. Any abstraction at all. There's going to be some kind of loss of, you know, there's a translation problem there and not everything is going to map perfectly one-to-one. Some things get closer than others. Definitely. You know, for example, the Scala Java thing, there's going to be a lot more that you can do in Scala to approximate the, the resulting Java code because it was built for that. Built primarily for that from the ground up. It would be like if Ruby was built, as an abstraction for iOS from the beginning, well, then you would never have net HTTP that doesn't work with, with that native environment, because why would you build that? Right. So it's, it's important to understand that there's always going to be some kind of trade-off when you have any kind of abstraction like this. Yep. It's all about trade-offs. You got to look for the trade-offs. That's what, that's what you learn over, over the years. Yeah, absolutely. All right. So Ruby motion. Yes. I think I had, I had a lot of fun with it and, and I think I showed some good, you know, with a little, maybe a little bit of my hand type behind my back without getting into the third party stuff. But I think, I think I showed like how far you can get towards a cross-platform application with that. Next, I believe is Xamarin. And there's some, there's been some interesting news about Xamarin since I finished the book, which is the big problem with a book like this with so many technologies, they're all moving all at the same, you know, at the same time, there's always, something is always going to be out of date. I just had to kind of accept that. What, what was announced with Xamarin after I finished the book was that Xamarin, Microsoft just acquired Xamarin. So over the years, Microsoft has always been really sort of buddy, buddy with Xamarin and, and really close to the, to the guys. And there's always spec speculation. Yeah. That's, at some point, Microsoft's just going to buy Xamarin until the point where people are just tired of saying it and just kind of like, well, I guess it'll never happen, but they'll just kind of always have a partnership. And then they pulled the trigger and they acquired Xamarin just recently, like a month ago. So maybe you'll see that kind of move closer and closer to the the universal windows platform is, is, is the possible concept, right? I mean, that's gotta be the guess. That's the speculation is at least on my side, right? Yeah. I mean, that's gotta be the guess. That's the speculation is at least on my side, right? Yeah. I mean, that's gotta be the guess. That's the speculation is at least on my side, is they're, they're in, they're in a, they're in a clear third position on the mobile, the mobile race. But they've got some cool stuff coming up with the, the universal windows platform that gives you, you know, the ability to build on, on more than one of their screens. And Xamarin is really good at using the same technology C sharp and, and works really integrates with a visual studio. And, and, and, and, and, and, and, and, and, and, and, and, and, and all those kinds of things. And it's good at getting that code base to iOS and Android screens. So they're, they're making more of ubiquity play with us. This is what it seems like. Yep. Sure. And I don't, which is a good play for them. I think as the third player, like you can't compete on whatever else that you're not catching people's eye with the coolness of the devices, obviously you're whatever's going on. That's, it's a good play to make. So leaving that to the side, because we don't know where that's going yet. And it'll be interesting, you know, if I have to revise this at some point in the future, but leaving that to the side, what Xamarin is about is writing. It's, it's really, it, it started out as, as a way for C sharp developers to be able to write iOS apps. And then they added, you know, they had to, they added the Android support after that. And it was a way for those guys to be able to get in on the game. But even if you, if you weren't coming from that, you don't really have a taste for C sharp or something like that. It still is a pretty buttoned up, um, solid development platform for, for building apps for, for both Android iOS and windows phone, um, sharing the maximal possible code. In fact, uh, what, so what I did was in the first day I start out with what, what you, you, which, you sort of the standard, um, beginner Xamarin project, which is to have three code bases, or I'm sorry, three projects. One is an iOS app project. One is an Android app project. And the third one is a shared project called a, uh, um, a PCL or a portable compiled library, portable, portable component library, something like that. It's PCL in any case. And the idea is that you put all of everything that can be shared into the, uh, the, uh, the, uh, the, uh, the, uh, the, uh, the, uh, the, uh, the, uh, the, uh, the portable library code, and then all of the, the, the bootstrapping and, and some of the, and all of the view code, I believe, um, is, is a good, is a good, I guess, heuristic for what falls into the, the, uh, iOS and Android specific projects. Um, and then from that, you can share, so you can share what should be shared. It's the business logic. Uh, you know, this is what the, the shape of the API is. I don't have to write that, twice. I can pull that down and use, um, uh, so, so when you run a Xamarin application, it's actually running.net natively on iOS or Android. So you get access to all of the.net library or not all of them. I think there's some like surprising things that you need to know about them that I didn't get that deep into, but, um, it's, it's, it's no, you don't have the Ruby motion issue or you might, I guess maybe what you're saying is you might have some of the problems. The Ruby motion when in terms of C sharp, some of the stuff in C sharp or in.net, it may not necessarily be available to you. Right. When the.net component that you're expecting to be there, isn't there, you're kind of in trouble, I think is how it comes, what it comes down to, but I'm not quite sure on when that happens, but for things like loading something from the web, you're covered. So it's a little, it has a little more coverage and parody with what you're used to then. Yes. As a.net developer, you would expect to have this certain library or, or API. Um, I don't recall what it is cause I'm not a.net developer, um, off the top of my head, but you're, you, you, you expect to make a web request this way and you can. So that's, that's kind of the idea. So like my API code, I, I, uh, consolidated all of that, like the, the, the data models that describe, um, the, uh, request. So actually let me, let me describe this real quick. The application is a calculator that I built. Um, which allows you to, um, it's just a, it's just a calculator application. Um, and I went really, really far before I actually went to making a web request. And then when I made, got to the web request part, I showed where that, that can be shared and everything. Um, but what I did is I went back and reuse the currency conversion API so that you could like convert from dollars to euros within the calculator. So type something up and then it converted to euros or, or the other way around. Um, so that was the, that was the, uh, the API request I made. So that's totally shareable. I can write that code once and do the, the Jason to native object translation once. And I can share that code across iOS and Android. And that's pretty cool. And then, um, there's also a product called Xamarin forms or Xamarin. Forms, um, which allows you to write, um, totally cross-platform UI, um, to a pretty, pretty fart. Um, pretty, uh, a pretty good extent. You can share, um, what they do is you, you use components that, uh, they've defined and they do the translation behind the scenes to like a UI text field on iOS or a text text view on Android. Um, those are the underlying, you know, type something into a text field type components and you use their text field component and they do the translation underneath to say, okay, I mean this on this. Platform and this on this other platform, um, which is pretty cool. You know, as far as that goes, uh, which mostly deals with components and layouts and things like that, um, which will get you pretty far, but there's still, you know, ways that you can build, uh, whatever custom stuff that you want to do. So I think at the end I end up with, um, pretty much almost a hundred percent completely shared code base across a hundred, uh, iOS and Android. With the differences dealt with in fairly nice ways with using conventions that they allow you to deal with. I can't recall quite what those are. Actually. I think at least one of them is if, if I'm making a call out from the emulator, uh, the Android emulator, I need to use some weird local, uh, IP address, which then gets translated to local host. Um, just because of how it's a, it's like a VM. under there. And on the iOS simulator, you can just call localhost because it's a simulator, not an emulator, not a VM. So that's like a cheap example, but still I use that as like a way to write into the code base some platform specificity. And that was to show that. Yes. So that was a fun little example to build. Yeah, for sure. And especially good for .NET developers. If you're a .NET developer and you're interested in doing native, definitely go and take a look at Xamarin. Yep. I mean, I have to admit I'm not a huge fan of .NET. Although there's some really cool features when compared to Java and I'm getting more and more converted or at least like able to say, yeah, it's definitely got other ones beat. Mostly because I'm not coming from a Windows background, develop on Mac and stuff like that. But it's a very it when when somebody comes to you as a customer and says, we must have this on two platforms and you must do it quickly. And, you know, what can we what's a great answer for a cross platform tool? Xamarin is a really good answer. I would say I would say even beyond that, if there are developers here who, you know, developers listening to the show, and you have a .NET like day job, right? Like you're just... developing every day in .NET and you want to break out and do something on the side, this would be a fantastic option for you because you're not going to have to spend a bunch of time ramping up into, you know, native development. You may be able to get started on whatever that side idea is that you wanted to build in your in your free time. Yes, I think if that's if that's your profile, then that was that was who Xamarin was written for. It was written for you. And also, you know, if there's, you know, a development, a team that already knows .NET and needs to maintain the application, if like in a client services type environment, then definitely Xamarin is the right choice. Today's episode is sponsored by FreshBooks. FreshBooks is the ridiculously easy to use online accounting software designed to help people just like you. You can create and send an invoice literally about 30 seconds and your clients end up paying you online. That means that you end up getting paid a lot faster than if you had to wait, for a check, for example. Now, if your client forgets to pay you on time, FreshBooks will handle that awkward conversation so that you don't have to call them up and ask for your payment. FreshBooks will do that for you. FreshBooks also helps you take care of your expenses. They have a mobile app where you can take pictures of your receipts and you can automatically import your expenses directly from your bank account statement. This makes things much easier for you. During the workday, you can track your time with it. You can also do a little bit of tracking. You can also do a little bit of tracking with FreshBooks so you know exactly what you did and when you did it. And all of the little details about your cash flow are kept in one place. So FreshBooks knows exactly what invoices you sent, when you sent them, who's paid you, and who owes you what. Now, FreshBooks is offering a free month to Developer T listeners. You can get paid today and you can start sending invoices today by going to freshbooks.com slash developer T claim. You can also get paid today by going to freshbooks.com slash developer T claim. And make sure you tell FreshBooks that you're coming from Developer T in the how did you hear about us section when you sign up. That's freshbooks.com slash developer T. And of course, that link can be found in the show notes at spec.fm. So the exciting one for me, I've been kind of just waiting for the next one because I personally, I really enjoy this next environment quite a bit. And we were talking before the show, it sounds like maybe React Native is going to be the next one. And I'm not sure if that's going to be the next one. But I'm sure it's going to be the next one. And I'm sure it's going to be the next one. React Native was one of your favorites out of this group of seven, at least for your particular situation. So let's talk about React Native. Yeah, I'm not afraid to say that I did really enjoy, I probably enjoyed learning about React Native the most out of all the technologies in the book. I'm not going to say it's my favorite technology because I don't quite know what that means from the seven in these books. Yeah, yeah. It's like trying to pick a favorite language or a favorite color, right? Right, yeah, yeah. So that's hard to say that it's my favorite platform, but it was the most fun I had learning the technology of any of these in this book. The thing that I enjoyed the most about React Native was the way that they thought about the development tool chain. You can tell they're coming from people who are working on the web and using web tools and expecting to have things like ... ... ... ... ... bringing ... I made a change in the code. I just want the app to reload quickly. Like, where's my reload button in the simulator? I don't see it. What is this? It sucks. Why do I have to build this every time? So they wired that up for you. Command-Shift-R. I want to see that move quickly. Yeah. Yep. It's built right in from the get-go on both the Android emulator and the iOS simulator that you can just reload the code base or even have it auto-reload and look for changes using Watchmen, which is a Ruby gem. Maybe it's a Ruby gem? Or it's some underlying technology that's... I'm sorry, not Ruby. It's Node. We're in Node land now. No problem. Yeah. So using Watchmen, which is watching for changes in the code base and emitting some sort of event using the underlying system capabilities to say, hey, something changed. Reload it in the simulator. Then I can just flip over and see it or have it side-by-side and see my code change without me having to go through the whole compile cycle. All that stuff is really great. So what's happening there is it's running, I believe, a Node instance in the native platform and you're able to... So you're writing in JavaScript and you've got a lot of the Node stuff available to you and that tool chain is pretty familiar if you're coming from that world. And they've done a lot of stuff to give you, if you're coming from a web development background, things that you would expect to see. And that was really cool. So you can just write in your favorite editor. A little shout-out for Vim. If you want to write in Vim, you're covered. And you just flip over to the simulator and your code is already loaded up and ready to test without going through a compile cycle. And it's a really nice experience. So I liked learning that. Yeah. For those of you who are not familiar with Vim, you could also in this particular case, you're probably using something like Sublime and that would work perfectly fine for this too. I did a quick Google search for Watchmen, by the way, and it turns out that it's actually you can run it directly from the command line. It's actually only like 3.5% JavaScript. So it looks like maybe Facebook has created some hooks into Watchmen and they're using that for that live reloading feature which is really incredible, by the way. I've done a little bit with React Native as well. And of all of those platforms, in terms of being able to do something quickly, it's amazing how fast you will move in the first two or three hours once you get up and running with React Native. Yep. That was my experience. This is really refreshing coming from an IDE and a compile cycle and all that stuff. They really put some thought into it. Yeah. The other cool thing is I guess I have to admit that I haven't done a lot of modern JavaScript development or I haven't kept up as fast as the JavaScript community changes things. But you can use some really cutting edge features of ECMAScript, I believe 15 or something like that. ES15, ES2015 or something like that, whatever it's called. It's... You can use things like return types for your functions. You can use things like the let instead of the... I'm blanking on this var, right? Yep. Yeah, right. So that gives you, I believe, lexical scoping, which is sane, which has always been one of my problems with JavaScript. Lexical scoping is insane. Like when you're having to do the whole... Like, this is what I mean by this thing has always been one of my problems with JavaScript. So I think that they've dealt with that a little bit with the let keyword, I believe. I may be wrong about that. Yeah, there's some interesting stuff that happens in ES6. And that's another thing I can include in the show notes. There's quite a lot of interesting additions. The first time the language really has been overhauled at the language level itself in quite a while, because JavaScript has basically relied on... browser APIs to evolve rather than the language itself. Now the language is evolving on a yearly basis. Yeah. And I think I believe... Like when Node came out, it was like, oh my gosh, these JavaScript people just won't quit. Like they've got to have JavaScript everywhere. And it's weird. And it's, you know, it's just like an excuse to have JavaScript somewhere. But it turns out to be pretty useful when you want to do things. On the web, like from an API standpoint or driving a website, something like that. Like, I mean, this is all known. Node has been around for a while. But I think one of the cool things from my perspective that Node has done is allow people in the JavaScript community to see the need to evolve the language beyond what already works in the browsers. And I think that's what we're seeing with some of these capabilities that... You called it ES6. I got to get my terminology right. Well, it's ES2015, I think, officially now. Okay. Yeah. That's the one we're talking about, though. Those capabilities are available to you when you write React Native. So things like defining a class instead of... I mean, with those class-like semantics when it's really, you know, it's still a prototype language underneath. But it looks like you're defining a class and that semantics look a lot nicer. Yeah. And reveal intent a little bit better, I believe. And then you can use that type as a return type from a function and a number of other features like that that are really useful. And that was, I guess, maybe a kind of a minor theme to this chapter on React Native was showing, you know, using those features of JavaScript. Sure. Yeah. But the application that I've built is a little sort of... Yeah. It's a little bit more of a note-taking application. And what I did was... Let's see. So you can create a note which has a title and then a body, and you can display that in a list. But then I went on to get into the location APIs on the platform to grab the current location. So you can tag a note with a location similar to other note-taking applications like Evernote, for instance. And then at the end, I put that... Put those locations on a map. And I use a little shout out to MapQuest, which is my employer. Yes, we're still around and we've got some cool stuff. It uses the MapQuest API to do the reverse geocoding. Very cool. From taking the location... The lat long and turning that into something to tag the note with and say this was taken at this location. Yeah. Yeah. Yeah. And then I can just drag and drop it. And then I can just drag and drop it. And then I can just drag and drop it. And then I can just drag and drop it. And then I can just drag and drop it. I wanted to do that even though I found out kind of early on that that wasn't going to work on Android. Because this was... First of all, it's hard to come up with seven apps to build. And I came up with... Oh, yeah. I can imagine. A set of features. Seven apps about the same size, particularly. Yeah. Yeah, exactly. Yeah. And not just like... Because... Or very early on. I guess this is maybe anecdotal fun stuff people might want to know. Very early on, I was kind of... In the writing of the book, I came down strongly on... I want to build the same exact application on every platform because I want people to be able to compare what it's like apples to apples. And the series editor was just like, no, you're silly. Don't do that. Everybody thinks of doing something like that when they get into this series, but don't do it. You're going to bore people and they're going to walk away. So I struggled a little bit with it. Came back with different arguments. Still didn't fly. I finally came around to thinking about it. And I'm glad that I didn't do it. Yeah. Because it's a better experience. And it doesn't cut in. It doesn't take away from the comparability, I believe. Anyway, it's still hard to come up with seven apps. So I came up with this feature set before I realized that it wasn't going to work on Android. Because those... The location APIs are a little... A little bit behind from React Native. But I thought it was still worthy of including that feature set because the way that you access, give me the current location, whatever platform I'm on, and also display a map view and put these things on the map are not... They're not platform-specific APIs in React. They're... So that means that... At some point, I feel like that's kind of a commitment on React's part to some point, this is going to work on Android. So I kind of wanted to... Even though maybe that's not like the most successful outcome, if somebody really wants to build something cross-platform with map and location stuff right now, I think there are, by the way, some ways around it by doing some more convoluted things like building it yourself. Like building the translation yourself or the translation from React Native. To the native API yourself. There may be some third parties out there that have solved this as well. But I wanted to show, you know, even where React Native doesn't have full parity across all the platforms, here's the experience of running into that as a developer, because you may. And what does it look like when you run into it? So it actually fails gracefully on the Android side. Kind of gracefully. Like you... It doesn't crash. So that's... Sure. Yeah. So... Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. get um the community to grow things right to grow it and get they get something back from the community like they get something out of it too um so you don't pay a dime for it um where whereas if you pay zamarin uh they're going to be the ones that are they're doing the work to make sure you get the cross form the cross platform parity but um it's still not that bad of experience like you could still maybe find your way around it for for like doing a proof of concept or getting developing a startup type app from from the ground up sure there's something you can do and still get that that shared code base at the at the end yeah absolutely so i thought that was a pretty important story to tell still yeah for sure for sure i do think that uh that for those who are looking into these cross-platform things you're doing the right thing in my opinion that's particularly true for startups um and and true for smaller companies to look into that idea of of potentially going with a clock a cross-platform solution and the reason for that is because you know changing the code base in one place and changing the code base in two places for the same outcome on two different platforms there's a lot of like dependency craziness that can occur and when you have a single cross-platform or or cross device platform that you can build on top of a lot of that uh management goes out of the window and what that does especially for the smaller companies is it allows you to focus on those features rather than focusing on um the implementation and and part of the reason why you might eventually go to ios specific or android specific is to gain advantages of those native apis and to do that you might not necessarily have you know perfect parity with something like react native yeah and and again we're back to talking about trade-offs it's an important important to understand what you're trading off like the cross-platform tools are not going to give you something for free you're going to have to deal with it so right yeah with those trade-offs are but especially like the the case or the the profile of the of a hypothetical company that you just talked about they've got a very important problem to solve as quick as they can they have to get to market with their concepts so that they can start to see what the market thinks of it and then what do we need to do as a business based on what the market thinks of it and uh as as smooth and as quickly as they can do that will be all to the good so it's definitely that that profile company was should probably think about um a cross-platform tool like don't don't just throw it out and they're they're i mean i've had arguments with people that are like oh i don't know i don't know i don't know i don't know i don't know i don't know they're they they they they they they they they they they they they they they they they side or the other and i'll play devil's advocate and all that kind of stuff and um you you've got to do the thinking like don't throw it out but also don't think that it's a silver bullet you've got to you know take a really good uh nuanced view of the trade-offs that you're that you're looking at and across platform because the other the other alternative is to go with one platform um first yeah yeah and there's been people who've written articles about this too well yeah you should do ios first because look at the market and look at the experience and and all that kind of stuff or hey no you should go with android first because of x and then they sneered each other across the aisle like it's it's that may not be the right answer either i don't know i but but a full like a mature product shouldn't be on just one platform i believe that pretty pretty strongly so you're gonna have to think about it at some point when when do you think about it as goes into that trade-off and i have to admit by the way that i i if i had to pick um being i guess maybe being who i am or knowing what i know or whatever i would like to have native development platform native so i would like to develop an ios app and an android app yeah yeah but that's maybe not the right business choice you know you gotta figure out what you're at where you're at you know i like developing on multiple platforms i like this whole polyglot idea i like i like that as a fun thing to do and i think that's a good thing to do and i think that's a good thing to do and i think that's a good thing to do and i think that's a good thing to do and i thing and uh as a fulfilling thing but again you've got to i i hope that this book helps people understand how to think about the trade-offs with with enough information that's and that's kind of one of my goals yeah and and and that's really um what i wanted to get out of this interview was you know there's seven for a reason it's not that we're trying to do a shootout that's not the point of this book here right it's not that we're trying to do a shootout it's not that we're at the point of these seven and seven series is let's experience all seven of these in their nuances and in their strengths and weaknesses and you know in their styles um there's there's a lot to be said just for preference for you know looking at code and saying wow you know i like the way that looks on my screen and and i would like to look at that code regularly you know so um i think that's a really powerful statement that uh you know this this is more about understanding and learning the process of of comparing the trade-offs and that's what seven and seven allows you to do yep it's seven and seven as a series another byproduct of look like this is there's so many things to be taken from this kind of way looking at it like we're looking at seven different we've been talking about the business trade-offs like you've got to think about you're building an app why are you building an app you're building an app for your you know to grow your business unless you're just having fun with it in which case you know have fun but if you're thinking about building a business you've got to think about these trade-offs pretty you need to have the right information to make the decision and then get going so hopefully this can help do that but then also coming to the seven and seven series the idea is that you can look at what it's like using different paradigms and different different uh uh apis and different um different ways of looking at here's how we're going to solve problems like just going pairing all in in this this is more complex book which is maybe not necessarily a great thing than seven languages in seven weeks um although it's you know it serves a slightly different purpose but um when you pair back all the the mobile platform stuff you're also dealing with different languages and different paradigms and stuff like that and that's that's what people are going to be able to do and that's what i'm going to be able to do and that's what people really liked about seven languages in seven weeks and the other seven and seven books is that i can learn how to think about things the way this framework wants me to think about it and then go to a different framework and say oh interesting now um i i can think about it in this way and maybe also bring what i just learned from the other platform to my thinking about this new platform and then at some point you become good at coming up to speed quickly with new technology that's a good byproduct but also you go back to your workaday language maybe you're stuck with an older older language that doesn't quite you know scratch the itch anymore but you can apply the thinking that you've picked up from discovering how this other platforms thinks about solving problems other language other what are the other idiom thinks about solving problems and apply that to your your day-to-day language and that's another another benefit same thing with with with looking at these different mobile platforms how does maybe you know you look at react native and you say dang they really solved this development workflow issue that's bugging me and i have to stick i'm not able to use react native at work but but i'm going to go sell to the product owner how important it is for us to to clean up this development flow and let's build in something like they've got for for you know automatic reloads because that would that would give you know increase our development productivity so you know i like the idea of just of just learning from these different platforms there's there's so much going on in uh the mobile application space and it's important for i would say all developers to to be looking and aware of of this space because it's you know it's we can't just ignore the the uh the massive nature of the mobile the mobile web first of all but also just mobile devices in general and that includes things like watches it includes things like wearables but it also includes the concepts mobile development like mobile first progressive enhancement we're going to see a lot of movement towards this idea even more in the future that allows us to build you know one maybe two code bases that reach screens of all sizes from your watch all the way up to your television and everything in between and all capabilities in between uh natively so that's in the future for us that's that's coming down the pipe and you know these types of platforms the ones that are in uh seven mobile apps in seven weeks that tony has written uh these are going to be the things that that kind of define the the first days of that movement um and it's already happening this isn't something that's like happening in 2020 this is already beginning today so um go pick up the book if you're listening to this podcast and you're interested at all in mobile development uh go and pick up tony's book when it comes out and tony do you have about an estimation of when people can pick this book up i believe that it should be it's going to you know the final production and printing and stuff like that mid-june-ish to end-june-ish and it should be available soon after that on channels like amazon and some bookstores as a hard or as a hard copy book a softcover book but um you can also go to the pragmatic programmer website now and and get the book and you can get the book and you can get it uh in digital form and and um and get the book later on when the book is released perfect yeah and of course there will be a link in the show notes uh to that pragmatic programmer link that tony is mentioning there um just a quick side note tony and pragmatic programmer none of this is sponsored and um i i i just believe that this is a this is going to be a great book for those of you who are interested in this subject um tony has has not given me a kickback or anything like that that's not what we're doing here um i just want to share this information with with all of you and uh tony reached out to me and i thought it was it was a perfect fit so i'm very glad to have had you on the show tony i have two more questions for you today um and it's questions that i like to ask every developer who who comes on the show and really every guest who comes on the show sometimes we have non-developers on the show so those questions the first one is if you could spend 30 seconds or a minute with every developer what advice would you give them wow that's a burden that's a that's a it's a tough one to answer let me let me i mean maybe it's top of mind because we're already talking about it but i think uh the theme of what the seven and seven series is about is something i believe in as well anyway and i think it would be especially for a developer earlier in their career is don't don't stick with one technology um get into the polyglot mindset where i can i can jump from platform to platform or language to language maybe it's not not necessarily the case like you're not going to be an expert if you if you just jump from one to the other but get in and be an expert in one and then go on to learn from a different point of view and then go on to learn from a different point of view and then go on to learn from a different point of view how this this completely different mindset like the difference between procedural programming and functional programming understanding how looking at the world from different perspectives like that helps you solve problems uh and the mechanism by which you you get that is by by digging in and understanding what's different about this platform and you have to do that by by going through a few of them and as you start to exercise those pattern recognition muscles um that is that is something that you should as a developer foster because really a lot of what we do is is pattern recognition and categorization of stuff by that mechanism and that's going to make you a better developer by by by learning more than just one platform language whatever it is yeah that's good uh understanding that our that our jobs are not just about platforms and languages but they're about the underlying principles that drive those platforms and languages and languages to become popular and to become usable and uh and and functional is those are all incredibly important things uh for us as developers to be aware of so that's that's great advice tony exactly your job is to solve problems so you know understand how to solve problems that's your that's that's going to make you a better developer exactly the second question that i have for you is uh what do you wish more people would talk to you about what topic uh or or concept do you wish more people would talk to you about another way to phrase the question is what do you wish more people would ask you about oh so i can i can go off the uh the uh i can take off the developer hat for a second is that what you're saying yeah absolutely okay uh well um one thing i'm interested in um one thing that i would love to talk to anybody about and i go probably go out of my way to talk to people about whether they ask me or not is uh as a hobby that i've picked up recently um our pursuit rather than hobby i think i like i would like to say uh of historical fencing which is very interesting yeah when i saw that there was this new york times article that came out a few years ago that showed hey there's these there's these groups around the country and around theension and they were all talking about theension and they were all talking around the world that are starting to pick up, um, historical fencing, uh, which is means like they're going to, they're going to fence, they're going to fight each other with historical weapons, uh, like the long sword or, um, older weapons than, than the modern sport fencing weapons and make this kind of a sport and do it safely and all that kind of stuff. But like recover a bit of this history and, and, um, like the origin, the techniques that, that people wrote about, you know, up to 400, 500 years ago. Um, and, and see, I see how they can sort of make that, um, uh, how they can gamify it to the point where they can, you know, fence as if they were fencing, like with modern, modern sport fencing, sort of in a modern sport fencing, uh, situation, but with the historical weapons, um, and it's called HEMA, uh, historical European martial arts. And I wish people would ask me about it just because it would give me a chance. It's when I saw this article and I saw the video of, of this, the small little tournament, uh, in New York and people like fighting each other with long swords. I said, why didn't anybody tell me this was something I could do? This is awesome. Where did this come from? And I, and I thought that this time was over. Yeah. I thought, I thought I missed the boat, you know, by being born in the 20th century, but I didn't. It's, it's pretty cool. I I'd love to talk. So are you yourself going to, uh, going to, uh, to, uh, to, uh, to, uh, to, uh, to, uh, to, uh, to, uh, to, uh, to actually participate or, or what's the plan there for a year? There's a, there's a club here in, in, uh, Denver, uh, Colorado where I live that, um, that, that does these, these things. We look into, you know, they study historical treatises about how to, how to fight with, with these different kinds of weapons. And then we, uh, you know, we do it, we spar, we learn the techniques and then we, we, we go at each other and it's, it's a lot of fun. And yeah, I would love to share with more people because I think they'll probably, a lot of people will have that same reaction. Like, what is this? This is awesome. Yeah. Yeah. Yeah. You know, I, I think there's something really interesting about embodying and performing in order to learn. This is quite relevant to developers. We actually learn best by going in and writing code, right? Um, we can learn history quite well, you know, actually going and seeing historical places, for example, but, uh, what you're doing, with this, with this historical fencing, you're embodying that, that mindset and the same kind of physical actions and the same threats and the same sporting. That's really quite an interesting way to learn about it. Yeah. It's, and that's, that was one of the impetuses. One of the many impetuses, I think that, that people who originally started to do this was having, like, you see sword fighting in movies and it's awesome. And it's, you know, it's done for the glamor of it. And, uh, you know, it's, it's, it's, it's, it's, it's, it's, it's, it's, it's, it's, Martial artists would look at that and say, this is a little fake and that really wouldn't happen. But somebody probably said, or lots of somebodies said, what was it really like? What did you really have to deal with when somebody stood up against you with a 54-inch tall weapon and they were going to swing it at you? How would you actually deal with that kind of a thing? And what did people write about? And one of the early manuscripts we look at, it was written in the 1380s. And it's interesting to get back in touch with that tradition that we've kind of lost. Not like you need to go out and wear a sword these days, so that's not practical, but it is a way to get in and learn just a bit of what life was like back in those days. Yeah. You know, this stuff more often, being called up and told to fight for your Lord or something like, I don't know, you know, all that stuff is super interesting to me. But you get to go in and try to get yourself in the mindset of looking at this wood carving or this wood cutting from 400 years ago. And it looks a little weird that it wasn't a great, great artist. So I'm not quite sure what this guy was actually trying to say. Should I stand exactly like that? Yeah. Or was he just like, I don't know. Yeah. What's the, what are the martial principles that we know that we can apply to this and say, well, I think they mean this. And that's a lot of the sport is really interpretation and like that. And it's really getting, trying to get in the heads of the people who did this, you know, for either a living or, or whatever. Or just had to, had to fight and had to know how to deal with it 500, 400 years ago. And that's, that's pretty cool. Sounds like a lot of fun. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. And you're particularly interested in what about what period was this, you said? Well, so, I mean, we study a range of weapons that probably so the manuscripts that we can we actually look at. There's one written in the 1380s. That's probably the oldest. And then stuff written all up into the, you know, the 19th century for some other weapons. So it spans a really wide range. The sweet spots probably in the 1500s, something like that. The 1500s. Perfect. Yeah. So for those of you who are interested in the hand-to-hand combat of the 1500s particularly, and you also live in Denver, you should probably reach out to Tony because he has a lot to talk with you about. And really anybody who wants to talk about something more than code. You know, Tony and I were actually talking about this before the show. Having something beyond just code that you do, it's a pretty healthy idea. Sometimes, you know, taking. Off the hat of the developer. When you come back to development, you have new context. It's like cross-training for your developer job or whatever it is that you're writing code for. You can learn a lot outside of the editor. You can learn a lot outside of your browser. So go and find something else to do every once in a while. You know, it's certainly a healthy thing. So. Absolutely. Very interesting stuff. Well, Tony, thank you so much for being on the show tonight. It is night when we are recording this. So I appreciate your time. And thank you so much for writing a book about these seven different frameworks that people can learn about. And I appreciate your time tonight. Thank you for having me on the show. I really appreciate the opportunity to just talk about it. Like you said, it's not really. I'm not sponsoring it by the book. But instead, what we're getting together as developers to say, you know, this is a really. Important idea. The idea of being a polyglot and experiencing different frameworks and things like that. That's that's really what what this is about. And I really appreciate the opportunity to talk about it. Of course. Yeah. And if people want to find you on the Internet, how can they find you on Twitter? My handle is T Hillerson. And I believe I mean, on Facebook as well. But that's more for family and friends. But, hey, you know, send me a note. And we can I believe we can still chat if you've got questions. And, of course, on GitHub, I'm also T Hillerson. Perfect. All right. And those links will be included in the show notes as well. Thank you so much, Tony. Thank you. Thank you again to Tony for being on the show. And thank you for listening to Developer Tea. If you enjoyed today's episode, stop what you're doing unless you're driving or doing something else dangerous. If you were to stop, stop what you're doing and go and subscribe to this podcast. And whatever podcasting app you use, this will help you not miss out on any future episodes of Developer Tea. Thanks again to FreshBooks, the ridiculously easy to use online accounting software designed to help creative entrepreneurs get organized, save time and get paid faster. You can start getting paid and getting organized today by going to FreshBooks.com slash Developer Tea. Make sure you enter Developer Tea in the How Did You Hear About Us section when you sign up over there. That link and all of the other relevant links from today's episode can be found at spec.fm. Thank you so much for listening to today's episode. And until next time, enjoy your tea.