Hey everyone, I'm on Come 2 Developer Tea. My name is Jonathan Cutrell 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 and Seven series, make sure you listen to the first episode in this interview by the way. But go and check out the Seven and 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 a 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 to you 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 Flate 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 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 point number, and I got taken to task by this for buyer of viewer, but I didn't want to deal with big decimal and confused 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, OKHTTP, which is developed by Square of, yes, Square of many open source project fame and also a credit card reader. So we get to see how that works. 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 contributed a lot to different projects like Android code is 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. Some, 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 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 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. Does 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 what I wanted to hit that for Android. Okay. On to the next one. This one was an interesting one to pick, but I wanted to stick with this theme 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? I did and it was kind of fun. But what was interesting, there's a lot of cool stuff. It's still weird for me when I talk about this. Microsoft used to be the evil empire and all that kind of stuff and now they're really an underdog and doing cool stuff. Going back to when Windows Phone first came out, the Metro design and all that people were like, wow, that's actually pretty nice. We never would have expected that. Microsoft come up with that. It's got to leg up on the other ones and they had to kind of race to catch up visually with ease of use and that kind of stuff. So I thought that's enough of a reason to see what Windows Phone is up to these days. And you know what this phone hasn't sold that well. So I don't know how many people were 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 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 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 new. That's brand new with the Universal Windows Platform. Universal Windows Platform stuff for Windows 10. And that was a lot of fun. So what I did for this application, which is a stock, a stock's applications. You can put in some symbols and see what the current price is. And it starts out with a couple of indices 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. We dealt a little bit with how to do the thing that's kind of like responsive design for that platform. That was actually fun. So I had fun with that. I had to deal with 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 the fact that you can develop a Windows desktop app and have it run on a phone or think, you know, 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 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 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 the competition, quite honestly, that they provide for Apple, especially when it comes to this universality and also 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 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 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 yet. I actually have looked into this and TV OS is an entirely different setup and it's based on JavaScript and it's a totally different thing than if you were to go and build an iPhone app, 100% different. Okay. Then I'm way off there. I mean, at some point, let's assume that they give you native apps on Apple TV. Like an app store or something, right? Yeah. Then the question is 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, I guess, destination. 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 native platforms and now we can talk about the cross-platforms and just touch on each one of these and what your experience was developing for Ruby Motion Xamarin and React Native. Yeah. Again, I broke the book into what I called platform Native, which was my own phrase for this. I had to distinguish between the natively running apps for either built by a cross-platform tool 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. Like, no hate or anything, but like, Cordova and PhoneGap, those type of things, I don't think they're the right answer, maybe for prototyping and proofs of concept apps or something like that, possibly if all you've got is web technology or web background. But I really want to focus on the user experience is so much better and you're never going to catch the web up on a mobile device to native performance. All those things, like, I just wanted to focus on apps that can pile down and run natively and instead of apps that are better run inside of a web view to get the cross-platform. Sure. So that's why I had to come up with 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 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, Ruby Mine is the wrong thing. That's the ID. Yeah, that is an ID. It was like Coco. I don't remember. But the guy who built Ruby motion came from Apple and he'd done some work there getting Ruby working for building Coco apps was cool. Yeah. So that was pretty cool, but then he turned into a business. And it looks like Ruby motion can also do TVOS and watch OS as well now, by the way. And OS10. What you're doing is, I mean, underneath it still uses 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. Or 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 at some point, that's probably what you're going to build as a hello world app 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, I've, or at least got into the, 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 Ruby motion, you, 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 is not, it's not maps as 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, 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, net HTTP, I don't think is available, I think you have to use something like, I believe it's called bubble wrap, is that right? Well, so this is where I made a choice not to get into the third parties. I didn't do any party code with Ruby motion, although that would be the first smart thing to do is to look into that community because there's been a lot of stuff that's built up by the community to solve these kind of problems. Sure. I wanted to stick with what I can do without getting into that because right after that I would be faced with, 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 wait in that water and make it 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 Ruby motion in this book is to try to make as much of a cross platform code base as I could. It turns out the answer is not a ton. It's not super cross platform. The code share ability is limited by the fact that Ruby is running locally in an interpreter and you don't get things like NetHTTP. Let me take a step back, I guess. What's happening when I call a Ruby function or make a Ruby class or call an underlying API on the native platform with Ruby is that it's passing those calls through to whatever's underneath the cover. 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. What I actually did was, I believe I used, 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 NS URL session, 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. 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 I'm on and what am I going to do to fulfill the request here? I tried to make that as abstracted as possible 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. Just like you've already mentioned, there's a big developer community which is one of Ruby motions, 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 Ruby motion myself although it was a few years ago and there's 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. If you really enjoy writing Ruby for the bulk of the code, it's going to feel very much like Ruby. 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. It's not necessarily the fault of Ruby motion. 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 component. It's a compiled code that you'll need on that native environment. There are some trade-offs obviously but if you really, really love Ruby a lot and if that's your favorite language of all time, then it's certainly something to consider. I think I ran into that right away. 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. 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? 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 take a step back and say, okay, here's what we've got to do instead. Maybe those resources are on the web but you just didn't find them. How long is it going to take you to be an experienced Ruby motion developer because it's a bit more like a core Xamarin or whatever because that's something that you don't just, 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 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, this is the right way to do it on this platform. Over time, you might get that. You might be 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. It's not just within any of these cross-platform tools for free. Yeah, absolutely. 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, it's not just transpiling, right? Or even just polyfills. Any abstraction at all, there's going to be some kind of loss of, there's a translation problem there. What everything is going to map perfectly one to one. Some things get closer than others, definitely. For example, the Scala Java thing. There's going to be a lot more that you can do in Scala to approximate 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. Then, you would never have net HTTP that doesn't work with that native environment because why would you build that? 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. It's all about trade-offs. You've got to look for the trade-offs. That's what you learn over the years. Yeah, absolutely. Right, so RubyMotion, yes, I think I had fun with it 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 showed how far you can get towards a cross-platform application with that. Next, I believe, is Xamarin. 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 at the same time. There's always something is always going to be out of date. I just had to accept that. What was announced with Xamarin after I finished the book was that Microsoft just acquired Xamarin. Over the years, Microsoft has always been really buddy-buddy with Xamarin and really close to the guys. There's always speculation. At some point, Microsoft's just going to buy Xamarin until the point where people were 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. Then they pulled the trigger and they acquired Xamarin just recently, like a month ago. You'll see that kind of closer and closer to the universal Windows platform. Is the possible concept, right? That's got to be the gas. That's the speculation. At least on my side is there in a clear third position on the mobile race, but they've got some cool stuff coming up with the universal Windows platform that gives you the ability to build on more than one of their screens. Xamarin is really good at using the same technology, C-Sharp and works really integrates with Visual Studio and all of those kind of things. It's good at getting that code base to iOS and Android screens. You're making more of ubiquity play with this. This is what it seems like. Sure. Which is a good play for them, I think. It's fine to do as the third player. You can't compete on whatever else that you're not catching people's eye with the coolness of the devices, obviously. Whatever's going on, it's a good play to make. Leaving that to the side because we don't know where that's going yet and it'll be interesting. 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 really, it started out as a way for C-Sharp Developer To be able to write iOS apps. They added the Android support after that. It was a way for those guys to be able to get in on the game. Even 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, solid development platform for building apps for both Android, iOS and Windows Phone. Sharing the maximal possible code, in fact, what I did was, in the first day, I started out with what you, sort of the standard beginner Xamarin project, which is to have three code bases. 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 PCL or a portable compiled library, portable component library, something like that. It's a PCL in any case. The idea is that you put everything that can be shared into the portable library code and then all of the bootstrapping and all the view code, I believe, is a good, I guess, heuristic for what falls into the iOS and Android specific projects. You can share what should be shared. It's the business logic. This is the shape of the API. I don't have to write that twice, I can pull that down and use, so when you run a Xamarin application, it's actually running.NET natively on iOS and Android. You get access to all of the.NET library. I think there's some surprising things that you need to know about them that I didn't get that deep into. It's, no, you don't have the Ruby motion issue. I guess maybe what you're saying is you might have some of the problems of the Ruby motion. 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 down to you. I'm not quite sure on when that happens, but for things like loading something from the web, your code... It has a little more coverage and parity with what you're used to then. Yes, as a.NET developer, you would expect to have this certain library or API. I don't recall what it is because I'm not a.NET developer off the top of my head, but you expect to make a web request this way and you can. That's kind of the idea. Like the API code, I consolidated all of that. The data models that describe the request. Actually, let me describe this real quick. The application is a calculator that I built, which allows you to... Okay. It's just a calculator application. I went really, really far before I actually went to making a web request. Then when I got to the web request part, I showed where that can be shared and everything. But what I did is I went back and reused the currency conversion API so that you could convert from dollars to euros within the calculator. Type something up and then convert it to the other way around. That was the API request I made. That's totally shareable. I can write that code once and do the JSON to native object translation once. I can share that code across iOS and Android. That's pretty cool. Then there's also a product called Xamarin Forms or Xamarin.Forms, which allows you to write totally cross-platform UI to a pretty, pretty, pretty good extent. You can share what they do is you use components that they've defined and they do the translation behind the scenes to UI text field on iOS or a text view on Android. Those are the underlying type something into a text field type components. 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, which is pretty cool. As far as that goes, which mostly deals with components and layouts and things like that, which will get you pretty far, but there's still ways that you can build whatever custom stuff that you want to do. I think at the end, I end up with almost 100% completely shared code base across iOS and Android with the differences dealt with in fairly nice ways 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 I'm making a call out from the emulator, the Android emulator, I need to use some weird local IP address, which then gets translated to localhost. It's like a VM under there. On the iOS simulator, you can just call localhost because it's a simulator, not an emulator, not a VM. That's a cheap example, but still I use that as a way to write into the code base some platform specificity. That was a show that. That was a fun little example to build. For sure, especially good for.NET developers, if you're.NET developer and you're interested in doing native, definitely go and take a look at Xamarin. It's, I have to admit, I'm not a huge fan of.NET. There's some really cool features going compared to Java, and I'm getting more and more converted, or at least able to say, yeah, it's definitely got other ones beat. It's because I'm not coming from a Windows background and develop on Mac and stuff like that. When somebody comes to you as a customer and says, we must have this on two platforms and you must do it quickly. What's a great answer for a cross-platform tool? Xamarin is a really good answer. I would say even beyond that, if there are developers here who developers listening to the show, you have a.NET like day job. 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 native development. You may be able to get started on whatever that side idea is that you wanted to build in your free time. Yes, I think if that's your profile, that was who Xamarin was written for. It was written for you. Also, if there's a development team that already knows.NET and needs to maintain the application, if I can acclion 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 in your clients and paying you online. That means 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 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 Tea, claim your free month, and make sure you tell FreshBooks that you're coming from Developer Tea and the, how did you hear about us, section, when you sign up. That's FreshBooks.com slash Developer Tea 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 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 and 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, I'm sorry, React Native was the way that they thought about the development tool chain. They're, you can tell they're coming from people who are working on the web and using web tools and expecting to have things like, like I made a change in the code. I just want the app to reload quickly. Like where's my reload button? I don't see it. Why I have to build this every time. So they wired that up for me. 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 Amulator 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 lamp now. No problem. Yeah. So using Watchmen, which is watching for changes in the code base and saying and emitting some sort of event using this underlying system capabilities to say, hey, something changed reloaded 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 that 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 expect you would expect to see. And that was really cool. Sure. So you can just write in your favorite editor, a little shout out for VIM. If you want to write VIM, you're covered and you just flip over 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. 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. 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 ECMO script, I believe, 15 or something like that. It's called, you can use things like return types, your functions, you can use things like the let instead of the blanking on this var, right? Yep. Yeah, that gives you, I believe, lexical scoping, which is sane, which has always been one of my problems with JavaScript, lexical scoping is insane. When you're having to do the whole, this is what I mean by this thing has always been one of my problems with JavaScript. I think that they've dealt with that a little bit with the let keyword, I believe. I may be wrong about that. 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. I believe 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. It's weird and 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. From an API standpoint or driving a website, something like that, 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. I think that's what we're seeing with some of these capabilities that you call the ES6. I got to get my terminology right. Well, it's ES2015, I think, officially now. Yeah, that's the one we're talking about. Those capabilities are available to you when you write React Native. Things like defining a class instead of... I mean, with those class-like semantics when it's still a prototype language underneath, but it looks like you're defining a class and that semantics look a lot nicer and reveal and tend to a little bit better, I believe. You can use that type as a return type from a function and a number of other features like that that are really useful. That was, I guess, maybe a minor theme to this chapter on React Native was showing using those features of JavaScript. The application that I built is a little note-taking application and what I did was... Let's see, so you can create a note which has a title and a body and you can display that in a list. 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 Avernote, for instance. Then at the end, I put those locations on a map and I will 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 geo-coding. 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 in the world. That was... I wanted to do that even though I found out early on that that wasn't going to work on Android. This was... First of all, it's hard to come up with 7 apps to build. I came up with... I can imagine. 7 apps about the same size, particularly. Yeah, exactly. Yeah. Not just like... Because we're very early on. I guess this is maybe an ago-to-fun stuff. People might want to know. Very early on, I was kind of in writing 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, Apple's to Apple's. 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. I'm glad that I didn't do it. Because it's a better experience. 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 the location APIs are 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. So that means 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 wanted to, even though maybe that's not the most successful outcome, if somebody really wants to build something cross platform with map and location stuff right now, I think they're, 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. I wanted to show 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 Android side, kind of gracefully, like it doesn't crash. So that's it. So check it out. And here's what you might have as an experience as a developer getting into React Native when it's not full parity because it's not a paid product. It's Facebook is developing it because Facebook wants it and believes that it, that open source is the right way to get 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. So you don't pay a dime for it, whereas if you pay Xamarin, they're going to be the ones that are doing the work to make sure you get the cross-platform parity. But it's still not that bad of an experience. You can still maybe find your way around it for doing a proof of concept or getting developing a startup type app from the ground up, like there's something you can do and still get that shared code base 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 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 and true for smaller companies to look into that idea of potentially going with a cross-platform solution. And the reason for that is because 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 dependency craziness that can occur. When you have a single cross-platform or cross-device platform that you can build on top of, a lot of that management goes out of the window. And what that does, especially for those smaller companies, is it allows you to focus on those features rather than focusing on the implementation. And part of the reason why you might eventually go to iOS specific or Android specific is to gain advantages of those native APIs that may not necessarily have perfect parity with something like React Native. Yeah. And again, we're back to talking about trade-offs. It's an 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. Right. You have to deal with the trade-offs, sorry. Especially the profile 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 concept 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 as smooth and as quickly as they can do that will be all to the good. So it's definitely that profile of company should probably think about a cross-platform tool. Don't just throw it out. I mean, I've had arguments with people, the developers, they're coming down on one side of the other and I'll play devil's advocate and all that kind of stuff. And 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 take a really good nuanced view of the trade-offs that you're looking at and a cross-platform. The other alternative is to go with one platform first. 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 all that kind of stuff. Or hey, no, you should go with Android first because of X and then they sneer at each other across the aisle. Like, that may not be the right answer either. I don't know, but a full mature product shouldn't be on just one platform. I believe that pretty strongly. So you're going to have to think about it at some point when do you think about it as goes into that trade-off. And I have to admit, by the way, that if I had to pick maybe being who I am or knowing what I know or whatever I would like to have native development platform-made. So I would like to develop an IOS app and an Android app to get. But that's maybe not the right business choice. You know, figure out what you're at, where you're at. I like developing on multiple platforms. I like this whole polygon idea. I like that as a fun thing and as a fulfilling thing. But again, I hope that this book helps people understand how to think about the trade-off. With enough information. That's kind of one of my goals. Yeah. And that's really 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? The point of the seven and seven series is let's experience all seven of these in their nuances and in their strengths and weaknesses. And in their styles, there's a lot to be said just for preference for looking at code and saying, wow, I like the way that looks on my screen. And I would like to look at that code regularly. So I think that's a really powerful statement that this is more about understanding and learning the process of comparing the trade-offs. And that's what seven and seven allows you to do. Yep. Seven and seven as a series, another byproduct of looking at this is there's so many things to be taken from this kind of way of 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 APIs and different ways of looking at. And here's how we're going to solve problems, like just going, pairing all in this, this is more complex book, which is maybe not necessarily a great thing than seven languages in seven weeks. Although it's, you know, it serves as a slightly different purpose. But when you pair back all the mobile platform stuff, you're also dealing with different languages and different paradigms and stuff like that. 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 different framework and say, oh, interesting. Now 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 work a day language, maybe you're stuck with an older language that doesn't quite 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 day-to-day language. And that's another benefit. Same thing with looking at these different mobile platforms. How does maybe you look at React Native and you say, dang, they really solved this development workflow issue that's bugging me and I'm not able to use React Native at work. But I'm going to go sell to the product owner how important it is for us to clean up this development flow and let's build in something like they've got for automatic reloads because that would give increase our development productivity. So I like the idea of just learning from these different platforms. There's so much going on in the mobile application space and it's important for I would say all Developer To be looking and aware of this space because it's, we can't just ignore the massive nature of 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 that are available to us through 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 in a one, maybe two code bases that breach screens of all sizes from your watch all the way up to your television and everything in between and all capabilities in between natively. So that's in the future for us. That's coming down the pipe. And these types of platforms, the ones that are in 7 mobile apps in 7 weeks that Tony has written, these are going to be the things that kind of define the first days of that movement. And it's already happening. This isn't something that's like happening in 2020. This is already beginning today. So go pick up the book if you're listening to this podcast and you're interested at all in mobile development. Go and pick up Tony's book when it comes out. And Tony, do you have about a 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 you can also go to the Pragmatic Programmer website now and get it in digital form and get the book later on when the book is released. Perfect. Of course, there will be a link in the show notes to that Pragmatic Programmer link that Tony is mentioning there. Just a quick side note, Tony and Pragmatic Programmer, none of this is sponsored. And I just believe that this is going to be a great book for those of you who are interested in the subject. Tony has not given me a kickback or anything like that. That's not what we're doing here. I just want to share this information with all of you. And Tony reached out to me and I thought 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. And it's questions that I like to ask every developer 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 tough one to answer. Let me, I mean, maybe it's top of mind because we're already talking about it. But I think the theme of what the 7 and 7 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. 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 how 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. And the mechanism by which you get that is by digging in and understanding what's different about this platform. And you have to do that by going through a few of them and as you start to exercise those pattern recognition muscles, that is something that you should as a developer foster because really a lot of what we do is pattern recognition and categorization of stuff by that mechanism and that's going to make you a better developer by learning more than just one platform language whatever it is. Yeah, that's good, understanding that our jobs are not just about platforms and languages, but they're about the underlying principles that drive those platforms and languages to become popular and to become usable and functional. Those are all incredibly important things for us as Developer To be aware of. So that's great advice, Tony. Exactly. How does the solve problems, so understand how to solve problems? That's going to make you a better developer. Exactly. The second question that I have for you, Tony, is what do you wish more people would talk to you about? What topic or concepts do you wish more people would talk to you about? Hmm. Another way to phrase the question is what do you wish more people would ask you about? Oh, hmm. So I can go off the, I can take off the developer hat for a second, is that what you're saying? Yeah, absolutely. Okay. Well, one thing I'm interested in that I would love to talk to anybody about and I go, I'll probably go out of my way to talk to people about whether they ask me or not is a hobby that I've picked up recently or pursuits rather than hobby, I think I like, I would like to say, 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 groups around the country and around the world that are starting to pick up historical fencing, which means like they're going to, they're going to fence, they're going to fight each other with historical weapons like the Long Sword or older weapons than the modern sport fencing weapons and make it kind of a sport and do it safely and all that kind of stuff, but like recover a bit of this history and like the techniques that people wrote about, you know, up to 400, 500 years ago and see how they can sort of make that, 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 situation, but with historical weapons and it's called Kema, historical European martial arts. And I wish people would ask me about it just because they would give me a chance to talk about it. I saw this article and I saw the video of this, the small little tournament 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 thought that this time was over. Yes. I thought I missed the boat, you know, by being born in the 20th century, but I didn't. So it's pretty cool. I'd love to talk to this. So are you yourself going to actually participate or what's the plan there? Yeah, I have been there. For a year, there's a club here in Denver, Colorado where I live that does these things. We look into, you know, they study historical treatises about how to fight with these different kind of weapons and then we do it. We spar, we learn the techniques and then we go at each other and it's a lot of fun. 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 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 and writing code, right? We can learn history quite well, you know, actually going and seeing historical places, for example, but what you're doing with this historical fencing, you're embodying 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, and that was one of the impetus. One of the many impetus is I think that people who originally started to do this were who was having like, you see sword fighting in movies and it's awesome and it's, you know, it's done for the glamour of it and martial artists would look at that and say, you know, this is a little fake and that that really wouldn't happen. But somebody probably said, or lots of somebody's said, what did, what was it really like? What did, what did you really have to deal with when somebody stood, you know, stood up against you with a, you know, yeah. 54-inch tall weapon and they were going to swing it at you. Like how would you actually deal with that kind of thing and what did people write about? And like one of the early manuscripts we look at it was written in the 1380s and that'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 like practical, but it is a way to like, to get in and learn, like just a bit of what life was like back in those days. They had to deal with, you know, this stuff more often being called up and told the fight for your lord or something like, I don't know, you know, not, 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 there 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 or was you just kind of bad at drawing? 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. It's really getting, trying to get in the head of the people who did this, you know, for either a living or whatever or just had to fight and had to know how to deal with it 500, 400 years ago and that's pretty cool. Sounds like a lot of fun. So if you're out in Denver 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 actually look at, there's one written in the 1380s, that's probably the oldest and then stuff written all up into 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 pretty healthy idea. Sometimes, you know, taking off 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 sponsoring it by the book, but instead what we're getting together as Developer 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 really 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, send me a note and I believe we can still chat if you've got questions. And of course, on GitHub, I'm also T. Hillerson. Perfect. All right. Then 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 a 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.