[ Silence ] >> All right. So welcome back to Computer Science S-76. This is the last time we'll meet in this more formal setting. Recall that next Wednesday is our app party at which point all of your projects will be more than several days done most likely and we'll gather in the lab room and we'll have some cake and some snacks and some chitchat, and the goal will be to bring your app, to bring your laptop as appropriate and actually demonstrate what you did not only for your last project, but maybe your first project or two as well, particularly if you took novel approach to the user interface or generally just want to show off. So tonight, we wrap up our look at iOS, but first, a couple of things. You know that we've had a team of folks behind the scenes here and in front of the camera, namely Chris, and RJ, and Rob. So I just wanted to publicly thank them for all of their efforts thus far. Thank you. [ Applause ] And also to folks you haven't probably met in person, but Shelley and Ramone and Dan who've been running things behind the scenes. So thank you to them as well. [ Applause ] Just in case you would like to relive this summer experience and realize that the videos will remain online at CS76.tv for the next few years most likely, for better or for worse. So, if after the class ends and you're back in school or back at work, you'd like to at least review material or pull up PDFs, or sample code of the like, I know that that will continue to survive on the internet. So feel free to tune in there. So a couple of outstanding details here. So we started the semester looking and talking about web apps versus native apps. Someone want to recap in just a sentence or two what the distinction is and was? [ Pause ] Five weeks later? What's a difference? >> So the web apps are much more portable, you can them across browsers. >> OK. Good. So web apps are much more portable, you can use them across browsers. >> You can get access and also use special tools [inaudible] numbers and-- >> OK. Good. But certain special hardware is typically inaccessible to you. Things like the accelerometer for which browsers like Safari and the like don't necessarily provide an API 2. Good. Other thoughts? >> Native apps run natively on the iOS whereas web apps have to be downloaded via HTTP [inaudible]-- >> OK. So web apps do have to be downloaded via HTTP in the context of the browser before they can actually be run, but you kind of give us a circular definition before. What does it mean for native apps to be native? >> Native apps are a [inaudible] the iOS and so you do not have to retrieve with it some others source. >> OK. Good. So you don't have to retrieve them from other source other than the first time installation from the App Store which is another compelling feature perhaps, most people know how to find apps in the App Store, but most people probably you don't know how to actually bookmark a web page so that it appears to be an application which was a technique we looked at way back early on. So if you had to choose right now for your third and final project which you do, how many folks are leaning toward or already down the road of web apps? OK. So, handful six or so--and the native apps? OK. And most everyone else. So not better at all. So we have a good mix of at least both at that class. So, all right, so that was web apps versus native apps. What if you didn't necessarily have to choose between two [inaudible] contrast? Well, it turns out that there are wrappers and the most popular of which is probably something called PhoneGap which allows you to write web apps that create the illusion of them actually being native apps. And by this, I mean, you go to PhoneGaps website and you download what kinds--what essentially is a starter code that they have written for Objective-C, for Java, for Windows Phone, for a whole bunch of other platforms as well and they've implemented in different ways and each of those languages hooks into the native hardware. And then I have exposed that via JavaScript to WebCode. So in short, you couldn't theory implement an application entirely in HTML5, CSS, and JavaScript, but you can actually ship it to the Apple App Store and the user could download it and it would have an icon, and they would have gotten it for free or 99 cents, whatever the case may be. And when they run it, it's actually native iOS code running on the phone, but the contents of the rectangular window are largely coming from some website externally. In fact, this is how the earliest version of the Facebook application was written. Some of you might recall that it used to be much slower, which is actually a downside of taking that approach. You don't necessarily get the same lack of latency that you might in an iOS native application, but the upside is, one, you don't have to learn Objective-C and iOS. Two, you have access to tools and more familiar environments which for most people is web-based these days. And three, I'm kind of out of reason, so two. So we have two pretty compelling reasons. So how do you go about doing this? Well, technologically, this is actually implemented in kind of a clever way. So first and foremost, this technique using PhoneGap actually gives you access to quite a bit of hardware and contrast to what we proposed was the case a few weeks back. So, all of the green boxes here represent a native hardware that is supported on Android, BlackBerry, iOS, Windows Phone, and so forth, things like the accelerometer, the camera, the compass, and other details that are typically inaccessible to JavaScript. But by downloading this starter code which is native, you're therefore providing a bridge of sorts between native code and JavaScript code. And the means by which they did this in the iOS platform, though it differs on others, is the PhoneGap folks essentially register with their iOS native application URLs of the form gap, colon, slash, slash, and then something and they essentially have an MBC style approach here where you can then specify as part of this URL a class name, and a command, or a method to actually call, and then some number of arguments. So in another words, they kind of made up their own sort of protocol by teaching iOS to handle URLs that appear inside of a browser window via code that they've written. So it turns out there's a protocol called the UIWebViewDelegate. And if you implement this, you can actually be the code that is invoked when an otherwise foreign URL is used in the confines of an embedded web browser. And indeed, that's how PhoneGap works. You write WebCode that you therefore embed inside of a rectangular window that's just an embedded web browser and if you want to talk to the native hardware, you essentially do this by way of the URL bar. So this delegate class allows you to specify what codes should get invoked when the embedded browser window sees a URL that start with gap, colon, slash, slash. And meanwhile, there's also a UIWebView. This is the class. So even if you've not used it before, it allows an iOS code to embed a browser inside of your own native app and it turns out there's a method associated with this class called string by evaluating JavaScript from string which means that your code can be injected into the local browser and then executed by way of this method. So in short, this provides a bridge of sorts between native iOS code and the browser by way of this URL-based trick. And there's one other step to this whereby--or rather in other operating systems, this is done a little bit differently. But I'm sure Apple provided enough in the way of hooking that folks like PhoneGap are able to come along and allow you to implement your next app as really a web app underneath the hood, composed almost entirely of JavaScript with a bit of Objective-C that some other folks have written. So I would consider that perhaps for your next project well beyond courses if that's of interest. Questions? All right. Well, what about provisioning? Sadly, some of you have struggled with this this past week because you may know a hacker or some prosecuted white-hat type person found some vulnerabilities in Apple's developer portal. The result of which is that he was able to compromise supposedly a whole bunch of names and e-mail addresses of all of us who have [inaudible] registered for the iOS developer portal. And to my knowledge, this was the first time that Apple proceeded to take the entire thing offline for, I think, over a week which is wonderfully [inaudible] time for someone likes us. So, apologies to those of you who have struggled with this, but this means now that that thing is starting to comeback online, you can, in fact, provision your device to run software written by you. So if you have an iOS device, iPhone, iPad, or iPod, you can eventually, if not already, go to URL like this, follow the online documentation, and frankly, this is one of the biggest headaches of iOS development. Just getting your damn code onto your own phone, it's not nearly as simple as it is in the Android world or in other platforms because you essentially have to upload a public/private key pair or portion thereof to Apple, so as to register some cryptographic key with them then your code has to be digitally signed in such a way that it's allowed to run on your own phone even if you're doing all these at home with a USB cable and this costs you only 99 dollars a year for this privilege. So, long story short, this is a huge headache, and every time I go, it changes every year but you can kind of muscle through it with the documentation which has gotten better overtime, but the end result is that you can run the software on your own phone. If you want to distribute it to friends, you'll have to go buy a way of the App Store or there are ways over the air that you can distribute apps for testing's sake, and there's also for those of you who work professionally, there's an enterprise level account for 299 dollars a year, or 199 that allows you to share code that you've written other folks on the development team, which makes it a little easier to at least share and test software among each other. So, not a particularly fun process, but there is quite a sense of gratification, I think, once you've got in your own code working on your own phone. So, aspire to that perhaps for next week and realize you don't have to pay any of those fees. Assuming the member center as it's called as back up and running, we can provision your phone for you. You can fill up the form that's linked on the course's website, and in the specification, so that you can then use our academic account at least for the remaining couple of weeks of summer school. All right, so we're fortunate today to be joined by folks who will bring us two different perspectives on how Mobile Software Development can be done. First is Dan Armendariz who's a buddy of mine and also the former instructor of this course back in a day we doubled in both iOS as well as Android development. And Dan has come back from California to join us for an hour's chat this evening about how Android development compares and contrasts with Native iOS developments. We're also fortunate to be joined by a friend of ours from down the street at Microsoft NERD, New English Research & Development. Bob Familiar is joining us tonight to take a look at Windows Phone development and also some of the latest features in Windows 8. So those of you who've been following some of the progression of that operating system, even has a neat beta and demo for us take a look at. So without further ado, allow me to introduce Bob Familiar who will join us for the next hour. Bob. >> Thanks a lot, David. >> Thanks so much. [ Applause ] [ Pause ] >> So, good evening. First, I thank you for the opportunity to be here and to talk to you. As David said, my name is Bob Familiar. I'm the director of technical evangelism for Microsoft here in northeast. Myself and my team, we work with students and professional developers. We teach them how to build apps for Windows Phone, for Windows 8, leveraging our Cloud, Windows Azure, and, you know, we do that through activities that we do online, through our blogs, through engaging in technical forums. But we also run a lot of hands-on workshops on college campuses and other offices across the country. So what I want to talk to you about tonight is modern app development on Windows. So the agenda is, I just want to talk about, you know, what does it mean to develop for Windows. I'm going to dig in a bit. We'll look at some code. We'll talk about building apps that you use open data APIs. So if you've been interested in building apps for iOS or for Android or for Windows, and you're interested, hey, you know, I'd like to do something with that Instagram API, or it's Yelp, or Facebook, Twitter, I'm kind of go over that design pattern. I'm going to show you some examples, we'll dig into it. I, myself, am a C# developer so I'll be using the C# programming language to demonstrate that. But the great news is that the pattern I'm showing you is applicable, you know, really very much in a cross-platform way and you just, you know, there's different ways to implement it whether you're doing JavaScript or you're developing in Java for Android or on the Apple platform. So it just changes in languages syntax at that point. Now, I'll close out and just really ducktail nicely what David is talking about with PhoneGap. I'm going to cover just the cross-platform app and game development landscape. As you go into this space, if this is your, you know, this is your career aspiration, one of the things you really want to understand is what are all the different ways that you can build apps and games or these platforms. And if you're doing it professionally, there may be value in leveraging cross-platform frameworks and tools. So I'll just give you a sense of what they are, what platforms they support, what languages and what skill sets you might need. But, you know, knowing how to do something natively, it's a fantastic skill to have, but also there may be business reasons why a cross-platform framework or tool makes sense. And we'll just go over that briefly. And I'll finish out with pointing you to a whole bunch of resources that we have for you. So when you think about developing for Windows, you know, obviously, we made a significant change in the experience of Windows when a user first used it. They're presented with a Start screen. The apps that used to be on the Start menu are now represented as tiles. And these are, in many cases, live tiles. So the tiles themselves will update with information. It's a touch-first experience. It's very, you know, our goal is it's very immersive and allows a user to really get to what they want to do very quickly. I'll demonstrate some apps for you to show you that. Another key point from a developer's perspective is that we provide new language choice. So you can develop natively on Windows and on Windows Phone in C++, in C#, but also in HTML5 and JavaScript. So that, you know, opening up the platform natively for web developers was, you know, a big shift. And the way we do that, I'll describe what the platform architecture is a little bit. But the bottom line is there's a common runtime. So regardless of what language you use, you have access to the full API set natively. So it's really about it. It's a skill set decision for you. So, let's demonstrate a couple of apps for you so you get a sense of, you know, when you're targeting the Windows platform, how do you really differentiate your app from others. So first off, you know, this is the main Start screen in Windows 8. I'm running a--this is an ASUS ZenBook Prime Touch so it's got a touch screen. I can see all my apps, I can easily scroll through them. With touch, I can pinch zoom, in this way, I can see all the different categories that I've defined. If I want to run an application, let's say I want to go to the Microsoft Store, I simply touch it, or of course, I could click it with the mouse. It's--and one other interesting thing about the platform is everything within Windows is still fully functional with keyboard and mouse. But we've made it also a very, very good touch-first experience. So now, I'm in the store. And if I was interested in purchasing Halo: Spartan Assault, you know, I could go in here and I could check it out, I could see the different screenshots, I could look at reviews, and so on. And I could choose to purchase it which in this case I already have, so it knows that. Now, from an app developer, one of the things I might wan to do is make sure that the tile itself is providing value to the user. So you can have what's called the live tile, and there's a couple examples here. You see some tiles updating with the different images. You can see the store title is telling me that I have an update. So these are things that you, as a developer, can take advantage of. The user could choose to turn that off or turn it on at any time, but it's something that if you are providing say status of your game, you might want hotlist what the recent high score is, or maybe if it's multiplayer game that might want to tell the user it's their turn, you know, it's a chess game. The person you've been playing with has made their move, now, it's their turn to go in and play the game. So you could actually do that without the app actually running. So it's pretty powerful. Another thing that you can do is you can provide different tile sizes. So, on Windows 8, we give you the option of a wide tile or a standard 150x150 tile. It's another way you can differentiate. You don't--the wide tile optional, but it's--you supply that if you want to provide that capability for the user. Now, let's see. [ Pause ] Let's go here. So this is the Allrecipes application. So this just gives you an example of sort of the design language that we are promoting with Windows 8. It starts with it being chromeless. All right, so what that means is you're not seeing any decoration, let's say operating system window decoration here, right? Traditionally, in Windows, if you opened a window like on Windows 7, on the desktop, there would be an edge to the window, there would be Minimize and Open and Close buttons on the upper right-hand corner. There might be a menu across the top. There's a lot of stuff going on in this window. Here, the philosophy is content is--content of the app is the centerpiece. And so, you see very vivid, you know, images being used. The user is guided through this application. They navigate through it with--by the use of topography. So, you know, really nice looking fonts, different sizes mean different things. I'm interested in recipes that deal with bacon, all right, so I know I can just click on that, I can touch that. And now, I'm seeing all the recipes that match that particular category. If I want to go back, I can see in the upper left-hand corner, little bread crumb arrow. I know that I can navigate back to the main screen. So there's a lot more to that design language. We refer to that as modern app design. I think initially when we released it, we referred to it as metro design, but now it's modern app design, and if you going to design.windows.com, there's a great deal of documentation on this design language. It's guidance on how to make a really beautiful application on Windows. Some of the other things this app demonstrates is the integration with the operating system itself. So, I just swiped from the right-hand side. I brought in what's called the Charms Bar. So, this is also a capability as a developer, you have accesse to this platform features from your application. So, for example, Search. If I click on Search, what you'll notice is the Search layout panel comes in. And Allrecipes is selected by default. So, if when I do a search now, I'm going to be searching Allrecipes. But you can see that there are number of other applications that have registered themselves with Windows and are making themselves available for search. But if I was interested in cookies-- [ Pause ] --in All recipes, that search is now being--that search query was just passed to the application and the application then decides how it wants to deal with it. So, any application can tie in to the search capability that's built in to the operating system. Something registers itself as a search target when the user types in terms, so, your application could do that. All right, so you could just tie in that feature. And the same with sharing. So, this says this app can't share, all right? So, this app hasn't implemented this feature. But what you could do in an app that would share is it might say, "I'd like to share whatever information's on the screen," in which case, it might be interesting to see if I go into a particular recipe if it allows me to share. There we go. So now that I'm on a particular recipe, it says--in Allrecipes, user says, "I want to share this recipe." Well, what comes up are all the applications that have registered with Windows that support sharing as a share target. So, Allrecipes doesn't know how to share with Mail, doesn't know how to share with OneNote, or SkyDrive. The operating system knows how to do that. Allrecipe is simply saying, "I want to take this information which is this recipe and share it out." And the user gets to choose where they share it. So, that's another way that you can differentiate your app on the platform, take advantage of search and share. Now, Allrecipes, that's a great example of an HTML5 application. That was built in HTML5 and JavaScript for Windows. An example of a game that's built in HTML5 and JavaScript is Cut the Rope. So, it's a popular game. So, it's on all platforms. It's available in the browser. What this team did is they took their HTML5 and JavaScript code. In about two weeks, they had it running on Windows 8, very early on in the beta timeframe. So, you know, just to give you a sense of, you know, the kind of performance that you can get, I'm going to embarrass myself and try to play this game here so. [ Pause ] Here we go. Two out of three. It's OK. Here we go. That's HTML5 and JavaScript. Pretty performing, that's because you--whether you're building a C++, C#, or HTML5 and JavaScript, there's a common runtime for all those languages. Now, you could actually build and you can get closer to the metal and go C++ native, in which case, you are not leveraging that common language runtime. But, you know, for most cases, for most applications and games, that's actually quite sufficient from a performance perspective. If you're writing something like Halo Spartan, then you're probably, you know, and you're doing 3D modeling and things of that sort, you're going to be right on the metal with C++. Here's an app that's written in C#. This is Cocktail Flow. So, this is just also showing you, you know, that design language I talked about earlier, its guidelines. The--as a developer, you get to decide how you want to implement that particular--you take that guidance and apply it to your app. And here is an example where we've got this really just beautiful immersive application. It looks great on that big screen. And, you know, maybe you're interested in how you make this particular [inaudible]. You can see the nice animations, fantastic imagery. And it's very fast. We used to--when this first came out, you know, we would refer to apps like this as fast, fluid, immersive, and beautiful. That's really at the core of the philosophy of that design language. [ Pause ] This is a game that's built in C#. [ Pause ] I'm not saying that all the power of this but you're the sense of--that this is a--let's go. One more. At last. All right. Very sad. But, the point is you can build apps, you can build games, you know, in your language of choice. Now, we make that possible as I've said earlier because we have this common run time Win RT, Windows Run Time. And on top of that, you have your choice of language, C or C++, C Sharp or Visual Basic, HTML, and JavaScript. There is something called XAML, Extensible Application Markup Language. That--that is the language that you would combine with C or C++ or C Sharp or Visual Basic that does the layout of the UI. So, you can think of it as equivalent to HTML--that HTML with JavaScript, XAML with C Sharp. That's the same relationship there. [ Pause ] So, what I want to show you now is if you're interested in getting started to build an application for Windows, what do you need? When we start with Visual Studio? Visual Studio is the development tool--you're students, so, you have access to Visual Studio at Professional at no cost through our DreamSpark program. So, if you're not signed up at DreamSpark, please do. In fact, in the Applied Sciences and Engineering Department, you actually have your own DreamSpark Premium and you have a web store. So, does this class know all about that? >> They-- >> Plugged [phonetic] into that? >> They don't but they do now. >> They do now? Beautiful. So, I don't know what the URL is to the Harvard Web Store, but if you go there, you can get access to all of our products at no charge. We'll make that available to students. So you're in Visual Studio. You want to get started. Well, I'm going to go ahead and click New Project. And the first thing you'll see is the way that we organize the templates is by language. So, I've got Visual C Sharp here, but there are other languages and I can expand that. I could see--here's JavaScript. So, if I wanted to build an app for the Windows Store in HTML5 and JavaScript, I could start with one of these templates. All right? Let's say grid app. I'm going to say, "OK. I want to get started. I want to build an app that's based on that grid layout that I saw with all the recipes. It was very similar to Cocktail Flow. I want an app that sort of looks like that." It started with that template. So now, it's going to generate that solution. It's going to give you essentially all of the scaffolding for that application. And by default, these templates used--what we call Model View ViewModel. So, it's the variation on Model View controller but the ideas that, you know, Model View that's the user interface layout that's done in XAML or be done in, you know, HTML and CSS. And then, there's the ViewModel, that's the data that you want to bind to your user interface controls. All right. So, that's sounded [phonetic] by, you know, what David had said earlier in the beginning of the class that you're familiar with Model View controller, so, Model View ViewModel. You'll feel very comfortable. Same concept. So here I am. I've generated this HTML5 and JavaScript Windows Store application. I'm going to go ahead and just run it on the local machine. See what I get for free. [ Pause ] Starts up, this is the default splash screen. Here's an area you're going to want to have some focus on, right? Having a great looking splash screen is key. Now the app is running. So by default, you get a template that's laying out some pseudo information in groups. And if I were to click on to a group header, I would see this view just showing me the items within that group or I could click on a specific item and now I'm looking at that specific item. So there's all place holders for the data that is going to light up your application, all right? So, you can see this is--this is certainly not ready for the store but all the scaffolding is in place, the navigation is in place. What you need to now do is come in, apply design, and bring in the data of your application, that's going to be something I'll focus on when I talk about using these open data APIs. But the bottom line is you get a pretty functional starting place for your applications. [ Pause ] As I file, new project again--so that was HTML5 and JavaScript. Now if I go to C-sharp, Windows store, I can see I've got those same templates. I have a blank. I have a grid. I have something called the split app. So let's do grid in C-sharp. I say OK. I'm really going to get essentially it's the same application, but now the language is C-sharp and XML. [ Pause ] If I say go ahead and run this on the local machine again I get this default slash screen. The app is up and running, looks identical. All right. [ Pause ] Now we also support building for the phone. So we're on to that, I'd say OK, I want to do let's say C-sharp for Windows Phone, and now here are all the different templates that I could use for a Windows phone application. So say I want to do a Pivot App. Let's say OK. What platform? Is it the Windows Phone 8 or is it 7.1? I'm going to choose Windows Phone 8. Say OK. [ Pause ] And right there in that Window you can see there's--this is the XAML which is defining the layout. Here is the WYSIWYG editor, so I can see exactly what it looks like. And if I wanted to see, you know, want to dive into the code. I could open up the source file, and dive in. I'm going to go ahead and run this. So what you're seeing here is we're emulating the phone to get, you know, it's actually running as a virtual machine, and it's running the Windows Phone operating system, and but it's fully integrated, so I can actually, you know, test it. There--I can test it with touch. I can test it with the mouse. And there are also some additional things I can do let's say like, you know, Pivot. So if you wanted to make sure that your application will respond to the user, putting the device into landscape mode, to make sure the user interface responded to that, you could test that. [ Pause ] Any question so far? Go ahead. [ Inaudible Remark ] Right. So the question is, if I'm targeting the Windows platform and take advantage of some of the things that differentiate the app on Windows, the Tiles and Search and Share, those things aren't unavailable on the other platforms, you know, how do you plan for that? How do you deal with that? So later in the talk, I'll inform you on all the different ways you can build cross-platform apps and games. And but one of the things that you'll learn is that especially in the area of apps, is the one thing you can't really replicate going from one platform to the other is the user experience, that is the UI. So the first step in your architecture is separation of concerns, that's for model-view-controller comes in, or MVC as--MVVM, I'm sorry, that we promote. The whole idea is separating the UI layout, UI logic, middle tier logic, data access, make sure you've got good separation in your code. So when you go to do something in a cross-platform project, not all your code can go cross platform. Typically, what you have is you try to target the majority of your logic is--that's not user interface-related, that can be cross-platform. You try to choose a language that will get you cross-platform, that's the other thing you have to look at. But typically, you'll do unique UI implementations on every file, because each on has their own controls, their own idiosyncrasies, their own features that you're going to want to leverage. So it's a great question. [ Inaudible Remark ] The short answer was no. The shorter answer is, it's like anything else in, you know, I've been doing this a while. The classic consulting answer, is it depends, that's how you start answering any of those questions, right? And so, you can take as a skill. Put that on your resume. You know how to say it, it depends. It just buys you time as you try to come up with the answer. So if you're ever in the consulting situation, you could start there. Yes? [ Inaudible Remark ] Right. So, you know, both Windows 8 and Windows Phone have support for sensors, for obviously touch and dealing with accelerometers and gyroscopes, cameras, those APIs exist. What's--When you start to get into that part of the API, that's probably where the majority of differences are between developing for Windows 8 and developing for Windows Phone, 'cause when you start to get into hardware-specific areas like that. A large percentage of the capabilities between Windows 8 and Windows Phone are shared, there's a shared core which I believe is actually is a good lead into my next slide. Between Windows 8 and Windows Phone, there's a shared core, probably gets you about 80 percent commonality. But when you get into things that are specific to the hardware, it's just going to be different. You know, how you deal within accelerometers on--in the Windows Phone space work that's dealing with the phones from Nokia, and you know, HTC and other phone manufacturers. And then, you know, on Windows, yes we have a camera, we do, you know, we handle--we have sensor support and so on, a whole another set of hardware vendors. We try to abstract as much as possible, but that's sort of where the differences lie. So again, separation that concerns is key. When you're designing how, at the implementation, you know that's the kind of thing you want to encapsulate a way into a class library. Make sure it's something that's architecturally a little more plug and play. [ Inaudible Remark ] Yes? [ Inaudible Remark ] It's a great, great question. So the question is, if I already have an app for the browser and I'm using, let's say a jQuery and maybe some other JavaScript libraries, can I get that to run on the Windows 8? The answer is yes. So it's their--well, I should have started it. It depends. Well, the answer is yes. It will work. Is it going to be just move your code over and hit run and it goes? No, so what you're going to need to do is first determine any third party JavaScript libraries you're using, do they work on Windows 8? Most do, jQuery as an example, it just works. If you want to use jQuery for doing AJAX calls, no problem. The Microsoft has libraries, JavaScript libraries that you bring in to your project that give you access to the WinRT APIs. So you'll need to add that into your project. You need to decide how do you want to--where it gets interesting is dealing with scaling your UI, so that it, you know, has the look and feel in a Chromeless function on Windows 8, right? So you might have to adjust some of your style sheets and things of that sort. How do you want to integrate with Search and Share, that's calling a specific Windows API? You'll do that through Microsoft JavaScript libraries. But the third party libraries for the most part, we've seen that they just work. So a lot of them already test it. People are already using them. There's probably a lot of documentation on the internet, how that's being used. So, the story there is it's a pretty good story. In fact, a guy in my team by the name of Jesse Freeman who's a really well-known in the Indie Game Development circles, he builds games in HTML5 and JavaScript. And he actually teaches students who want to build games in HTML5 and JavaScript. He teaches them first to build it in the browser and then, the last class, they move it over to Windows, they get it running and they submit it to the store. So, so he's got it down to a science on the gaming side. You're using Canvas or if you're using, let's say, ImpactJS or what's another one? CreateJS is popular for doing HTML5 game development. They just work, so. >> [Inaudible] It's got to be possible to know that, right? It's not just fully innovative view. It's really native. >> It's really native. Where you would want to use PhoneGap which is, again, another great choice if cross platform mobile--if you are HTML5 and JavaScript and you want to make sure you're going to work on all the platforms then PhoneGap is a great choice. If you want to take your existing browser, HTML5 JavaScript browser code and just get it running native on Windows, that's another choice, and you might decide to do that but then use PhoneGap for iOS and Android. So, you--these are all business decisions at some point, right? If you're in a startup, you're in a company and they're trying to make decisions on investing time and money into building mobile applications and which platforms to support, this is exactly the conversations that go on in the design meetings. And so, it's good to kind of think through those things, maybe learn all the different ways to do it as you're doing it in this class and maybe in your own copious spare time. Try out all these different approaches and you'll learn a tremendous amount about what each platform can do, what each, you know, framework or tool like PhoneGap can do. Where is the gap in functionality and so, that's just tremendous value that you bring to whoever, you know, future employer might be. Differentiated apps, by that we mean taking advantage of live tiles, right? On the phone, you can actually have your app be available on the lock screen, also on Windows 8. There's a--the ability to build applications that take advantage of the web camera and do things with the lens, integrated wallet. Of course, if you're a game developer, there's an opportunity to be branded Xbox. All right, so we work with independent game developers, game studios and if--you can always reach out to the Xbox team and say, "Hey, could you take a look at my game." And if they like it, they license it, you get to brand--you get that nice little Xbox green bar across the top of your game. That will push more downloads than anything else. It's that, you know, that little sort of "attaboy" from the Xbox team. So you'll drive a lot of attention to your app if it's tagged with Xbox. So, I'm going to dive back into Visual Studio in a bit. What I want to go over is building apps that use these Open Data APIs. We have discovered that mobile developers who are learning to build for the various mobile devices that are out there, a lot of times, you need some ideas. And Open Data APIs provide you a ton of ideas. Let me just--I don't know if you've ever been out to this site. Let me go to apihub.com. You go to apihub.com and you could search or you could browse by category. You know, they've got over 13,000 Open Data APIs registered here. So if you're looking for data, because the data is really what makes an app interesting, right? And so, if you're interested in building an app for healthcare or education, or you know, you want to use, you know, government data, you want to--you know, you want to integrate maps into your Mashup App, this is the place to go and at least get started finding what you're interested in. So, I want to build an educational application. I want to use REST protocol. I'd like it to return JSON because that's--and there I've got, you know, I've got the Khan Academy has an API. DonorsChoose API, Google Books API, TED API, hey--I'll start--you're starting to get some great ideas. Yeah, I'd like to build a TED app, right? So, maybe I want to mash that up with Bing Maps or Google Maps or something like that, right? You create a really interesting application. The data is what makes it interesting. So, learning how to develop against these Open Data APIs is another very marketable skill. [ Pause ] Once you've identified--where do I [inaudible]. Let's go here to Mashery. Mashery is a partner of ours. They--there was called an API curator. Go ahead and sign in. [ Pause ] They've got over 50 APIs that they helped customers build and host. And one of the ones that I've worked with is Rotten Tomatoes. So I've just logged in. You can see all the different API keys I have. So once you start to work with these Open Data APIs, there's some things you need to know about. them. Many of them require you to get a developer key. It usually doesn't cost anything. You just have to register and then they give you a key. So, for example, if I go to the dynamic documentation here for Rotten Tomatoes, which is movie information, I've logged in so they know what my key is and I've just selected my developer key. And now I can use this API Explorer which is in the browser. It's just a browser app and I can say, "OK, I'm interested in building an app using the "In Theaters Data". Let me go ahead and try it. I want to see how this works. So I try it out and what I see is--zoom in here. You can actually see what the API that they just fired, what it looks like, it's a URL and it's got some parameters on it and it ends with my developer key so they know who's making this call. And-- [ Pause ] --they send you back, you know, what the data would look like which is right here. So again, I'll zoom in so we can see it a little better. This is the data coming back and it's coming back as JSON, JavaScript Object Notation. So, why does it do that? Well, APIs that are on the internet are architected to return very chunky data. Think of this, if you wanted to write an app that went and built a list of movies that someone could go see in a theater, would you want to make a call and say, "OK, give a movie," and that's one call. Now, make another call, give me the second movie. Now, give me the third movie, and you're doing that on the internet and you know how internet connectivity is, you know, only at the very beginning of what the capabilities of that are from an infrastructure perspective. It's not always perfect. It's not always fast. It's not always there. So, chunky data makes a lot more sense. Go get me 16 movies, all right, at a time or 20 movies at a time and not only that, not just the name of the movie, give me the title, the year, the rating. Give me critics' consensus. Give me the release date. Give me a synopsis. Give me movie poster thumbnails. So, it's pulling back a ton of information. Who are all the actors in the film, right? That's chunky data. That way, you can make one API call on this, you know, not very reliable internet connection. Get back a lot of data and now use it in the app. That makes a lot more sense. So, this is the classic, they used to call it chunky versus chatty, right? We want our Open Data APIs to be chunky. Another thing you need to be aware of about these APIs is they are sometimes throttled, which means the folks who are hosting these APIs and they're providing all these data for free, you get a developer key but they might tell you, you can only make two calls per second and no more than 10,000 calls a day. That might be one level of threshold. Another one might be you can make, you know, five calls per second but you're limited to a hundred calls a day. And if you want to do more than a hundred calls a day, you need to pay us, right? So there're those kinds of scenarios as well. So do your research into the APIs you're interested in using, determine if they are bottlenecked in anyway, there's a threshold, a cap. Is there a cost? You know, what do you have to do to get a developer key? But then, once you figured that out, you say, yeah, this is a reasonable API. It's open. It's free. It's not throttled, you know. I can build an app and I can get a thousand people using my app and all calling that API and I shouldn't have, I shouldn't exceed any threshold. That's kind of where you want to be to leverage these APIs. So, I found my API. I'm happy with the threshold limit. Now I want to build an app. [ Pause ] So, the place to start. [ Pause ] When I go ahead and run this application, at least you'll see what it looks like. Then I'm going to come back and we'll walk through it. We'll probably set some breakpoints. So, another thing I'm pointing out here, this is the Windows 8 emulator. So this is another way to run and debug your Windows 8 app so we have a phone emulator, we also have a tablet emulator that's built into the tools. So, you can run the app. I could run this app locally on my machine but I could also test it in this simulator. So again, I can make sure that I could simulate touch and I could change the resolution. That's another nice feature of this. Windows runs on a lot of different devices. You want to make sure that if you're building an app for Windows that it will work on anything from the size of a surface all the way up, you know, to one of these, all right? So, built into the simulator is the ability to change the screen resolution so you could actually see if your layout is working regardless of what monitor the user happens to be using. So, here I am. I just made that API call to Rotten Tomatoes and I got back a bunch of movies which are in theaters and I could select one of those movies and now I can see, you know, before I got a thumbnail of the poster, now, I can actually see this movie poster and I'm getting a synopsis and the rating and the audience score. So I didn't have--I pulled that data all the way back, right? So, it came back. It's in my app. I'm now running--you know, working with this data completely locally on the device. And I can say, now I'm interested in some reviews. Now, I'm going back out to the internet. As soon as I said, I want to, you know, look at some reviews of this movie, what Rotten Tomatoes gave me back was a link to another API that I can invoke to get a list of reviews. And then, for each review, now it's actually a webpage. So I'm trying to connect to the New Yorker right now and hopefully, that will come up in a second. But I can see the list of reviews here on the left hand side then I can actually read the review of the Despicable Me now in the New Yorker, all right? So that's what the app does. [ Pause ] So the way I built this app is I--one of the nice things about Rotten Tomatoes, they actually give you nine different APIs that you can use. The way they design them though is pretty clever. Every API returns the same format of data. So this is an interesting thing. Another interesting thing you'll find when you start to dig into these Open Data APIs, some of them are well designed, some of them are not, or some of them just have--they weren't able to do something maybe based on the data they're returning. That is as clean as this. So each one of these APIs and I've got them documented in my code returns the same structure. It's a list of movies as you saw before in that JSON that I showed you. I've also written a sample app that uses Edmunds which is if you've ever been to Edmunds.com, that's where you can go look up new and used car information, right? So they have a developer API. Their developer API is one of the most complex that I've seen because they have a vehicle API, they have a dealer API, they have a deals API and they have, I believe, a reviews API. And then, so each one of those APIs is actually a collection of calls and each one of their calls returns a different format. So you actually have to study each individual API and determine what the structure of it is to be able to deal with the data. So again, just be aware of that. So, I have defined the APIs for Rotten Tomatoes. I've got them all defined in here so I can actually change this application to not show in theaters information. I could change it to show DVD top rentals. So, how would I do that? [ Pause ] Well, let's see, the best way to understand this is to probably set a few breakpoints. So let's see, we're going to set a breakpoint right there, and right there. So this is the point in code where I'm actually going to invoke the In Theaters API. It's defined as a string. The next thing that happens is we take that and we use an object in the Win RT class library called HttpClient. That's the class that allows me to invoke a URL. So I simply instantiate that and I call the GetStringAsync that makes that API call. We'll set a breakpoint here as well so we can see what comes back. The next thing I do--now remember that comes back as JavaScript object notation. It's going to come back as a string, a giant string that has all that movie information on it. So how do I deal with it in my application? The first step I have to do is just something called deserialization and there's a library that does it for me. It takes that string and it will deserialize it into an object model in memory for me. So, the only extra work I had to do is actually define what that object model is. Well there are tools that do that for you automatically. So you don't have to necessarily write that code. But once that code is generated, you end up with a class that looks something like this. So I've got Rotten Tomatoes movies, has a collection of type movie and a movie is made up of an ID and a title and a year and a rating and a run-time. This is as all that same information you saw in the JSON, right? But now it's represented as a C# class. And so the deserialization process takes the string of JSON and turns it into a run-time object model based on this class structure here. One line of code does that, all right? You simply have to have the class to define and there are tools that generate it for you and it's this line of code right there that actually does the work, all right, so we'll walk through that. Now when a--remember we're using Model View ViewModel, right? But what I get back from Rotten Tomatoes is not a ViewModel, it's a data model. So now that I have all this movie information, it's extremely rich, it's more information than I want to put on the screen and it's not in the format that's bindable to the user interface controls. So I have to map from the data model to a ViewModel and then after that one line of code binds it to the UI. So I have to define my ViewModel. So a ViewModel would look something like this. It's a movie. Well, and this is the reviews, let me scroll down, I'll get to the movie, information will start there. I have a movie item. It's derived from this base class. Now what--why is that? Let me scroll up because I scrolled passed it already. On Windows, what makes a class bindable is that it implements the interface INotifyPropertyChanged. Model View ViewModel means that you put your data in the form of a ViewModel, you bind it to the UI control, it could be a list view, it could be a drop down, a combo box, a grid control, something like that. If the user interacts with it and changes it, you want your ViewModel to be notified that the data has changed. If your program changes the ViewModel, you want the Model View to be notified that the data's changed and update automatically. All of that machinery of keeping the Model View in synch with the View Model, the Model View in sync with the View Model, is handled automatically by the platform, whether your HTML 5 and JavaScript or your C# XAML, C++ that's handled automatically. You simply have to derive from the right, you know, implement the right interface. In this case it's INotifyPropertyChanged. And there's the implementation. So now that that's implemented, I can now derive classes from this base class that are my ViewModel and that's all that that's going on in this particular file right here. So if I come down, where was I? Movie item, all right? So here's my movie item that's bindable and it simply got--it defines the data that I want to be able to put on the screen and then accessors, get and set accessors. That's it, very straight forward code. And I'm being instant message by someone out at corporate. So I'll just ignore that. So let's see, so that's the ViewModel. The last thing I want to show you is, OK, now every thing's in the ViewModel then what happens? Well, when that call returns all the way back up to the--to my user interface layer, I'm going to end up here in the response from the call. I'm going to get the data. I'm going to copy it from the data model to the ViewModel and this is the line of code that binds it to the UI. We take all the movie data and we simply say it's the default ViewModel for this--let me bring up this particular UI layout which is implemented in XAML. [ Pause ] There's the binding definition right there, collection view source. So that's one of the nice features about the platform is a lot of that plumbing, all that capability that you expect these types of applications to have it's build into the framework, the class libraries that we provide in Win RT. You just need to know how to wire it up. When dealing with open data APIs. You're going to make a call, you're going to get back that string of JSON. You're going to deserialize it into a data model. You're going to map the data model to a ViewModel and then simply--and then your binding code will pick up after that and you've got it on the screen. [ Pause ] Now, I wanted to show an app that was built that way, but it's in an HTML 5 and JavaScript. Now, this is not my code, I'm going to do my best to try to at least point out a couple of interesting parts here. Interesting in JavaScript that whole, you know, invoking the API and getting back that string of JSON that doesn't happen in JavaScript, why? It's coming back in JavaScript logic notation. So the nice thing about calling these APIs from JavaScript is you get back an object model by default. In C#, I have to map the string to an object model. So it's one extra step in the implementation. So here's an example of invoking the Meetup API in JavaScript. Let's see if I can find the call. [ Pause ] I'll make sure I'm in the right places and so this is not my code, here we go. Get upcoming meetings. So here's the API call that we want to make in our app, right? It's in--it's just a URL. And we're setting up the parameters and this is the built-in--you could use, obviously, you could use jQuery to do this using Ajax call. But if you're using the Win RT JavaScript libraries you can just use WinJS.xhr. You give it the URL, the response type, and then of course what code follows is the code that is going to deal with the response. So you can see we're just dropping into a foreach loop and then we're just gathering the info--he's just gathering the information about each of the Meetups and he's putting it into the right collections that will be bound to the UI controls is exactly the same pattern that we did in C# and XAML but this is just using HTML 5 controls, CSS, and JavaScript to do the implementation. If I go ahead and run this-- [ Pause ] Here we go, so he's gotten back Meetups near Boston filtered by keyword JavaScript. And if I click on one of this it gives me a nice map and is also going out and he's using, this is a feature of Bing Maps. So he's--he is going to mash up between Meetup and Bing. And so the Bing Map is showing you all of the coffee shops that are near where the Meetup is happening, all right. And so Bing has points of interest API. So once you have the geolocation of the Meetup, Meetup will give you a longitude, latitude for the Meetup, you can use that with Bing to say, give me back a list of points of interest. And so that's the mash up he's doing here. So again, interesting data makes for interesting applications. [ Pause ] And the last thing I'll show you before I go into the last part of the talk here is--that same pattern, same capability is available on Windows phone because I told you I did an implementation for Edmunds, car data. So that's what this application is doing. It's going to go out to Edmunds. It's going to get first a list of makes Acura, Aston Martin, Audi and so on. And if I'm interested in Audis I can click that and I'll get a list of the models, so that came back from Edmunds, and I say, you know, I'm interested in A8. It's then going to show me--hopefully it will go back out to Edmunds and get me the images of an Audi A8 so I can salivate over them. My ultimate goal is to start a transportation business like Jason Statham that's just a dream of mine to be a transporter so anyway. You have to know that movie I guess to get the joke. No problem. So we have the same capability in Windows phone, any questions? Very good. So this is just a visual of that pattern that I talked about. We invoke the API. It's an asynchronous call. That's also important. These calls you make this open data APIs and we fully support an asynchronous model on the phone and on Windows. It's an asynchronous call that means you're--the user is not waiting for that call to return. They can keep using your app, they can go use another app, and then when the call returns, your application will be notified. That's where you'll do the deserialization. If necessary copy to the ViewModel and then bind to the UI. And we did all of that. So now I'm just going to dive into this cross-platform app development landscape discussion. For C# developers, this is one of the best options you have out there for a cross-platform support for iOS, for Android, for Windows is with the tools and the frameworks from Xamarin. They're actually based--they're headquartered here at Harvard Square. The founder of this company is Miguel de Icaza, he many years ago when Microsoft open sourced the .net framework and the C# language and standardized it, he took that and he created that implementation from Linux. And so he's been making his living building cross-platform tools and libraries based on C# and the .net framework for--it's going to be 10 or 12 years now. And the latest incarnation is Xamarin and they provide a cross platform framework for targeting, you know, all the mobile platforms and the nice thing here is--to our discussion earlier, you can get 60, 70 percent code reuse. Their model is, you know, port the business logic, the cloud integration, the database access, that's portable but do your user interface natively for each because there's no substitute for a native UI, there just isn't. This has been something we've been trying to solve and computer science for many years. You can go back to the '80s. There were companies that were trying to spin up cross-platform UI, frameworks, and tools and they began to be called--they were referred to as least common denominator or LCD which meant they were the poorest implementation on every platform they ran on, all right? So that's not where you want to be. You don't want to be least common. You want your app to sing and to just be the most fantastic experience on whatever mobile device that's on. But at the same time, if you want to have the farthest reach, the most opportunity for downloads and for monetization and all of that, you want to be on as many mobile platforms as possible so you need a strategy. It might be native on each platform, that's a strategy. Could be crossed platform with something like Xamarin which means you're going to develop in C# and you can actually do debugging in Visual Studio for Android, and for Apple, and for Windows so it's a great development experience. They've got a great product here. A lot of applications are beginning to take advantage of that, earlier stated, your HTML5 developer, phone gap, fantastic option for a cross platform solution, all right. [ Pause ] If you're a game developer, Unity just released their Windows 8 Windows phone support for Unity. So you can now, you know, take your--we're actually told by Unity that about half the games in the iOS store are built with Unity. So we know there's a lot of Unity developers out there. It's a great tool. It's on the high end but, you know, under the covers it's C #. It's actually using the cross platform implementation of C# that Miguel has it designed years ago. So it's called the Mono Framework. And so you can build games that target all the platforms. There's another framework, this one's very interesting. It's called MonoGame, again same community, you see those kind of a--when the C# world, if you want to go cross platform you're working in what's called Mono. So it's MonoGame or it's the Mono Framework which is used by Unity or it's Zemuron which is using Mono and its implementation. So it's having a lot of impact. MonoGame is a cross platform implementation of Microsoft's XNA Framework. So if you're familiar with building games for Xbox or for Windows or Windows Phone, the framework was called XNA. The cross platform version of that is MonoGame and there are games like ARMED! that are in the Windows 8 store that are built on MonoGame. I'd built one myself and put it in the store, works incredibly well. It's very straightforward way of doing game development and it supports Android and iOS and Xbox and Windows and you name it. [ Pause ] If you're an HTML developer and you're a game developer, you might want to look at something like GameMaker Studio from YoYo Games. This is a cross platform game development tool. It will generate HTML5 and JavaScript and allow you to target all the different mobile platforms. [ Pause ] There's another one like that, that's called Construct 2 from a company called Scirra. We actually use this in all of our game workshops. With students and professionals we use Construct 2. That's because the free version is very, very powerful and you can publish to Windows Phone and to Windows 8 with their free edition. You have to understand that each one of these tools showing you has a cost to it. This one, what's nice about is no cost for targeting Windows at least. If you get into iOS and Android then there maybe a cost to getting that export capability turned on, all right. [ Pause ] Another one's called Gamesolid. You see there's several of these, all very similar. They're all leveraging HTML5 in JavaScript in the code generation. But the act of building the game is drag and drop, that's one of the nice things about these tools. You're not in the code, you're--if you're a game developer you want to focus on the artwork, the assets, the sound, the gameplay, the heads up display, the layers things like that. That's what these tools are good at, they give you an IDE, you lay everything out, you say what the rules are of the game, and then you test it in the browser, and when something doesn't work just right, you don't go change code, you're back into their tool and you're modifying properties of objects, some things with that, so it's all visual. If you are into the code then another choice is create JS. This is a suite of JavaScript libraries that help you build games. There's one example out there that does a complete implementation of which is got to be about 15 or 20 different Atari games. All done in the--they run in the browser, they've also imported to Windows 8 and this is the bit.ly. It's kind of cryptic. I didn't come up with a proper name but it's bit.ly/R--capital R3, lower case v2, capital D capital H. And at least you'll get to the website and you can check out all the apps there that have been built with CreateJS. There's also one of--a member of the team built the Catapult Wars and did it with CreateJS and put that into the Windows 8 store and there's the bit.ly for that if you're interested in reading up on how that was done. [ Pause ] I'll make these slides available too after. Another game development framework is impactJS and a guy--I told you about him earlier, Jesse Freeman who is on my team, he's on New York, he wrote the book called 'HTML5 Game Development. Iit's all about how to build HTML5 games using ImpactJS. He's built--he's just got tons of sample code online, he's got a book, he's quite good and he has a bunch of games in the store right now. His favorite is, you got that he likes that old 8 bit look and feel to the artwork. So he creates a lot of his own artwork and builds these games using HTML5 and JavaScript. And he gets them running in the browser and then he gets them running on Windows and now he's forwarding them to the phone. [ Pause ] So just to close out, so I'm right at time, is I want to make sure you know about DreamSpark. Now if you go to DreamSpark.com, you could register there but it sounds like what you should do is find out the URL or the Harvard DreamSpark site. And if you go in there, you can get Windows, you can get Visual Studio, you can get SQL Server, you can get, you know, everything but an Xbox all right? You can get basically all of our stuff there. So download the development tools, download the SDKs. You also get a free Windows 8 and a free Windows Phone developer account that's a 150 dollar value. All right, so students get account for free. I want to make sure you guys get access to that. App builders are site for developers. If you go there and register build.windowsstore.com, there's--you can earn points, you can register your apps, they can send you on some quests and you'll earn, you know, you'll earn points to be able to win stuff. There's also a ton--a ton of training material up there if you're looking for either apps or games. Some other training I found that might me, you know, really applicable to what you're doing now is there is a C# fundamentals online course set of videos and then there's also Windows Phone 8 for beginners. So if you're just getting into the space, you just want "Hey, I just need to learn some C# and I need to just get started with Windows Phone," those two resources are fantastic. And then the work I was showing you is a project that my team did called APIMASH which is at aka.ms/apimash and that will take you to GitHub. So we post all of our stuff up on GitHub. So we've got a bunch of StarterKits up there. If you scroll down, we have StarterKits for Windows and for Windows phone and we're actually expanding this list. So everything you see here is being ported over the phone. But we've got active access on Chuck Norris StarterKit, Earthquakes and Bing Maps, Edmunds, Facebook, Foursquare, Instagram, Meetup, Messier Sky Objects, Rotten Tomatoes, Stack Exchange, Tumblr, Twitter, Univision, Wikipedia, World of Warcraft, Yelp and ESPN. All of these are all functional Windows 8 apps with the code. And everything I showed you, that's the pattern they're all using. That whole open data API call deserialize bind to the UI. If you're interested in seeing how you get started building for Windows 8 and for Windows phone, these are fantastic resources here all built by my team. So it's all creates up on GitHub. The way to do it is you just go to that site and click the download zip file. So we also include a Lab Workbook, there's three Lab Workbooks in there just to kind of take you through how to get started with this stuff, all right. So I want to make sure you are aware of that and with that thank you very much. [ Applause ] >> Thank you so much Bob. We've been deposted at C76.net, an instructions for how you can get access to a DreamSpark account-- >> Beautiful. >> --so actually you can get that and then we'll post the slides later tonight. >> Fantastic. >> Thank you so much. >> Thank you. >> Why don't we go ahead and take few minute break here while Dan get set up and then we'll transition to the third and final platform for the evening, Android. [ Pause ] All right, we're back so the third act here is Dan Armendariz who actually started this class several years ago. What's the origin of C76 can be traced back to him and a colleague of his and it was--I came along a year or so after that that I finally got involved. So everything you've seen thus far is all traces back to Dan. So, Dan is going to look at Android develop fellows and without further ado, Dan Armendariz. >> Thanks. Hi everyone, it's nice to be back. So, speaking a note in a contact and from where you're sitting it doesn't really seem that way. The cause is very different back then. Just like mobile development has really evolved over the years. In fact in the best years since the last time that I actually co-talked this class with David. Android development has gotten a lot better in at least in the initial set up. So, we're going to talk about as quickly as we can. We're going to try to shoehorn what I use to put four weeks worth of content into 1 hour. So, please allow me simply way as I go a little quickly through some things. Of course if you have any questions, you can interrupt it anytime and hopefully we'll be able to get you guys comfortable in such a way that you'll be able to do some Android development soon as you go home. So, just that I can sort of get a sense of where everybody is. How many of you used an iOS device as your say primary phone in iPhone? That's just about everybody. Now, is--are there any of you that using Android device as your primary phone? OK. So, for those of you that have your hands up, is that constant, do you always use that device rather than an iOS device? All right, so, for those of you that had your hands up, you probably are familiar with the differences between the experience of an android device and an iOS device. And this is actually really important is that. In order to develop on one of these platforms, it really is useful to have a sense of what that platform is actually liked to be able to use it. And so, if you are serious about actually doing cross platform work just to reiterate comments that the [inaudible] the first hour, it's really helpful to get a sense of that experience at how you actually want to replicate that on this other device. And even though Android is considered to be the primary competitor to iOS, it's really difficult to put them I think on that same sort of comparison, they operate in very different ways, they have very different reasonings behind very different decision that went into their implementation. And there's a lot of maybe let's see, what is the proper word to use here. There's perhaps a lot of difference between the two that's in a large confusion between the two that really just arise from this sort of basic differences, this basic differences that arose initially from when Google was first started developing the Android and when Apple first started developing iPhone and iOS. So, this is actually pretty important for us as well as developers. So, for us as developers, what are some of the differences that we typically hear about the--about developing for iOS versus developing for Android? If you were to go out unto a tech blog and read the comments that people always post whenever Apple or whenever Google updates one of their hardware devices. People always complain about the same sorts of things, right? What are these differences? What do Android users dislike about iPhones and what do iPhone users dislike about Android, any ideas? Yes. >> [Inaudible] you know just like how as a [inaudible], you have much limited perspective on iOS rather than Android before functionality that [inaudible]. >> So, perhaps if I could summarize that in a way to say that people consider Android to be a little bit more open than iOS. And so, that is certainly true in many respective in for us as developers when you'd create the developer account with Google, you pay a one time 25 dollar fee, you have an account with them basically that 25 dollar fee is to weed out to people that just want to create, you know, flood the store with spam. It's not a terribly high fee but it is one fee that you have to do. But then after that, you're free to submit your applications to the store, there's no review process and you basically create your application, you publish it to the store and then that's it, it's up and ready for people to download. That's just one sense that Google might be a little bit more open than Apple but there's others other ways as well, you have a little bit more control over your phone, some people would argue a little bit more customization whereas in iOS they tried to really funnel you towards a certain types of experience which in itself I'm trimming not in the sense this is a negative but in fact that is a very--again, a very different way of thinking about this. Google allows you to have a lot more options, and so it can to people who are mot familiar with the system appear to be a little bit more complex. And so, again, this is just that same sort of idea that we want to point out the differences between the two, you have a question or a difference? >> [Inaudible] are the open source in any way? >> So, for the longest time Android was open source but they have in fact to close source to some of them. So, a lot of the code is in fact open source but I think a lot some of that now more basic functions are in fact closed source from Google. Yeah, that was also a primary difference between Apple and Android again, part we could perhaps include this within this openness aspect. What about other things, anything else as developers that might be different? Yes. >> iOS [inaudible] might say that Androids were fragmented [inaudible]? >> Right. So, there's--this is definitely a big one that we hear a lot is that this fragmentation in Android devices. And in fact this is a very important point that I want to bring up right a way, is that's there is some truth to this in what is actually fragmented. There are many different types of hardware devices available for with the Google operating system with the Android operating system from different manufactures where as Apple only is the only manufacture of iPhone and iPad. There are many different manufacturers that use Android as a platform. And even within that context, many people don't update their software as much as we as developers might want them to. And there's a variety of reasons for this. Some of them may not be aware that there is an update. Some of them--but I think one of the more pressing problems is that with many of the third party phones that come out that have Android on them, they have a lot of stuff to it. Sort of like when you buy a PC and has a lot of stuff installed and my friend just bought an Asus and he said they would have like a--on my gosh, I wish I could remember exactly what it was but it was like an Asus internet connection help wizard or some sort of very specific thing that he was kind of surprised that they actually bother this one, [inaudible] company actually bother to create the software report and it's sort of a similar thing. A lot of these companies will in fact add their own additional UI components on top of the Android base OS which further adds to perhaps some of the confusion between different users when you pick up an android device from say Samsung versus one that's Google create with just the base Android. OS it might actually look different even though it has the same version of the OS because of these additional little flares, you know, the additional pieces of software that they will actually add on to this. Now, I don't want to confuse the issue with all that stuff aside, one of the base issues in this fragmentation argument is the bit--just the wide range of versions that were installed on hardware devices right now. So, this is a chart that Google actually created. They released a similar chart every half month or every month or so, showing the distribution of devices that connect to the Google play store which is the equivalence of the App store on iOS. And as we can see here, there's really no one slice of this pie that makes up the majority of the devices. It really runs the gamut from ginger bread right here which is a version two of Android OS which is now several years old all the way up to jelly bean which is one of the later versions, version 4.1 and 4.2 and now there's an even newer version 4.3 but I'm not sure that any devices have been released to actually have that through that. It's actually been released at this point. Now, sort of the saving grace here with this is that if you did want to target a lot of this users, you can actually create of course an application that is targeted at one of this APIs, one of this earlier APIs and be able to get a large portion of the market. And by the market I mean the available market for your application. Of course if you wanted to use some API that's only available in some later version of the OS, then you will perhaps limit yourself in terms of the market that is available for that. But the Android OS isn't the only reason why this system might be considered fragmented. We also have things such as the screen size and the density. Like I s aid the actual hardware devices are very, very different. And this is just--I intentionally left out some of the explanation of some of this but just to show you that this is really all over the place. That screen size on the left and screen density on the right and Google goes through on the web site on differentiating all of this and sorts of the exact pixel dimensions and the exact number of dots per inch in each of the densities here. But really we can see that we have a problem and that is that if you want to create an application for an Android device that should work on a multitude of devices. You do have to contend with this issue that there are many different types of devices running many different types of OS's that have very different hardware capabilities. Now, to Google's credit, they have done everything that they can to try to combat this issue. They really try hard to make it possible for you to create an application that can run on a lot of this sorts of devices. And in fact, one of the ways that they are able to do this is is through this inclusion of resources within an application. So, there is an--we're going to get a little bit technical at this moment before we kind of come back a little bit wider and talk about what exactly--how exactly this works. Oh, and looks like a font is missing here. So basically, application resources are stored in a resource folder, so it says RES. And there's a variety of different folders, it's a hierarchy of folders, and within that, there's a variety of other directories that you can include like a drawable directory which will include bitmap graphics or XML graphics. And there's also a layout so that you can actually add layout information in XML form or you can also add many definitions in a menu directory as well. And what's really neat about this set of directories is that not only can you localize strings, but also you can modify the name of the directory itself to [inaudible] OS of what sort of resources are included in there. So, let's say that you create a game for instance. And in that game, you have perhaps a variety of assets, a variety of graphics that you created for different devices. Perhaps you've created some--well, it's something low resolution graphics for the lower DPI--the lower DPI devices or perhaps you created some really high risk resolution graphics for the larger screens or for the devices that have very, very high DPI available. And what you can do is very much in the style of a CSS selector, which you might remember from your token web developments, can you actually add some properties to these folders which are again not intentionally masked here but you--we'll hope we see them when you download the PDF when it is posted on the website. But you can actually add CSS style selectors or--I don't actually don't want to say that. There are selectors in style of sort of CSS in the way that you can have these different selectors to target specific hardware devices or specific OS versions within each of these folders. So, it becomes a little bit better. You don't have to release different versions of the same application, but you do as you can imagine how to create different versions of these assets for these different devices. And even though there's the arguments, well, iOS is now fragmented between the iPad, the iPad mini, and the iPhone and the older versions which did not have the retina displays. And all of these different things is really not quite as bad as we have here on Android, this is an attempt on Google's part to make it a little bit better. Now, these resources are in fact included within the file that's called an APK file. An APK file is in fact your Android application. And what's neat about this APK files that you can actually download an APK file on to your computer, you can rename APK to .ZIP, unzip it and see what the contents of that application actually is. It's kind of an interesting thing, you can actually see the resources that are available there, anything that is not been compiled that becomes very easy to look at. You can't look at the original source code of course because it's been compiled and then included within that ZIP file and package into this Android format but you can in fact look at some of the resources that are available within that one file. So, this is important to realize that we have this APK file which is in fact this application that we want to ultimately create. Within an application, we have these resources. Again there's--you can create resources that are generic so that it would apply to all hardware devices or you could even make them very specific by having multiple drawable directories for different resolutions or for different density screens. And you can create different strings directories for localization, international localization and so on. But really, the heart of all of the Android applications comes from this one XML file called Android Manifest file. The Android Manifest file basically tells the system, the Android system when it is launching your application, what it should expect, what is the name of this application, what is the minimum version of the OS that I can run this application, what are the different screens called activities that might be available, what are the permissions that this app requires, does it require phone access, does it require access to my contacts, does it require GPS access, all of those sorts of things. So, the OS parses this information and will make a determination, the OS will actually decide whether or not it can install and run this application based on the limits that you set in this XML file and also the limits of the device. So, perhaps the user rejects your permissions because you want to do all sorts of things on the user's device, you have--your permissions are too lose and they decided that's actually not quite a good thing to do. Well, you can modify all of this information here in your own application towards that end. Now, one of the things that is really important to realize about this as well is that you'll notice that here, we're--we define variety of things, but within this application, we actually have some components. Now, in this simplified version of the XML file, we have a single component called an activity. And this--when we start to talk about activities, this is where really starts deviate from the way that we would expect it to work if we only are familiar with iOS devices. In Android, it's really difficult for us to talk about an application as a single all enclosed app that runs entirely with your code. It is possible for instance, if I am creating a--let's say that I want to create an application that perhaps uploads some photos from your phone up into--up to the web. Perhaps I have a photo sharing services some [inaudible] and I want to be able to take your photos from your phone, user selected of course, upload them and share them on the web. So, perhaps we would create this application to actually pull the user's photos which everyone they select from their photos app and then upload those on behalf of the user to the internet. What's interesting about this is that we can actually have a very simple UI that presents the user with a couple of options saying, OK, we'll what, log in first and tells what album you want to add these photos to. But when the user actually goes to select the photo, we could in fact launch an activity from an entirely different application, perhaps the photo application, and have the user select one of those photos in that other application. Is this relatively transparent? What the user sees is that they open up your app, there's a couple of options, you have to have to log in or do whatever then they click a little Choose Photo button and it appears seamless to them and that there's another window that appears on top of that UI that they are previously interacting with. So, it appears as though it's one application, but now all of a sudden, it's a photo selector probably different application all together. Now, this sounds kind of convoluted but there's a great power to this and that we can generalize them, we can have this--this become very generalized if you wanted to include, say drop box support in your application. You could actually make sure that the drop box application was installed and asked drop box to run the log in activity and have the drop box application deal entirely with the authentication mechanism or perhaps you want to have your users be able to select one contact out of their contact list rather than fetching all the contact information and displaying it to them, you can in fact ask the contact application itself to show the contact list and have the user select one of those context. So, we have to differentiate between this idea of an application which is what we would create and would be always self-contained and what the user would actually run. When the user actually runs this application, it becomes a slightly different turn that Google likes to use called the task. And the reason that is called a task [inaudible] applications because this task could actually run multiple applications [inaudible] to the user. Again, in the same context whereby they start your application and in this application, we want the user to be able to select a photo. So now, we have our application running and they see this one activity. By the way, an activity is just a screen interface to the user that the user have actually interact with one screen is essentially one activity. So, we have our own activity here. Now, our application request from the photos app, the photo selector. And so now, another activity comes over then masks the one that we had below but, we have two applications running. So, this is the difference between the task in an application. Application is what we are creating and is something that we are--that we are eventually going to run. But you have to realize that activities are not necessarily so specific to your application that it's only run by your application, depending on the properties that you apply to this activity it's possible for you to create an activity that someone else's application could then run. So, again the example here would be say, a contacts application or let's say that I am creating the new social media platform or what have you and I actually want the user to be able to select one of their contacts from the Android device and rather than create a contact list on my own I can just request from the contacts app to show that contact selector, that contact list and have it return the data to my application. So, this is just a difference in terminology, a difference in implementation, already this provides quite a lot of, a lot of power and a lot of openness. Notice that in--I never said that--well, maybe I did say but I didn't mean to say that there is the contacts app, there is one built in contacts app that you always have to use. Due to this sort of open nature of Android it's possible to create a competing contacts app place it on the Google Play store and that's--and then your users could then interface with that contacts app, with that new contact app instead. So, rather than when my application request a contact from the contact list, rather than go to necessarily the default application it could provide the user with the choice. Well, I see you how multiple contacts apps installed on your device how or rather which application do you want to use to select this contact? Perhaps another example would be let's say that you just have a--an activity that's very simple which has URL on it, you click on that URL, you don't want to--you don't want to implement an entire web browser yourself, and so you figure OK, well now I can just launch a web browser activity from another program to show that webpage to the user, you can imagine this--you can envision the scenario where there's multiple browsers installed on this computer or a computer yes, but also on this device, there's multiple browsers installed and perhaps Chrome, perhaps Opera, maybe some others as well and you could provide the user and by you I mean this happens automatically the--by the user clicking on that URL and you requesting from the Google operating system from the Android operating system that you want to open a URL it might realize, oh hey, there's two programs, there's two applications that actually support this type of data, which one do you want to use? Do you want to use Chrome or do you want to use Opera? This can then select one of those two options and proceed to show that that information, that webpage or that webpage in whatever browser they choose and again it appears to be relatively seamless, it doesn't look its swaps applications to this other--to this other web browser it instead just loads an activity in front of the one that you are using. So, there's a variety of--there's a variety of components that can be part of your application, the activity is sort of the simplest one in the sense that it--this is that UI that the user is going to interface with and what we are going to see in some code examples in little while or just various forms of activities, but there's also different types of components that exist in an Android device as well. So, these activities, single screen with the user interface if you want have multiple screens you certainly can but that means that you're going to have multiple activities, that's not that big of a deal it's just sort of an interesting thing to note. Another type of component that you could have is a service which would be just the background task for long running operations, let's say that you want to upload some information to your web server, let's say let's go back to that earlier example of having this photo sharing website and I want to have the user selective photo and be able to upload it to my website, if it's a big photo we can run a service that uploads it in the background while the user does other things, we don't have to be bother with it. Another example of a service might be music player, you might have an activity that actually is the interface to that music player with play, pause, stop, volume, control, forward, backward, so on, and so forth but the actual playing of the music occurs in the service which occurs in the background which allow you to change tasks, again this word tasks which would allow you to change task so they could go their web browser and continue listening to music from your same player. Now, there's a couple of other things that that could a little bit more specific but just listed in the interest of completeness the content provider is a way, it's just of a standard interface for applications to access your data. So, if I actually wanted to pull some data from a common application like contacts or photos this is separate from the idea of actually bringing up activities, but maybe there is some interface that I actually want to expose to allow other applications to access the data that my application will actually create, content provider is the way do that, broadcast receivers response to system-wide announcements. So, the tone will actually broadcast to all of the applications that the screen has gone, the screen has gone dim or that the battery is running low, or that the white Wi-Fi has been turned on of off, or a variety of other things and even applications themselves can send broadcast to the entire system as a whole and you can define which if any of these that you're interested in actually respond to them which is kind of an interesting thing, allows certainly a bit of power in what your application can do. Now, activity is meant to--because it's user facing it's going to be given a lot of priority by the Android OS whenever is actually being run. So, this would get a fair amount of CPU time as, you know, Android OS has been--has allowed background applications and background task to be run for quite a while now and one of their solutions was to prioritize what the user is actually interfacing with. Services, they'd also tend to be prioritized relatively compared to some other things but not quite as much as the user facing activity if they're running out of RAM for example perhaps it will free up some services that were running stale or running that the user wasn't actually using. Content providers and broadcast receivers these are smaller things, but they're meant to be very lightweight, they're meant to be--this is something that's happening as a result of this system call, so let's get it done quickly and be done with it. Are there any questions on this so far? I realized this a little abstract, mostly in attempts to point out some of the differences between the way that iOS would work compared to how Android actually function. Oops, so how then do we actually create one of these applications? Well, the short answer is that you go to developer.android.com and this actually for you as an Android developers you're home based, there's an enormous amount of information here, the API documentation, there's a lot of updates whenever new versions come out, there's a lot--I mean there's just a wealth of information that's fantastic, you can also download the SDK from this website. You'll notice if you go to the website though that there's two versions of the SDK, there's software development kit, the SDK and the native development kit, the NDK. The native development kit is a bit lower level, it allows you to write high performance applications in C or C++ and basically embed them within an Android application. We're going to essentially ignore the NDK, but if you are interested in high performance native applications because you need to create a game for example of very graphics intensive game then you might pay more attention to the NDK, but for the vast majority of us we don't really care about that, it's nice that it's there but we're not going to quite use it, the software development kit is the way to go. So, there's a couple of things to note about the SDK, first when we create an Android application we're actually writing code in Java, the end result isn't the Java program and I'll explain more about that in just a moment, but the code that we write is actually in Java. We use and we can use if we want, again as part of this openness, that slightly more open idea we could use a variety of different development environments, the one that's recommended in that would actually include with the SDK if you download it as a clips, you could just use plain text files if you wanted you can kind of do it however you want but you'll notice that using a clips tends to be the fastest and the best option for us. So, what then--how then--what is the process for us to build an Android application? I mentioned that we have to write the code in Java and there is a few important things that are--that distinguish this from Java and I'll point those out when we actually look at a hello world example, then we have to compile this into some Java bite code just as we would a regular Java program, but Android itself doesn't actually run Java code. In fact the Android platform is a modified version of Linux that runs something called the Dalvik Virtual Machine. So, whereas in Java, it actually runs a Java Virtual Machine to run and execute the Java bytecode that has been compiled by the Java compiler. Google has created a slightly different version of this virtual machine that is a little bit more--well, it pays more attention to things like memory usage and CPU time and is a little bit more fair with regard to all of those things because in this mobile environment we have to be very careful about battery usage and the amount of time that we spent in each of these applications. So this bytecode is converted to a Dalvik compatible executable which is basically just the modified version, again, of this bytecode. It is running in essence Java bytecode but it's been converted, some things have actually been changed to be compatible with this Dalvik VM. So, it's derived from Java but it's not exactly the same. But this process allows us to write the code in Java and then creates and compiles it into an application that's actually run and understood by this Dalvik VM within the Android Platform. Now after that we have to package it up in a special way using Zip in a tool called AAPT which actually includes some of the--well actually pre-compiles some of the information that we have including the Android manifest file and variety of other things and actually creates an Android package. So, you might remember that--I said before that this has gotten a bit easier. Well, it's always been a little bit easier than is, as if you are kind of the hard--the hardcore hacker person that loves to do everything manually, you can certainly do this. But for the rest of us you can just download the SDK which includes Eclipse, the IDE, and also the Android tools plug-in, the ATT plug-in and allows you basically just to go straight from the code directly to the end result, the Android package. You can find all of these on developer.Android.com and one of the ways that it is much easier now is that they actually package all of these up into one download, that means so much easier. Before it was really a pain. You just download Eclipse and then you had to download the SDK and you had to download the Eclipse plug-in and you get all to work together but luckily we don't have to do that anymore. It comes in just one nice package, makes it very easy for us to do development. So, again, if you're actually interested in this, go to the website developer.Android.com/sdk/index. Download the SDK and that's it, you pretty much can get started with it right away. So from here, how do we actually create an application? Well, of course, the HelloWorldApp is the--well, the simplest thing that we can do to actually create an application. And there's a couple of things that I want to point out about the code in this HelloWorldApp and I'm going to switch here to this other screen because it has better text color and it makes it a little bit easier to take a look at what's going on. So, the very top of this Java file, we basically have a couple of things, one is package information. How many of you have developed for Java in the past or at all? Pretty much everybody, OK. So for those of you that haven't, it's very similar in syntax to C or C++, but of course there's a variety of differences. It's going to be very heavily object-oriented. I'll try to point out as many differences as I can. But I don't really want to do a Java primer right now. There's--If you do a search for Java tutorials you will find some very excellent tutorials by Oracle that talked a little bit more about this. But we have to put all of this code into the scope of a package, into a particular name space, and so that's what we are doing in this first line. Then we're going to import a variety of libraries that actually make it possible for us to run this code--the activity library which we just talked about and couple of other things we're sure actually required for us to run this, the bundle is required by the OS. This log one--is it really required unless we're doing logging which there's some very basic logging at the very bottom of this of code which will occur in just a second and also a widget. You can maybe guess by the name what this actually does but it's essentially this, it allows you to place a text object on the activity and allow you to view some text on that, on the screen. So, that's just all sorts of some initial setup that we have to do and this is the contents of the code. Now one thing that you'll notice for those of you that are Java developers that's very different from other things is that there's no main method. There is no method that makes it very obvious where we're actually starting the application and the reason for that is that the main method is done by the operating system itself. What the OS does is it looks at the manifest file that we've actually created. And so this is a full-pledged Android manifest file that has been not reducted for simplicity. So we can actually see how some of these things work. Again, notice that this is the manifest XML element, uses a minimum SDK version of 3 which is now ancient. There's no need for you to use version 3, just like Android 1.5 or something. So, only if you want maximum compatibility do you really need to do that. But even then there's problems using minimum SDK version of 3. It implies certain permissions that are not necessarily what you would want. I think it wants full access to contacts and some other stuff that if you just upgrade the minimum SDK version to 4 or 5, then you lose a lot of these problems that actually existed. But this is meant for maximum compatibility here. Now, the application within the 3 actually defined where the icon is for that app on the home screen of the device. It's within--You'll notice at Drupal [phonetic]. Remember I mentioned that Drupal directory within our resources. We can have various resolutions of our icons to support the different density and different size of the screens that might exist. Similarly, can we actually apply a label to the name of that application within the string resource and provide--you'll notice that here we're looking for specific resource within the string directory called an app name which--you'll just have to--you'll just have to trust me for now that says something in English. Now, if we skip this and go down to activity, notice that we have defined one activity here. And within it, we have this idea of an intent filter. And what this intent filter actually does is it notifies the OS what's this activity should actually do and there's variety of filters that we can apply to it. Perhaps we want to restrict this activity from being open in other applications. Remember that I mentioned that we can task, we can have other applications request in activity. We can explicitly disallow or allow that with this intent filters but also we apply these to elements to this intent filter telling the OS that this is the main activity and this is the one that I launched on boot. Or on boot is opening the application itself. And so really there's no main method that is because we've hold the Android OS that we have this activity and this is the one that we want to run. Now, the activity itself--excuse me--the activity itself goes through a life cycles of sorts. There're a variety of methods that allow you to run some code when the activity is first been called upon to actually open and then things have been rendered on the screen and then it's finally ready for use by the user. We're going to ignore a lot of those for now and I'll defer to the Android documentation for you to get more information on that. But now we can take a look again at our HelloWorld code and realize how this is actually working. We have a public class Code One. This is just the class for this one activity, extends activity because this is in fact an object of type activity. I actually want to create some code that launches activity and display something to the user. And within that we have this one method on create. This method is invoked by the OS within this activity object whenever this activity is about to be started. Let's say, "OK, I am about to display this activity so I'm going to create it and display it on the screen. What do you want me to do?" It's asking this code, and by asking means invoking this method, which allows our code to actually create the layout and apply a layout on to this activity and then display it to the user. So, the next few lines--this super.uncreate, we just have to make sure that we actually invoked the act--the main activity classes on create method just to do any house cleaning, otherwise you will get a very nasty error from the Android plug-in or from the SDK when you do this. And then programatically we are actually going to create a TextView that says some text. We're going to create a TextView object. It's just basically instantiated in this first highlighted line. Next, we're going to set the text to be displayed by this TextView. And then, we are going to set the content view which is the content displayed within this activity. So, this is not necessarily a mysterious function call. This is actually a function call that's implemented by the Android activity class that allows us to set the layout for this activity. It's basically the layout for this activity will be what? Any guess? This based on this code. [ Pause ] Yeah. [ Inaudible Remark ] That's right. So, all--the only thing that will be on the screen, when we actually run this activity, will just be a TextView. But that TextView itself is invisible. We don't actually see its bounds. We just see the text that's contained within it so we should expect to see the text, oh high. You know, there's some logging capabilities stuff down here which if we have a little bit more time, I would explain is very useful for us to actually get messages from our code back in to this really cool, little section down here, log caps which allows you to actually run. It's sort of a consul-like way of actually being able to look at errors from your activity. In fact, you can see, it says, "This is an error," which [inaudible] or which replicates what we see here is a very good for debugging in the Android world. But if I actually run this code, this is what we would see. So, very much like in Xcode how you have an emulator for iOS, you have an emulator for Android devices as well. So, what's cool about this is that this is actually an emulator, the Android device, since so I can go to the--I can't see the--oh, we've been bitten by the resolution bug. There's some buttons down here that allow me to go to the home screen and we can sort of play around with this version of the Android device. But personally, it's cutoff. So, rest assured, it's there. You can click on it, but not right now. But what this allows us to is our HelloWorld application. We have here our activity which takes up the entirety of the screen. By default, the theme was black. We didn't get to see that, but it's elsewhere actually in--within the package itself. We have our one TextView, this is our text, and that's about it. Up here, this is just a title bar for the application itself. It's a little confusing at first when expect to only see this and you also see the title of the application but realize that that is actually just the Android OS displaying a little title above the application itself. We could give a flag in the manifest that would request that this activity become full screen and hide everything. We haven't set that flag. We've just done a very simple manifest file here. And of course, we have our systemwide status bar at the very top here. Now, there're few other things that I want to show you about this. I'm going to make a few of these activities available in the source code for you to download and actually play around with. We don't really have a lot of time to go through them. But hopefully, if you just go through them on in a time, they'll progress in such a way that you will be able to hopefully start following along as we make slightly more complicated layouts, start adding second activities and start doing other things with the Android OS. But there're a couple of things that I want to point about the SDK itself. One of them is that this IDE again is Eclipse. This is not written by Google but is in fact is a larger open source project. If you already have Eclipse downloaded because you do development in other languages or even in Java, you can actually download the SDK without including the IDE itself. You can just download the SDK to plug-in and follow some steps on the developer website to get all of that working in your own version of Eclipse which you might have already installed. But if you don't have installed already, don't worry about it, you can just download everything and work out of the box. Once you have everything set up though, if you go to this menu, the Window menu, you'll notice that you have a couple of new Android options. And I'll zoom in here so that you can see them. You have Android as the key manager, Android virtual device manager and Android lint which is a checker. But, it's these two that we are worried about now, the SDK manager and the virtual device manager. The SDK manager allows you to download different versions of the SDK. So, if you want to build an application against a specific API number, you have to make sure that you have downloaded that SDK. So, if you download all of this, this is going to take of a lot of space. It's several gigabytes with--of information that has to be downloaded on to your computer. But then you could compile your application against anyone of these API targets and it will work just fine. In this case because I had set the--in the manifest file the minimum SDK version--oops--of 3 as we can see here. Let's make sure that I in fact have that version installed. And as you can see, Android 1.5 which is an API level of 3, so realized that there're two different versions. The public facing version is the string Android 1.5, but the API level is in always incrementing integer which started at one basically that earliest version that was released through consumers was API Level 3 and it just has been going up ever since then. So, here, we can see that I in fact have the SDK platform and the APIs installed. You can do that on your own for whatever version you want to run. But the for more fun one, I would say, is the virtual device manager which allows you to create virtual devices, emulated devices in just about any configuration that you can imagine. So, if we were to create a new device here, what this is going to allow us to do is to create a new emulator of sorts that replicates certain features of a device. So, we can specify a variety of things. We can give it a name. So I'll just say Android 2.4 just for example. Now, we can see here that when I click on device, we have a list of different device sizes. Pick your Poison, it goes all the way from the Nexus 10 which has an enormous 10 inches screen all the way down to some of the earliest Android devices including a 240 by 320 screen. It's pretty small. We can select any of these and actually create emulators that you can actually test your application across the wide variety of devices before you even release it to the Google Play Store. I'm just going to [inaudible] so I connect Nexus 10. I can select the target. So, this is the API, this is--basically, the OS version that this should run that this hardware device should run. Now, it is possible for you to get yourself into trouble here and run an ancient version of a target on a new device that would not ever have that installed. So, you have to sort of be careful here that you select ones that would make sense for that. Sometimes, you get the ability to change the CPU if there's in fact an option between ARM and Intel. Hardware keyboard would be emulating and actual hardware keyboard on this device, hopefully the rest are somewhat self-explanatory. You do--would get to set things like the RAM size, the amounts of heap that your virtual machine would have for this application, the amount of internal storage if that device actually has to emulate an SD card. And notice a couple of options down here, snapshots which if you've used virtualization software elsewhere like VMware or Parallels or any sort of thing, we actually close that virtualized window. It saves the state of the memory and will allow you to restart it from there. Similar thing here with snapshots, you can actually save the state between times that you close and then we open the emulator which is pretty good because sometimes, it takes a while for this emulators to load. And, they now have also hardware accelerated GPU which is great because before was software and it was just--it was jut the worst. It's so slow. OK, so you can create one of these and you can have actually a variety of them. Now, in order for you test your application on an emulated device, you have to first--here's the steps, make sure that you download--oops--make sure that you download the appropriate SDK and SDK manager and then create a virtual device in the virtual device manager. Then you have an emulator that you can actually run. So, in this case, I actually have my Android 2.3.3 running, as you can see right here. So, I'm emulating an Android 2.3.3 device in this emulator. There're a couple more things I want to point out. One of them is that there's this number to the left of the name, 5554. Now, this is pretty cool. What this allows us to do is to log in to the emulated device from our computer. So, in this case, I can open up a terminal Window. Type in "Telnet localhost" and then that port number. That number actually coincides with the port that's running within our computer or within the emulator and is exposed to our computer. When I hit Enter, notice that I connect to this emulator and this is something that you can really only do to the emulated devices. Now, you can type "help" and you actually get a variety of things that you can do. So, you can actually force the emulator to change its state. And there are variety of interesting ways. You can have, for example, it follows a set of GeoTracks or maybe your application is actually really dependent on geolocation. So, you could actually provide it some GeoTracks and observe how your application reacts as the phone is not taken in a physical sense but it's taken in a--in an emulated sense though that geolocation track. You can also do a variety of things like what happens when I changed the network settings on it and say that the user loses cellphone signal and they only have WiFi or vice versa, how does my application actually react to any of this-- to all this sorts of things. You can also send the emulator an SMS, just pretty funny. But it is actually useful especially if you are creating an application that is relevant to that, a variety of other things as you can see here. Now, one of the really neat things here is that if you have an Android device and you are doing Android development, you can plug in that device using USB to your computer and you will be able to develop directly on to that device. You might actually have to check all, check a few a settings in the developer menu that says allow development, mode, and some other things. But what this essentially allows you to do really without having to deal with any certificates or any or anything like that is that you can very quickly and easily connect an Android device to your computer and try your program not only on an emulated virtual device, but also on your physical phone or physical tablet as well. And can you also run, you can also connect to it and run a variety of commands. It's really limited in these physical devices because you don't have root access to the file system unless you have actually rooted the device which is an entirely different issue. But even though that is an option, it's probably better to test this out on an emulated device and see how it behaves on the physical one, but then it certainly an option for you there as well. And one of the great things about the Android SDK very much like the iOS, the iOS development in Xcode is that once you understand these simple principles, once you've understand Java, once you understand how and APK is built and what its hierarchy of files actually looks like, becomes very easy for you to look up the APIs that are given to you in the API documentation and quickly make an application that you would want to run or that you would want to deploy to users. And so, hopefully then, this has been a good summary of how you can actually get started with it. So, if you are interested in this, go ahead and go to the developer website, download the SDK and get started on Android development. And until then, I want to thank you very much. I think David has couple of last words. But that you ought for you time. [ Applause ] >> [Inaudible] Dan and Rob. We [inaudible] like for a couple minutes for one-on-one questions, otherwise, we post it all resources from tonight. The course's website on Wednesday, [inaudible] we're going to dive some more in advance, iOS [inaudible]. In Wednesday, we will gather for one last time for [inaudible] app, so we will see you then. [ Noise ]