Hey everyone, Dylan Schumacher, Citadel Defense. Let's talk about pistols. So at this point in the American Minuteman Gear series, it seemed appropriate to discuss pistols. I've been thinking about this for a while and I guess I have a couple thoughts on this. One, I have removed my pistol from my main battle rattle. As you can see here, here is the right side of my battle rattle and there is no pistol here. Now to some people, and to me initially right, that idea is anathema. How could you possibly not have a pistol on your gear? I mean, good God, is this America? What are we doing? And as I thought about it, again, mission drives the gear. So when considering your pistol, I've come up with a couple different thoughts. The first consideration is conceal carry. I know that might sound silly in the context of American Minuteman Gear because I thought we're talking about when China invades Dylan and what are we gonna do then?  So you need to conceal carry every day. That's something you need to do. And ideally, that would be the same gun that then goes on your battle rattle. If you're a pocket carrying a P365 from six hour every day, but your main battle gun is a Heckler and Koch MK245, the huge pistol. That's a little weird, right? Like it should be the same, ideally.  Those are the guns you should go to. So you have consistency across the board and so you're not burning money on extra pieces you don't necessarily need. The second consideration is as a American Minuteman when China invades and it's red dawn, you might have to do more covert spy type operation stuff and all of those concealed carry skills that you're garnering now will be a lot of use then. Being able to conceal your pistol well would serve you very well in kind of spy-y covert operations type stuff. And so having a pistol would be an extremely beneficial thing then. The third consideration is does it belong on your main battle rattle or not? Well again, mission drives the gear train that depends on what you're doing. If your plan is to go out with 20 of your closest friends then I don't know if you necessarily need a pistol on your main battle rattle because that's what you have 20 of your closest friends for. You're able to go out and you're able to have friends and maybe you're gonna be doing a lot of walking.  The answer you're gonna get back is little to none. Rarely do pistols come into play. The primary reason people do wear pistols on the battle rattle, like here, is if you're doing some kind of CQB, urban room clearing type stuff because then if I'm in a room and a guy is four yards away and my rifle goes down, it's nice to be able to immediately transition to that pistol to finish the job, right? That's the idea and that's why we started carrying pistols again. But when you're out in the rural fields and you're moving and walking and doing all that stuff, a pistol becomes more of a liability than it does an asset. I know that might sound crazy. It sounded crazy to me. However, that's the current situation. I don't make the rules, I just report reality. So those are some different considerations for your pistol. I think that we all, as Americans, default to slapping a pistol on that gear no matter what and hey, I get it, I can admire that. However, I think there are some deeper thoughts and considerations we need to think about when considering the role of a pistol. What is it that we are doing and how is that pistol gonna serve us? If we're primarily, again, in a rural, moving, patrolling, wrecky type environment slash mission, then a pistol probably isn't the best thing to bring along and it's mostly just gonna be dead weight. If you're moving into a more direct action, urban, CQB type thing or we're in and around vehicles, again, there a pistol might serve you better because you're gonna be in closer contact, closer quarters and a pistol will more likely, although still not likely, your primary is called your primary for a reason, a pistol will more likely be able to help you rather than hurt you. So I hope those are some helpful thoughts when considering a pistol. Do you carry a pistol on your gear? I'm assuming you do. If you don't, would love to hear why and if you do, have you thought about what that pistol is there for? I wanna prevent us from simply just copying whatever the latest global war on terror slash SWAT magazine says and really think about why it is that we have the gear that we have. Be a thinker, do brave deeds and endure.


What is going on guys? It's your boy DPJ here today with another Destiny video and in today's Destiny video we have top 5 trials of Osiris, Clutches and Aces of the Week. Now if you guys do enjoy the video at the end, if you couldn't leave a like, I would appreciate the support. Hope you guys enjoyed the video and I'll catch you on the next one. Match point guardians. Careful. Enemy team eliminated. Another battle won. Onto the next fight. Eliminate your opponents and claim victory. I'm watching his orb.  Get him, get him, get him.


ping the classes for characters in a game and building a hierarchy between the superclass A B Spike and the subclass Ghoul. Methods that are not overridden in a subclass like Ghoul and are public in a superclass like A B Spike, GetLife and IsCaptured, for example, can be called by Ghoul objects even though their definition was never written in the Ghoul file. Methods like these are inherited from the superclass. Let's look at how constructors can be inherited. The constructor we wrote in the A B Spike class performs these actions. In the Ghoul subclass, we'd like most of the same actions, but the life should be set to a default value of 15. We can do this by calling the SetLife method that is written in the A B Spike class method. That method adds the input parameter to the field, which in our case would be positive 5. Here is the code we would need to include in the subclass constructor. But SetLife is a private method and therefore is not visible to the subclass and can't be called by a Ghoul. We should change the keyword to protect it. This will allow subclasses to call the method, but still won't allow client classes residing in a different package to attempt to change the life level directly. This design decision makes sense for what we are trying to accomplish. Here is the complete code for the Ghoul class. Because of inheritance, it's really small. Let's take a closer look at the constructor we have just designed for the subclass. Let's rely on our understanding of how objects are instantiated. When a Ghoul is created, the compiler will first call a constructor of the superclass, in this case, a b spike. Once that work is done, the constructor of the subclass finishes up any code that was written for the constructor. The subclass author can either decide to make an explicit call to some constructor in the superclass using the keyword super, or a call to the default constructor in the superclass will happen automatically. This call to the super constructor needs to be written. But you can see that because the subclass is counting on the inheritance of some fields and or behaviors, the superclass must be called in some way. Let's review private methods and fields before we move on. Private fields and methods are not accessible from outside the class in which they are defined. This means that private fields that are inherited from the superclass may not be directly accessed by the subclass that inherited them unless they use public or protected mutator and accessor methods. Let's try a visual example of the relationship between a superclass and its subclass. Here we have base1 as the superclass and sub2 as the subclass. Code in the class file sub2 can directly access its own private fields and methods. Sub2 can also access protected methods from the superclass base1. And of course, code written anywhere can access public methods from both classes. Sub2 code cannot access private fields directly nor call private methods found in base1. From a client file the rules are pretty straightforward. Public fields and methods can be called by any appropriate object in a client file. A protected field or method can be accessed by any other class file that is in the same package, whether it is a file that defines some new object or is acting as a client file. Private fields or methods cannot be accessed by another class under any circumstances. See here that the method UpdateX is defined in both the superclass and the subclass. This indicates that the method has been overridden in the subclass. If an object of the base1 class calls UpdateX, the version in that class is executed. If an object of the sub2 class calls UpdateX the version in the subclass will be called. The method is overridden. In the case of the method MutateX, we see that the parameter lists are different. An object of the sub2 class can call either of these methods because the version in the superclass was inherited by the subclass. The first call would match the version in the superclass. The second call would match the parameter list and version in the subclass. This is an example of a method that has been overloaded. This lesson focused on increasing your confidence in designing a class hierarchy for different scenarios. Taking advantage of inheritance and polymorphism whenever it helped to increase the reuse and customization of existing classes. Now that you've completed this lesson you should understand what it means to inherit a method. You should also have learned how to build constructors in a subclass that call superclass constructors explicitly and explain what happens when no superclass constructor is called by the designer of a subclass. Moreover you should recognize when to declare state and behaviors as private, protected or public. Finally, by reading well written code, you should be able to classify methods as inherited overridden or overloaded. You should take some time to review this lesson and to make sure that you understand the relationships between these files so far. In particular the self-assessment quiz included with this lesson has an accompanying PDF file that contains some Java code with line numbers. Refer to this file as you attempt the quiz since it will challenge you and solidify your learning thus far. Welcome to the next lesson in the module on inheritance and polymorphism in Java where we'll work on the now familiar equals method and explore the concept of polymorphism in more depth. After completing this lesson you'll be able to implement an equals method in a subclass relying on methods defined by the superclass to simplify your work. Polymorphism as a key object-oriented programming concept and apply this concept to transparently customize methods defined by subclasses in an inheritance hierarchy. Finally, you'll understand how polymorphism can be implemented by the Java compiler and Java virtual machine to dynamically dispatch methods associated with the subclass of the object used to invoke the methods. So let's get started with this material. Let's now consider the equals method and how we can take advantage of inheritance to write it. Here is a good way to write the equals method in a subclass taking full advantage of inheritance. Suppose the superclass has the equals method defined in this way. If we are comparing an object of the superclass cast it as a superclass object and then check for further equality. Then we can check the field X. If it is not an object of the superclass, simply return false. Now we come to writing the equals method for the sub2 class which is a subclass of the base1 class. First, we would like to discover if the object that was passed as a parameter is also an object of the subclass. If it is, then we need to make the appropriate comparisons between the two objects. In most cases that will mean comparing everything between the two objects that was inherited from the superclass and then making the remaining comparisons of the fields that are found in the subclass. Here is the code to accomplish that. We set a local Boolean variable to false. If it turns out that the past object is not of the same class the result will remain false and will be returned. If it is a sub2 object we cast it and then call the equals method of the superclass in this case base1 to make the comparisons and return a Boolean value of the results. We end this method with the results of the comparisons made with any subclass fields and a final result is determined. This result is then returned from the equals method. There was a lot of information on that slide. Let's unpack it a bit by looking at the how why and why it works. The how is the code that we just saw. Use the keyword super to call the equals method of the superclass. The why brings us another term for your object oriented vocabulary. We rely on the code written for the superclass because it makes things like refactoring reusing and debugging easier. Refactoring means that we can change implementation details of our code without changing how other users of our class interact with our code. In our previous example suppose we want to declare two super objects equal if field variable X is greater than or equal to the field of the object being compared. This would affect all of the subclasses and the superclass as well. Usually a subclass object would be compared to other subclass objects using the same test. Change it once in the superclass and no subclass user needs to make any changes at all. This is an example of refactoring. And finally, why does this work? You may not have picked up on it but we used a sub to object as the parameter for the equals method of the superclass. Certainly it will make the call because all objects will qualify as type objects. But is it an instance of a base one object? It is. Because of polymorphism. Polymorphism another term commonly used in object oriented programming allows a subclass to take on the identity of any of its ancestor classes. In our previous example where we were designing characters an atomic ghoul is a ghoul. This means that an atomic ghoul can be used as a parameter where a ghoul object is expected. This works because an atomic ghoul has inherited all of the fields and behaviors of a ghoul object. Any method that was expecting a ghoul can still execute if it receives an atomic ghoul object instead. In the same way an atomic ghoul is an ab spike. This was the superclass from which the ghoul class was derived. Because ghouls inherited all the fields and behaviors of an ab spike object, those same fields and behaviors are passed down to the atomic ghoul class. And finally a ghoul is an ab spike. Let's review objects and method calls before leaving this lesson. First let's see where these calls may take place. A subclass can call any public or protected method that is in its superclass because they are all inherited. For example, code like this may be found in a class file where the method setTotal is protected in the superclass from which the class is derived. An object can invoke any public method from its superclass. Yes, that is similar to the first rule but here I am referring to a call found in a client file. My object is an object instantiated from the subclass and the method getTotal is a public method inherited from its superclass. It must be public as opposed to private or protected because this call is being made from outside the class file. Here are more rules about method calls. In all cases these rules apply to both calls made in a class file as well as calls made on objects instantiated in client files. When an object invokes a method that is inherited from the superclass the compiler will look for the definition of that method in its own class file. If there is no definition there this means that the object is referring to an inherited method so the compiler will then reference the superclass of the object. If nothing is found there then it must be a method that is a superclass first inherited from its superclass and so on. Suppose the method called is overloaded meaning that the name of the method is defined more than once but the parameter list differ. The first priority is to find a method definition with matching return type and parameter list. Once again the compiler would look for the definition in the first class file of the object. Then in the parent class and in the parent of the parent class and so on until a suitable definition is found. Because of polymorphism and inheritance this object can use any of the public methods found in its ancestor classes and the subclass file can also use the protected methods. What if a method is overridden? Recall overridden refers to the notion that there are several methods with the same name, return type and parameter list found in different subclass files and superclass files. It enables clients to write code that is very readable, like this while invoking two different methods definitions. Once again the compiler looks in the subclass that made the call first then the superclass and so on. If the object actually wants to invoke an overridden method in the parent class file that must be set up in the subclass. You might see this in something like the to string method. The subclass will most likely override this method. But what if we wanted to make both versions of the to string method available to the subclass? In the subclass file we would define the overridden method to string along with other methods that might call the parent class version the key word super and the subclass's own version or just call the parent class version by itself. In the client file the calls would look like this. Notice the first call to print object x is an implicit call of to string. The other two calls must be made explicitly to methods written in that subclass. A client file cannot use the key word super to try to make the subclass method. That reference must be made in the class file itself as a design decision made by the author of the class. And this is in keeping with our ideas about abstraction. Users of a class should not know what methods are native and what methods are inherited. They should just be able to interact with the object in useful ways. You don't need to know how polymorphism is implemented easily, such as to create subclasses that override the equals and to string methods defined in superclasses as discussed above. However, understanding how polymorphism works will increase your qualifications as a coveted full stack developer since you'll be more familiar with other layers in the Android stack and development tool chain. It will also help you to design object-oriented programs that strike the appropriate balance between flexibility and efficiency. Polymorphism in Java is implemented via the Java compiler and the Java virtual machine or JVM, which contains a bytecode instruction that calls the appropriate method for an object at runtime which is a process commonly known as dynamic dispatch. The specific method that's dynamically dispatched corresponds to the method associated with the subclass of the object used to invoke the method. This subclass method can override and customize the method inherited from the object superclass. Dynamic dispatch is also known as virtual method invocation, which is the default dispatching mechanism for methods in Java. Therefore, a subclass can override any method defined in a superclass, unless that method is declared as private, final, or static. Although the Java virtual machine specification does not mandate a particular internal structure for objects, a Java compiler typically generates a virtual table or vtable for each Java class. This vtable contains the addresses of the dynamically dispatched virtual methods in the classes API. Likewise, the Java compiler generates a pointer to the vtable of the class associated with each Java object. This so-called vptr, vpointer, is used internally by the JVM to locate the appropriate method in the vtable and dispatch it whenever a virtual method is called by an app. Java's dynamic dispatching mechanism is also commonly referred to as late binding, since virtual method calls are not bound until the time of invocation. In addition to supporting polymorphism via dynamic method dispatching, Java also supports static method dispatching where the implementation of a method is selected at compile time rather than at run time. JVM uses this technique to dispatch Java's private, final and static methods. For example, the static eq method in abstract map is statically dispatched to compare whether two objects are equal. Although statically dispatched methods cannot be overridden by subclasses, the underlying JVM can implement and optimize them more efficiently and dynamically dispatched methods since fewer instructions are typically required to invoke a statically dispatched method. These types of methods therefore play an important role in certain types of Java apps that value performance more than extensibility, such as time critical apps where the right answer delivered too late becomes the wrong answer. Now that you've completed this lesson you should be able to implement an equals method in a subclass relying on methods defined by the superclass to simplify your work. You should also be able to recognize polymorphism as a key object-oriented programming concept and be able to apply that concept to transparently customize methods defined by subclasses in an inheritance hierarchy. In addition, you should now understand how polymorphism can be implemented by the Java compiler and Java virtual machine to dynamically dispatch methods associated with the subclass of the object used to invoke the methods. This lesson underscores how concepts you learned in previous lessons continue to resurface as they apply to new scenarios. To refine your understanding therefore, you should continually apply these concepts by coding your own examples trying out your own ideas about classes and objects and in particular, try coding some of the examples contained in recent lessons if you haven't already. Make changes and then see if you can explain the results that you've seen. Trial, error and success can be powerful learning tools. We know our MOOC students lead very busy lives so please don't code and drive. Welcome to another lesson on class hierarchy and interfaces in Java. Now that we have a good foundation in classes and inheritance hierarchies we'll discuss interfaces which is yet another feature of Java. After completing this lesson you'll understand the similarities and differences between Java's class and interface features so you can evaluate programming problems and apply the best solutions. You will also be able to provide examples that contrast between these two features. Finally, you'll also know the proper syntax needed to implement the interface features presented in this lesson. So let's get started. Once again, it's much easier to discuss the ideas of object oriented programming in Java if we have an example in front of us. Consider these four objects you might find in a to-do list app that helps to schedule items an errand, a bill, a workout and a social engagement. Each has a very different way to define the state of the object and so each has different fields. We can't even say that their behavior is necessarily the same but the way in which clients would interact with these objects is the same. Each of these objects can be scheduled on a particular date and each can be marked as completed. They may also have other unique behaviors but we want to focus on what they have in common. Clearly these items cannot be arranged into a hierarchy. Superclasses and subclasses won't work here but we should be able to take some advantage of their similar behaviors. For example, to schedule an errand we would consider the deadline, the time it will take to complete and then try to find a time slot that works. To schedule an engagement we might check the requested date and then generate some sort of RSVP. In both cases we'd like to keep the call to the schedule event similar and simple. This keeps code readable and easy to write. Although a hierarchy is out of the question we can still take advantage of some of the benefits of code reuse by designing an interface. A JALA interface includes public method headings that's name, return type and parameter list but it doesn't include any body, no implementation. Like this method header for the method completed. This is all that we would see in the interface. Interface name should be capitalized. The file name and the interface name must match just like a class file and the file you write will end in .java, again just like a class file. But there should be no constructors no instance variables nor any bodies of any of the public methods written. Interfaces will never be instantiated. They do not contain the necessary information to create an object. They act as a form for methods that implement that interface to follow when it comes to defining methods. You can see what I mean in the next slide. Here is an interface called item that includes two public method headers schedule and complete. These are two behaviors that will be common to all the classes that implement this interface. But the implementation details of how each class accomplishes the method will be quite different. The class errand implements the interface item. Arend can have instance variables constructors, accessors and mutators necessary to model the class but it must also implement all of the methods listed in the interface. In this case, we have two schedule and complete. Another class engagement also implements the interface item. Its instance variables and methods can be completely different from those found in Arend. But it must also implement the two methods provided by the interface. There is no inheritance at work here, like we saw between superclasses and subclasses. We have two classes, Arend and engagement, that both invoke the same method schedule but with two very different implementations. Finally, an interface can be used as a parameter type. Polymorphism makes this possible because every class that implements the item interface is an item, it can be passed as an item to a method. Here is an example of a method to schedule any unfinished items for tomorrow and mark them as complete on today's list to close out the day. Because each of these items can implement both schedule and completed, we could pass an engagement, an Arend, or any other object that implements the item interface. You have now added knowledge of interfaces to your growing knowledge of Java object-oriented programming features. Now that you've completed this lesson, you should understand the similarities and differences between Java classes and interfaces. You should also be able to provide examples that contrast these two features. Finally, you should know the proper syntax needed to implement the interface features presented in this lesson. As we wrap up this lesson, try coming up with a couple of scenarios where a Java interface would be appropriate. For example, developing classes of shipping containers like flats and boxes could be facilitated with a shipping container interface that included methods for capacity and dimension. Try designing a few interfaces yourself. Be sure you aren't simply designing a class hierarchy and burdening it by forcing an interface where one is not needed. Welcome to the next lesson in this module, where we'll dive deeper into some advanced topics related to classes, interfaces, inheritance, and polymorphism in Java. After completing this lesson, you should understand what abstract classes and methods are and how they differ from concrete classes and methods. You'll also recognize how abstract classes compare and contrast with Java interfaces. In addition, you'll learn how Java supports various types of nested classes that are defined within the scope of an enclosing class. Not every Java program uses these advanced Java features. But once you are familiar with them, you'll be able to read and write more powerful apps in Android. Up to this point, we've been focusing our discussion on concrete classes, which are classes that implement all of their defined methods so that they can be instantiated directly to create and manipulate objects. The ghoul class is a good example of this. It's also possible and often quite useful in Java to define so-called abstract classes and or methods. These classes and methods create what we refer to as abstract types that provide an incomplete implementation or no implementation at all and can be used to define and enforce a protocol, a protocol that must be supported by subclasses. For example, the class abstract map is an abstract superclass that defines certain methods that must be implemented by all map implementations such as hash map and tree map. An abstract method is a method that's declared without any implementation. In other words, the method signature is followed by a semicolon rather than an opening and closing brace containing the method definition. An abstract class is a class that is declared with the keyword abstract before the keyword class. An abstract class may or may not include abstract methods. For example, the abstract map abstract superclass defines the abstract entry set method. An abstract class can't be instantiated directly, but it can be extended by a subclass. If that subclass provides implementation of its abstract methods, then instances of the subclass can be created. For example, it's not possible to create an instance of abstract map since its entry set method is defined as abstract. However, it is possible to create an instance of hash map which extends abstract map and provides an implementation of entry set. Abstract classes and abstract methods are used in many Java and Android class libraries to create inheritance hierarchies whose methods must be overridden by subclasses to transparently customize their behavior. Now that we've covered both Java interfaces and abstract classes in earlier discussions, we can compare and contrast them. Abstract classes are similar to interfaces in many respects. For example, neither can be instantiated directly, but instead must be customized either by subclassing in the case of an abstract class or implementing in the case of an interface. They both can contain methods declared without any implementation. However, abstract classes have additional capabilities that go beyond what's available in Java interfaces. For example, abstract classes can define fields that are not static nor final. Likewise, abstract classes can define public, protected, and private concrete methods. In contrast, interfaces can only define public, static, and final fields, and all methods must be public. Moreover, in releases of Java prior to version 8, methods in an interface cannot be implemented. Another difference between a class and an interface is that a class can only extend one class whether or not it is abstract. Conversely, a class can implement any number of interfaces. In addition to allowing developers to create top-level classes within a package, Java also enables one or more classes to be defined within an enclosing class. Classes organized in this manner are called nested classes. For example, Java Vector is a top-level class that defines several nested classes to handle its various iterator mechanisms used to access each element in a vector without exposing details of the vector's internal implementation. Nested classes provide several benefits, including grouping together classes that are only used in one place to avoid creating additional files. For example, nesting the iter and vector splitterer classes within the vector class enables all these classes to reside within the vector.java file. Nested classes also increase encapsulation by hiding implementation classes that needn't be visible to other top-level classes. For example, the nested iter class is defined as private, so it can't be accessed by clients that use vector. Finally, nested classes enhance accountability by placing nested classes within top-level classes, so the nested classes are defined close by to where they are used by programmers. For example, the iter nested class is used by the iterator factory method defined directly above it, and the vector splitterer class is used by the splitterer factory defined directly above it. There are two types of nested classes. An inner class is a nested class that can reference non-static methods and fields in the enclosing class. For example, iter is an inner class that can access the mCount field defined by the vector top-level class. Likewise, next method in iter can invoke the element data method defined by vector. A static class is a nested class that can't reference non-static methods and fields defined in the enclosing top-level class. For example, vector splitterer is a static nested class that doesn't access any fields or methods defined in vector, but instead uses fields it defined privately to maintain its own state. This lesson focused on several advanced Java features that once mastered will greatly enhance your ability to read and write powerful apps in Android. Now that you've completed this lesson, you should understand what abstract classes and methods are and how they differ from concrete classes and methods. You should also recognize how abstract classes compare and contrast with Java interfaces. In addition, we've also learned how Java supports various types of nested classes that are defined within the scope of an enclosing class. Java is a large and ever-evolving development and runtime platform. Be prepared to continue expanding your knowledge of its features, both in the context of Android and beyond. In the meantime, don't let the contents of this lesson rattle you. Begin working on the programming assignment for this module if you haven't already. Review the material, apply what you have learned, and reinforce your understanding by building, breaking, fixing, and rebuilding these programs. Welcome to the next lesson in this module, which focuses on Java support for exception handling, which involves both an extensible hierarchy of classes and a set of virtual machine mechanisms that separate the control flow paths of normal app execution from the control flow paths of anomalous app execution. After completing this lesson, you'll know why exceptions are needed to make Java apps more robust and easier to understand and evolve. You'll also understand how exceptions are reported and handled in Java apps. Finally, you'll recognize the two main types of exceptions that are supported via Java's hierarchy of exception subclasses. Despite our best efforts, apps will occasionally encounter problems that just can't be ignored. Echoing the classic Murphy's Law, anything that can go wrong will go wrong. For example, problems can arise when an app attempts to open a file that is not available on the device, or tries to call a method or access a field via a null reference, or indexes into an array before or after the valid range of the array. To provide a nicely structured way of dealing with these types of problems, Java provides an exception handling mechanism that enables the logic of an app to differ in a structured way, so the control flow paths of normal app execution is clearly and cleanly separated from the control flow paths of anomalous app execution. Exceptions in Java are supported by both an extensible hierarchy of classes and a set of mechanisms provided by the underlying virtual machine that systematically handle problems arising during the execution of an app. If an error condition occurs in a block of Java code in an app, that block can throw an exception to notify another part of the app that a problem has occurred. This notification allows the part of the app that catches the exception to take the appropriate action in response, which may include interacting with the user to fix the problem, logging the problem, or exiting the app altogether. Any code can report the occurrence of an error condition by calling throw with the appropriate instance of an exception class. For example, if the initial capacity passed to the vector constructor is less than 0, a new illegal argument exception object can be thrown to the portion of code that tried to create a vector erroneously. Likewise, if the index value passed to vectors last index of method is beyond the bounds of the vector, then a new index out of bounds exception object is thrown. When an exception is thrown, the virtual machine performs a number of steps. For example, consider an app with a group of methods that are called in a particular order, where method 1 calls method 2, which performs some computations, and then calls method 3, which in turn performs other computations, and ultimately calls method 4. Let's assume that method 4 throws an IO exception, which can occur under various circumstances, such as trying to write a downloaded image to a file when there's no space available on the storage device. When method 4 throws the IO exception, normal program execution stops. Control then transfers to the appropriate exception handler, which may involve the virtual machine searching up the runtime call stack to find an appropriate handler for the IO exception. For the sake of discussion, we'll have method 1 catch the IO exception and perform the appropriate action, such as informing the user that the storage device is full. The Java language provides some syntax for handling exceptions. A try block contains a sequence of one or more statements that encloses a region of code that may throw exceptions. For example, this try block encloses a statement that defines a vector of strings. This vector is passed a negative number as its initial capacity, which of course is an error. One or more catch blocks can be associated with a try block. A catch block defines an exception handler that handles the type of exception indicated by its argument. For example, this catch block handles the illegal argument exception thrown by the vector constructor when it is passed an initial capacity less than 0. Another syntactic element associated with Java exceptions is the finally block which always runs no matter how the try block is exited. For example, this finally block is always run to unlock the lock regardless of whether the statements within the try block throw an exception or if the try block returns from the method. Yet another syntactic element associated with Java exceptions is the try with resources block which was introduced in Java 7. This variant of a try lock declares one or more resources that will be closed automatically after the app's flow of control exits the block. For example, this try with resources block defines a variable called buff reader which is used within the block to read a new line. The close method of the buff reader variable is automatically closed when the try with resources block exits thereby ensuring that any resources it allocates are released. Java exceptions are organized into a class hierarchy all of which inherit from the exception superclass. Handlers can be specified for different subclasses of exception. For example, a try block could be followed by two catch blocks one for the index out of bounds exception and another for the illegal argument exception both of which are descendants of the exception superclass. If a method doesn't specify a handler for an exception that's thrown the next matching handler up the runtime stack gets called. For example, method one handles method two within a try block. Method two then calls method three without using a try block. So it has no way to handle any exceptions method three may throw. Therefore, if method three throws some exception it won't be handled in method two but instead will be handled back in method one's catch block which handles some exception. To handle every possible type exception in a method simply define a catch block that handles exception which as a superclass forms the base of the Java exception inheritance hierarchy. Moreover, to handle every possible type of error define a catch block that handles throwable which is the superclass of all recoverable runtime errors and exceptions in the Java language. A useful method defined by throwable and thus available to all exception subclasses is print stack trace which prints a back trace of all methods on the runtime stack leading up to the location where the exception occurred. This back trace can be extremely helpful when locating bugs in your apps. There are two general types of exceptions supported by Java. One type is called checked exceptions. Methods declaring checked exceptions require their callers to provide an exception handler or else the compiler will flag the calling code as an error. For example, the right object method in the vector class explicitly declares that it may throw the IO exception. Therefore, if method one calls the right object method on a vector object it must contain a catch block that catches the IO exception. The second general type of exception supported by Java is called an unchecked exception which can be thrown by a method without it having explicitly declared the exception in its signature. For example, method A can throw an unchecked exception such as the index out of bounds exception. Method B can call method A without having to define a catch block for the index out of bounds exception. Moreover, it could define a catch block for a more general exception such as the exception superclass. In fact, method B could catch the index out of bounds exception as an exception and then re-throw it as a new runtime exception. Although we've covered quite a bit of material in this lesson there's still more to learn about Java exceptions. So we recommend you read more about these topics in various online Java resources. This lesson focus on exception handling in Java which involves both an extensible hierarchy of classes and a set of virtual machine mechanisms that separate the control flow paths of normal app execution from the control flow paths of anomalous app execution. Now that you've completed this lesson you should know why exceptions are needed to make Java apps more robust and easier to understand and evolve. You should also now understand how exceptions are reported and handled in Java apps. Finally, you should recognize the two main types of exceptions that are supported via Java's hierarchy of exception subclasses. Even well-written apps occasionally encounter problems that just can't be ignored. So Java's exception handling mechanism provides a nicely structured way of dealing with these problems. Welcome to the last module in this MOOC. This module guides you through the final programming assignment which is a so-called mini project designed to give you more freedom designing and implementing a creative solution that applies all the object-oriented Java programming language features we've covered in this MOOC. In this mini project you'll develop a simple calculator app which provides the means to add, subtract, multiply, and divide numbers input by a various Android user interface components. After completing the lesson in this module you'll understand the requirements of the calculator app, know how to download the Android Studio project and associated files that provide the skeleton of the app, be familiar with guidelines for structuring your Java solution to receive full credit and submit your solution and assess solutions submitted by other learners in this MOOC. If you've successfully completed the programming assignments in the previous modules you should be well prepared to develop a creative and functioning implementation of the calculator app. So let's get started. In this mini project assignment you'll write the program logic needed to complete a simple calculator app in Java. This app will perform integer arithmetic on values entered via components using Android's user interface, or UI. We'll supply you with skeleton code that implements the calculator's UI and Android. The app you implement should meet the following requirements. The UI we provide allows the user to enter two integer values and select one of four operations addition, subtraction, multiplication, or division. After supplying the two integer values and pressing the calculate button on the UI three entities will be provided to the Java code you write. The two integer values entered by the user and the operation they selected to perform on these values. Your code must then perform the necessary computation and print a strain that contains the final answer in the expected form. The final results printed for integer addition, subtraction, and multiplication are what you'd expect them to be as shown in these screenshots. The first screenshot shows performing addition, the second shows performing subtraction, and the third shows performing multiplication. However, the final result printed for integer division must include both the quotient and the remainder, even if the remainder is zero, as shown in these screenshots. This screenshot shows performing division with a zero remainder, and this screenshot shows performing division with a non-zero remainder. Please start this assignment by downloading the supplied zip file corresponding to this mini project. Extract the contents of the zip file onto your computer. The contents extracted from this zip file contain an Android Studio project. Next, launch Android Studio and load the project. In addition to the UI-related classes, which you can ignore for the time being, you'll see this project supplies you with five skeleton files containing the following Java classes. The logic.java file contains the process method, which receives the three entities passed from the UI. The two integers upon which to perform the computation, and an integer value indicating the operation to perform, with a value one equals addition, two equals subtraction, three equals multiplication, and four equals division. Naturally, we recommend using symbolic constants for these values rather than magic numbers. There are four other files. The add.java file contains an empty class named add. The subtract.java file contains an empty class named subtract, the multiply.java file contains an empty class named multiply, and the divide.java file contains an empty class named divide. Your work should start by modifying the logic.java skeleton file. Open this file on the Android Studio integrated development environment and look for the comment to do, start your code here. You can then add your implementation at this location as you see fit. Likewise, open the other four java skeleton files and follow similar steps until you've completed your implementation. For a more detailed analysis of the skeleton files and other parts of the UI code, please watch the lesson entitled mini project assignment walkthrough. We'll now discuss the guidelines for structuring your solution, which are divided into two parts. The first part are guidelines for source code design. Given the intentionally limited capabilities of the calculator app, one solution might involve performing all the work in the process method via a multi-branch if else statement. However, this design would be unmanageable if we later wanted to extend our calculator to support additional operations and or add additional data types. We therefore encourage you to create an object-oriented solution that will provide better abstraction to simplify extensibility and refactoring the future. In particular, to receive full credit for this assignment, you must apply java language features we taught in recent modules of the MOOC and use the four empty java classes we provided by adding methods and or instance variables to them. We also recommend you consider defining a java interface that these four empty classes implement. The second set of guidelines involves source code aesthetics, such as commenting, indentation, spacing and identifier names. They're required to properly indent your code and will lose points if you make significant indentation mistakes or inconsistencies. None of your lines of code should be longer than 80 characters. Please also use a programming style that's easy to read and maintain by doing things like creating additional helper methods as needed, using meaningful variable and method names, making the code more readable by using white space and blank lines appropriately and explaining tricky pieces of code with useful comments. For this assignment, you'll need to submit a zip file containing all the java files and android studio project files needed to compile and run your calculator app. To build this zip file open the gradle window in android studio which is located along the far right edge of the screen all the way up. Then go to the M8 assignment calculator tasks other menu item and double click on project zip to generate the zip file of your project in the project root directory zip folder. After you locate the zip file on your drive you can upload it to the Coursera platform. Unlike previous assignments in this MOOC that were auto graded this mini project will be purely peer assessed which involves giving and receiving feedback from other learners in the MOOC. There are two steps involved in peer assessing programming assignments. First, you'll submit your assignment by following the steps we just discussed at which point you'll be granted access to a video that walks through our solution so you can see how we implemented the calculator app. Second, you'll then review five submissions made by your peers. Using a grading rubric we supply you with to guide your peer assessments. Your final grade on this mini project will be calculated using the median scores you receive from your peers on each assignment component. There's a 20% penalty for not evaluating your peers so please make sure to follow these instructions so that everyone benefits from helpful feedback. As you do your evaluation please keep an open mind and focus on the positive. Our goal is not to find every way to deduct points over small deviations from the requirements or for legitimate differences in implementation styles. Therefore, look for ways to give points when it's clear the submitter has given a good faith effort to do the project and when it's likely they've succeeded. Finally, remember that almost everyone is working hard and putting in serious effort so if you've got doubts please err on the side of giving too many points rather than giving too few. Congratulations! You've now finished all the contents of this MOOC. The final mini project in this module gives you experience developing a simple calculator app in Java that provides the means to add, subtract, multiply and divide numbers input by the Android user interface components. Now that you've completed the material in this module you should understand the requirements of the calculator app. Know how to download the Android Studio project and associated files containing the app's skeleton. Be familiar with guidelines for structuring your Java solution to receive full credit and recognize how to submit your solution and assess solutions submitted by other learners in this MOOC. On behalf of my co-instructors Mike, Jerry and Julie we hope you've enjoyed learning how to program Java for Android. We also look forward to working with you in subsequent MOOCs in our specialization on Android app development. This video performs a code walkthrough of the skeleton files you can find for the mini project assignment in Module 8. We'll start by opening up the project clicking on the particular files and choosing that in Android Studio that we'll go ahead and open up the project then go take a look at the project click down to find the files that you're down here and we'll start by taking a look at the skeletons that you have to fill in to perform your work. We'll start first by looking at the logic interface. The logic interface is a Java interface that defines the API for processing user calculations. As you can see here it has one method called process that takes the first argument and the second argument passed in from the user interface which we'll examine later as well as the operation that's been selected by the user and it goes ahead and performs the operation on those particular arguments. Let's go take a look at the logic file you can see the logic class implements the logic interface which means you have to come along and implement this process method that's where your code will go. You can also see that we keep a reference to the activity output here which is used to interact with the activity from within this code and then we also have constructor that takes the activity output reference and stores it in this field that's part of the logic class. As usual we do this in order to be able to decouple the Java portion of the code from the Android portion so you can focus your solution purely on the Java portion. Let's now go ahead and take a look at the various files as we mentioned in the earlier video these are all empty files you can see add which is a class divide which is a class multiply which is a class and subtract which is a class and your job as part of this assignment is to figure out how to implement each of these different classes and then connect them together with the logic class so when process is called back you'll go ahead and do the appropriate computations in order to perform the operation to add, divide, multiply, or subtract that's basically what you have to do so your job is to figure out the appropriate design, figure out the appropriate implementation using the various Java features that we've been talking about throughout this MOOC things like interfaces and classes and inheritance and polymorphism and so on in order to be able to implement this calculator logic for completeness we'll also walk you through the user interface, keep in mind this is not what you actually have to do you don't have to write this code, we provided it to you but it might be fun to see how it works we'll go over here and take a look at the main activity as you can see here this activity provides the user interface that prompts the user for two integer values as well as for the operation to perform on these values main activity extends activity and implements activity interface we'll come and take a look at activity interface in just a second let's go ahead and take a look at some of the fields that are provided in the main activity class we have something called a spinner which is a drop-down selector that you can use to choose which operation to use there's also a button that you can press when you want to perform the computation after you've entered the values you can enter value one and value two and that means you can add things to them and then there's going to be a result that's also stored in an edit text that stores the results of the computation that's where the output is actually stored we also have a reference to the logic object that of course is what you'll be implementing over here with the logic class that we looked at before that you have to go ahead and fill in there's also something that's called an array adapter and this is used to adapt an array of character array of characters or character sequence care sequence to make it usable by the math spinner and this we'll see later on when the program actually runs now let's get into a little bit of Android callback methods these are called lifecycle hook methods we'll be discussing a lot more about these in the second MOOC in the specialization where we talk about activities in more detail one of the things that the Android environment does for you the Android platform does for you is it has certain hook methods that are called back automatically by the Android platform by the framework portion of the Android platform in order to initialize your activity objects activities are the ways that you interact with the user they provide user facing operations in this case it's the GUI that's used by the calculator to get the input and the operation and then present the output what we do here is we do a call up to the super class just kind of always done in Android code we'll talk about that more in the next MOOC you don't have to worry about that here we call a method to initialize the various views and other fields that are part of the activity and then the final thing we do is we go ahead and we create a new logic object passing in this activity and this is actually this which is the object that implements the activity and that is actually going to be used to give the activity interface to the logic object that we defined over here so if you look over here you can see we're passing in something called activity interface and we'll come back and talk about what that means in a second this is going to get stored in a field called mLogic so that's now available to interact with the code that you write here's the initialize UI method this again is a lot of detail that we'll talk about more in the next MOOC so don't worry about understanding it I'm just going through it now for completeness we set the layout the user will see the user interface with the calculate button and the two edit text fields to get the input and the edit text field to present the output down here we then go ahead and get a bunch of references to the various view objects these are things that are part of the user interface widgets or the user interface interactors components the button, the edit text fields the thing called the math spinner which allows you to be able to select the result and the result object then we go ahead and create an adapter which is going to be used to allow us to visualize the spinner and the last thing we do is we go ahead and we add we make the default selection for the math spinner to be add so if you don't do anything to the contrary you'll end up adding the two inputs that are given by the user naturally if you want to change that you can go ahead and click on the spinner and it'll select the other operations to perform when a user actually presses a button that goes ahead and is automatically dispatched by the android framework to the button pressed method right here and that will go ahead and get the operation number we'll take a look at how that works in a second once we've got the operation number we get the first value and the second value that's specified by the user and the user interface and here is then the hook that connects with the code that you write we end up calling the process callback method or hook method on the logic reference with arg1, arg2 and the operation and that vectors you over here where this code is going to be run, the code that you write there if you go down a little bit and take a look at some of these helper methods you see get value 1 and get value 2 essentially take the string that was given through the user input and converts that into an integer for value 1 and for value 2 those are returned as ints and then down here we also have a way of being able to select the appropriate choice from the math spinner to get the appropriate operation as an operation number so I think add is 1, subtract is 2 multiply is 3 divide is 4 and so on and so forth here then is the way in which we print the result to the user output this is something of course that you'll end up needing to call from within your logic process method when you're all done you'll go ahead and call back and you'll print the result which just goes ahead and sets the text for the result to be the text string, the string that's passed in here so that's basically how the activity works let's now go take a quick look at the activity interface if you take a look up here you'll see that the main activity implements activity interface here's activity interface as you can see the activity interface simply provides some ways of getting at various values that the user provided in this particular case the only one that really matters is the print method we provide the other ones here just if necessary but they're actually passed in as you can see as the value of argument one argument two an operation so that's actually not strictly necessary here we only really need to provide the print method and we use this activity interface in order to be able to have a very loose coupling between the activity the math activity that we define here which is all android code and then the code that's over here in the so called logic folder and this is the code that by and large is just plain old java code and so you don't have to really know much if anything about android in order to be able to carry out this computation whereas that allows us to be able to write the android activity over here we're doing that in this course for a couple reasons the main reason is so we don't have to teach you everything you need to know about android at this point and then later when we get to the next course we'll teach you more about how these things work and we're also doing this because it makes it easier to mock up various test applications to test the logic here without having to drag in all the android operations and the android platform and the android framework and that of course was used earlier in order to make it easier to write unit tests we could use with our auto graders here's a bit more this again is stuff we'll cover in the next class these are some of the resources that are provided as part of the android studio environment to dictate the way in which information is laid out on the screen here's activity underscore main XML if you go over here to main activity you can see that there's a reference to activity main here we do the set content view call that basically says that this will be the main activity for or rather the main layout for this activity so if we go take a look at this it's going to be a xml file and there we go it's showing you what the view looks like so you can see we have value one value two you've got spinner here which gives you the different items you have the calculate button and then you've got the output edit text for the result so those are some of the things that you get here here's what this actually looks like in the xml format and I'm not going to go through this in gory detail right now this is something that we'll cover again in the next MOOC but basically what you can see here is we indicate that this particular text view is going to give you a prompt to edit to enter the value one text and then we're going to have the input for this that's the edit text and it's given a name and we're going to use those names in the main program take a look over here you see we go look those things up by their name come down here we see another prompt which is going to be for edit the value of two edit text we have a calculate button and you can see that this particular xml descriptor says when somebody clicks on this button call back to the button pressed method and if you take a look over here here is button pressed it's right there there's the button press method so what this is doing is it's basically connecting this resource file is connecting the button that's clicked on the user interface with this method that's defined in the android activity and we'll talk again later about other ways of doing that that's just one way of doing it the next MOOC we'll cover that in more detail here's how we define the spinner and here's how we define the results that will be printed out so again you don't have to know about all of this stuff in order to do the assignment I'm just walking it you through it because it's kind of fun to get a preview of what's going to come along later in the course but the main thing to remember for right now is that you need to start focusing on the logic file and filling out how you do the process method and then implementing the ad divide multiply and subtract files and we intentionally made this assignment quite open-ended to give you maximal ability to be creative and that's why we're going to be doing this using peer evaluation as opposed to auto grading because people will do things in different ways and we didn't want to be restricted in the way in which we evaluated it we want to let you guys be as creative as you'd like so that's the walkthrough of the skeletons hope that that is helpful to you and of course as always please feel free to contact us on the discussion forums if you have any questions whatsoever