• Shuffle
    Toggle On
    Toggle Off
  • Alphabetize
    Toggle On
    Toggle Off
  • Front First
    Toggle On
    Toggle Off
  • Both Sides
    Toggle On
    Toggle Off
  • Read
    Toggle On
    Toggle Off
Reading...
Front

Card Range To Study

through

image

Play button

image

Play button

image

Progress

1/61

Click to flip

Use LEFT and RIGHT arrow keys to navigate between flashcards;

Use UP and DOWN arrow keys to flip the card;

H to show hint;

A reads text to speech;

61 Cards in this Set

  • Front
  • Back

Native Apps

Install from app store


Binary executables are stored on the phone


Executables directly interact with the user

Mobile Web Apps

Install by hitting web page, maybe bookmarking


Binary executables are stored on a server


Executables generate HTML+CSS+JS for browser

Smartphone Capabilities

GPS, accelerometers, gyroscopes, accurate touch input, camera

Smartphone Output

High-res screens and good audio

Smartphone Chipsets

Good CPU, Wireless + 3G/4G, flash RAM

Smartphone OS

iOS, Android, Blackberry, Windows, Ubuntu

Most media is now viewed on...

Mobile Devices (roughly 60%)

Android Software Engineer Salary VS iOS Software Engineer

Android $96,000


iOS $102,000

Lessons from the market

Keep your code and skills from going stale


Problem: non-portable native code

Platform Differences

Physical: Screen size, text input, scrolling




Stylistic: Back and Cancel buttons, Placement of navigation bar, colors

How to target multiple platforms?

Write platform-independent code, interpose libraries




Write platform-independent code, compile to platform




Platform-specific frameworks

Pros and Cons of targeting multiple platform options

Platform-indep libraries


Pros: Using existing JS skills, very easy to get started, nearly 100% portable


Cons: Lowest performance and Limited API access


Platform-indep compiler


Pros: Probably use your JS skills, better performance, some access to binary API, moderately easy to learn, nearly 100% portable


Platform dependent code


Pros: best performance and access to full binary API


Cons: Maybe new language, relatively hard to learn, nearly 0% portable

Abstraction of content away from devices

Images: organized based on screen size and resolution




Layouts: general descriptions of user interfaces




Menus: lists of options




Values: localized versions of strings

Layout resources

XML files that describe the widgets of a UI




GUI for drag-drop editing, setting properties




Several kinds of layouts supported


-table layout handy for forms


-relative layout handy for displaying content


-linear layout is most efficient

Tips for creating layouts

Try to avoid hardcoding sizes




Use dp to specify size on screen density




Be sure to give all widgets a unique ID

Activites

An activity is a window


Implements the behavior of a UI


-Init code


-event handling


-integration with your other classes


An activity is a type of a context which generally means a place where code can run

Lifecycle

created -> started -> resumed -> paused -> stopped -> destroyed

Handling lifecycle events

onCreate: init UI, app state


onResume: init expensive live resources


onPause: release expensive live resources


onSaveInstanceBuncdle: save app state


other lifecycle events are usually less useful

Permissions

The manifest also indicates what permissions your app will request from user during installation from the play store




Examples:


-Network


-Location


-Contacts

Hardware Management

Usually need to request specific permission




Then, request a reference to a manager object of some sort




Then attach an event listener




Finally, release resources when done

Threading

There's a thread that handles activity's UI called the main looper




Rule 1: Do heavy lifting in background thread




Rule 2: You can only access UI widgets from UI thread

Android vs iOS

Android


-Highly customized by each vendor


-Most parts of OS are open source with license


-Very permissive app store policies




Apple


-Nearly uniform system specs and behavior


-Only parts of iOS are open source


-Relatively restrictive app store policies

Major differences among iOS devices

Size




Pixel density




OS level

Diff levels of platform independence

•Option1: Write platform-independent code, interpose libraries




•Option2: Write platform-independent code, compile to platform




•Option3: Platform-specific frameworks

Choices of Languages

Objective C


-Most mature and kind of odd




Swift


-Least mature and less odd


-Seems to be Apple's new pseudo-standard




PhoneGap/JS


-Medium mature and leverage skills plus reuse

Swift Overview

Blend of JS with objective C




Major diff:


-all vars have types


-diff between nullable and non-nullable versions of types




Lots of old, redundant classes in the mix

Type conversion are very annoying

var myint = 4*7 is fine


var y = myint *4.4 is NOT fine


var z = 28*4.4 IS fine




var y = Double(myint)*4.4 IS ALSO FINE

Nullable "optional" variables

A type terminated with a question mark is a nullable type




var myint : Int?




Many functions require non-nullable values


In this case test for nil then unwrap non-nullable typed value with ! if(myint != nil) { foo(myint!)}

Other Swift Features

Classes: Basically like Java but all methods are public


Closures: Basically like JS, except that class member variables are accessed via "self"


Named parameters: function parameters can have "externalized" names, so you must specify the right "paraname"


Protocols: Very similar to Java interfaces


Tuples: Basically arrays with other operators

Notice some similarities to Android

General-purpose IDE with app-related wizards




Separation of app behavior from appearance




Use of virtual device for testing

Storyboard

Storyboard describes how the screens of the app fit together


-this includes the individual views


-and also the segues among them


-as well as the starting view




typically, in a device generalized way


-so the same storyboard can be used for ipad, iphone, etc...

Views

Each view is essentially a screen




Behavior is determined by its view controller




In addition, the widgets within the view can delegate responsibilities to the view controller

Protocols

A class "adopts" a protocol by implementing the methods, properties, and other parts of the protocol




1: Declare protocol on your class


2: Copy-paste the needed method declarations, create an empty body


3: Fix your typos


4:Implement the body of your methods

Outlets and actions

Variables (properties) of your class


Used to hold a reference to a widget


Declared as implicitly unwrapped




Outlets: Use to read/write widget values


Actions: Use to receive events

Auto-layout constraints

Auto-layout enables you to specify constraints on widgets' position and size




A generic "view" widget can be used to group widgets together, to simplify layout

Device-generalized constraints

You can specify that some constraints should be deactivated or activated only when the view is a certain size and shape

Accessing hardware

In general, the iOS hardware APIs are much more of a mess than Android


-Usually follow a "get manager, register listener, get value, unregister" approach as in Android




Sometimes have to specify a string for use in prompting user for permission at runtime

How many iOS applications were uninstalled during the study?

More than half (62%) of the 3400

How many apps were uninstalled within a single day? Within two weeks?

20% within a single day




31% within two weeks

What apps exhibit a shorter application lifespan?

Games and social networking

What was strange about paid apps?

They were uninstalled in the first day frequently

What are users more comfortable exploring?

Websites and web apps rather than downloaded apps

Smartphone still need improvement in order to deliver satisfying performance. What does performance mean?

The holistic user experience

Why target multiple phones?

To compliment the needs of different user groups

Why integrate with other apps?

Users wanted their apps to integrate with email, youtube, facebook, sms, .. while maintaining privacy and security.

Portability

The ability to run properly on multiple platforms without changes to code.




Hardware and OS version.

Usability

People can accomplish intended use cases quickly and correctly.




-Minimal confusion


-Minimal missteps


-Minimal clunkiness

Reliability

The software doesn't just work correctly once; it works correctly over and over again

Performance

The software uses few resources for the amount of work done

Security

The software keeps information confidential, available, and correct

Interoperability

The software can exchange data with other systems to provide benefits to users.

Concept of Utility

Great performance and bad security. You would focus on security, not optimizing code.




Marginal utility: the value you get from having

Suggested Process

Create a very basic version of your app


Figure out which quality attributes are too low


Use the advice in this unit to improve the app




Exceptions: Don't do things that will obviously harm quality

What is portability?

The same program runs properly on multiple platforms without changes to code.




Binary portability: the executable is portable


Source portability: the source is portable

Example of Binary Portability

Writing a mobile app, compiling it, and deploying the binary apk onto Android 1.1 through N.N




Or 1 through N on apple




These are examples of binary portability

Example of Source Portability

Writing a mobile app...


-Compile and deploy to Android phones


-Compile and deploy to iOS devices




Similar to writing a C program and compiling it with multiple OS's

What would happen if we didn't have some binary portability?

Outdated apps would have to be deleted not updated




Apps wouldn't run because of hardware differences




Expensive, app store would be small, hassle for end user

Why do we need source portability?

Platforms come and go




Same for cloud resources




How hard would it be to transfer code between platforms?

Reliance where feasible on standards

Use standards instead of "rolling your own" alternative




Use standards across languages




Use language-specific standards when feasible

Limited use of platform APIs

Choosing platform-specific APIs will always decrease portability




Nonetheless, you might still choose the platform-specific API/language to other considerations




Moral of the story: Don't use platform-specific APIs unless you have a good reason

done

done