There are two different lifecycles because the Fragment itself lives longer than the Fragment’s view.
There are a number of events that can cause the Fragment’s view to be destroyed, but currently keep the Fragment itself alive:
Putting the Fragment on the back stack (i.e., when you navigate() to another Fragment)
Calling detach() on a Fragment
Calling setMaxLifecycle(Lifecycle.State.CREATED) on a Fragment
In these cases, the Fragment’s view is destroyed, moving the Fragment view lifecycle to DESTROYED. However, the lifecycle of Fragment itself is not destroyed – it generally stays as CREATED. This means that the Fragment can go through multiple cycles of onCreateView() -> onViewCreated() -> onDestroyView() while only going through onCreate() once.
Where this becomes a problem is when it comes to how LiveData works. When you observe a LiveData, LiveData automatically unregisters the observer when the lifecycle reaches DESTROYED. But if you use the Fragment’s lifecycle to observe in onCreateView(), etc., that registered observer will still exist after onDestroyView(), despite the view being destroyed. This means that the second time your Fragment goes through onCreateView(), you’ll actually create a second active Observer, with both running simultaneously. Then three Observers the next time and on and on.
By using the view LifecycleOwner in onCreateView()/onViewCreated(), you ensure that you’ll only have one active Observer running at a time and that Observers tied to previous view instances are correctly destroyed along with the view. Therefore, yes, you should always use getViewLifecycleOwner() as the LifecycleOwner when in onCreateView() or onViewCreated(), including when using Data Binding.
Of course, if you’re registering an Observer in onCreate(), then the view LifecycleOwner does not exist yet (it is created right before onCreateView()) and you don’t have the multiple registration problem, which is why the Lint check specifically does not apply to any registrations done at onCreate() time. In those cases, using the Fragment’s lifecycle itself is absolutely correct.
As per the Fragments: Past, Present, and Future talk, one future improvements for Fragments is going to be combining the two lifecycles together, always destroying the Fragment whenever the Fragment’s view is destroyed. This is not yet available in any shipped version of Fragments, alpha or otherwise.
class SharedViewModel : ViewModel() { val selected = MutableLiveData<Item>()
fun select(item: Item) { selected.value = item } }
class MasterFragment : Fragment() {
private lateinit var itemSelector: Selector
// Use the 'by activityViewModels()' Kotlin property delegate // from the fragment-ktx artifact private val model: SharedViewModel by activityViewModels()
override fun onViewCreated(view: View, savedInstanceState: Bundle?) { super.onViewCreated(view, savedInstanceState) itemSelector.setOnClickListener { item -> // Update the UI } } }
class DetailFragment : Fragment() {
// Use the 'by activityViewModels()' Kotlin property delegate // from the fragment-ktx artifact private val model: SharedViewModel by activityViewModels()
Here comes ViewModel to rescue us from handling a lot of scenario and implementing interface . We only need to create ViewModel class and create instance in fragment but using the activity scope so that it will be available for all the fragment of the activity including activity itself.
Create a ViewModel class
class SharedViewModel:ViewModel(){ val inputNumber = MutableLiveData<Int>() }
To emit or pass data from our input fragment create ViewModel in activity scope. To do this we have to pass the activity reference as argument of the ViewModelProvides.of() method. Noe just pass the data to ViewModel object like this
In the activity we just need to create instance of our ViewModel and observe the required data like this
val sharedViewModel = ViewModelProviders.of(this).get(SharedViewModel::class.java)
sharedViewModel.inputNumber.observe(this, Observer { it?.let { // do some thing with the number } })
Now what about output fragment? We can do same for the output fragment to observe the data. But keep in mind that we need create the ViewModel instance in activity scope, otherwise android will create a separate instance rather than sharing the same instance and we will not get the data.
For output fragment do it like this
activity?.let { val sharedViewModel = ViewModelProviders.of(it).get(SharedViewModel::class.java)
sharedViewModel.inputNumber.observe(this, Observer { it?.let { // do some thing with the number } }) }
Here comes ViewModel to rescue us from handling a lot of scenario and implementing interface . We only need to create ViewModel class and create instance in fragment but using the activity scope so that it will be available for all the fragment of the activity including activity itself.
Create a ViewModel class
class SharedViewModel:ViewModel(){ val inputNumber = MutableLiveData<Int>() }
To emit or pass data from our input fragment create ViewModel in activity scope. To do this we have to pass the activity reference as argument of the ViewModelProvides.of() method. Noe just pass the data to ViewModel object like this
In the activity we just need to create instance of our ViewModel and observe the required data like this
val sharedViewModel = ViewModelProviders.of(this).get(SharedViewModel::class.java)
sharedViewModel.inputNumber.observe(this, Observer { it?.let { // do some thing with the number } })
Now what about output fragment? We can do same for the output fragment to observe the data. But keep in mind that we need create the ViewModel instance in activity scope, otherwise android will create a separate instance rather than sharing the same instance and we will not get the data.
For output fragment do it like this
activity?.let { val sharedViewModel = ViewModelProviders.of(it).get(SharedViewModel::class.java)
sharedViewModel.inputNumber.observe(this, Observer { it?.let { // do some thing with the number } }) }
Enumerations in Kotlin are data types that hold a set of constants. Enums are defined by adding the modifier enum in front of a class as shown below. Yes, in Kotlin, Enums are classes.
enum class Months{
January,
February,
March
}
Here are some important points about enum classes in kotlin.
Each enum constant is an object. Enum constants are separated by commas.
Each of the enum constants acts as separate instances of the class.
Enums are useful in enhancing the readability of your code since it assigns pre-defined names to constants.
Unlike classes, an instance of enum classes cannot be created using constructors.
Hence, we can assert that enum classes are abstract.
Let’s see how the enum class is initialized in the main function of our class.
fun main(args: Array<String>) {
println(Months.January) //prints January
println(Months.values().size) //prints 3
println(Months.valueOf("March")) //prints March
for (enum in Months.values()) {
println(enum.name)
}
println(Months.valueOf("Mar")) //throws java.lang.IllegalArgumentException: No enum constant Months.Mar
}
Few inferences from the above code:
Let’s see how to tackle this scenario.
fun enumContains(name: String): Boolean {
return enumValues<Months>().any { it.name == name }
}
fun main(args: Array<String>) {
if (enumContains("")) {
println(Months.valueOf(""))
} else {
println("The string value does not match with any of the enum constants.") //this gets printed.
}
}
enumContains is a function that calls the lambda function any which iterates over the enum constants to check if any of them matches the string and returns a boolean.
Enum Properties
Every enum constant has properties: name, ordinal to retrieve the name and position of the constant.
fun main(args: Array<String>) {
println(Months.January.name) //prints January
println(Months.March.ordinal) // prints 2
for (enum in Months.values()) {
println(enum.name)
}
}
Enum toString()
We can override the toString() function in the enum class as shown below.
enum class Months {
January,
February,
March;
override fun toString(): String {
return super.toString().toUpperCase()
}
}
fun main(args: Array<String>) {
println(Months.January) //prints JANUARY
println(Months.January.name) //prints January
println(Months.valueOf("March")) //prints MARCH
}
Enums are classes. So besides defining the constants we can define other things as well that can be present in a class. To do so we need to first end the enum part with a semi colon. Note: Month.January invokes the toString() method of the class whereas Month.January.name directly prints the enum constant’s name.
Enum Initialisation
Enum constants can be initialized using primary constructors as shown below.
enum class Months(var shorthand: String) {
January("JAN"),
February("FEB"),
March("MAR");
}
fun main(args: Array<String>) {
var x = Months.January
println(x.shorthand) //prints JAN
x.shorthand = "Shorthand changed to J."
println(Months.January.shorthand) //prints Shorthand changed to J.
}
Enums as Anonymous classes
Enum constants can behave as anonymous classes be implementing their own functions along with overriding base functions from the class as shown below.
enum class Months(var shorthand: String) {
January("JAN"){
override fun printSomething() {
println("First month of the year.")
}
},
February("FEB"){
override fun printSomething() {
println("Second month of the year.")
}
},
March("MAR"){
override fun printSomething() {
println("Third month of the year.")
}
};
var a: String = "Hello, Kotlin Enums"
abstract fun printSomething()
}
fun main(args: Array<String>) {
Months.February.printSomething() //prints Second month of the year.
println(Months.February.a) //prints Hello, Kotlin Enums
}
Each of the enum constants must override
Enum inside an Enum
It’s possible to define another enum class in the current enum class as shown below.
enum class Months {
January,
February,
March;
enum class Day{
Monday,
Tuesday,
Wednesday
}
}
fun main(args: Array<String>) {
println(Months.Day.Tuesday) //prints Tuesday
}
Only an enum class can invoke another one. The inner class Day cannot be invoked from the enum constants.
Enums and when
when is Kotlin equivalent of switch in Java. We’ve covered the workings of it in the Control Flow tutorial. An example showing how when statements are used with enums is given below.
enum class Months {
January,
February,
March;
}
fun main(args: Array<String>) {
var m = Months.February
when (m) {
Months.January -> print("Matches with Jan")
Months.February -> print("Matches with Feb") //prints this.
Months.March -> print("Matches with Mar")
}
}
sealed class의 경우 parent constructor가 정의되어있지 않더라도 child class 는 constructor를 가질수 있다. 각 class 정의 사이에 구분자는 없다. (정의부분 뒤에 enum의 경우 , 가 붙는데 sealed class의 경우는 없다는 이야기)
sealed class BasicGarment2(){ class CLEAN_PRESS(var name:String, var price:BigDecimal): BasicGarment2() class CLEAN_ONLY(): BasicGarment2() }
enum class BasicGarment(val na: String, val price:BigDecimal){ CLEAN_PRESS("a",10.toBigDecimal()){ override fun calculatePrice(): BigDecimal { return 10.toBigDecimal() }
@Insert fun insertBothUsers(user1: User, user2: User)
@Insert fun insertUsersAndFriends(user: User, friends: List<User>) }
.
update
@Dao interface MyDao { @Update fun updateUsers(vararg users: User) }
.
delete
@Dao interface MyDao { @Delete fun deleteUsers(vararg users: User) }
.
query
@Dao interface MyDao { @Query("SELECT * FROM user") fun loadAllUsers(): Array<User> }
@Dao interface MyDao { @Query("SELECT * FROM user WHERE age > :minAge") fun loadAllUsersOlderThan(minAge: Int): Array<User> }
@Dao interface MyDao { @Query("SELECT * FROM user WHERE age BETWEEN :minAge AND :maxAge") fun loadAllUsersBetweenAges(minAge: Int, maxAge: Int): Array<User>
@Query("SELECT * FROM user WHERE first_name LIKE :search " + "OR last_name LIKE :search") fun findUserWithName(search: String): List<User> }
