 So this is the introduction to Android course. What we're going to be doing is we're going to be building a very simple Android app. It's not going to have any kind of connectivity and nor is it going to air-face with any of the services. It's going to be a very straight forward beginning. But we're going to start off with installing the Android students. How do you actually have Android students going to be able to install it in the machine already? Good. That skips 90% of our steps. Now, did all of you who installed Android students remember to install the Java as well? OK, so we can skip all of that stuff. That's nice. It's very handy. So here's the app that we'll be making. Very simple app, just or coffee. This app has two different activities. One, which you can see out here in the main activity, which is where you can interface with the increment buttons, which will tell you how many copies you're going to order. Three checkboxes, which will determine if you want cream, milk, or sugar, or any combination of the three types of coffee. We're actually here at the time of the live broadcast. And it'll also show the price, but also the next activity you trigger after you hit total will also show you the price. That's in there for a couple of different purposes, because we're also going to show a few different ways you can pass values through to different activities using Android itself. Quick question. How many of you have written Java code before? This is supposed to be in a chart. OK. So I'm assuming most of you know how methods work, and passing values through methods and things like that. So that'll be a small refresher on that in the app, but I'm pretty sure the majority of you will be able to get started. OK. What you saw initially in the first part of these presentations was called a layout. A layout is what somebody sees when you trigger an activity in an Android app. This is how your user interacts with it. So in the case of a layout, it has to be easy to use, easy to understand, and has to be able to handle most of what you want it to initially do right there. As you saw with our simple coffee app, it had every button that you could want to order coffee right there in front of you. Creating it is a little bit more complicated. All Android layouts are in XML, which is this extensible markup language. This is where we can declare all of our different views and where we place them, and what kind of properties each view will have inside the app. Over here on the side, I have a very simple explanation of the basic code of what you need for a text view. Now, a text view, switch over to IDE here. This is a text view. Pretty self-explanatory. A text view simply shows text somewhere on the screen. A text view will simply display text inside of your Android activity, and you can modify it as you see fit. You can have all kinds of parameters, such as size, whether it's full or italicized, where you want it, all kinds of stuff like that. In order to declare something in XML, if you look up at the top here where it says text view, there's a little character to the left. This entire statement, wait a minute. This statement right here is the declaration of what kind of view you're actually making. In the case that we've said several times now, it's a text view. So this is the opening bracket for a text view. Over here is a closing bracket for XML. How many of you have seen HTML, or written some kind of HTML? Same basic concept. Any kind of tag that you open up inside of this needs to be closed at some point, or else the object, or whatever you're trying to close within those brackets will not actually exist. So as we go further into, so as we begin to go into what views are, we need to explain what exactly holds a view and what arranges that property. And these are what are called layouts. There are two major layouts inside of Android, which is a linear layout, a relative layout. These can all be nested within each other to help you build your layout in just the way you want it to be. The layout that we saw before required, when I built it, required, I think if I'm not mistaken, three linear layouts nested within another set of relative layouts. Now, a linear layout is interesting in that when you declare your views in the XML, that's the order that they will appear in a linear layout. Originally, when you declare a linear layout, it'll set everything into a vertical orientation, which means that if I were to declare the text view one, text view two, and text view three, they'll appear one, two, and three on top of each other inside of the activity that I've declared that. As long as that activity is viewable on the screen. In order to change that orientation, we change this parameter here. This is an XML line that lets me change the properties of whatever view or layout I chose. So this Android declaration is actually what SDK you're gonna be using for the XML for this. There are a couple of different versions depending on which version of the Android SDK you install. Our focus today is just very simple. So we're gonna be looking at it from SDK 19 just Android 4.4 and up, because that's a little under what 90% of the devices are using, so most device nowadays will be able to run that. But unless you really have a reason to change that, most of the time, this will actually be filled in for you initially when you declare your layout before your activity. So there's no real reason to change it unless it's absolutely necessary. So this will declare that the SDK that you're using here is part of the current SDK that you're looking for. And this name here where you see layout with height and orientation, these are all the parameters that you change. When you first declare any kind of layout, any kind of text view, any kind of view at all over layout, you have to declare a layout within a height. So in this setup here, I have wrap content. What that means is that any contact, any content that is stored within this layout, the layout will dynamically size in order to fit whatever content is in it. So I can have something of any length provided it fits within the parent. Sometimes it can go out, but then it just goes weird. As long as it fits within the parent or on the screen, the layout will resize itself in order to fit those items. It's generally best and good practice to decide that you want to wrap the content if you're not sure what size the content will be or if it's changing size based upon input or what the user's doing. In our app, as you'll see later with the image view, I actually have a static layout with them like defined because I only want the image to be one size. It won't fit. I can extend that, I'll go further to that later on. Now back to our linear layout here. This line here with the parameter orientation, this dictates how the object will be laid out and lined up in the linear layout. In this case, I have vertigo. Again, from the text view example we had, I had text view one, two, and three on top of each other. If I were to change that horizontal, instead it would lay them out in a horizontal fashion left or right from text view one, two, and three. Any questions? A relative layout's a lot more flexible than a linear layout is. A relative layout lets you change your layout based upon relative locations on the display or in the activity XML file. So I have a couple of things in this example relative layout here, a text view and a button. So I have the relative layout declaration and I have both my width and my height declared. In this text view, I have my property state that it's going to center in parent. So in this case, it's going to center itself within the center of this declared relative layout. And I'm also going to assign an ID to it. We'll explain why and I'll get to that in just a moment. Below that, I have a button. So with a button, this is where I can explain the ID actually. I have an ID up here in text view which I just simply made labeled. This plus ID means that I'm going to add this ID as a variable that I can access later on in the XML file. You can declare these in a separate file as well if you'd like. It really depends on how you're going to use the app. In our case, we're just going to make it simple and declare them dynamically as we go through the XML. But anyway, when I declare my button down here, now this is only available within a relative layout. I'm declaring that this button is going to be below where this text view button is. So the text view will be centered in the screen with whatever information that's going to have on it and the button will be below it. Unfortunately, I didn't declare a center to center horizontally. Neither of these are any clear. I didn't declare the button to center horizontally. So the text view will be in the middle of the screen but the button will be below it but all the way over to the left because that's the initial horizontal location of everything that's on the screen. But since I declared this layout below, no matter where the text view goes, I had to say I wanted to move it a little lower than this. If I declared something else, say another button above the text view, put that in the center and declared this text view below that, it would actually shift my second button down so it's constantly below that text view. That makes a relative layout extremely flexible when you need to add things in the layout. A lot of times though, as an app developer, you'll be nesting these. So in the initial layout that I showed earlier, this is a linear layout. This is a linear layout. This is a linear layout. This is a linear layout and these are linear layouts. All of these are nested within a relative layout. In this case, I have, this one is the centered element and these are all nested around it based upon where the linear layouts are. So if this is one page linear layout here, I have this one centered in the parent and I have this one that is referencing above whatever I labeled this linear layout. All the rest of these, this one's listed, this one has a property of being below this layout. This linear layout here is below this linear layout and these buttons in their own linear layout are below this linear layout here. So that'll show you how you can change around the way you want your layouts to actually look. So we're moving on to the actual views that you can put inside of these layouts now. This is where you actually add content to the application that they can interact with for the user. We've already gone over a little bit of text view but I'm gonna go over a little bit more about it, such as, like I mentioned earlier, you can make the text old and you can change the size. So as you can see here, I have a text size here, which is 12 SP. SP is a characteristic use for size pixels for text on an Android application. That's the way they set that up. There's two different ways you can declare pixels on it. In this case, we have the text, which is independent size pixels based upon the text that you wanna use. And if you look down here where I have padding bottom, I have DP, those are density independent pixels. So if you look at an Android app, if you look at the resolution of Android devices all around, throughout the years, Android device resolution has changed from really small 320 by 240 displays all the way up to really big, but anyway, if you were to have a button that is 30 pixels by 30 pixels on a 320 by 240 display, it would be much larger than it would be on my 2250 by 1440 display. So what this does is it makes the density, it makes the size of that button completely dependent on what the density is, and it'll actually base the size more upon what the smaller resolution button will look like. So that way, no matter which device I put it on, it'll look the exact same. Text style here, that's just simply how the text is gonna look. You can choose to be out of the bold or italic in the quotations here. Quotations are pretty much how you decide what arguments you're gonna have with the properties. Also, Android text. Two things, one major thing about this, this is all depending on how you're gonna use it, good and bad practice. In the case of simplicity here, we're simply declaring the text in here as a static variable quantity. Most of the time, if an app is gonna be used internationally, that value will actually be stored in a file called strings.xml, and you will reference that here, using the same way I did the add ID, except instead you would have add strings slash the name of whatever string it is you're looking for. That's so that way, again, when you go internationally with apps, users can choose which language they wanna use and the app will reference a different strings, a different strings resource file in order to change the language of the app without the developer having to go through and reset all of those values inside of the program. Image views. Oh, I had that separate wrap content. That's not supposed to be there, anyway. So, an image view is simply displaying an image. As you saw above the title of the app, I had an image of a coffee cup. Let me see, let me pull this up, let me see if it wants to behave now. Okay, if you look here, you can see my image view, which is this little coffee cup here. So, I've declared a couple of things in here. Most importantly, what I was stating earlier was my layout width and my layout height are static. Since I have several different sizes of the picture itself for the different application, for the different devices that it will be on, I only want my picture no matter what to be this size based upon what device I am on. So, I declared it as 150 by 150 density independent pixels. So, no matter what, whether I go to a higher-res device or a lower-res device, this coffee cup will look exactly the same in each one of them. The important thing in the image view though is the source image itself. So, if I open up the project pane on the left, if you see under the drawable folder, which is referenced over here, we look at the source folder here, all along the sides here in drawable under the folder java.pane, I have my pictures, which are all listed for different pixel densities. All these little symbols and parentheses specify what kind of pixel density on the device that will be used when that image will be used, in which case we have high, low, mid, extra high, extra extra high density pixel density for device. But so, since I have the java.pane in here, look at the source here, I'm referencing the drawable folder and I'm pulling out the java image to actually make my coffee cup appear on the app itself. Okay. Now, very simply, a button. There's not really much more to it. It does exactly what it's expected to do. It sits there and waits for someone to click on it. And when you click on it, you can make things happen with it. Same declarations pretty much everything else, which is why I left only just with the height, because again, those are extremely important and have to be different for every single new object that you place in your app. They can not be stressed enough for them. So, when people put this thing on there and wonder why it's not showing up, those will be the first things that anybody will look for when it's working. While exploring how to add functionality to that in a little while, that is basically kind of different for any of you. Which we're actually gonna start doing that. You know, gonna change it up. I'm gonna show you guys the nesting that we have going on in our layouts for the device. So, as we can see in this code, I have at the top, this whole thing is, this whole app itself is showing in a linear layout. And inside of that, in the first set, where the image and the first set of text are stored, those are both relative layouts. Because in a linear layout, you actually can't center the object itself inside of the parent. No matter what in a linear layout, it will always set the layout to be what is on the furthest left of the display. So, if I were to pull that relative layout out like this, notice how the coffee cup and my title of just Java have both shifted all the way of fact over to the left. It's because there's no, this center horizontal does not exist inside of linear layout. So, in order to center something like that into this play, I have to have that parameter being defined within a relative layout. So, in order to keep those centered, I place them within a relative layout. So, if you'll notice my relative, my relative layouts in this case, this is gonna be, this is what's all gonna be decided for my text cube, my quantity here. We're just gonna have the intervention within it. Anybody notice this? I'm not declaring any kind of ID inside of this. Can anybody tell me why I don't need an ID for these relative layouts to stack properly? So, again, same as before, I have no ID defined for these relative layouts. Can anybody tell me why I'm not worried about whether they'll stack in the proper order? Was that again? And why is that? Whoa, so I'm looking for something a little bit more different, please. It's because of something that's in the code that's not part of the relative layout, but it's where the layout is residing. It's because the relative layout is in a linear layout. So, I don't need to define any kind of ID for these relative layouts, because I know, since I'm declaring them in a way that I will have each of these relative layouts to stack in the way I want them to, as long as they appear in the correct order of the exam now, if I were to make this in a relative layout, I would have to declare an ID for each one of these relative layouts. So, just another example here. So, here's where it gets a little awkward. So, inside this main linear layout here, just below the just-job icon here, I have a small relative layout. Inside that small relative layout, I have a small linear layout. The small linear layout only holds the buttons for the incrementer. Which, when you click a button, that'll add in subtract one from this little incremented value zero here. And so, in order to make, that was mostly to make sure that I kept these items centered. Originally, when this app, when they have you initially write this app inside of the audacity course, you spend a crap ton of time with the whole thing in like the upper left hand corner. It just looks ugly. Nobody wants to deal with an app where it is in the upper left hand corner. Everybody likes things centered in their apps. So, I declared them within a relative layout here and moved them to the center so they'd be more accessible and make the whole app itself more presentable, in my opinion. Whether you like it or not, I don't care. It's my app, not yours. Checkboxes. I do not have a slide for these because these were a last minute edition. I'm assuming everybody knows, these are checkboxes right here. So, checkboxes is the same as most of the other things. You'll notice that pretty much all XML things have very, very similar decorations or very, very similar property definitions just to make life easier for everybody. So, I declare my checkbox, closing tag here. I got a bunch of little things here to define what the touchbox is, what it's gonna say, and here's the function for calling up what I wanted to do. This is where I'm gonna explain how functionality inside of the Android app works. So, as the first slide says, making an interface, you can make an interface really pretty in Android. If you try hard and work a long time on it. But if nobody does anything, but if it doesn't do anything, what's the point of the app? I may as well just have a fancy wallpaper with a bunch that doesn't do anything. So, in order to do that, we have to declare what is gonna happen when the view that's on our device is going to be interactive. In order to do that, as you saw in the checkbox, we have to declare the onClick parameter. Down here is the onClick parameter. So, what this onClick parameter means, when I click one of these little checkboxes here, it's gonna trigger a function, in this case, that is, want them. Or, sorry, once I click one of these checkboxes, it'll set a function that is want them. I'll show how that function works later on. The button will probably be just as good as an example to this because it doesn't do much. There we go. So, this button right here, my subtraction button. When I click that button, it'll trigger a function called inMyApp called someone. And what that'll do is it'll take the little incremented value here and it'll subtract one from it. So, I think we're gonna move on to some Java right now. So, Android apps are written entirely in Java. Now, you've all done Java before and you all know the basics of how the land works. Well, Android bests all that. When you declare a new activity in Android, it sets most of the basic parameters that you would generally have to define yourself for a job application for you. So, it makes you really lazy in the process. Unless you wanna write an Android app in a text editor, in which case I'm so sorry for you. Because it's extremely difficult without using the IK. So, when you declare an activity, which I'm gonna pull up the main activity for this app here. First thing it's gonna show you is, it's gonna show you the class, what the name of the activity is and you can name the main activity whenever you want. I just chose to leave it main activity so I don't know that it's a main activity. And depending upon what you're gonna use, what SDK you're gonna use for that, it'll either give you extends activity or extends app compatibility activity. Extending app compatibility activity is much nicer because in my layout here, if you notice I have this really pretty blue bar at the top. That is what app compatibility allows me to use. It allows me to use a toolbar at the top there. Why? It's a good question. Nobody seem to figure out why exactly it doesn't want to disappear the rest of the time. So, one of those figures is out, let me know. Because I'm certainly not sure right now and I'm trying a bunch of different methods to figure that out. But if I were to change this just to a simple activity, it doesn't want to do it now, but this would disappear. It's supposed to disappear. Sometimes the synchronization on the Android Studio doesn't work as properly as it should. But anyway, that's for something if you guys want to mess around with it. If you guys want to mess around with the top bar. So, this function right here, the onCreate function. This is the first thing that's called an onYourApps. This is the first thing that's called onYourApps main activity. And this is the first set of code that will run when this entire activity is created. So, I'll explain that later when we get into launching activities from different apps and things like that. But for now, this is essentially the same as your main for any other Java, any other Java program that you've written. Now, underneath here, I have a bunch of different functions written down. And they're very simple void functions because I only attempt to do simple things. Ignore the submit word, we'll get to that a little later because that's a scary code. But, so you see I have an add one function and I have a sub one function. Now, I have view view as an argument for these. That means that when I call this function, this is looking for an argument called from an XML view. In which case, this function is triggered by a button view or this function is triggered by a text view or something like that. I can't simply call the add one function from a different function inside of this application without some form of view argument. Now, this will simply take a copy number, take a, I declare a copy number as a private variable up top here, just a few little private variables to get me going. We'll increment that number and I'll explain why, and it will display it all. I'll explain how that part works in just a minute. And it'll update the display to show you that number. I really wish I could make this app live right now, but unfortunately, I accidentally failed to predict it. So with these onCreate functions and things like that, there's also several other methods that are required for the different life cycle of an app. How many people know the life cycle of an Android app? Okay, there are several stages in an app's life cycle. There's the point where the app is created, which is where the onCreate functions. There's the onPause life stage where if you hit the home button where you go to a different app, it'll pause this app and place everything of its data, of its information in the back. There's the onReceive, which when you go into your system and you choose this app again, you become the front app on your device. It'll run that code, probably open up some data that was in the form of the store state that was there before. And onDestroy, that is when you go home and hit resets and you swipe away to kill the app, the onDestroy function is called. Normally onDestroy is generally meant to pre-memory for any part of the object that was created in the app, any kind of data that's not needed anymore, so that way you can keep the memory of the app small. And on the device, you'll still have such a time that's when you need it again. So as I said before, Android is pretty good job. So a lot of the stuff that you learn will figure out pretty quickly and easily. So it's a really nice step. It's a really nice step for people who enjoy writing Java and want to get more practice with it. Although I wouldn't recommend it as a first language because you see the learning curve is exactly the smallest thing in the world. But anyway, all the major things that you've learned in Java are there. The only things that are weird are activities, broadcast receivers, and services. Oh, and interfaces depending on whether you're a user or not, sometimes they can be a little too many but I'll make it a little simple for this. So we've already seen an activity. An activity is something that runs on the app on what it's called. A broadcast receiver is a small signal that the channel when the app is running an activity. So the most common example of this is some phone with a downloader. If you're looking to say I have an app when I open up the app, it's gonna go online, it's gonna grab a file, and it's gonna download that about my device. So the download is gonna declare a broadcast receiver that will tell the appers, hey, I'm downloading something. So give me priority with the HTTP calls so that I can go to this website, I can download the system, I can download the file that I need, and then when I'm done, I'll let you know that I'm done so you can open up a notification to the user and that's what it does. So in order to do that, you have to declare an abstract broadcast receiver and that you wanna do in the background and that's why I skipped that part because that's gonna get really ugly. Services, you can have an app have a main activity or you can have it run as a service. In which case, it doesn't have any actual interface. It'll simply trigger it and it'll constantly run in the background or you can trigger it on boot and it'll constantly run in the background. Chat heads, baseball chat heads are a good example. They're a service. If you leave them up, they leave them all in the corner of your screen. That is a service that they have running in the background with an interface on top of it, a very small interface that sits in the location that you chose for your device. So that's how a service works. You can't kill it. You have to go, you can't kill it via a recent journey like that. You have to physically go in and disable the entire, and kill the entire app in order for the service to be stopped and interfaces. Interfaces, how many of you people have used an interface before and have seen an interface or can tell me what the term is? Okay. An interface is a skeleton for the methods that this app will implement. So I have an example of an interface because I made this app way more complicated than me. So I just have a very simple interface here which declares a pair of buttons which is actually very nice to have in my time. But, so it's gonna display our method and I calculate price of it. Those are what are called inside of my main class to display my price and to calculate my price. And they're all implemented within this fine price implementation class. So in this fine price implementation class, I'm gonna look at this line first here where we have a main activity, main app. So in order for this class to actually change anything on the app in the case of the display we have going on with this app, when you click one of these increment buttons here, it'll increment and update this number here. It'll also display a price down here, all as you click it. In order for that to happen, you have to pass the main activity, you have to pass the interface for the main activity into your interface so that way you can change any views that are inside of that. In order to do that, to do that so that way I can use that implementation and change around how my views look inside of my main activity here, I use this line, which is the implementation of this line and is passing the activity that's currently inside of it. This is where my main activity, this here is my main activity which is going into my price implementation of my interface. So using that main, I can now update my whole interface here with whatever views I want. In order to do that, you notice these lines here. Find a view by ID. Remember how we declared all of these different IDs early on with all the different views? This is how you manipulate and programmatically use your job. I'm declaring that this price view is a text view. I'm also casting a text view here through my main activity which I've defined up here after I've passed the argument through. Finding a view by ID. So since we declared the IDs, we can call upon the IDs inside of our Java application and change whatever parameter we want on the update. Has anybody ever heard of R? Ew, what's R? Language, yeah. This is for data mining or something like that. Yes, but you're wrong. So Android pre-compiles a lot of your code as you're writing it. In this case, Android pre-compiles it into an object called R. R is an intermediary step between the actual program and the app itself. So R is where all of your little IDs and all of your little code, all of that stuff is stored for future use that way. Not only can you speed up compilation later, but you can also test and make sure things that you're looking for actually exist. In this case, my object R is gonna have my, I'm searching under the IDs for my object R and I'm looking for my price text view which is my, which is the updater, which is the text view on my app that shows what the price is. So whenever this, so since I made this declaration, I can modify any parameter I want in there. In this case, I've chosen to change what the quantity is. Oh, sorry, I'm gonna change the price view to quantity view of my app. Price view, there it is. So I am simply calling it price calculation, which is up here. And it's very, very simple arithmetic. I hope I don't need to explain that to anybody. He'd be really disappointed by it. And from there, I'm gonna change the text of my price view to this little private string up here which is gonna have my total value and the value that's gonna have my price. So since I made this, again, since I'm passing through all of my views on the main activity, I can manipulate them as I see them in here. And I only want to change the text. I can change the color of the line, but we don't need that. Okay, so now we're gonna get into the next step, which is where when you click a button, you wanna launch, you wanna say, you wanna do something. Instead of simply just changing around the current view, we're gonna launch an entirely different activity to do something different. So that's what I have happen when I press the total button on this app. Oh, that was a lot of work. But anyway, so I have another activity here declared, which is order activity with a completely different layout set here. But if you notice, it looks absolutely nothing like what my original layout was. Once you hit your order button, this is similar to what you'll see. It kind of goes more like, so say I ordered one coffee, and I wanted cream and sugar only. This is what the user will see afterwards. So, once that activity, I had to do several different things. I had to pass a number of different variables into that, and I had to do a couple of interface updates to make that happen. This is where we get to the core of how Android handles everything, which are called intents. Intents are triggers throughout the system that cause activities or services or methods to happen. So if I go back to my main class here, down here you'll see a declaration of an intent. So the intents take two arguments, the initial class that's being called upon, and the class or activity that you're actually going to implement with this intent. So in this case, the main activity is what's calling this intent, which is this. And I'm going to go to my order activity class, which is the other activity in the interface that I showed you. But, like I said, we're passing parameters into this, and intent initially does have a bundle of data that goes with it, but it's not much. It just simply unmasks back to what the original main activity of the application is. So what I'm going to do is I'm going to put extra data into it. In this case, I'm going to pass a couple ints and a few booleans, and then pass a string. Oh, what'll that do? I just go to string. But anyway, so these two values here, I'm passing through integers, and these three values here, I am going to pass through booleans. So notice how each of these has a string in front of them. That is the identification string for the data inside of this intent, plus whatever variable I want to pass into it. So those are the two arguments you need when you are putting any extra, any extra into an intent, which is an identification for the data and the actual data itself. So after I put the data in there, I am now going to start that activity with the intent, which is this call right here, start activity intent. Now if we go over to the activity that I'm triggering, which is the order activity, here in this very, very ugly block of code is where I'm receiving the intent. So now this is where it gets a little awkward with how the intents are handled. Notice here, I have a call of get intent. So this activity is going to take any data from the intent that's passed by the main activity, and it's just going to grab it all at once. So that means that it can only be triggered by that activity that calls it, and it will only receive data from that activity that calls it, no matter what other activities are running at the time. From that get intent, I'm going to take that, I'm going to split it into the exact data that I'm looking for, in which case both of those integers and all three of those Booleans. Now notice how I have two different calls here, get int extra, get Boolean extra, that specifically states what kind of data I'll be getting with this get intent. And here is where we're reusing that identification string that we passed through earlier. So I'm looking for these exact strings. Now these variables here, I would assume that I don't want them to always be false, right? If you're really disappointing if somebody hit a check box and it's still not necessarily false. So instead, what these actually are, is if no intent is passed through, if no value is passed through this intent, what is the default for that? So if I don't have any integer values for display value or coffee count, it'll be zero. Same thing if I have, if there's no check mark for milk, cream or sugar, if I don't have any through, through those intents, they'll by default be false. So from there, I'm going to unspool all that intent nonsense and I have it assigned to all the variables and I'm going to update them on my view. So again, I'm having a call to my test view here, finding the view by ID. Notice how I don't have, notice how in my implementation here, if I pull up my interface implementation, notice how right about here in the code, I'm calling main dot find view by ID. That means that I'm calling it on the main that was passed through this argument. But notice how in this one, I don't have that call. Can anybody make a guess as to what was that? Yes, that is a new activity, but there is another reason behind that. It's because I'm not calling it on any other activity besides this current activity. So by default, if you don't put an argument inside of that or pass any kind of view into it, it'll choose the layout for what activity you're currently working on. And from there, it'll update that, that view all the way. So if you pass through a view of your main class but don't actually call it anywhere, it won't update anything. But if you call this a view but don't call that other view that you're trying to pass through, it won't update anything. But it'll update something on your current activity view, which if you're passing through a view, you probably don't want that view to be horribly confusing. So when we declare a new activity, there's a couple of ways you can do it. You can just simply make a new Java class file, set it up as an activity, using the headers that we showed earlier. Like this. Pretty simple call. Pretty simple, pretty simple. I don't know what the class is going to be. And the extension, it's not that difficult. Anybody can probably write this in just a simple Android class app on that. But what makes it special are the extras that are thrown in there.