Section 1

Preview this deck

Android Studio

Front

Star 0%
Star 0%
Star 0%
Star 0%
Star 0%

0.0

0 reviews

5
0
4
0
3
0
2
0
1
0

Active users

0

All-time users

0

Favorites

0

Last updated

7 years ago

Date created

Mar 1, 2020

Cards (62)

Section 1

(50 cards)

Android Studio

Front

customized IDE based on IntelliJ that allows you to build apps IDE = Integrated Development Environment

Back

not finding databinding class in Fragment?

Front

make sure your xml is surrounded with <layout> </layout> and the namespacing are on these layout tags

Back

AVD

Front

Android Virtual Device emulator that pretends to be a device on your computer

Back

View reference

Front

ViewModel does not need View reference in MVVM bc of data binding, but is needed in MVP. Thus MVVM doesn't need all the interfaces that MVP requires

Back

MVVM

Front

more event driven than MVP

Back

Activities and fragments

Front

only contain logic dealing with UI display and capturing user input

Back

ViewModel

Front

store and manage UI related data in a lifecycle conscious way. Allows data to survive device-configuration changes such as keyboard availability and screen rotations

Back

using Dispatchers.Main

Front

means that the coroutines launched in the defined scope will run on the main thread.

Back

how to change the value of a livedata variable

Front

Back

race condition

Front

results when several threads try to access and modify the same data concurrently

Back

what does it mean if LiveData is an observable

Front

an observer is notified when the data held by the LiveData object changes.

Back

avoid excess code with .copy

Front

// Build appointment object. return AppointmentData( result.id ?: 0, status, time, result.location?.name, result.windowStart, result.windowEnd, result.location?.id, result.location?.address?.street, result.location?.address?.city, result.location?.address?.state, result.location?.address?.postalCode, result.location?.lat, result.location?.lon, result.location?.distance, result.job?.type, result.job?.number, result.job?.jobDescription, result.job?.id, result.job?.jobTypeWeight, result.job?.dueBy, result.techs?.map { tech -> tech.id ?: 0L } existing.copy(status = pending.status) Do the bottom instead of the top

Back

things to know MVVM and RxJava observables

Front

1. The view should always know about changes after the ViewModel & everything should go through the ViewModel 2. Emit one stream with states instead of events

Back

How to apply event driven data in MVVM

Front

Use RxJava library Observables

Back

may not be MutableLiveData

Front

when you want to cast it as LiveData to send elsewhere where it wont be changed.

Back

View

Front

actual UI ex. Activity, Fragment, or custom View For Activities and Fragments, we bind and unbind from the event sources onResume() and onPause()

Back

DataModel

Front

exposes data through event streams (RxJava Observables). Gets the data from network, database, or shared preferences, and exposes easily consumable data. Holds all business logic

Back

dependency

Front

when one object depends on the concrete implementation of another object. The Parent instance is dependent on the child. If the Child class itself depends on a class C, which in turn depends on class D, then all that complexity will propagate throughout the code base and hence result in a tight coupling between the components of the application.

Back

using Dispathers.IO

Front

means that the coroutines launched will run on the IO thread since getting stuff from the database is an IO option

Back

Steps to set up a device

Front

settings about phone tap build number item a ton go back go into developer options enable usb debugging

Back

ViewModel

Front

abstracts the View retrieves data from DataModel, applies UI logic, exposes relevant data for the View to consume. Like DataModel, VM exposes data via Observables

Back

POJO

Front

Plain Old Java Object

Back

lambda expression

Front

anonymous function that isn't declared, but is passed immediately as an expression

Back

More MVVM advantages

Front

has separation of concerns like MVP, but also has data binding benefits ALLOWS FAST REACTION TO DESIGN CHANGES

Back

layouts

Front

incredibly flexible and allow you to define how your user interface is presented on the device

Back

Fragments

Front

UI benefit A single activity can contain multiple fragments mainly used for tablet benefits For example, a news application can use one fragment to show a list of articles on the left and another fragment to display an article on the right—both fragments appear in one activity, side by side, and each fragment has its own set of lifecycle callback methods and handle their own user input events. Thus, instead of using one activity to select an article and another activity to read the article, the user can select an article and read it all within the same activity, as illustrated in the tablet layout in figure 1. should be modular and reusable

Back

job

Front

allows you to cancel all coroutines started by this view model when the view model is no longer used and destroyed

Back

Abstraction

Front

Pulling out specific differences to make one solution work for multiple problems. Preserving information that is relevant in a given context, and forgetting information that is irrelevant in that context

Back

Live Data

Front

observable data holder class that is lifecycle-aware. For example, you can wrap a LiveData around the current score in the GuessTheWord app

Back

View Data Binding Example

Front

Back

MutableLiveData

Front

LiveData whose value can be changed. MutableLiveData is a generic class, so you need to specify the type of data that it holds. // The current word val word = MutableLiveData<String>() // The current score val score = MutableLiveData<Int>()

Back

test with Mockito in ViewModel

Front

mock the DataModel and control the returned data for the methods used

Back

View and ViewModel relationship

Front

notifies the ViewModel about different actions, which creates a two-way data binding between the View and ViewModel. One to many relationship. This means View Model may be linked to many Views, but a View is linked to only 1 ViewModel. View has reference to VM, but VM has NO INFORMATION ABOUT THE VIEW. The data consumer knows the producer, but the producer (ViewModel) doesn't know or care about consumer (View)

Back

More on ViewModel

Front

VM EXPOSES STATES FOR THE VIEW, RATHER THAN JUST EVENTS. for example, create a DisplayableUser object that encapsulates name and email states. The stream will emit every time the name or email changes. Thus, our View always displays current state of the User. EVERY USER ACTION GOES THROUGH THE VM AND ANY POSSIBLE LOGIC OF VIEW IS MOVED IN THE VM

Back

LiveData updates

Front

only updates observers that are in an active lifecycle state such as STARTED or RESUMED.

Back

Single Responsibility Principle

Front

Create a DataModel for every feature in the app For example, we have an ArticleDataModel that composes its output from the API service and database layer. This DataModel handles the business logic ensuring that the latest news from the database is retrieved, by applying an age filter.

Back

coroutines

Front

the way to handle long-running tasks elegantly and efficiently. Let you convert callback-based code to sequential code.

Back

Editor

Front

main window where you edit your code

Back

when should you use coroutines

Front

when creating a database operation such as creating or updating a SleepNight

Back

Benefits of MVVM

Front

since the View is just a consumer of the ViewModel, it's easy to just replace different UI elements (with minimal or zero changes in other classes). GREAT FOR WHEN UI REQUIREMENTS CHANGE

Back

coroutine pattern

Front

Launch a coroutine that runs on the main or UI thread, because the result affects the UI. Call a suspend function to do the long-running work, so that you don't block the UI thread while waiting for the result. The long-running work has nothing to do with the UI. Switch to the I/O context, so that the work can run in a thread pool that's optimized and set aside for these kinds of operations. Then call the database function to do the work.

Back

ui scope

Front

determines the thread that the coroutine will run on. scope needs to know about the job

Back

MVVM testability

Front

easy to test unit tests in datamodel test ViewModel with Mockito

Back

Project Navigator

Front

left of editor, shows you everything your project contains

Back

MVVM architecture

Front

View (informs the ViewModel about the user's actions) ViewModel (exposes streams of data relevant to the View) DataModel (abstracts the data source. The ViewModel works with the DataModel to get and save the data)

Back

listener bindings

Front

binding expressions that run when events such as onClick(), onZoomIn(), or onZoomOut() are triggered. Listener bindings are written as lambda expressions.

Back

how to use coroutines

Front

you need a job, dispatcher, and a scope

Back

view model

Front

collects data, adds data to the database, and displays the data

Back

custom android View data binding

Front

binding done in the constructor unbinding happens in onDetachedFromWindow

Back

MVP vs MVVM

Front

similar, but Presenter tells the View directly what to display whereas the ViewModel just exposes streams of events. the View is updated with by binding to these events with data binding.

Back

Section 2

(12 cards)

add font mixins/text defaults

Front

Back

Dagger annotation @Singleton

Front

The @Singleton annotation is not part of the Dagger API. It's contained inside the javax package you added to your build.gradle at the beginning. It tells Dagger that there should only be a single instance of that dependency. So when generating the code Dagger will handle all the logic for you, and you won't write all the boilerplate code to check if another instance of the object is already available.

Back

how many lines are in the complete public api of Dagger?

Front

30

Back

dependency injection

Front

loosening the coupling (talked about it in dependency term) Rather than creating the child object inside the Parent class, the child object is passed into or injected into Parent's constructor. The responsibility for configuring child is elsewhere, and the Parent class is a consumer of the Child class.

Back

@Component

Front

The component is used to connect objects to their dependencies, typically by use of overridden inject() methods. In order to use the component, it must be accessible from the parts of the app that need injection. Typically, that will happen from the app Application subclass, as follows.

Back

benefits of dependency injection

Front

In the simple example above, this means changing Child to a Kotlin interface rather than a Kotlin class. With this change, many different types of concrete Child type objects that adhere to the Child interface can be passed into the Parent constructor. This presents several key benefits: Allows for the Parent class to be tested with various kinds of Child objects. Mock Child objects can be used as needed in certain test scenarios. Testing of Parent is independent of the implementation of Child

Back

Why can you replace a POJO with a Data Object in Kotlin?

Front

Bc Kotlin doesn't need to write getters and setters

Back

Dependency Inversion Principle

Front

Depend on abstractions, not concretions

Back

How to initialize the wiki component in when the wiki application first starts up

Front

add the following to WikiApplication: lateinit var wikiComponent: AppComponent private fun initDagger(app: WikiApplication): AppComponent = DaggerAppComponent.builder() .appModule(AppModule(app)) .build() override fun onCreate() { super.onCreate() wikiComponent = initDagger(this) }

Back

Dagger annotation @Module

Front

annotation tells Dagger that the AppModule class will provide dependencies for a part of the application. It is normal to have multiple Dagger modules in a project, and it is typical for one of them to provide app-wide dependencies.

Back

Dagger annotation @Provides

Front

The @Provides annotation tells Dagger that the method provides a certain type of dependency, in this case, a Context object. When a part of the app requests that Dagger inject a Context, the @Provides annotation tells Dagger where to find it.

Back

Dagger 2

Front

Dependency Injection framework. Name comes from directed acyclic graph(web of dependencies that occur between objects such as Parent, Child, OtherClass, etc)

Back