Video details

Angular: Cross-Platform Apps with Capacitor | Mike Hartington

Angular
02.11.2021
English

Mike Hartington

Join Mike Hartington for a walkthrough of Capacitor, a new cross-platform native runtime that makes it easy to build web apps that run on iOS, Android, and on the web as Progressive Web Apps— all powered by a single codebase.  Capacitor is a spiritual success to Cordova and offers a modern approach to app building that makes it easy for web developers to reuse their skills to build quality apps for all platforms, while significantly lessening the likelihood that they’ll get stuck on native-specific issues.
ng-conf is a three-day Angular conference focused on delivering the highest quality training in the Angular JavaScript framework. 1500+ developers from across the globe converge on Salt Lake City, UT every year to attend talks and workshops by the Angular team and community experts.
Get your tickets to ng-conf today at ng-conf.org!
Follow us on twitter https://twitter.com/ngconf Official Website: https://www.ng-conf.org/

Transcript

All right. Let me just share my screen. OK, so I got a confirmation that my screens up and good, it is good. Yep, perfect. Thank you, everyone, for joining the webinar today. Like I said, my name is Mike Hartington. You can find me online at Martinsen if you would like to tweet me pictures of your animals or just ask questions afterwards. We're going to be talking about building cross platform apps and we're going to be talking about doing that with capacitor and Angular. So the topic that is very near and dear to me because I work in this stuff on a daily basis. So let's start off with setting some baseline, right? I think we all are aware that mobile development is not the easiest space to be in, depending on what approach that you try to take at building a mobile app. There's oftentimes a lot of complex tools to learn if you are looking to target iOS and Android. Well, these are platforms that have very different design languages and design expectations and or user experience expectations. So you're not necessarily building something that is going to work the same exact way when you are building with native development tools. If you try to build these new development tools, well, now you just kind of signed yourself up for maintaining both of these platforms and at the end of the day, we were missing out on this huge chunk of users that are accessing information out there through the Web. So native mobile development, very difficult and it only gets us so far. So when I started off doing cross platform development or just development in general, I think a lot of the main goals I want to have is just to reuse my Web skills. At the very beginning, I wouldn't consider myself a JavaScript expert, but I knew enough to get myself into trouble and then be able to get myself out. So I didn't want to have to go through that learning process all over again. So I want to reuse my skills and be a effective web developer that could also build for native. Again, I didn't want to I was a new developer, really didn't want to have to maintain so many different projects or even really learn a lot about these native platforms. So if I could have just reduced the amount of code that I need to maintain or that I even need to rate, that would have been great and. End of the day for everyone, I think the faster we can get something out the door and ship to our users, I think we're all looking to do that. So whatever we can do to reduce our other time to market or reduce the development cycle, making sure that we get features implemented and shipped quickly, that's all important. So whatever we can do to reduce that time to hitting deploy, let's try to hit that goal. Now, if you've heard me speak before, a lot of this stuff kind of sounds familiar and it's no it's no secret I've been involved with this space for quite a bit. And I think I think you're all at least slightly aware of what I'm going to be talking about. But I want to set the stage and kind of reframe how we talk about cross platform development and this kind of way of rate once run anywhere and reframe it as not about technologies or approaches, but about levels of abstractions in that. The technology choice that we make, the technology choice that we're going to look at today, it's less about right once run anywhere or any of the technical aspects of it, but more about being at that right point of of of abstractions away from any given target. And the best way to visualize this is by comparing going in a pure web developer friendly approach and that a pure native approach and seeing how if we take steps away from those approaches, how do they compare and what are some of the details that we need to know? So keep this graph in mind and let's kind of dove into the first one, which is this Cordova or phone gap. So if you've heard this name before, you probably have heard it from a talk from mine or from various talks online, but Apache Cordova, it is probably the original pusher of write once run anywhere. And their whole idea was that there was a group of Web developers who wanted to take part in Shiping Web apps or writing apps for mobile devices. Originally created around the initial release of the iPhone, they wanted to take part in this whole app marketplace, but they didn't want to have to learn how to write Objective C or even Java. Eventually, they want to just reuse their web skills and deploy to the App Store. And a lot of that comes through in the implementation and in the actual approaches that you see in the actual approaches that you use when you work with their technology. Now, their idea was that it was to properly fill the Web browser by giving you access to certain features and APIs that didn't show up yet, but things like camera file system, geolocation, at the time, those APIs did not exist on the browser. So this is a way to prove those APIs out, work closely with the spec in the standards to implement them in a way that would be very feature friendly and follow the spec to a T. Eventually, they didn't really get to that point, but that was the original goal. Now, just a quick sample code for this, we have this concept of navigator or some global reference to an API on this case. We're looking at the camera API. It's attached to the Global Navigator object. So if we want to say take a photo or bring up the native camera UI, we could just say navigator dot camera. Dockett picture. As a success and a fail callback and then some options for when that camera API gets gets called, though, in this case we're just calling camera picture, my success will set some image data that gets returned on fail, will get a message or a reason for why it failed. And I want to be a pretty low quality image and I want to get a data URL, which is which would be like a base64 string versus a actual file reference. So all of this would just let us call that and we attach a click handler and we pretty much have the have access to the camera right away. Now, things to note. This navigator camera dockett picture, it's not necessarily a standard API. There's no camera object available on the browser without Capacitor Cordova being involved. So this comes a little problematic right off the bat. We have to make sure that we are constantly using Cordova and that we constantly have access to this or that we have to conditionally code around situations where it was just not available. So Tamara isn't the only API that we could have access to, we could also have access to things, like I said, the filesystems geolocation, a built in an app browser. And this huge community of plug ins or APIs that were provided through this plug in architecture, now on that subject, the plug ins and the platforms that you can target, all of these things were kind of published before 9pm YA and before we have like a standard idea of what a JavaScript package should be. So most of these were kind of shipped with. That's very custom and very. Wouldn't say proprietary, but this nonstandard approach to adding packages to a project waste just didn't stand the test of time with the onset of AMPM yarn on having things stored in a local node modules directory. And that, to me, is also a symptom of, you know, a very fragile ecosystem. They had a very custom package. They had a very complex build release cycle. They had kind of iffy plug ins that were available some of the time, not all the time. So right now, I, I don't really recommend people using Cordova. But even so, at the time, it was still pretty quirky, weren't really following the standard Web flavor approach to doing things. In addition to that, they really tried to push that Phil approach to Web development, where their hopes were to follow the Web standards as close as they could, but the standards kind of kept moving and support from the community just wasn't there. So we would see things kind of. Hmm, we'd see things kind of get stagnant. So appears like the media device's API, we're never really fully adopted into, say, the camera API provided by Cordova. They really wanted to push this whole no need for a native or native tooling, you would just do everything through these online tools, which was great in theory, but had some pretty well say bad, but had some unforeseen consequences. Most most people who have worked with Cordova before have read have run into the dreaded error code. Sixty five, which sounds pretty scary, but really all it is, is just the project wasn't signed by the right cert, so you can't necessarily deploy to the right platform or to the right device. All that would have been solved by just opening the native ID. And also, they took the idea of the projects and really pushed them as a target or a build artifact, so if you were trying to build something, you'd have to make had to be saying Certificate's is working great on your machine. You commit it to version control. You've lost all of the native project configuration. There's no way for your coworker to clone that project and install it without having to manually apply those changes to the project. So it's kind of it's kind of a very volatile setup. So this is one approach to doing cross platform with Cordova. What about the other side of the spectrum? Remember, this is kind of one step removed from doing Web development. What's the one step removed from doing full native development unless he has compiled native approaches? And there's a few different solutions in here, but they all kind of provide this idea of what if we had an abstraction on top of needed development that was closer to needed for development and brought in some other Web goodness or JavaScript or just some third party language to really mix things up? And they kind of pioneered this idea of either learn once and write anywhere or don't use JavaScript or use some kind of other language and build your app. And they all kind of come with this promise of a quote unquote, truly native app. This is a bit of a marketing marketing term of a truly native app, as we'll look at later. But. They promise a truly native app made it performance what have you, and they bring this idea of a standard kind of API or standard wrapper around native controls and device features, basically removing the need for you to ever write or learn native languages or native features. So from like a ten thousand foot view, if we think about what this actually looks like, we have your app written in this very in this blue Texas blue box up here where we have that loaded up in some kind of runtime. Some approaches use things like Vuh on Android, JavaScript core on iOS or a fully custom Third World Custom Renderer virtual machine that interprets your code and handles all the communication between you need a device features. But typically, there is this renderer or runtime wrapper, this bridge layer, and then this communication channel between OS level features, hardware features and this kind of sub architecture where they would make calls from the wrapper, from your app to the wrapper to the bridge and then serialize them back. So this is not it's again, it's a very, very simplified overview, but it's a pretty similar approach across the board. This kind of breaks Sando, because we are now having to. Relearn a specialized version of the tools that were already used to some of them tell you that you can use just JavaScript, but then you are limited to what approaches that you can use. For example, you might not be able to use the same elements and IVs and each one's paragraph tags that you're used to using in the Web because those concepts don't exist in that platform. Some languages or some approaches say the script is not the right language to use other languages altogether. Which is a really hard sell to a web developer. Now, in addition to that, we also can't reuse any existing zip code or any existing project code that we have maybe developed in a prototype or whatnot. You basically have to rebuild that all from scratch. And if you specialize or if you depend on, say, like a specialized library or a third party package. You're going to have a hard time trying to find one that exists for these platforms, so if we were to say we need a. A canvas API, we're going to have to find a package that is specific for these targets versus just saying, oh, I can find I can find a canvas API on on AMPM. And there we go. I can add to my project and it just works. These projects, these type of approaches of comp. summative don't necessarily bring the benefit of what Web development can give you. So you're isolating yourself into this very specific silo. And this truly netiv and a pitch is a bit misleading because the idea is that I think. People try to read this as, oh, my code gets compiled away and I get this very highly optimized Netiv Binary, right, and that's not necessarily the case. In some approaches, you get the JavaScript that you write and that is just translated and loaded up, like I said, in a VM. So no B or JavaScript core that JavaScript is still there and still executing. It's just rendering all the controls that you need to show to your user on the fly. So if you write a very slow loop or if you have this very computational heavy, a bit of JavaScript, well, that can affect your affect your performance. And there's no way to really get around that. Other approaches where they say it's a truly need to actually implement all of the controls through a very custom render that doesn't use any of the native controls, so you basically are drawing a canvas on your entire screen and it's up to that platform to make sure that their code matches the native platform code that says this is really something that I would consider truly native if we're having to recreate all the stuff. So this kind of approach is they leave a lot to be desired, either some them or too much or some of them are not enough. What's the kind of sweet spot that Cordova and phone gap are like one step removed from doing pure web development? These compiles and different approaches are at least a step removed from doing pure native development. What's the middle ground where we can get the best of native native abstractions and the best of Web abstractions? Mean, that's capacitor right there, it sells a lot of problems that we saw from both decompiled and approach and the phone get sort of approach. So in a real simplified way to explain it, Capacitor is two parts, a native runtime and then a JavaScript library. It gives you a native shell that you can load up into your project and then it will load a Web app, the Web app that you write and give you access to device features. Exposes US features to a JavaScript library that you can import and install through NPM. Now, this JavaScript library in these APIs are adapted, so that way, if you would point to a website or as a progressive Web app, you're going to get the Web version of that implementation. But if you apply to an IRS device or an Android device, you're going to get the correct implementation for those platforms. And the way it achieves this is by making sure that it can utilize the correct native binaries and native features that each platform provides. So to get certain features added to Io's, we're using things like cocoa pods. And for Android, we're using Android libraries. So nothing here is custom, custom pooling or custom implementations, we're all just making use of things that already exist on these platforms. Now, big ten thousand foot view, we have our app again in this blue square. And that gets loaded by a native Westview for each platform. So this is Web kit or Safari on iOS and then a Chrome Web due for Android. When these when that app is loaded, there is a connection later to a bridge which will handle calls out to the device features and then serialize that back into your Web app, not too dissimilar from, say, a compiler native approach or even from a Cordova approach. What really sets it apart? From all of this is how these so how you get a webapp out of this, so you're bringing in your existing Web apps, your Web technologies, your Web developers, everyone can contribute to this because it's just loading up a glorified Web app. The native runtime is instant, near instant when you create the app, the web is already loaded, it already knows how to communicate back and forth with the bridge. So there's a little to No. DeLay in getting access to that code, if you're running a fast tab and you can load your load and bootstrap your app very quickly, you have access to those native features, kind of offsets the the expectation of is it the approach that is slow or is it? My webapp approach is very fast because it's all done natively. The Web app just needs to be assessed to be able to catch up to that. And then the. It utilizes the best practices from native, so if a new version of Android studio or Xcode comes out and provide some updates and changes, we can take advantage of that and know that it's not going to break our project or cause significant amount of errors because we're following the best practices and following the recommended approaches for building native code. Your apps are going to be able to take advantage of incremental updates as the platform moves forward. So kind of enough yammering, let's kind of look at how we can add capacity to a project. So I have this angular app running right here, I do use them, so you're going to see a lot of them. I apologize in advance, but I can't I can't get used to Scottsville, but we have this app right here. We're all it's doing is loading up different notes, as I've been trying to get better at keeping notes and making sure that I'm writing things down. So I'm going to create a new note. I'm going to call this hello. Uh. Hello, webinar, talk about app go demo. But. And yes, just using a text formatter using this project called Cuil Jass, if you haven't found it, haven't used before. Check it out. It's pretty awesome, but I have to this right here. I'm just going to save it. And hey, I had that showing up in my my list initially. I had my grocery list where I am loading up, say the bread I need to get milk, egg and coffee. I made some changes so I can say that all of this under the hood is using capacitor and so using it's filesystem API. Now, to get this into my project, I ran two commands, first I did and then PM Install and Capacitor Corps at SAAC, I installed the necessary Independence's. Now, this corps just gives you access to a to a standard kind of interfaces that you can get throughout the project, and the Seelie is just a per project Clie that you can use to interact with capacitor altogether. If I wanted to instantiate this project as a fresh new capacity or project, I can just run and. Ampex cap, and then now this will ask me a few different questions like where is my disc target or where is my Web code getting billed to? What do I want to call the package or the project? What's my bundle identifier? Which is pretty important in the development. Basically, tell me a little bit about this project and I'll I'll give you something, if we were to say go back and look at what that creates in this case, we have this capacitor config that's. So this is making use of a typescript based config file so we can have some dynamic values being added here, but we can say if I'm my app ID for the bundle identifier is this dot example dot app. It could be a few things. This really matters for the signing aspect of your apps that way. Each one has its own unique identifier, the app name. So what does the actual app show on your device installed? My web directory or my build location is going to be in this engie note taker. And do I need a bundle the web runtime? No, because I'm using things like Seelie to do my building for me. This is really only useful if you are not using a framework and you're rolling your own solution. From here, we can come into this homepage and inside of the actual homepage component itself. We're making use of angular material here where we're just loading up this common app header, giving it a button to add to our letter and then we're using this material list item iterate over. A collection of notes and to just render out the name of those notes, so the home component for this. Is actually using all of capacitor to load up files from a file system. So we're making use of this package called capacitor file system. It's just another package that we can install into the project and then we get access to stuff like the filesystem API itself, a directory enum, so that we can have some standard and type safe access of different file locations. This Reider results that way. It's just some type and we can type our methods and have some good auto completion. So on a net, we're just going to say, hey, filesystem request access for this. So if I go ahead and I love this up on a platform and I have said no to reading, reading or writing files before, it'll still prompt, you say sure. And we can we please just write a file. We're going to read into this one sandbox location and we please request permission. We'll handle that for you and just give you the. Other handlers say, yep, you can request permission and get access to that, and then once that's done, we can just say, all right, and the file system now and then file system is long promise of we're going to make a directory. No up from all the success and failures. Once that make directory has succeeded, we will just say read all the files in that directory. And then once we've got the files off of the results, we will just set the actual notes to be an ordered version of them where we are basically just organizing them by that final digit, which is just a timestamp. The real details here are the make directory and read directory, which is just returning promises. So all of capacitors, APIs are asynchronous, so we can implement them in a very friendly asynchronous way. This is a promise we could do this as observables as well by just wrapping this with a from above my needs. A promise works pretty well. So I'll read this directory. It'll be a path called notes in the directories document. So a document based location. And make there will do the same thing, this calling filesystem that makes her so pretty clean API and well, what else do we have on here? So we'll go to the file system itself. We have a few different methods that we can use. We could open the file. We can get a file. You or I delete, make a directory, delete a directory, get even the stats on that. So what kind of file does this file exist and what are some of the data or some of the stats on this file? So it's heavily influenced by some on the node file system API. So if you use that before, it should feel pretty familiar. Now, once this is all set up in place. We come over to our note taker or that note page, and we just load up content up so in the edit page. We have all of this being loaded up, we can ignore this module's part, this is just for us to set up the toolbar, but we come into here, we just grab the router ID from the parameters. And if there is a real I.D. on a net, we're just going to read that file, say, filesystem that read file, pass it in the location. Them directory and encoding to return to results from and then once that data has been returned, we're just going to set the content of our editor, our new editor, Cuil Ed instant's to be that data. So this is just using things like engy model to bind the value. So we have a really nice approach to reading file data and setting it somewhere in our app. If I make a change, well, I'm just saying, hey, does this file already exist by reading the real ID? If so, the name of this file is going to be that real ID otherwise generate a note, a new strain where I'm saying no equals eight now and then append the extension to it. So really simple here. From that, I can await writing this file and then once that file has solved, I can just go back. So as we saw here, all right, it's my grocery list. This is. Oh, my. Topping the list I'll save. Go back to it and Coulthart in there. Well, it's even better here is if I want to say delete a file, it actually would be quite simple to do so. What I'm going to do is add that real quick. I'll say async, delete, and I will just say const file equals this, the real ID and then if I'll. I will await filesystem. The delete file. Passing in the path would be my notes directory and then the file name itself, and then the directory is going to be the directories. Documents and you can see the list of locations and where you can store your files, whether it's in cash documents, external external storage, dated directories, all of these, and just kind of provided by the file system. So we will say, all right, delete the file. Await for that results and then when the sun will say this, that go back. Say that, go to the edit page itself and then on our button will just say Aulich equals the. Double check the. While successfully cool Soucy, we'll go to our hello webinar. I'm just going to delete this. See what went wrong real quick. Oh, no. Well, we did say that this is. Well, this is a demo, so we can kind of move on from it, if any of you eagly viewers out there can never see what's wrong with this, please let me know. That would be great. Bring it up in the Q&A. But let's go ahead and not delete. Maybe try that. Oh, that is right. They Chirico, I just hit the wrong button. Thank you so much. I'd say that's embarrassing, but I've done my fair share of embarrassing things as a kid so I can I can take that. Always during webinars, anyway, like if anything could go wrong with your code. It happens when you're presenting it. So this happens to work out that way. It does. Well, with that in place, we have our app running. This is just a Web app, right. And nothing about this. Screams I'm writing a native vet, so let's go ahead and actually add that stuff. So what I'm going to do is actually just come over here to my terminal and I'm just going to do a quick little build passing in the production flag to do a proud, proud build. This is a pretty small app, so it should go pretty quickly, but it'll still give me ample coffee time. So nothing. What we're doing right here is too far out of the expectations from what a web developer should feel comfortable with. We're just building our Web app and letting it just saying, look a little bit to get done, but fairly small app. Lets go in and let's say you apply it to iOS. So I'm going to run QEP, add iOS. So this is going to add a full native Xcode project for me. And it's going to copy the assets from my bill target to the native project. Now, what you can see right here is that they found one capacitor plug in for AOS. Again, this is using. Cocoa pods to manage plugins, so it's going to install the plug in for that and copy it over to our project. Now you get some little feedback here after the update and the ad have run so we can do a tap open iOS. And open up the IOC project here. Now, if you're afraid of Xcode, don't be it's like Apple Music or iTunes just for native development. But note that we have this app folder over here which holds our native project, like can come over to here and load up a swift file, which. It doesn't look too dissimilar from JavaScript, so that should be pretty familiar with and then I get this pods folder which shows me all of the different pods or plug ins that are being used for my project, all managed through native tooling that is found in a native iOS developers toolchain. So my app is ready. I haven't selected to target an iPhone. Well, let's go ahead and hit this run button. All right, I think we oh, hey, there we go. The apples learned when I was decided. I want to learn. Let's go ahead. Will create a new note. I'll just say hello from us. Say that and go back and our notes still. So we have a really good system of learning notes and these are saved to our actual file system on the device. So this is looking pretty good for a new project. And I won't go through the hassle of trying to do Android because if we think iOS was slow right now, Android would be even worse. So let's kind of go to slides again and just kind of wrap up what we did here, so we had an existing Web project and we wanted to add capacity to it. All we could do is just around the style command for the capacitor core library, the capacitor cli and then run Northparkes cap on it. This will give us all of the configuration for a fresh project. And then if we want to add different plug ins or platforms, we install them and run the appropriate TAMMAM for that. If we want to know more about the commands and the different settings that we have available. Well, you can go to Capacitor Jass dot com stocks to learn more about the project itself and the different Seelie initiatives that are available. Also want to point out that we have this new community organization that we've been trying to grow. It is a place for developers to share third party APIs and plug ins under a curated list for things like Sinon with Apple in that purchases Skatalites storage various different APIs that don't necessarily make sense to be part of core. But we want them to be there and we want to have some kind of way to help developers add them to their project and make sure that the code that is being used there won't get stale and is following best practices. Now, capacitor is more than just a side project. It's being used in a lot of good places. Folks like Burger King, BlueCross BlueShield and the BBC are making use the capacitor as well as for smaller startup companies like Circuit and this real small company. I don't know if anyone's ever heard of them. IBM, they're using capacitor as well. So we got a lot of traction so far with companies big and small. So if you're if you're thinking that no one is actually using this, but we have plenty of people out there that are using this. Now, Capacitor recently just hit its big three point of being a release, so everything that I kind of showed you today, the plug ins as a different package, some of the install commands, it's all based on our three point out. And if you go to a capacitor J.S. Dotcom flash plug, you'll get access to the release notes and the blog post going over what drove capacitor three. So before we hit the queue and I kind of want to have some parting thoughts about what it is that we kind of talked about in cross platform in general. For me, cross platform is less about right once run anywhere. But trying to reduce the amount of code that I as a user have to write and maintain. Yes, it was great that I could have had that I could write a file system implementation and access it through JavaScript and that would just work on iOS and it would work on Android. But I don't have to think about what the implementation is doing. I can just know that file system that redirects is going to do the right thing at the right time. And I know that and can be smart about it. We should be able to provide full native access just for JavaScript. There are other approaches to doing some math over the native API and give you full access to it through through through their API and their type system. But to me, that seems like very counterintuitive, because now we don't we don't have a way to run that in environments where. The does episode exist by having this higher level of abstraction around the native APIs and centering it around JavaScript? We can safely type against Web iOS Android desktop, even with things like the electron, we can be a little bit smarter about what APIs we are using under the hood and swap out those implementations that developers even knowing it. Also, it's better to have access to a native project than to not have access to it at all. The fact that I can open that up in Xcode, make modifications to the main app delegate, I'd rather have that than not have any access to it at all or have ways to modify that. So it might seem scary at first. But it's going to be a lot more future proof to have that there and maintain that inversion control than to just say, oh, the the the name of the project, we don't want to do that. So with that, let's kind of open it up to some Q and A. and see what people have been asking. So we got some questions in here. Awesome. Oh, right. So the scale at this and started asking these questions. Yeah, yeah, just work your way through it however you see best. Awesome. Cool. So we have. Our very first question is, if an application if I build an application with an capacitor that uses geolocation camera, do I need to build that using Android studio and Xcode to preview the native functionality, or is there some alternative way without installing an ID? So the actual what's kind of crazy, this was very agnostic, so I has no impact, Ionic is just the UI for capacitor. If you want to make use of the camera and geolocation, we have the geolocation API in the browser and then we also have a third party library, that third party still maintained by us of an optional library called. Elements which will allow you to have access to the camera in some UI to show that just through the Web. So yes and no, you could have access to these features without having to install Android studio and Xcode. But if you want to actually ship that to the App Store, you're eventually going to have to install those. So thank you for that question. The next question, is there any built in plug in for working with clav faster and faster, or do I need to install a standalone one from Firebase? So there's different approaches to this. We provide a firebase, a set of plug ins for things like their analytics, their crash monitoring service, things that you can do that you want some of the fidelity from a native implementation. But if you're just looking to get things like fast store or their real time database or even authentication, the Web implementation should be able to suffice for this. I think the best way to think about it is if the if the implementation depends on some native fidelity, use the plug in, but also know that the. Web version of it is still valid to be a valid solution to use. So is there any built in, plug in or way of working with it? You have the job script library that you can use for third party situations. You could also use their firebase analytics and firebase authentication plug ins from the capacitor community. So, yeah, check out the capacitor community, because there's a set of firebase plug ins there. Just capacitor, it's a good one from the military, does capacitor help in any way to publish your app to the app stores? No, capacitor itself does not necessarily care about how you publish it into the app stores. I will say a little shameless plug. It does offer a service called APLA, which supports capacitor projects, which will allow you to automate that whole entire process and have a publish to the App Store feature so you can check that out. But that itself doesn't necessarily that's not its focus. Let's see what else we can engy serve, work with capacitors so we can develop and test the live reload on a mobile device. I know that if you're using the ionic Seelie, it'll automatically give you a reload on the device. I haven't actually tested with energy on a standalone, so that's a great question. I'd like to know your name, but it says guest. But what you could do is go to our GitHub dot com slash ionic python team slash capacitor. We have a discussion panel on there. You could bring this up and we could discuss it there and figure out if this is something that is already built into the Seelie. And if not, how can we make this possible? Will the capacitor apps work on desktop, for example, the filesystem API and Electron would make sense to use. There are in an electron app and would it make sense to use it there? So the electron right now is in the capacitor community organization. So if you wanted to add that it is still a community based project, which you can totally add and check out, I'm not too involved in it. So I can't say with certainty if the filesystem API there makes use of the native filesystem implementation, but it does have a filesystem API, it should be able to support them. So I would I would suggest, Danny, going to the capacitor community organization on GitHub, looking up the electron repo and opening an issue for that so that we can discuss that a little bit further. A really good one from Sean, everything I've read about capacitor matches on chordoma clay approach, but a environment will require one. Require one. How do you address this? So I didn't really talk about it too much. Here, but there is no way to have a capacitor build and run your project through a Seelie, I would say that these are just tools on top of Xcode and Android studio or the Android SDK is built in Seelie Tools. So for us, it's something I think it's run that you can or Xcode build or X run that you can use to build out your project. And Android studio has its own approach doing that, so we're not necessarily trying to replace all of Cordova's approach. So, for instance, if you were in a GitHub actions kind of approach, any valid action that builds a native iOS project would still apply here. So you would just make make sure that you are picking out, hey, I want to test out my bill for iOS. Run this action for for for the OS platform. And it would work. Eric has a question, does it combined well, with an ex dev tools, her motto refroze, Yes, though I will admit that at this point it's still there's still some work involved to make sure that the experience is as positive as it could be. There is a community project called Annetts Extend that has capacitator plug in for Anex that can work in that situation. I haven't tried it myself. I know that one of the maintainers of it works on it. So I can always ask ask them to figure out if there's anything that people should be aware of. So reach out to me on Twitter handles are there on the screen. Hopefully I'll get an answer for you on that. All right, can I control what is being compiled to mobile versus Web? For example, if I have pages I only want on the Web, this is a very good question. I would suggest using, I think, in this less as mobile versus web and thinking. Thinking of it more in terms of. Environments like you would for your environment files or configurations, so you have energy, build an energy build prod. This is the same effect, the same way that you're doing things there. So if you have pages that you want to include for your native project but are only included in the Web project, you're essentially just creating a new environment in your angular Jason and then providing those files to your router set up. So that could be one way of doing that. That would be fairly typical to an angular developers experience. Bartosz, is it possible to create an Io's capacitor up on Windows? We have no Xcode here. Is it possible with the help of outflow? Yes, you could use airflow here to handle compiling your Iooss binary, as far as I know. Still to this day, Apple does not ship an SDK. That is, that you can run on a Windows device because. Apple being Apple, it's their it's their platform, they control it, but you could use Apple in this case to compile the app yourself. Lance capacity to have a plug in for GPS and tracking GPS in the background, I don't know about background tracking for GPS off the top of my head, I would check out the capacitor community or there could be one in there. I would also want to point out that background geolocation services are still a very what's the best way to say it if the subject, especially on iOS, they tend to. Only allow that for very, very specific use cases, so if you want that, you're going to have to plead your case on why why your deserves that future privacy matters, right? We don't want to be tracked in the background. Eric, you have a question from Eric, is there something like this Apple TV with Angular off the top of my head? I do not know. In theory, angular renderer is pretty abstract. So you could create your own custom renderer for that. But it's a bit beyond the scope for capacitor and what it tries to do. Are there any plug ins available for barcode scanning, built in, not used and built, not using the camera? If I'm understanding understanding this, I think it's like a hardware attachment, if you could just clarify in the Q&A that be great. I'm going to assume that, yes. So hardware. At the moment, I think we're talking with some some of the people who create hardware scanners as an option for that, so I don't have all the answers at the moment. But we are aware that this is something people want and we're talking to people who who actually manufacture those. So hopefully we'll have something to talk about there in the future. Another question from yes, without using a framework where the Anarkali can we use APLA and this live update feature with angularity and capacitator alone? Yes. So all these features. Of Aflalo are ionis agnostic, even though we're still very much tied to them. So if you have just an England capacitor app and you would like to use airflow in the lab deploy of features, it's totally possible to do that without having to change anything. Apple should have some documentation about this, more or less. It's just like committing to version control. And you just set the target to deploy to airflow and then the capacitor apple, read the updates and apply those to your app. So nothing specific to Ionic. Is there any work for square payments, not 100 percent sure what you mean there is there support for Square? For for for things like square payments, I'm going to assume the hardware potentially like the little card reader that you can attach, not top of my head that I know of, but we can always reach out and talk to them and see what they have for an SDK. To answer that one, I have a legacy solution that I use to build a stronger build. I need to install the cap in various parts of the code or any of my migration process for a smooth transition. Apolo cool. Yeah, there is a transition process if you go to. If you go to offload dot com, you should be or I think it's use offload that I'll figure it out on a framework that you should see a drop down for. We have that inside of our docks to show you how to migrate from some get build to outflow and cover all the details. And if you run into any issues, there's a little support feature in that float to send a ticket to our support team. They should be able to help you out. Is there any specific points that I should be aware of if I want to integrate a Web G.L. library with Capacitor again? No, you shouldn't really. WGL is a Web standard. You're basically just rendering to a canvas on the DOM and capacity is all about the DOM and being able to use your standard issue and webapp approaches. So there shouldn't be anything you should be aware of. It should just work. Are there any helpful tools in creating assets for your app? I see the icons and splash screen. Yes, we have a tool, unfortunately named DeCordova says you can sell it. AMPM that npm install Daftari Cordova hyphen Rev's. It is the of code go. Deliveries, yeah, send that to you. It's unfortunately named, but it does have the ability to generate the assets and then copy them over. So if you have, like a standard icon file, then the splash screen kind of template, it'll generate all that for you. And there is, I think, a dash, no coffee or no config flag that you can use to for capacitor projects. And then anonymous attendees, does a capacitor does capacitor have plug ins to convert the web of storage? I mean, I'm assuming you mean if you have a Web app and you want to access those features from the native app? If not, if that's the case? No, we actually don't, because the Web app and then the native are siloed differently inside of the operating system. So features that would exist or data that would have been stored in a way that you can't necessarily access them from the main. So that unfortunately would not be possible. And that's a limitation on just the native platforms. That's the limitation on Cordova. So thanks for that question. That's cool. All right, I think that's all the questions. So thank you all for the Q&A. Hopefully, again, if you have any questions that you can think of later, ask them to reach out on Twitter and Hardington. I'm pretty, pretty active on there, but thank you all for attending. Apologize for the audio issues going on there. But.