 Last year he run the the theming tutorial or theming bootcamp. This year he's going to talk to us about hybrid apps and if you don't know what hybrid apps are or if you don't know how you use WordPress to get over to mobile and all these other things then you're in the right spot for AJ today. So let's give him a round of applause and welcome him to the stage. Thank You Chris. How's everyone doing? Yeah? How's your work camp in? Excellent. Love Saturday. Right? Hi everyone. I'm AJ Zane. I work downtown at a startup called Veo doing fun and development and I have some incredible news. My coffee shop has an app. Right? It's amazing. When I found out I was so excited I stopped at what I was doing and I yelled in the middle of the store. I mean come on my coffee shop has an app. That's incredible. I downloaded it and I instantly discovered all the cool things it does. I could take pictures of my coffee and croissants. I learned about all the cool events that were happening and I got I was one of the first people to know about deals. I was able to reserve my favorite seat. It was a dark creepy little table in the corner but it got the best Wi-Fi and I was able to deliver coffee for those late-night code sessions. Then I realized the app was pretty pointless. It could have just been a website. How many of you guys have apps to small businesses or mom-and-pop shops? Anybody? Yeah? What do they do? It says what? Royalty apps? Okay so like you check in and you get deals and coupons and stuff. Yeah? Anyone else? Anybody? I know there's some salons. Yeah? That's something. A little Italy. So this is like a map of little Italy and it tells you like WordCamp San Diego is happening. Come check it out. Awesome. Cool. So interesting with the coupon things. Have you guys noticed that there's a new coupon app pretty much every three months? I think it might be a conspiracy but you know this keeps popping up. So when I discovered and came to the revelation that my coffee shops app was kind of useless, I decided to take stock of what I call clone apps. And these are apps that kind of don't serve any purpose beyond the mobile browser. Things like IMDB, Reddit, Facebook sometimes. I want you guys to take a minute. Think about it. Do you guys have apps that could just be a website? Yeah? How many do you think you have? More than five? More than ten? I have 22. 22 apps that are so useless. I sometimes open up the website anyways because I forget I have the app. Also beyond those 22, eight are coupon apps. So I think it's definitely a conspiracy. I don't actually have a coffee shop app. I don't even have a coffee shop. But this app craze is pandemic. And I think that business owners are getting tons of pressure and tons of marketing about how they need to amplify, how they need to increase engagement and conversions. And it's gone to the point where it's like the opposite of the responsive revolution. Instead of us having to go to people and convince them that they need a responsive site, they're coming to us thinking that they need an app. And I think this comes from a lot of assumptions people have about what apps do. For example, offline storage. Now it is really important that your website isn't wasting battery, isn't wasting a data plan. Offline storage also makes your app be kind of always available and always on. You can always get the features of it. Push notifications. Again, it's about engagement, engagement. It seems to be the buzzard right now. And that's what businesses think is the most important thing that they need to do. Rich data models. This assumption implies that an app is inherently different than a website. And that it not only can act differently, but that it needs to. And finally, speed. The assumption that an app is going to react better with the phone or mobile device hardware than a website can. The truth is these assumptions are just wrong. For example, browsers like Chrome and Firefox have offered offline storage and push notifications to web workers for a while. More browsers are adding it. Next year, when we were all back here, mobile browsers are probably going to look completely different than they do now. The rich data model is totally bunk. We all know how powerful WordPress is. We all know how much work, how many commits, how many decades or years have gone in to this awesome, awesome backend engine. 25% of the internet also knows how awesome WordPress is. Speed, I can't argue with. They're actually right. A native app is always going to be more performant than a website. But that doesn't mean that a website can't be performant enough. And if you think about it, could texting work for my coffee shop? Could I just text them? I'm going to be there in 40 minutes. I want to sit in my favorite table in order number four. Because they have some kind of system that has Twilio and just accepts the text, puts it into their kitchen and stuff, and there's good to go. Twitter, when it first became an app, was just a hybrid web app. It was just the Twitter website and a little box that ran in an app. And that worked good enough. So the browser is good, but when do you need an app? There are definitely times that you need it. If there weren't, I probably wouldn't be giving the talk, right? So first, you require device hardware, talking about GPS, accelerometer. For example, let's say you have a hiking app, something that's going to work offline, you're going down a trail and it follows you with your GPS, and it will push information up to a smartwatch, say, you know, who discovered that rock or the last Bigfoot setting that happened over there? You know, really, really important stuff. If your app is going to serve a really, really specific feature, it needs to do it at your users fingertips really frequently. Think Facebook Messenger is a great example of this. Facebook had it in the main app and they just tore it out. Because what they realized was that people wanted to do messages and they needed to do it in a very specific vertical. And that was a really great decision on their point. So let's get into how we're actually going to make apps. The software is a service model. There's a lot of tools out there that can help you do this. And I mean a lot. Now, these tools provide a GUI for you so you can kind of lay out your app, say what it's going to look like and choose what WordPress content you're going to pull out of it and where you're going to inject it. Now, like most page builders that we're used to in themes, this comes at the price that you only get to do what the developer provides for you. Now, I think that these services are awesome if you want to quickly get into an app and they do serve some specific purposes. Personally, I like writing code. I like cracking things open and when it breaks, I like to brand myself, I guess. So let's talk about how we're actually going to code some apps. We're going to nerd out. Are you guys excited? Yeah, we're going to go to the library. We're going to get some textbooks. Yeah, we're going to join some meetup groups, right? It's going to be so much fun. We're going to get on to Code Calvary. We're going to get on Stack Exchange. We're going to learn Java. Yeah, right, Java. We're going to learn C Sharp, right? We're going to learn whatever it is you need to know to write Windows OS apps, and we're going to make some apps, right? Yeah. Wait, no. Oh, wow, no. Sorry. No, I got really excited. We don't need to do any of that. We get to be lazy. I mean, efficient. Hybrid apps are built in web code. We know how to make a hybrid app today. As long as you know a little bit of JavaScript, you're good. Like Matt Mullin like said at the say of the word, learn JavaScript deeply. Now is definitely the time. Beyond that, these tools use the same build tools that we're used to. Just like we can take an empty text document, use Grunt, Gulp, Webpack, package up a completely deployed app, launch it to deployment, and five environments. These things do the same thing. Link text document to fully package downloadable app for your phone. And beyond that, hybrid apps have one code base to rule them all. They really achieve a right once deploy everywhere ideology. Now, we all know how difficult it is to write code for one website. Now imagine if we had to write different code for every single browser that hit the website. Now, granted, we kind of do that with CSS, but what I'm getting to is that a really smart developer was looking at their iOS and Android projects, and they said, why am I doing this twice? This doesn't make any sense. Which also brings up an interesting fact that usually when we say app, we're only implying iOS and Android. But the hybrid app approach doesn't only cut our development time down in half, it cuts it down by many, many multiples. The same code is going to run in the web. It's going to run on a smartwatch. It's going to run on a Windows phone on the next weird smart or stupid home device that comes out. And it's all going to be one code base. So here's the key. Who is playing WordCamp Bingo? Anybody? No one's playing WordCamp Bingo? Well, you should start now because you're going to get two things. One, a computer with a bunch of stickers on it. Two, WPJs on the REST API. Now, I know there's tons of hubbub about it. I'm sure you've probably been to some talks that have talked about it, but it really is, in my opinion, one of the most important things that happen to WordPress since custom post types. Who here has ever done a RESTful app before or knows REST? Okay, so cool. I'm going to go into some definitions really quick so we can be on the same page. REST stands for being REST. You know, lazy. No, I'm kidding. It's an ideology where the front end of our apps don't need to know anything about the backend. They don't need to know how the data is structured. They don't know what's in it. They can just make really easy requests and get the data back really simply. How it works is with a few key verbs. It's kind of similar to WordPress, how we have the loop, hooks, meta fields. There's just a key core concepts that make everything work. In REST's case, there are these verbs. Get means that you're getting stuff from the back end. Put means that you're putting stuff in the back end. Post means you're updating data and delete as well. The data that we get back is going to be in JavaScript object notation. If you don't know what objects are, they're basically like an array where each space in the array has a specific key that we can reference it. In this example, if you can read it, is a little description of this word camp. It's got the name, the date, location, and we're able to access all these different features dynamically. We could use the exact same data model for word camp LA, word camp OC for pretty much any event that we'd want. And finally, we get endpoints and routes. Now at endpoint, you can think of like a function. It's going to have some kind of action. It's going to give us data. It's going to update a user, create a post, change some metadata, something like that. A route is a URL to the endpoint. And it's pretty much for us humans. It's something that we can really easily visualize. Also, it's smart to note that a route might reference many endpoints. Just like when we're writing code normally, we can have a function reference another function, recursively reference itself on another function. You can get into that. Now, all of this introduces a kind of different way of writing code, usually known as model view controller. For example, here is a typical WordPress loop that we're probably all used to seeing. And you'll notice that the markup and the logic are all jumbled together. You know, it's true that as WordPress developers, we have to be front-end developers, we have to be mid-tier developers, and we have to be okay with the back-end too. We have to be comfortable with writing database queries. Tools like Timber that separate these concerns are doing a really good job of bringing an MBC approach, and these hybrid app tools also do the same. And this is kind of what it looks like. As you can see, the JavaScript is grabbing the data from the back-end and it's putting it into an object. The markup is just HTML with a little bit of templating. It only cares about layout. It's not doing any logic. It's not parsing stuff. It knows exactly where, in this case, the post title should be, and it just puts it right there. Now, this is super great for teams. Let's say you have a web designer and a back-end developer. They can keep focusing on their same individual thing that they're really good at. You can work really fast with your teams this way. Now, it's also great for your brain, and it keeps you organized. I mean, just look at how clean that is. I have dreams about it. Now, I have some bad news for you guys. Unfortunately, enabling this stuff isn't just one click out of the box. We don't have a five-minute install. We're gonna have to configure a couple things. First off is some server settings, like the great talk that we just came from, HTTPS, really, really important. Now that you're dealing with these mobile devices, they're just everywhere, and not under a Wi-Fi connection, it's secure. You really wanna make sure that all the info you're sending is secure, and that it's handled correctly, and that important information isn't gonna get lost or end up in the wrong hands. Cores or cross-origin resource sharing is a really tricky thing that will probably mess you up if you don't expect it. Now, usually it means what the website expects other websites getting information from it. So, for example, if you have a live environment and you're working on your local host and you try and request all your post data, it'll go, whoa, whoa, whoa, whoa, I don't know you. I can't give you this information. Now, there's lots of tools that you can use, usually some browser extension. Sometimes you might need to do a server tweak. I'm not too sure on the details, but just watch out for that if you run into it. Limiting requests. Now, because it's so easy to request content and request massive amounts of content and do it in really, really fast a session, you can take down your servers in no time and it's really embarrassing. Luckily, the WordPress JSON API2 version limits the default post that's gonna return to 10, which helps, but if you're making your own endpoints, if you're doing your own functionality, watch out for this. Finally, Torque Magazine has a really cool article called Preparing Workbest to Power a Single Page Web App, which I just realized has a lot of Ps in it. It's a really, really great article. It goes into these things in details. It also has some great examples of doing things like setting up an endpoint cache, where it's kind of like a transient and the endpoint doesn't need to go through the database and compile code and process logic. It can just know that's what data you want, just grabs it and spits it right back out. Now, to actually get running with this stuff, you're gonna have to enable the plugin. It's not in core. People keep saying it'll get in core in the next release. I don't believe it. I think there's a lot of work that still needs to get done with it, so make sure you get the right plugin. There's a lot of WPAPI plugins. This one, the REST API, you know, is WPJSON REST API, it's all acronyms. That might make it easier to remember. I don't know. Now, here's an example of adding custom field meta from advanced custom fields. As you can see, you need to add a little bit of code to get this kind of stuff that we're used to. Again, you can do this either through a plugin or through writing your own code. Now, this means that there is an extra step to getting WordPress stuff that we're used to, but it's a small step. And pretty much everyone else that's trying to do the same thing has definitely already done it. The number of plugins that are out there for things like this, for all the big plugins, there's tons of them. They're really well supported, really well documented. I wanna get into some code stuff too. Really quickly, an end-to-end example of how the whole JSON REST thing works. Step one, you've got your endpoint. In this case, I've got version one and version two for getting a custom endpoint for a custom post type. In this case, it's called legislation. Step two, you're gonna need a JavaScript function. That function is going to call the endpoint. Do your best database, it's gonna get the data out. Now, depending on what kind of tool you're using for your app or whatever thing you're building, it's gonna be written differently, but just know there is gonna be some kind of JavaScript thing that needs to shoot out information. And step three, you're gonna get your JSON back. This, you get a nice pretty little block, right? It's got its ID, its title, the content, author information, which is gonna have tons of stuff. Sometimes you might not even need all of it. You're also gonna need a tool to test endpoints. Personally, I really love Postman. It's a Chrome extension, so if you can get Chrome on the device you're working on, you can get this. It lets you break out your endpoints. You can organize them in folders. You can test them, you can share them with your team. When you work on new functionality, it will run through absolutely everything. You can have stuff like variables for your IDs, for other meta, and it takes care of all of it for you, and it's got a really, really nice UI. You'll also want a JSON formatter or a JSON viewer extension in your browser. The JSON I've been showing you has been formatted really nicely. It looks pretty and organized, and it kinda makes sense. This is the matrix mess that JSON is if you just try and view it in your browser by default. It's a block, and just a giant wall. So make sure you get something like that. It's gonna make your life really, really good. And the final thing I need is a framework. Again, these frameworks for hybrid apps are written in web code. They're familiar to us. We have all of the skills that we need to start running, and they have done a lot of the base work already. They have these awesome UI kits. Buttons are the right size for your thumb. Text is legible. A lot of the animations and other UI tweaks look native, so they give you that really native feel right out of the box. These frameworks come with tons of testing. Both unit testing and a huge community that's tested everything. You're also gonna be working in the browser, so you keep using your tools like the Dev Inspector. Get all of that. It's really, really nice. In the community for these things, just like WordPress, people care a lot about these. They're contributing to these tools a ton, and it's really easy to find solutions for your problems if you run into anything. And finally, also like WordPress, they're super extendable. There's tons of plugins for these tools I'm gonna show you, and they're really easy to extend yourself. Now the first one is Ionic. I personally love Ionic. It is written in HTML, CSS, and Angular. Since I'm in Angular Dev by day, I don't need to switch gears to get into hybrid app development. It's the exact same code stuff that I can write. If you don't know Angular, it has a bit of a learning curve. Ionic out of the box has a lot of the tools and the hard architecture written already. You can do just a lot of copying, pasting, and just tweaking minor bits. It's written in a web view within phone gaps. So again, like Twitter used to be, it's just a little browser that loads up this webpage that then has access to phone features. Google writes Angular, which I think is really cool. Really big company. They put a lot of work into it, and it is very, very, very well documented. Again, this is open source, and there's a really cool starter kit on GitHub, specifically for WordPress sites. You download it. All you need to do is change one line in the config for where your website is, and boom, you have a really basic WordPress site that's gonna load up your pages, all your posts, and have a homepage, and it's really easy to add more to it. The next thing is React Native. This is made by Facebook, based on their React language. It's written in React and JSX, which then compiles to JS Core, and then Objective C. So it's actually native code that's running. So it's supposed to be very, very, very, very performant, and their marketing really, really, really focuses on that. Personally, I haven't used React at all, but it looks really cool. It has some very neat concepts about how it's written. Again, this one's open source, and if you guys have followed Facebook, or Calypso at all that automatically released, that's written in React. If there's any automaticians here, you guys might be able to fill us in if you guys really like React, and it sounds really cool. All right, so what else you'll need? If you're gonna try and make an iOS or a Windows app, you're gonna need Xcode and a Windows development environment. If you're on the opposite environment, you're gonna need a virtual machine. If you want Android, luckily they don't care because Android's the best. You can always run Android on anything. If you're gonna want to release your app, or make something in an app store, you're gonna need a license to these stores. Apple's is $100 a year, Google Play is a one-time fee of $25, and Amazon is free, which I guess explains why there's so many scammy, virus-y looking apps on their marketplace. Now I wanna get into some code examples. I haven't said some deep stuff before again to Q&A. Here's an example to make a custom endpoint. In this case, the route to it is wpjson slash myplugin slash v1 slash author slash 42. It sounds kinda confusing, a lot of slashes, but all that it does is it gets the most recent post from the author that you put their ID in for. As you can see, it's just a WordPress action, and that's all the code that you need. Now, in the action, all you're writing is WordPress code. So now you get to use all the code that we're used to writing in WordPress and make really cool backends. You can make a really, really strong application and have WordPress do all the cool stuff that other frameworks can, too. User authentication is really important. The WPE API team has made a plugin for OAuth, which they suggest you should use. If you don't know what OAuth is, basically it allows someone to log in with their normal credentials, but as a server admin, you get to choose what apps are gonna actually be able to refer to that, and you can block off certain applications from logging in. Sanitizing data is something we get out of the box really easily in WordPress. If you're using these frameworks, you might need to jump through a hoop or something to enable it. Again, it's really important since we're not in a secure Wi-Fi environment. For Angular and Ionic, it's really easy. You have this Angular sanitized package that the team's made and saw it with Bower. You add the script to your index.html file, and then you inject it into your app, and boom, you're done. Like I was saying earlier with these tools, the community is huge. They've developed so much already. You really don't need to build new things because most of these problems have already been solved. Caching. I'm no cache master, but caching is super, super important, especially if you wanna give your users offline access. The way that I've seen that I like the most is having a local DB with a couch DB, pouch DB, some next DB that's gonna come out next month. You basically just have any data you're gonna do. You store it to that local DB first, and then have that DB sync to your WordPress site that's still up in the cloud. If that connection gets broken, the user still has all of the relevant info that they've been using. Killing sessions is also really important. Think about if you have an app that someone's logged into and they leave it on the table for two days. Do you want anyone to pick it up and that'll be in their account? Think about a bank site. How many minutes does it take before they lock you out? So very important to keep track of that. Formatting the content, this one is really annoying. In this example, you can see in the rendered content, there's the p tags. You might get link tags, hs, anything else that's in the WordPress content is gonna come out with that string. And when you display it, you're gonna get those carrots and all those HTML elements and it's just gonna look like a messy blob of nonsense. So make sure your framework has some kind of system around this. Angular has an ng-bind attribute and it just takes care of it itself. Some other things, you might have to loop through the content and process it first, but there's gonna be something out there. Just watch out for it. Next, registering custom post types for this. Obviously, no one knew that custom, the REST API would be a thing in five years, right? Five years ago. So you're gonna have to just add these three features. I'm gonna kind of skip through this. You guys can ask any questions if you want. You're gonna have to do that for taxonomies as well. Packaging is this whole world of its own. Again, these tools are gonna have systems in them. Some kind of build thing that's gonna automate packaging everything and getting it good for you. Getting all set up for the app stores. You're gonna have to set up your licenses. You're gonna need a specific config file. Every single store has its own system for it. You're just gonna have to read their docs to figure out how that works. The metadata, same thing. They're all gonna have different requirements for what you provide, like the title, description, author data, all the images, all different versions of the images and all the different sizes for every single device. It becomes a huge mess. Finally, you submit your app to the store and you wait. It takes a while. If any of you guys have submitted a plugin or a theme, it's a similar system. It just takes time. Ionic. Other reasons my favorite is a tool called Ionic View. It's great for teams where you're not all developers. For example, if it's you, your project manager, your boss, and a client, they can all download Ionic View. When they log in, it has a list of all the apps they have access to. As a developer, you can do some code work. You send it to your project manager. They say, all right, no, it's got bugs. They send it back to you. You fix the bugs, send it back to the project manager. They say, okay, then you send it out to everyone else. They go to notification, they update their app, and boom, they're running. And it's in their hands instantly. You can put it to any device you want. It's a really, really awesome tool. So, like I said, there's a lot of hoops to jump around to get this working in WordPress that you want. And it might seem like it's not worth it, but I think it definitely is. I think it's just a very small annoyance we have to get around, but it opens up so much that we can do. For example, now you have Cordova in your apps. This is a JavaScript library that lets you do all kinds of really cool phone device hardware stuff, like all this stuff, touching, where you can put your thumb on the thing and log into stuff, cameras, push notifications. It's all in the box. They have great libraries for this. Here's an example of accessing the camera and you get the file. You can do whatever you want with it. You could process it. You could share it to a social media thing. You could save it to the phone. And it's only that much code. So, that's it. Here's some resources for you guys. Thank you all for coming and I hope that we can make some apps for our coffee shops. Do you have any questions? I will try and come down and run to you with the mic. Yes or no? Questions, anybody? No questions. Who wants to make an app? Yeah? Are you guys excited now? You're gonna be able to do it? You feel confident? I hope so. It's really, really easy to do this stuff. Very easy. So, yeah. So, you're currently using Ionic, right? What is your workflow like when you're getting started? So, my workflow to get started in Ionic is the exact same as my workflow when I get started on the WordPress app. I'll download the Ionic starter through Git and in that, there's just a clear command. It's like Ionic, add platform, iOS, Android and then Ionic serve. That basically runs a run command that compiles up all the HTML and JavaScript and then opens up in your browser. From there, you're writing HTML and JavaScript is the exact same. Anybody else? All right, cool. I will be around if you guys wanna ask me questions. So, we're at the after party. Have a great work camp.