1 / 24

Software Design and Implementation for Mobile Devices

Learn how to design and implement mobile applications using Android platform. Explore concepts of privacy, security, and teamwork.

annaalexander
Download Presentation

Software Design and Implementation for Mobile Devices

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Compsci 290.3, Spring 2017Software Design and Implementation: MobileLandon CoxOwen Astrachan http://www.cs.duke.edu/courses/spring17/compsci290.3 See also Sakai @ Duke for all information

  2. Hello! • About me • Duke undergrad • Michigan PhD • Sabbatical at Facebook • Research interests • OS, distributed systems • Privacy and security • Moving into robotics

  3. 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

  4. 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)

  5. 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 …

  6. 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

  7. 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

  8. Android Button • Button "is-a" View • https://developer.android.com/reference/android/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

  9. 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

  10. 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/declaring-layout.html • How is layout associated with program? • See the onCreate method for your application and note that it has two statements

  11. Events via XML and AndroidStudio • Two "views" of XML • Text and Design • Use either/both • Event Processed • Use AndroidStudio!!

  12. 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

  13. 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!

  14. 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/widget/Button.html • Dissect the code in this example, what does findViewByID return? • Why is cast necessary? • How is listener object created?

  15. 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

  16. 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

  17. 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

  18. Android Architecture

  19. 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

  20. 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

  21. 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

  22. 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

  23. 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

  24. 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

More Related