kotlin - Coggle Diagram
A background job. Conceptually, a job is a cancellable thing with a life-cycle that culminates in its completion.
Jobs can be arranged into parent-child hierarchies where cancellation of a parent leads to immediate cancellation of all its children recursively. Failure of a child with an exception other than CancellationException immediately cancels its parent and, consequently, all its other children. This behavior can be customized using SupervisorJob.
The context of this scope. Context is encapsulated by the scope and used for implementation of coroutine builders that are extensions on the scope. Accessing this property in general code is not recommended for any purposes except accessing the Job instance for advanced usages.
By convention, should contain an instance of a job to enforce structured concurrency.
Defines a scope for new coroutines. Every coroutine builder (like launch, async, etc) is an extension on CoroutineScope and inherits its coroutineContext to automatically propagate all its elements and cancellation.
The best ways to obtain a standalone instance of the scope are CoroutineScope and MainScope factory functions. Additional context elements can be appended to the scope using the plus operator.
To start a new coroutine use one of the main "coroutine builders":
Futures, promises, and others
linear layout alternative inside constraint layout
example in constraint_flow2
You must implement this callback, which fires when the system first creates the activity.
This method receives the parameter savedInstanceState, which is a Bundle object containing the activity's previously saved state. If the activity has never existed before, the value of the Bundle object is null.
The onStart() call makes the activity visible to the user, as the app prepares for the activity to enter the foreground and become interactive.
The onStart() method completes very quickly and, as with the Created state, the activity does not stay resident in the Started state. Once this callback finishes, the activity enters the Resumed state, and the system invokes the onResume() method.
When the activity enters the Resumed state, it comes to the foreground. If the activity returns to the Resumed state from the Paused state, the system once again calls onResume() method. For this reason, you should implement onResume() to initialize components that you release during onPause(), and perform any other initializations that must occur each time the activity enters the Resumed state.
You can also use the onPause() method to release system resources, handles to sensors (like GPS), or any resources that may affect battery life while your activity is paused and the user does not need them.
However, as mentioned above in the onResume() section, a Paused activity may still be fully visible if in multi-window mode. As such, you should consider using onStop() instead of onPause() to fully release or adjust UI-related resources and operations to better support multi-window mode.
When your activity is no longer visible to the user, it has entered the Stopped state, and the system invokes the onStop() callback. This may occur, for example, when a newly launched activity covers the entire screen. The system may also call onStop() when the activity has finished running, and is about to be terminated.
onDestroy() is called before the activity is destroyed. The system invokes this callback either because:
1) the activity is finishing (due to the user completely dismissing the activity or due to finish() being called on the activity), or
2) the system is temporarily destroying the activity due to a configuration change (such as device rotation or multi-window mode)
Model, View, ViewModel
MVVM with Data Binding on Android has the benefits of easier testing and modularity, while also reducing the amount of glue code that we have to write to connect the view + model.
Model View Presenter
MVP breaks the controller up so that the natural view/activity coupling can occur without tying it to the rest of the “controller” responsibilities.
model, view, controller
The model, view, controller approach separates your application at a macro level into 3 sets of responsibilities.
The single-responsibility principle (SRP) is a computer-programming principle that states that every class in a computer program should have responsibility over a single part of that program's functionality, which it should encapsulate. All of that module, class or function's services should be narrowly aligned with that responsibility.
In object-oriented programming, the open–closed principle states "software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification"; that is, such an entity can allow its behaviour to be extended without modifying its source code.
Liskov substitution principle
The principle defines that objects of a superclass shall be replaceable with objects of its subclasses without breaking the application. That requires the objects of your subclasses to behave in the same way as the objects of your superclass.
Interface segregation principle
In the field of software engineering, the interface-segregation principle (ISP) states that no client should be forced to depend on methods it does not use.
ISP splits interfaces that are very large into smaller and more specific ones so that clients will only have to know about the methods that are of interest to them. Such shrunken interfaces are also called role interfaces. ISP is intended to keep a system decoupled and thus easier to refactor, change, and redeploy.
Dependency inversion principle
High-level modules should not depend on low-level modules. Both should depend on abstractions.
Abstractions should not depend on details. Details should depend on abstractions.
They dictate the UI and handle the user interaction to the smart phone screen.
Interface to global information about an application environment. This is an abstract class whose implementation is provided by the Android system. It allows access to application-specific resources and classes, as well as up-calls for application-level operations such as launching activities, broadcasting and receiving intents, etc.
They handle background processing associated with an application.
They handle communication between Android OS and applications.
They handle data and database management issues.
Represents a portion of user interface in an Activity.
UI elements that are drawn on-screen including buttons, lists forms etc.
View hierarchies that control screen format and appearance of the views.
tools: instead of android:
tools:listitem / tools:listheader / tools:listfooter
tools:minValue / tools:maxValue for numberPicker
Messages wiring components together.
specify which application will satisfy the intent, by supplying either the target app's package name or a fully-qualified component class name. You'll typically use an explicit intent to start a component in your own app, because you know the class name of the activity or service you want to start.
For example, you might start a new activity within your app in response to a user action, or start a service to download a file in the background.
do not name a specific component, but instead declare a general action to perform, which allows a component from another app to handle it.
For example, if you want to show the user a location on a map, you can use an implicit intent to request that another capable app show a specified location on a map
External elements, such as strings, constants and drawable pictures.
This class describes all device configuration information that can impact the resources the application retrieves. This includes both user-specified configuration options (locale list and scaling) as well as device configurations (such as input modes, screen size and screen orientation).
Configuration file for the application.
Google Play uses the <uses-feature> elements declared in your app manifest to filter your app from devices that do not meet its hardware and software feature requirements.
Beginning with Android 6.0 (API level 23), the user can approve or reject some app permisions at runtime. But no matter which Android version your app supports, you must declare all permission requests with a <uses-permission> element in the manifest. If the permission is granted, the app is able to use the protected features. If not, its attempts to access those features fail.
Your app can also define its own permissions. A new permission is declared with the <permission> element.
get current time
get current time in millis
parse milliseconds. by default it parses millis, not seccond
parse by individual parameters
DateTime( int year, int monthOfYear, int dayOfMonth, int hourOfDay, int minuteOfHour)
DateTime(2020, 3,14,14,32) .run(::println)
abstract class Random
get random number from Int.MAX_VALUE to INT.MIN_VALUE: