 Welcome to Taking Phoenix Beyond the Browser with iOS and Apple Watch. While putting this talk together, it took a lot of sort of pulling a lot of resources from my past and trying to be able to see a curation of things that have progressed along the way. And so today, I really wanna just talk about ideas and inspiration, but most importantly, I wanna talk about innovation. So I promised myself that I would only use the phrase Internet of Things maybe twice. And I'm not sure if this example really counts, but this seems to be where innovation has led us to. So that's one for me. Now, moving on. For those of you who do not know me, my name is Justin Schneck. I work at a company called Live Help Now. During the day, we create some excellent customer service software, including Live Chat. A lot of it is now running on the fantastic Elixir and Phoenix application stack. And on my spare time, I like to mess around with a lot of embedded hardware. And from that, we've sort of collaborated a great group of individuals together to be working on the NERVS project, which is for creating some embedded firmware for running Elixir and Elixir applications on smaller devices like the Beaglebone Black or Raspberry Pi or things like that. In addition, we have a component called Bakeware. We're also trying to work on together to be able to have an automated system to make it a lot easier for people to be able to bake this firmware. So how did we get to this point, or at least I should say, how did I get to this point? With a little bit more backstory. When I started programming software, I had this fascination with the ability for you to write some code and affect other areas. And at the time, it felt limiting because those other areas were other areas of code or software. And I sort of had this thought to myself where I wanted to be able to do a little bit more. I wanted to be able to control things around me. I wanted to be able to affect my environment. And one of the best ways to do this at the time was the Arduino platform. This is a very old Arduino right now compared to the ones that they have out today, but it was an incredible experience. I found that with a little bit of C code and a little bit of time and an Arduino board that I bought from Radio Shack, I was able to link that light. And I don't know if anybody, I'm sure there's a lot of people in here that have maybe gone down this path and started with electronic engineering or even playing with these toys, but that was huge. It was sort of the entry point to just changing my perspective on what I could actually accomplish with software. From there, I decided I wanted to go a little bit more. It seems that when you start buying Arduinos, your wife kicks you out to the garage because there's no more space for this anymore and wires everywhere and things like that. So my next obvious step now that I had an entirely new large man cave, I needed to deck it out with some excellent equipment, such as an intelligent tap system. And we started doing a lot of home brewing, was enjoyable. And creating some more stuff with fermentation systems. The system on the left is fantastic, I really enjoyed that one. That was Waze Kegs, to be able to tell you how much is left in them. That all worked through some lower end embedded systems as well. That was also built on an Arduino platform. The brewing control on the right there, that's actually a display system we've been testing with too. It's a fully touch screen Wi-Fi enabled that allows you to be able to stream it to the web. That's kind of where things started to feel a little bit more complicated. Arduino and really low level stacks trying to stream to the web. But anyways, we stepped a little bit further and after the lab was sort of complete in its own way, I decided that I wanted to be able to enhance things that I owned. And from there, I had my Triumph Tiger motorcycle. I built a sub computer system for it, also based on Arduino. With a wireless embedded electronics sewn into a riding jacket, where we were able to use some tri-color neopixels and synchronize all this data back and forth so that when you turn the blinkers on on the motorcycle, the onboard computer could sense the pulsation of the voltage. And was able to, in sync, blink the lights on the back of the jacket. Very cool. So, I wanna go over a few of these pieces and kind of share some of the things that I've learned along the way. And in doing so, I wanna bring up some of the things that we're gonna just be talking about. I mean, you can't have a talk entitled Going Beyond the Browser with Phoenix, with iOS and Apple Watch, without talking about iOS and an Apple Watch. The additional part that I've peppered into it was my love for embedded hardware. Now, some of these concepts that we'll be discussing can absolutely be reused in different avenues. You can use them on their own, you can use them with embedded systems. But they're all sort of centralized around the idea of Phoenix and channels. Before we get into that, a little overview. Some of the things I wanna discuss first are what are the problems that we're trying to be able to accomplish by introducing these new abstractions through channels with Phoenix. I'd also like to talk a little bit about the project, which are entitled Motor Metrics. We'll get into some code examples. And that code example there, you can see I have code examples and more code examples. The more code examples, we're gonna have to touch on some objective C, because that's the iOS library that I've done some of these examples in here. And then to wrap this all up, I'd like to discuss the future of some useful things that we can all create. So first, the problems with traditional web. The first problem that I feel like I've encountered in traditional web, and this is one that we've all sort of been talking about a lot, is connectivity. And a lot of us are all familiar with the outstanding ability of concurrency and connectivity that we get with Elixir and through Phoenix. So identify this and just sort of recap on a little bit of it. I'm sort of seeing this as a change of the state of change. And lots of people are discussing recently about stateful services and stateless services and really this is just to see a wrap up of where we've come from. I mean, we're all familiar with in the past the model showing us that a client makes a request to the server. The server then makes a response back to the client and then the client's able to go along their way and everything is fine well and handy and that's great when you have these desktop machines that are just out there asking for little bits of information. Well then the model gets a little bit more complex and you start adding in more devices. You now have laptops, portability is introduced. So desktop machines are now accompanied by this swarm of laptop computers and this compounds into this new swarm of tablets and phones. And furthermore, this now is starting to get onto the edge of compounding itself with tiny little sensors and bits of data streams that need to get curated somehow so that that information is actually useful to you. And when I say compounded I really mean there's a lot of them out there and they can all sort of just be on like Wi-Fi devices and have their own little data streams. You talk about what that could be, it could be anything from the current temperature of your refrigerator. The wash cycle that you're washing machine is on. Some useful, we've seen the other side, some other. And you can't talk about this kind of stuff without mentioning traditional WhatsApp, 2 million plus, the perfect place to be able to move forward with. So solving one problem. Another problem that I see is creativity. Now, I have to just go back and show you this slide again cuz it's so absurd that you have to realize that this is now what we're showing is creativity. This is what companies are coming up as, our best ideas to move forward with. Now, there's a lot of people that have different philosophies on why this is happening out in the marketplace. And nobody's really come up with a great way to be able to solve the problem cuz well if it was solved we wouldn't have these. And one thing that I consider this to be an issue with is the concept of walled gardens and software. I mean, if you buy company X's refrigerator and you wanna use it to be able to manage its smart device content, you also are expected to have company X's cell phone and their television set and their, I don't know, garage door opener. But nobody can really be that great at creating all of those products. And all of us are individuals. So we wanna have the ability of choosing and intermixing all the different data that we want. And that can be quite a task because the current standpoint seems to be like this, where your phone is just full of applications. And that, it's so convenient, if I wanna open my garage door, all I have to do is unlock my phone and go into the garage door app and then tap on the button that opens my garage door. And instead of hitting a button that used to just open my garage door, that was there. It seems like we're kind of limiting ourselves with this feeling of abstraction. But we feel the need that, we feel like that abstraction needs to exist somehow. But it needs some tuning. So my proposition in this case for the solution is to sort of start from the ground up again. The issue there is the ground up required in the past really low level libraries and a lot of knowledge to build this on. A lot of people who wanted to be able to tinker around with electronic devices really needed to hone in on the ideas of soldering their wires together and breadboarding and understanding the low level pieces only to get themselves finally to the point that they could control something. Then as we saw, came along the Arduino platform. And this brought in a lot new pieces of innovation so that a lot more people could come on board. It had an easier to use build environment, a great IDE. This caused the community to grow and more and more people to be able to create great libraries for it. From here, they moved on to something a little bit more powerful and we see the Raspberry Pi platforms start to take off. In addition to Beagle Bones and a lot of other custom Linux hardware that was out on the market. And this stuff was great because it provided higher power, which gave you higher connectivity stacks. It finally brought you out to the web in a secure way and also you could write in higher level languages. So what's the point of those pieces? Well, I feel like part of this might be able to be sort of a history rewritten in a way. Because if there's one thing that we do best as developers, it's standardized things. And we can all agree when we get to a point where we say, yeah, that looks really good. I wanna use that moving forward. So to me, socialized standards is a great way. And GitHub is a perfect tool for this. And we all experience in the Elixir community, these sort of abilities of conversations exploding into new features and full requests and it's just momentum that you feel because everybody's sort of on the same track towards greatness. So the third part about this is performance and productivity. And I'm not necessarily speaking directly about Phoenix's performance and productivity discussion. Whereas, yes, you do get a lot of great performance and you are very productive in it. I'm speaking more along the lines of from the connectivity part, connecting Apple Watches or iOS devices. And up until now, that sort of felt like this. We've always seen some of these where you have cross-compiled code and some sort of JavaScript library that you wanna run in lieu of actually creating an individual iOS application or an individual Java application for Android or things like that. And you always have to make that choice of sacrificing performance, because JavaScript and cross-compiled mobile device frameworks felt slippery. Versus the actual feeling of running native accelerated code on your actual system, or on your devices. And that also came at the expense of the unified code base. You had to make that split decision where you go, how much of my mobile device stuff do I wanna reuse? Versus how much of it do I have to write into every single application? So performance is a big part of this because we've all sort of come to light to be accepting of the moving forward platforms. So what do I mean by that? Take this example here. I mean, in 2007 when the iPhone hit the streets, mobile device at that time was a new realm of smart devices. And at the time desktop machines were touting a fantastic quad core 2.67 gigahertz core duo. When the mobile devices came out, it was great. We've got a single core 620 megahertz processor. Now this might be okay because we say we consumed less on our phones. And it was for little bits of snacking on some data and some interactions at the time. Well, I'm kind of touting this as a different example. And really, while I wrote this, I wasn't reading a lot of other things. But earlier today, Bruce put it great as the pendulum. And sort of I need to touch on that because as a similarity I'm feeling in hardware specifications, I'm seeing it as the reset button. And I'm sure everybody here knows what that reset button is. You have to press it really fast for the game to finally work, yeah. So this reset button sort of falls into this reset loop where we have these desktop machines and really fast, powerful processors moving, marching forwards. And then we get to the point where we're like, smart phones exist. And then they're like, it's a slower processor. And you're like, okay, let's go back and work with that. And then in 2012, it happens again. They say, quad core 3.6 gig machines for desktops, i7s are out. And then Raspberry Pi comes along and 700 megahertz single core processors. We hit that loop again. And this just kind of keeps going in the same sort of pattern. This back and forth, we're like marching forward, iPhone's got faster. Embedded systems came out that are better and better. But we don't need to snack so much on that data. So this is that Utopia zone. It's the elusive search for the best unified code base. Cross-compiled JavaScript with a little maybe peppered in. We're not going all the way in one direction, but we're not necessarily going all the way in the other. To me, this zone was a combination of several different pieces of functionality. With those embedded system designs, we formed them moving forward into the NERVs framework. We're allowed to deploy embedded Elixir applications onto the higher hardware like Beaglebone and Raspberry Pi and connected those between web services using Objective-C libraries. And I'll get to a reason for Objective-C in a second. And then that all connected through to Phoenix which was just felt outstanding because there was finally a situation where it all felt like it kind of fit together and work together. And you've reached this point where you have that productivity in your development cycle because it doesn't, nothing seemed to get in the way. So here's an image of the kind of hardware that we were talking about in that realm. And the reason for Objective-C specifically, well, there are other libraries out there. There are other channel clients. In this talk, it's entitled iOS and Apple Watch. So I'm focusing more on the iOS and Apple Watch libraries. But as Chris put earlier, there are Java clients, C-sharp clients, things like that. So really, and then you can always fall back to the JavaScript if you need to. And the reason here is that there's the excellent Swift client that's out there. I got a chance to play with a little bit. Didn't satisfy our needs at Lifehub now because we had a bigger platform that we had to deploy to. We needed support for older Mac OS operating systems and older iOS devices. So here's just a rundown of some compatibility as far as targets are concerned, so to help you decide which one you want to be able to move forward on, depending on what your project requires. So let's look at some of the fun stuff now, the MotoMetrix project. It was certainly fun for me. The reason that it was fun for me, it was several of them. Well, I kind of took this motorcycle that I had and I wanted to be able to go out on a ride and just enjoy the scenery. And the most difficult part about riding and enjoying the scenery is wanting to be able to go out and ride and enjoy that scenery again. But remembering where it is in a way that you're not trying to use a phone while you're riding. So the big part that drove me towards this was the ability for me to be able to relive these rides. I wanted to know where I went. And when I got there, I wanted to be able to know how I could save them for later. In addition, it was really exciting for me to ride. So I wanted to be able to try to share the same excitement that I felt with anybody else that might be able to want to look at this data. And ultimately, I mean, it's just remote starting your motorcycle from an iPhone. You look pretty cool doing it. So some of the pieces that are in this talk are actually going to be a little bit more high level on this software. Because my wife would not be happy if I drove my motorcycle from Pennsylvania to Texas. So in this case, it's going to have to just be a little bit more high level. But we started out with the ability of connecting together several different technologies. We wanted the ability to view GPS data on the phone, also capture statistics on speed and lean angles. We wanted to be able to stream this information back from a server so that we can get updates in real time back to an iOS or a macOS desktop application. And of course, the Apple Watch is out so you gotta do something cool with that. We decided that we wanted to be able to use that to leverage as the start button. So how does this get set up from the start? Well, this example code here is pretty much pulled in as a very basic way to be able to get started with channels in Phoenix. In this case, in your endpoint, you just pretty much declare a socket that you want to be able to allow your devices to be able to connect through. Once you have that socket connected, and this is all part of the scaffolding. If you want to just be able to launch out a new Phoenix application. Once that socket's up and running, you can decide that what you have a transport and allow people to just connect in. Now, this is in some ways throwing caution to the wind. You'll see in some of this, it's pretty unprotected, but I didn't think many other people had the ability to hack into my system and start my motorcycle. Ooh, that's not good. Yeah. And from there, then you have the channels. The channels in the organization of this is really nice because it gives you a place to be able to kind of capture the end points of, I shouldn't use the word endpoint there, but the edges of where your data is actually going to be input, output, manipulated. In this situation here, we basically have our ability to join up to a ride that we've created and just call out some sort of authorization on that object. This can really be protected anyway that you like. You can use token authentication mechanisms. There's some stuff that's included, but if you wanted to be able to just scaffold it out and get something up and running, it's very easy to do that as well. So that got us to the point where we had a phone connected and streaming data from our motorcycle. From here, I'm sorry, actually that had us ready to connect the phone and stream data from our motorcycle. From here, we have to have a little bit of the iOS side of things. And I wanted to make it easy for you to be able to connect using this channel client library. So that it feels a similar way to deploying and scaffolding it from the other side on Phoenix. So it's pretty easy. All you have to do is a little objective C work here. It's very easy to bring over to Swift. But you declare the URL of the site that you're trying to connect to. Then you open up the socket and pass some parameters if you'd like to. User ID, something like that to protect yourself. And then later you can create the channel connection. So we have our individual channel connection here to sample room. Oops, one, two, three, let's say that works. The on event there, now we have the ability of listening for location changes. That's how we're going to stream some stuff back from the Mac OS onto the Mac OS application so we can see our write updates. And then when we're done laying out all that structure, we're just going to tell it to join so that way it can understand where all those callbacks exist in line. And we can start doing fun things like streaming our position. So this is all done through the push mechanisms with channels. You push data, everybody's pushing data back and forth. And in this case, we're going to push out some event, update position. Where let's say we hook into the iOS GPS system and we start pulling or receiving GPS data updates frequently. We can add that same loop. We can pull in the latitude and the longitude coordinates that we have. Package it up in a NS dictionary at this point and send it down the pipeline to be able to get pushed over to our server. Where it all gets handled nice and neatly. Coming into the channel, we can decide what we want to do with it. In this case, we're just telling it that we're going to update the position. And keep us marching along our way. Now, this is all great until we got to the point now where we have the phone being able to stream this data. And we want to do something cool and constructive with our Apple Watch. Well, there's a caveat here. And that caveat is that the Apple Watch, as cool and new as it is, doesn't support web sockets. There's probably a reason for this. I mean, I'm sure it would just drain the battery on the device if you were holding a connection open all the time. And I sort of pondered this one a little bit over and over again, trying to figure out a way around it. And once Apple Watch OS 2 hit the streets, I sort of, and noticing that they were missing the required libraries to be able to perform this functionality, I sort of took a step back and thought to myself, is it weird to long pull with my brand new Apple Watch? That would be working. Anyways, here's a workaround. So with Apple Watch, WatchOS 2, you can still interact with the open channels that you might have with your device. It's better to be able to support those open web socket connections on your phone, because the battery's a little bit more available. And in this situation, what we're doing is we're using the WatchKit session to be able to establish a session with the device and communicate back and forth with the phone. What this does is it allows you to just decorate out a module. Maybe it's the same module that you're holding your Phoenix connections open in to begin with. And in that module, you can pass data back and forth. So it's just acting almost like the phone is your intermediary to be able to get your data back to Phoenix. Now, this doesn't have to be a stopping point. Honestly, you can bypass this if you needed to do, say, short, stateless kind of interactions. WatchOS has the ability of just making out a call and being able to broadcast out and say, hey, I'm here. I'm telling you some data, I'm leaving. And then you can wait for a response that you'll get back through the phone. The sacrifice to this, obviously, is that you can't do any of this without your phone being around you. So you can't actually leverage the Wi-Fi abilities that they've touted in WatchOS too. So, how did this look? It looked pretty cool. It's got a prime of the fuel pump, yeah, it takes a while. Well, starting it was neat, but then riding it was even more fun. That's my professional chase car right there. So that was a lot of fun. Now, I gave you some higher level pieces of code to be able to look over there. But I will be open sourcing the entire project. You'll see it available after the conference. I will tweet out a link to all the information for it. There's just a lot of stuff to be able to curate together. I will also include examples of the work that we've done to be able to do the jacket interface and things like that. And the reason for this is because I want to break the cycle. I want to get away from the idea that these people who are controlling us with the terrible ideas coming for the Internet of Things, that's two, to be able to come up with a future of useful things. That's modified enough that it doesn't count. So for the future, this could take several forms. One of which is most people's ideas are to say that we should take what we know works and we should apply it to regular life. That might not work all the time. I mean, imagine the organization of this grocery store. So therefore, as I've stated earlier, I feel like it's up to us to be able to come up with the new ideas and moving forward. So it seems to me like it's not written yet. And together, if we can drive towards a goal of creating what we want, we can come up with cool new interfaces. One of which I brought with me today, because I couldn't bring my motorcycle. I took a labyrinth game, this wooden labyrinth game here, and I decided what great way to be able to show how we can stream some data back and forth between the two, then actually taking an embedded system and streaming some data back and forth. So this labyrinth game right here is running on a Beaglebone Black. It has two server motors mounted to it. And those two server motors access the X and the Y, access of the labyrinth game. The Beaglebone Black is running Phoenix and it's running a Phoenix channel application. And on my phone, I have some just very easy sample code that streams the X, Y coordinates of the gyroscope that's existing on there. Well, what does this look like? You can't really see the tilt too much, but my eight month old, she loved it. The hard part about this, as you can see from this image versus this real life image, is shipping an item like this to Texas also was quite a feat. UPS wanted to charge a lot of money. So as a last-ditch scenario, I spent an entire evening with some colleagues, going store to store and trying to see what I could do to make it pack into luggage. Here's in the middle of Radio Shack, trying to be able to figure out how to get it to work. And finally, we got it to the point where we could build a new structure. So I invite everyone that's here to not only go forth and build what you want to be able to enhance your own world. But after this presentation, you can certainly come up here and play with the Labyrinth game. Now this wouldn't be complete without giving you a little bit more information. So if you're interested in learning more about embedded elixir in action, I employ you to go to see embedded elixir in action. That is happening, Garth's talk tomorrow on track two. And you can learn more about this kind of technology that we're running this with, and at that point, any questions?