Compsci 290.3, Spring 2017 Software Design and Implementation: Mobile Landon Cox Owen Astrachan http://www.cs.duke.edu/courses/spring17/compsci290.3 See also Sakai @ Duke for all information Compsci 290.3/Mobile, Spring 2017 2.1
Hello! About me Ø Duke undergrad Ø Michigan PhD Ø Sabbatical at Facebook Research interests Ø OS, distributed systems Ø Privacy and security Ø Moving into robotics Compsci 290.3/Mobile, Spring 2017 2.2
Hello! About me Ø Schools with the letter 'D' Ø Lots of Duke Connections Ø Google v Oracle Research interests Ø Astrachan's Law Ø Teaching Computer Science K-12, College Ø Design Patterns resurfacing Compsci 290.3/Mobile, Spring 2017 2.3
Where does 290.3 Fit? Alternative to 308: Software Design and Implementation (Mobile) Ø Many concepts are the same Ø Platform is different Ø Many issues in mobile aren't on the desktop (more later) Fit into curriculum Ø Design and deliver in teams is good for Ø Good design comes from experience, experience comes from bad design (attributed to many) Compsci 290.3/Mobile, Spring 2017 2.4
Goals and Learning Objectives Turn ideas and specifications into working, mobile Android applications Work collaboratively on a small team Leverage and demonstrate understanding of tradeoffs in creating code for mobile device(s) from software perspective Demonstrate understanding of privacy and security concerns related to mobile apps More Compsci 290.3/Mobile, Spring 2017 2.5
Administrivia We will have readings for the course, these will be online Ø synched with 308 when feasible/possible Books completely optional, lots of material on the web, but books can be very useful Projects, groups, midterm, final Compsci 290.3/Mobile, Spring 2017 2.6
Format of Today's Class Android concepts Ø These are specific to 290.3 (compared to 308) Java concepts Ø Reminder of how Java works, Java the language compared to Java the platform Software Design concepts Ø Not particular to Android, nor to Java, but expressed in terms that leverage those platforms Compsci 290.3/Mobile, Spring 2017 2.7
Android Button Button "is-a" View Ø https://developer.android.com/reference/androi d/widget/button.html Ø What does "is-a" mean here? It's all about inheritance. See Android documentation for View What can you do with a view? What shouldn't you do with a view? Ø Yes create Listener, no drawing/layout Compsci 290.3/Mobile, Spring 2017 2.8
Event Handler aka Event Listener Pressing a button creates an event Ø Program processes the event, similar to other views, e.g., menu, scroller, spinner, Ø Sensors (android.hardware) also have associated event listeners Must associate click/press with button/widget Ø Attach an EventListener and write code to process event Compsci 290.3/Mobile, Spring 2017 2.9
How are buttons/widgets displayed? Layout for app is specified in.xml file Ø More details can be found in documentation, e.g., https://developer.android.com/guide/topics/ui/d eclaring-layout.html How is layout associated with program? Ø See the oncreate method for your application and note that it has two statements Compsci 290.3/Mobile, Spring 2017 2.10
Events via XML and AndroidStudio Two "views" of XML Ø Text and Design Ø Use either/both Event Processed Ø Use AndroidStudio!! Compsci 290.3/Mobile, Spring 2017 2.11
Project 0 specification One method to process all buttons Ø Determine which Button was clicked by asking the button its identifier Ø Using the generated/debug class R.java Ø Switch on the int value of the button's id For small programs, maybe viable, but switch statements like this not ideal Ø Quickly become unwieldy Ø Don't support "Open Closed Principle" design Compsci 290.3/Mobile, Spring 2017 2.12
Listener Alternatives Each button has its own method Ø Specify using layout XML, combine design and text view Ø Right click to get properties, e.g., in Design view Ø Use AndroidStudio autosuggest for method Let's refactor the code for Project 0 Ø Refactoring is very important design idea! Compsci 290.3/Mobile, Spring 2017 2.13
Create Listener Programmatically Rather than using the XML layout manager/specification Ø Create button listeners in code/program Ø Similar to JavaFX, Other GUI systems https://developer.android.com/reference/android/w idget/button.html Ø Dissect the code in this example, what does findviewbyid return? Ø Why is cast necessary? Ø How is listener object created? Compsci 290.3/Mobile, Spring 2017 2.14
Java: Anonymous Inner Class Button example uses OnClickListener interface Ø What's an interface? Ø Specify methods without implementation, just the method signature Anonymous means: class not named, must implement the required method Ø Always use @Override Compsci 290.3/Mobile, Spring 2017 2.15
Recall: Button is a View, a Widget Connecting widgets with code Ø XML Design, each has a unique ID, int value Ø The value should be generated automatically based on @id text label Ø Access this int value using R.id.unique_label View/Widget must be cast to actual type Ø Button b = (Button) findviewbyid(57); Ø Won't ever use 57, but R.id.button_gallery Compsci 290.3/Mobile, Spring 2017 2.16
What is Android? How does Java work with Android? Ø It's a little complicated, sort of, maybe Ø Java language, Java bytecode, Dalvik bytecode Ø Android Runtime (ART) processes bytecode Java Libraries, Android Libraries Ø Android is a mobile platform, requires libraries specific to mobile Ø Intellectual Property issues at play as well Compsci 290.3/Mobile, Spring 2017 2.17
Android Architecture Compsci 290.3/Mobile, Spring 2017 2.18
Android Specifics Creating a AVD requires specifying OS Ø http://www.bidouille.org/misc/androidcharts What version should you use? Ø It depends? Ø KitKat? Lollipop? Marshmallow? Nougat? Why don't all phones run same version? Ø Can all phones run the same version? Stock versus customized: Open Source Compsci 290.3/Mobile, Spring 2017 2.19
Why Use Android? By far the most widely deployed mobile and OS in the world Ø Maybe not at Duke, but We can use Java (the language) to develop Ø Familiar, widely documented, many tools Open Source and Open Ø Customizable OS and libraries, e.g. Samsung Ø Easier to deploy to phone/app Store Compsci 290.3/Mobile, Spring 2017 2.20
Loose Coupling: OO Design We want classes to be loosely coupled Ø Independent of each other in that they interact via APIs Ø Changes in one class have minimal impact on other classes except via APIs and those should be changed infrequently Applications and programs change Ø Minimize the "ripple" effect through the system Compsci 290.3/Mobile, Spring 2017 2.21
High Cohesion: OO Design Classes capture one abstraction Ø Create more classes when you need them, don't be a class miser or misanthrope (word abuse) Keep things simple, strive for simplicity Ø Don't use Swiss-army knife approach, one tool for one purpose Loose coupling and high cohesion, goals for programming Compsci 290.3/Mobile, Spring 2017 2.22
Open Closed Principle Classes and Programs will be changed Ø Open to extension Ø Closed to modification What does this mean? Ø If not modified, don't need to be re-tested on a Unit testing basis Ø Extension can be by design, by language features Compsci 290.3/Mobile, Spring 2017 2.23
SOLID OO design Single Responsibility Principle Open/Closed Principle Liskov Substitution Principle Interface Segregation Principle Dependency Inversion Principle Ø We'll look at these in more detail, but these principles are in general widely accepted Ø Principles, not rules Compsci 290.3/Mobile, Spring 2017 2.24