Kelley: Hello everyone. Welcome to today’s webcast. My name is Kelley Ricker. I work with developer relations for Xuni, which is our mobile product. I’m joined by my colleague Ross Dederer who is also in developer relations and works for Wijmo.
Ross: Hello everyone.
Kelley: Today we’re going to be talking about mobile app development, and specifically we’re going to be focusing on hybrid web solutions vs. pure native solutions. So, just as a general outline for what we’re going to be going over today – first we’re going to start with a snapshot of where mobile development’s at right now, right at this moment in time.
We’re going to give brief overviews of Native and Hybrid app development; layout and define what each of those styles of development are; Ross is going to give an intro to Cordova and Ionic; we’ll give some reasons for going with Hybrid app development vs. reasons for going with Native app development – sort of a side-by-side comparison there; we’re going to do a real-world demo – just sort of show off some features that may be more appealing that may drive you towards one or the other; and then we’ll wrap this up with a conclusion, trying to define which might be best for you and a little bit of product information.
So, I’m going to hand things over to Ross, to kind of give us a snapshot of where mobile development is at right now.
So, we have our mobile websites, and then, of course, we have our Native applications. Now, the Native applications are what Kelley’s going to be focusing on when I hand it back over to him. And, he’s going to talk to you guys about the iOS apps, the Android apps, you know, written in these native programming languages, developed in native environments, using native IDEs, and, you know, writing it three different times for each of the devices. And I’m going to focus on what I call Hybrid apps.
When I think of a Hybrid app, I’m thinking of something that is a mix of web and sort of the Native approach. And we’ll clarify this a little bit later on in the discussion. But, what’s truly going to enable us to take these web languages and create Native app-like experiences is going to be Ionic Cordova. So, I’ll spend a few slides talking about Ionic Cordova, as well. Before we jump too deep into what I mean by Hybrid web apps, I wanted just to kind of get everyone up to speed on where web application development is today.
So, today, if you’re developing in the World Wide Web, you might be developing what I call desktop websites. And, when I think of a desktop website, I’m thinking of a website that, you know, is going to look really nice on a high resolution screen, maybe a high Dpi screen or something like this. The desktop website is going to be, like, highly feature-rich, so it’s not going to be a watered-down version of anything. We’re going to basically give our users as much user interaction as possible on the screen. And, as you can see in the graphic on the right, this is kind of a simple example, but you can see how we sort of scale our site down as we get to a smaller screen size. And these, basically, head us in the direction of these mobile websites.
Traditionally, when you went to a website, if you were on a desktop computer, something on the server would realize that and give you the traditional desktop view. And if you were coming, maybe trying to access the website from a phone, maybe you were served up maybe a completely different view. You know, same domain, just a different sub domain. I don’t know if you guys remember, but google used to do this with m.google and google.com. So, you have a single domain, but you might have some sort of logic to control the layout, whether that’s on the server-side, or maybe you’re developing some sort of responsive web application where, you know, you’re doing it on the client side.
When we talk about Hybrid web apps, I’m going to be focusing mostly on mobile websites. It’s worth noting that you actually can run, like, what I call your desktop websites through Ionic Cordova. You’re still going to get, you know, a native app, it’s just not going to behave and be very cumbersome for the user to use because it’s a desktop view. So, today we’re just going to be focusing on, you know, your mobile version of your website, running that through Ionic Cordova.
So, you might be thinking, you know, I have a great desktop website for large displays, and my web application’s responsive, I’m happy, you know, it behaves nicely on web devices, but, you know, why are these web apps not enough? Really the answer here is that, you know, our end users, they still need to open up a web browser on their device and navigate through the site. When I mention this, I mean that users need to open up Safari or Chrome or FireFox, you know, go to Google or Bing or any of those search engines, find you website that way, or maybe they’re linked to your website from another site or something like that. But, at the end of the day, users still need to open up the web browser.
Since we’re, you know, accessing the web app through the browser, we’re not really, we don’t have visibility to any of the app stores. So if your web app looks really great on iOS, if people go to the app store and search for your app, they’re not actually going to find it in the app store. They’re going to actually have to go to Chrome or something like this to find your site.
Naturally, since you’re running it inside the browser, you’re bound to the limitations of that particular browser. So, certain browsers do expose certain device APIs to you as a web developer. I can think right off the top of my head, Safari on iOS does expose certain geolocation features to you as a web developer. Now, you can’t guarantee, though, that your users on a iOS device are going to be using Safari. Some of your users may have downloaded and installed Google Chrome on your iOS device. In this case, your API that you have and your website is not going to work with Google Chrome. So, you’re kind of bound, so there are some browsers that do kind of expose some of this native API stuff. Now, you’re really not, it’s really not something that you’re going to be able to program and guarantee that everyone is going to be able to use it.
Naturally, you’ll need to support every different browser for each different mobile OS, so we could be talking about Opera, and Chrome…even when we mention Chrome, we’re talking about supporting Chrome on Android, Windows Phone, and iOS, so even just the one browser, you have to support three different ways. And, ultimately, you know, your users don’t really feel like they’re using an app. They really feel like they’re just using a well-designed website.
And, on the other side, we’ll have our Native app development, which Kelley will talk about at great depth, as well. And this is more the Java, Objective-C, C# style of development. And, you’re actually targeting specific platforms in each project.
So, what do I mean when I actually say Hybrid App Development? Well, these are actually web applications, these can be web applications that we already have built, or maybe this is a web application that we’re planning on building. But, these are web apps that execute within native wrappers. So, an iOS native wrapper, an Android native wrapper, and a Windows Phone native wrapper. And what these wrappers provide is actually going to provide these device specific APIs to us.
For example, we can access things like the camera roll or the camera or something like this…the file system. And really, at the heart of this is Cordova. Cordova really is the thing that’s going to allow us to create these hybrid web applications. So when I think of hybrid web application, what I’m really thinking of, what I’m trying to accomplish here is I’m trying to blend my mobile site and combine a lot of those native app experiences that you’ve grown accustomed to, or, you know, what feels natural when you’re using an iOS or an Android device.
Another big benefit, and another thing with hybrid web apps, you can actually use all of the existing responsive web frameworks out there to control the feel of the app. In addition to that, you know, you can use all the existing, you know, web frameworks, you know, you don’t have to really handle responsiveness. You can use Backbone or Ember, which I’ll get to a little later. And truly, what we’re, the goal here is to have the same code base, you know, sharing our business logic across our desktop and mobile applications. So, I’m actually going to hand it back over to Kelley at this point, now that I’ve explained what I mean when I refer to hybrid apps. I’m going to let Kelley introduce what we mean by sort of native app development.
Kelley: I’m just going to take a moment here just to define native app development a little more strictly. So, when I’m talking about native app development, I’m talking about apps, projects, that are specifically targeting iOS, Android, or Windows Phone. Generally, these types of apps are designed around single screens with some kind of navigation that you’ll hook up between them, that lets you move between these different screens. On iOS that’s gonna be a storyboard where you’re going to navigate to different view controllers. On Android you would do navigation between different activities or different fragments, and so forth. UI can be built in a visual designer, so this could be GUI-based design, you could be expressing your graphic design in a markup language, uh, so this could be storyboards like on iOS or Xibs. It could also be XML in Android, or it could be XAML on Windows Phone. And you can always generate your user interface in code-behind, as well.
Each platform has its own code base. On iOS, that would be Objective-C or Swift. On Android, that would be Java, and on Windows Phone, we’d be talking about C#. All very distinct and all very separate. Beyond that, you’re developing each type of application with its own IDE, that’s made available by the platform vendor. On iOS, that’s just Xcode, but on Android there’s actually multiple options there; it could be Eclipse, it could be Android Studio. And on Windows Phone it would just be Visual Studio. So, with that, I’m actually going to turn this back over to Ross to cover hybrid app development a little bit more. This is a complicated topic that involves a few different technologies that a lot of people aren’t familiar with, so I think it would, uh, be best for him to spend a little bit more time for him to cover this stuff for us. So, Ross.
Ross: Alright, thanks Kelley. So, when I think of hybrid app development, what I really think of is really the best of both worlds. So, the idea here is what if we could develop something that has one single code base for our website, right? And still develop a mobile app for our end users without having to duplicate any of that business logic. So what I really mean here is, on the left in the blue square, this is our already existing web app. We’ve tested it, our users like it, you can connect into the database, everything works fine. And really where we want to be is in the yellow box. We want to have visibility on the Google Play and the App store. So, how do we kind of bring these two things together? Well, we can employ Cordova and Ionic to create native apps that we can actually put on the app stores and have visibility on them.
But, you’re probably asking yourself at this point where Ionic comes into the picture. So what Ionic is going to do is Ionic is going to customize the look and feel and the interactions of each platform, if you will. So, if I just run my app through Cordova, it’s gonna look and feel the same across Android, iOS, and Windows Phone. Cordova’s not going to give us any device-specific kind of look and feel. Ionic is going to provide that. And I’ll demo this a little bit in the demos section as well.
Of course, Ionic is not enough. Well, I’d kind of mentioned briefly that Cordova is just going to give us the native wrapper. It provides some access to device features. But what it’s really lacking is the interactions, the look, and the feel. And the reason for this is because Cordova is simply just the engine, if you will. You’re gonna have to still write your custom UI CSS, to match your platform-specific look and feel.
So, what I mean by that is if you run your app through Cordova, you’re gonna have to write an Android CSS file, an iOS CSS file, and finally a Windows CSS file. Once you do that, if you want to have, you know, specific views for perhaps a phone versus a tablet, then you’ll have to, you know, write CSS files for phone and tablet for each platform. So really, what Cordova’s doing is honestly just stripping the browser window out, just giving you that full-screen browser viewport. So, the catch here is how to we actually accomplish this deed: the native look and feel. Well, this is actually where Ionic is going to come into play.
And the main advantage here, and as you’ll see when Kelley starts talking about native app development, is that with native app development, you’re gonna have to write that same business logic three times. So that’s one of the big advantages here. As I…I kind of said this in the beginning, but this is going to allow you the ability to create an app that you can actually publish you know, under your company’s name, in the App Store. That way when people open up the App Store or the Google Play Store, they’re actually going to be able to find you in ways that maybe they weren’t able to find you before.
Of course, probably the largest advantage of going hybrid is that it’s going to allow you to prototype things very, very quickly. So, here you can see on the left, in my Chrome, I wrote one view here, and then just using Cordova, I was able to see what that was gonna look like in my iOS simulator and my Android simulator. So, it allows my to kind of prototype things out very quickly, and here I already have something that I can demo to people or at a show or something like this.
So, if, you know, your application requires some device-specific thing, you’re going to really need to learn how to do that on your own, write that code on your own – that Java code or that Objective-C code on your own – or you’re going to have to hire somebody. Someone through freelance, or some sort of consultant. So, you know, there might be a higher cost involved there, if you need to do the device-specific. There’s a lot of plug-ins out there available for you to use. Unfortunately, as these specific OSs are updating, you know an iOS 9, iOS 10, iOS 11 comes out, you know, the plug-ins are going to be changing, so, definitely check those out occasionally.
I put here that documentation can be lacking. This is kind of a generic point, but really what I mean here is that, documentation for everything on the web isn’t always as good as what you’re going to find in Apple’s docs, or in Google’s docs. And, even then, not all…the documentation isn’t always integrated into your IDE. Kelley’s going to show you some really cool things that some of these…for example Xcode offers you as far as documentation, that really can save you a lot of time. That’s why I put that documentation can be lacking. So, at this point, I hope you kind of understand what we’re kind of referring to with hybrid and see the advantages of it. I’m going to hand it over to Kelley here, who’s kind of going to introduce native app development, and then he’ll take us into the demos as well.
Kelley: Thanks Ross. So, I’m going to talk a little bit about native app development – some of the advantages, some of the shortfalls – like Ross just did for hybrid app development. I…some of these things are very broad, categorical statements that I can make about all types of native app development. I’m kinda going to focus in more on iOS, just because there are very specific platform things that will vary by, you know, each device. So, I’ll try to call out when I’m saying something broad that applies to everything, and when I’m just focusing on iOS.
So, with that, the first advantage would be performance. And this is one of those broad platforms that’s going to be true across all native platforms. You’re going to have a high ceiling for performance when it comes to a native app. It’s really going to be based on how good your code is, but the best performance that you can possible wring out of it is going to be in native code. You’re going to get the natural look and feel of that device very cleanly. You’re going to have access to all the controls that the vendor typically provides you for, you know, doing layout, for adding elements like buttons and labels and things of that nature. So, you know, categorically, performance is going to be better with native app development.
You can also easily provide appropriate interfaces depending on device. So, if you want to do a different interface for an iPhone versus an iPad, it’s quite easy to do natively. If you’re doing a hybrid solution, this is a little more difficult. In native iOS code, for example, if I want to check to see if my application is running on an iPad, I can just check the device idiom. If I am running on an iPad, I can use one completely separate view controller versus what I would display on an iPhone. I can also do things like change values around for padding, for positioning, all of that kind of stuff is very easy to do natively.
So, the next big over-arching category would be development and debugging. So, I’m going to talk a lot about the native IDEs here. I’m going to be mostly focused on Xcode, but I’ll try to give some call outs to the other platforms as well. So, utilizing the native IDE and development tools, this will give you things like built-in Git support on Xcode. It’s really easy to add other kinds of source control to the other IDEs out there, say, Android Studio Eclipse. It’s easy to hook this up with GitHub, or TFS if you want, and this is just something that you get out-of-the-box, you don’t have to search a lot for this, it’s just in the IDE. Another big feature, the documentation. So, Apple, Google, Microsoft – they all have really excellent documentation. It’s often integrated directly into the IDE, so you don’t have to go out to the web to hunt for this stuff. You can just highlight a certain object type, get more information about it, get a link to the website. It’s very convenient.
It’s also easier to debug your code using the native IDEs. If you want to do things like set break points to step into code, step over things, do some kind of error checking for your parsing, do profiling, all of this stuff is built in to the native IDEs. It’s really easy to access in Xcode. I’ll show it a little bit here. This is something that if you were trying to do this in a hybrid solution, you really wouldn’t have this kind of direct access to it. With hybrid, you’d be creating an Xcode project, if you’re doing iOS, and you could run that Xcode project, and yeah, you could look at memory usage and CPU usage, and you can profile, but it really doesn’t tell you much of anything. It just kind of tells you that your web view is using a little of the CPU or a lot of the CPU, using a little bit of memory, or a lot of memory. So, it’s much better on the native side, directly. Also, the code’s compiled versus interpreted.
It’s also only $99 a year for an iOS developer account, and that gives you access to the developer portal, you’ll be able to publish apps to the App Store, get information regarding usage for the controls, a lot of extra stuff you get out of that. If you’re talking about doing, say, Android development, I believe it’s $25 for a lifetime developer account, which gives you much the same benefits, and Microsoft has a similar, I think $99 a year plan on their side. Now, if you’re doing hybrid development, you would eventually need to pay this kind of money, but you would reap less benefits from it. You would have less relevant material for you. It would mostly just be important to you as a matter of publishing your app to the App Store.
So, there’s some significant shortfalls to native iOS development, as well. Probably the biggest, or at least one of the biggest, issues is this requires very specific developer skills. So, you need to know not only the language of the platform, but have some familiarity with the IDE, um, some idea of how design works. It’s likely gonna be different skill sets between different platforms. You know, an iOS developer, an Android developer, and a Windows developer likely don’t have a whole lot of overlap, at least directly. Now, they might be able to learn some of the skills that the other developers have, but, you know, out-of-the-box you’re likely talking about three different people for each platform. I just kind of alluded to this, but you’re going to be targeting one market at a time here, as well. Because each platform has such specific skills, um, you know, you’re really only going to be able to focus on one at a time. Uh, this is something that’s specific to iOS, but you actually have competing languages on the iOS platform right now.
So, I posted a code snippet of Objective-C versus Swift, so Objective-C on the left and Swift on the right, and you’ll see they’re actually quite a bit different. Objective-C is the more historic language of choice for the Mac platform in general, and Swift is very new. Swift is just from the past couple of years. Objective-C, you’ll notice…you’ll notice a bunch of things that might look a little strange. You’ll see this alloc, you’ll see the bracket syntax, you’ll see a star in front of image, for a pointer, which I’m sure a lot of people aren’t thrilled to see. It’s generally a much more esoteric and also a little historic, the way it looks. We’ll probably give people bad flashbacks to straight up C. Whereas Swift, Swift looks a lot more modern. You know, creating an object doesn’t require this weird allocation and initialization. Method calls look a lot more normal, there aren’t brackets everywhere.
So, the real issue with this right now is that both of these two things kind of coexist at the moment. Objective-C, since it’s been the historic language, a lot of people who have existing iOS applications, this is what their applications are written in. Now, people who are just getting into the market trying to write iOS applications, they’re probably going to be writing, or wanting to write, in Swift. So, right now Apple hasn’t really set up any kind of migration path from Objective-C to Swift. You can bring Swift into a project that’s written in Objective-C, and it’ll create a bridging pattern and everything will work, but you know, ultimately, you kind of want to know when and exactly how everything’s going to move to Swift. Because that’s really where Apple wants everybody to go, and I think that’s new people in the market want to go. So, there’s certainly some confusion there.
And this is, this is huge. Native development, it definitely has the highest development cost. Because developers require really specific skills, because you can only really focus on one market at a time, it’s…it’s gonna cost a lot to develop these apps. So with that, I’m going to go into a brief real-world sample here, uh, it’s basically a sample explorer application that I wrote. Just, kind of highlight some of the points that I made about the advantages of native iOS development.
So, this is my Xcode project here, uh, I’m gonna run this. Run this on my simulator here. So, you’ll see here, these samples are broken into the same broad categories as the advantages that I highlighted in the slides. Things like performance and device features, debugging. So, let’s get started with performance here.
You’ll see here that there’s a grid that’s got a lot of row details. It’s basically a lot of stocks and things. You’ll notice there’s a few other elements here: there’s a UI text field up at the top, there’s a UI label here. So these are native iOS controls, these aren’t some kind of styled controls. These are exactly what Apple provides you. So, you know, I can easily do things like, well, I can do things like highlight and sum, I can do things like filter if I want. And the scrolling’s very nice and fast and responsive. It behaves, you know, exactly like you would expect an iOS application to behave. And, that’s all something that I’m getting for free, here.
The next sample I’m gonna go into here, it’s similar. It’s a, this employee data sample – another grid. You’ll see here it’s got some images embedded in it. There’s a UI button up at the top that allows me to group things. By department, if I’d like. I can ungroup them again. The important things that I’d like to highlight here. These images that are embedded, this is all done natively behind the scenes with a UI image – another Apple control. I have access to everything behind the scenes in code. These are all separate objects that I can manipulate, if I want. If I want to do some kind of editing here, of the grid, if I double-click, it’ll pull up a picker here – a UI picker – down at the bottom. Another one of Apple’s native controls. I can very easily choose between the different departments. If I do the same thing for hire date, I get a UI date picker. I can go in and I can change the date here. And so forth. This is all the native controls. So, let’s move on to some device features here.
So, I’m gonna open up this dashboard sample next. The important takeaway here is that this actually will have…this sample will have different view controllers depending on what device it is. So, the view control is everything that you see on the screen here. That’s the single screen slide. I’ve set it in the code-behind to actually check if this is running on an iPhone or an iPad. So, you’ll see here that we actually have things stacked neatly one on top of the other, single gauge at the bottom, chart and pie chart right above it. So, let me go ahead and stop this and run this on an iPad simulator, just so I can show what the other interface looks like. In fact, you’ll see the whole sample has a slightly different interface, here.
So, I will open up the dashboard sample, and you’ll notice the sample explorer itself is totally different. It’s taken on sort of a Master-detail kind of appearance. On the left here we have a sample list, and on the right we have the separate view controllers for each sample. You’ll notice the sales dashboard itself, it’s got a completely different interface, here. The chart’s much larger, and the pie chart is on the right now instead of stacked underneath. And rather than one gauge, we actually have three. So, this is really quite a bit different, and in terms of setting this in code, it’s really quite simple. If I go into my Master View controller here, you’ll see, basically I’m just checking this device idiom. So, I’m checking to see if it’s on an iPad. If it is, I’m doing the sales dashboard tablet, which is this view controller versus this other view controller for the phone. So, let me go back to the sample here.
The next that I would like to do is this Xuni weather sample. So, this is parsing some JSON behind the scenes to not only populate this chart, but also populate the grid underneath. So, parsing is one of those things that’s always a little bit of a pain, you know, something that can be something that certainly requires some debugging. So, if I want to do something like set a break point to debug my code, that’s actually quite easy. So, let me go into the Model here, in this sample. I’m gonna go into the Weather Data Model, and I will set a break point here after it’s populated, this dictionary with all of the data…all of the weather data for the chart and for the grid. So, I re-ran the sample, um, I’m hitting this break point, and, you’ll see right here, underneath, I already have access to all the different objects that are in scope at this particular moment. If I go down in to the forecast list, I can actually go to individual indices here, and I can actually see the Key Value pairs in that dictionary.
So, if I’m getting some kind of bad data back, it’s very easy for me to just debug it, straight here in Xcode. Whereas, in a hybrid solution, you really couldn’t do that. You’d be kind of stuck going back into, say, Chrome or Safari and using developer tools there to debug your code.
So, finally, I’m gonna run one last sample here. It’s this On Demand sample, it’s loading, but this is another grid with a lot of rows of data. What’s kind of unique about the On Demand sample, is as you scroll down into this list, as you reach the bottom of the list, it will actually reach out and go out and grab more rows to populate the bottom. So, it’s not gonna load all the data at once, it’s gonna load data as you know, approach the bottom of what data has already been loaded into the grid. What I can do in the View Controller for this, is I can actually set another break point right at the moment where it’s going to pull in more data into the grid. So, as I scroll down through this, I’ll eventually hit this break point. So, I can basically capture what’s going on at this moment. And really, what I’m interested in is what’s going on in terms of CPU usage, uh, which I can profile further if I’m interested in it, and how much memory is being used, too, I want to make sure that this is something that I’m loading an appropriate number of…of rows, that it’s not going to potentially crash the device because I’m using too much memory. You know, I can also profile disk and network in here too, if I want. There’s a lot of information available to me directly in that IDE.
A couple other very small things that I’d like to cover before I turn this back over to Ross. So you’ll see here, this is in Xcode. What I’d like to do is define, say, NSString. So, if I highlight NSString, I just wanted to show you the integrated documentation in Xcode. So, highlighting this NSString, which NS is Next Step, because, well, just Apple history. You’ll see on the right here it actually brings up information about the NSString class. I get a little description, I get an overview, I get links to further documentation, if I scroll down I get more information about usage. It’s just quite comprehensive, and it’s all available directly in the IDE. And it links to more specific information. I mean, I even get guides down here at the bottom. And this is all within the IDE.
The other thing you’ll see is that there are these ‘m’s’ next to some of my View Controllers, and that mean ‘Modified’. These are dirty at this point. This is source control…or under Source Control in the local kit. So, if I right-click on it I can go to Source Control. I can commit my changes if I want. It’ll pull up a side-by-side comparison, and I can see what’s changed since the last time I looked at it. And, I can check in my changes. So, that’s…that’s all available directly here in the IDE. So, you know, now that I’ve spent some time kind of introducing you to some of the advantages here, I’d like to turn this back over to Ross and let him wrap up with the hybrid demo.
Ross: Thank you Kelley. Let me go ahead and just open up some of my…we’re working with two monitors here, so I’ve got to drag some windows across. So, I’m gonna kind of walk you through how to get started kinda with Ionic and Cordova, and then show you a demo kinda similar to what Kelley was demoing there. So, for this I’m kind of going to assume that you already have Cordova and Ionic and some of the other tools installed on your machine. If you don’t have these things installed yet, there are guides out there on the web that you can follow. I personally wrote up a guide myself that’s available on our blogs at wijmo.com, if you’re interested in kind of seeing the steps of getting all of this set up. But, once you have this set up, getting started is actually pretty simple. You just type in your terminal ‘Ionic Start’, and then, we want to give it, basically, the name of our application. So, we’ll give it, we’ll call it ‘NewApp1234’, and then I can give it a template.
So, currently, Ionic offers a blank template, which will just go ahead and grab the folder structure for us, or we can go ahead and download the Side Menu template, or we can actually download the Tabs template. So, I’m gonna download the Tabs template. It already exists, so we’ll override it. So, what this is going to do is this is actually going to go out on GitHub, and it’s gonna download some templates, here. Now, since we’re doing this on iOS, it’ll automatically build an iOS application for us. We don’t want any push notifications, here.
So, now that it’s finished up, we want to change our directory and navigate into that folder that we just created. So, we created a NewApp1234 folder, which I’m going to navigate into. And, once we’re inside that directory, we can go ahead and list the contents of the file. And, you’ll see here that we have some bower information, a bulk file, we have platforms, we have an area for some plug-ins, and obviously we have dubdubdub there as well. So, if I actually, if we take a look and see what’s inside Platforms, you’ll see in there that we only have an iOS project folder. This was added whenever we, like I said, whenever we hit start, it just automatically put that in there for us, so that’s very cool.
But, let’s just run this in the browser to see what that actually got us. So, I’m gonna go ahead and type ‘Ionic Serve’. And, what this is going to do is launch a local web serve. So, let’s go ahead and launch that. So, here’s what it looks like launched in Chrome. So, you can see here that we have ‘Chat’, and ‘Account’, and things like that. It’s pretty cool. This is it just running in Chrome, but, as I said, Ionic’s gonna provide us some custom sort of device-specific configurations.
So, let my type ‘Ionic Serve’. Now, here I’m doing to type ‘-L’. And ‘-L’ is a shortcut for ‘–Labs’. And what -Labs or -L is gonna give us is, it’s gonna actually give us a side-by-side comparison in browser of what our application is gonna look like when you actually deploy it on the native devices. So, this is really, really neat if you’re a Windows user. You know, if you’re a Windows user, you don’t have access to Xcode, you don’t have access to the iOS simulator. But, using the Ionic Labs, or the Serve Labs, you can actually, you know, take a look and see what it actually might look like. It might not be exactly what you’ll see on the iPhone, but, you know, it’s pretty close. And, as you can see here, some of the major differences, I…and this is Ionic stepping and doing all of this for us, is that, you know, on Android it’s gonna justify some of our titles more towards the left. It’s gonna move our menu, our nav bar, down towards the bottom on iOS, and towards the top on Android.
And, even if you look at our switches, the behavior of the switch is gonna appear different depending on device. And this is all Ionic just giving this, us this functionality. So, that’s sort of a pre-built sample that I already made. But, let me go ahead and…or that was a sample that the, uh, the Tabs kind of template. I had already made a sample that I wanted to show with you guys.
So, let me go ahead and just open up this in Explorer and I’ll show you what we’re looking at. So, this is our project folder right here. We have our dubdubdubs, our platforms, our projects, our platforms. Now, you’ll see in here we actually have Android and iOS. Under iOS, you’ll see here that I actually have an Xcode project right in here. So, let me go ahead and open that up, and I’ll kind of show you what this application does.
So, let me just go ahead and run this, so you can see what it looks like.
There it is.
So, as you can see, as I update these values, I’m still getting my charts updating. I can change the chart title to 2014, if I like. So, this is, this is pretty neat stuff. Of course, I mentioned how easy it is to prototype. You can see here that running it on Android is very, very simple. Um, of course my Android emulator isn’t as fast, but you can see here – all I’m doing is clicking on this dropdown menu, and you can see that I’m getting these different sort of native kind of, you know, user interactions, and look and feel, and interactivity. With Android, I can update it very easily, as well.
Now, of course, like what Kelley was saying, if, of course, if I wanted to use something that was more dynamic…here’s my dynamic sample. So, this is bringing some data in, and we’re actually…this is a sample that’s tracking trucks, ships, and planes. Since I’m running this from Xcode, what I can do is I can come in here and profile. Now, as what Kelley was saying, you know, this is only sort of a testing tool. I’m not really gonna be able to gather any meaningful information from this, other than the fact that I know that there’s a problem.
So, here you can see that my memory keeps growing, growing, and growing, but over here on my chart surface, obviously I’m recycling data. So, I have a memory leak somewhere. But, I’m not gonna be able to find out where using Xcode where that memory leak is. What I’m gonna have to do is come back to my Chrome, and inspect my element here, and I’m gonna have to do all my debugging…actually this is Safari. But, you know, I can set my break points in here and do my debugging in here, but you know, I can’t actually test it on a device. Even though I can still monitor CPU usage and memory usage, as well as disk usage, and things like this.
We’re really focusing with Wijmo on small, kind of core controls. If you haven’t used Wijmo, I would really encourage you to check it out. Obviously, it’s fairly powerful. And I’m actually gonna at this point, hand it back over to Kelley, who’s gonna kind of talk about some of the controls he used, and then Kelley is going to sum everything up for us, and sort of give us a conclusion. So, Kelley.
Kelley: Thanks, Ross. So, the native controls that I was using for our iOS application, they are our Xuni controls. It’s all native iOS, Android controls. We have Xamarin controls, as well, for all the different Xamarin platforms. One of the big focuses is trying to use the same API across all platforms. We actually share the API with Wijmo, so there’s even some consistency, not just across different native platforms, but going form native, to web, to hybrid. Because we’re mobile controls, we focused first on touch. And, another big focus for us is providing expressive animations for loading, updating, and selecting data. So, animations in general are a big focus point for us.
So, to wrap everything up today: Which solution is best? Well, it turns out that it’s a really nuanced answer. It’s really gonna depend on your needs. I mean, you as a developer, uh, you as a company, you know, you as a team or you as part of a team, I should say. Hybrid – it’s a very low barrier to entry, it’s the least expensive to develop, and it’s the biggest target market and audience, so there’s a lot of upside there.
So, uh, thank you all for attending today. Once again, I’m Kelley Ricker and I was joined by Ross here. I work with Developer Relations for Xuni, which is our native product. Ross works with Developer Relations for Wijmo, which is our web/hybrid solution. If you guys have any questions, feel free to email us. Also, check out our forums, we’ll answer questions there, as well. Be sure to check out our blogs, too. Ross just published a guide to setting up Ionic and Cordova, which will be very helpful if this talk was interesting to you. And I also just published, a sort of high-level overview of native versus hybrid development, as well as other overviews about the different Xamarin platforms and things like that.
We’ll also be sending out a survey at the end of this, which’ll help us…kind of guide us toward future talks that you guys might be interested in. So, if you really liked this, be sure to let us know. If there’s something you think we’re missing here, let us know that, too, because we’d like to talk about that in the future. But, once again, thank you all for attending, and have a good rest of your day.