I researched and learned about Context in my own way, so I will leave it in the article.
As a trigger When I was developing Android and passed Context as a method argument without thinking about anything, I received such a review from a lead engineer.
Be careful of overdose of Context. Before I knew it, I couldn't get out of it and eventually I couldn't touch it. If you add Context to the argument, you should be aware that you will lose and do not add Context to the argument.
So I wondered "What is Context?" And researched various things.
(Sentence) context, context, context, background, situation, environment
And so on
Excerpt from this site http://e-words.jp/w/%E3%82%B3%E3%83%B3%E3%83%86%E3%82%AD%E3%82%B9%E3%83%88.html
Even in the field of programming, the same code description and program elements may behave differently or be subject to different restrictions depending on their position in the program and the internal state when they are executed. It is sometimes called a context.
--Context is defined in an abstract class
--Activity superclass (Activity inherits Context class)
--Inheritance: Context
← ContextWrapper
← ContextThemeWrapper
← Activity
--Application superclass (Application inherits from Context class)
--Inheritance: Context
← ContextWrapper
← Application
By the way, getApplicationContext ()
is defined in ContextWrapper class
--When Dialog is generated
--When using Intent
--When accessing application resources (eg getString ()
)
And so on ... Anyway
--Depends on the activity life cycle. Therefore, when Activity is destroyed (such as when the screen is rotated), Context is also destroyed. --The instance doesn't seem to be a singleton.
Java
Activity: this
View, Fragment: getContext(), requireContext()
Kotlin
Activity: this
View, Fragment: context, requireContext()
--getContext ()
: Returns a nullable Context (treated as Context? In Kotlin) as a value
--requireContext ()
: Returns a non-null Context as a value
Reference material
--It is application related and does not depend on the activity life cycle. --It will not be destroyed or modified while the application is alive as a singleton.
Java: getApplicationContext()
Kotlin: applicationContext
In conclusion, it has become an abstract one, "** Implement after considering the life cycle and the risk of memory leaks **".
However, basically, it seems better to use ActivityContext
as much as possible in consideration of the risk of memory leak.
I referred to multiple articles, but there were various opinions.
--If the lifetime of the Context is longer than the lifetime of the receiving object: preferred implementation --If the life of the receiving object is longer than the life of the Context: There is a risk of memory leak
Until now, I used Context
appropriately without thinking about anything, but in this situation, "Which is better to use, ActivityContext
or ApplicationContext
?” I will implement it while thinking.
We will deepen our understanding in that.
If you have any mistakes or suggestions, please feel free to comment!
Finally, in conclusion, Context is difficult ... Thank you very much.
Recommended Posts