CamilleBC
11/16/2018, 1:05 PMfun init(application: Application) {//do stuff}
or is there a better way?Alan Evans
11/16/2018, 1:08 PMigor.wojda
11/16/2018, 1:11 PMclass MyApplication : Application() {
lateinit var context:Context
override fun onCreate() {
super.onCreate()
this.context = context
}
}
Now context is staticly available through MyApplication.context
However it would be wiser (from testing perspective) to inject this context into the object then accessing it directly using MyApplication.context
CamilleBC
11/16/2018, 1:11 PMAlan Evans
11/16/2018, 1:13 PMigor.wojda
11/16/2018, 1:15 PMCamilleBC
11/16/2018, 1:15 PMAlan Evans
11/16/2018, 1:15 PMCamilleBC
11/16/2018, 1:16 PMAlan Evans
11/16/2018, 1:22 PMthat object saves a picture obtained in retrofit GET to a fileSo, to write to a file in Android, you do not need Application context. Presumably you're using it to get the path to save to? You can either init your instance with the path, pass the path in during your method. You can also use dependency injection, but sounds like that would be yet another thing to learn at this point.
gildor
11/16/2018, 1:22 PMCamilleBC
11/16/2018, 1:23 PMAlan Evans
11/16/2018, 1:25 PMCamilleBC
11/16/2018, 1:27 PMjishindev
11/20/2018, 6:37 AMAlan Evans
11/20/2018, 4:52 PMvar context: Context
.
2. No one should.
3. You certainly don't need a library for it.
4. Using/having a library for it just normalizes this anti-pattern and hides lint warnings for you. Doesn't mean the issues lint was warning you about go away.
5. Instead of lint, using this library comes with tons of warnings about gotchers in JavaDoc. Why not just follow best practices and not bypass lint warnings that are trying to help you.
6. Rather than understand their problem, you're assisting with their attempted solution. See http://xyproblem.info/louiscad
11/20/2018, 6:46 PMval
, not a var
, and it is made so it can't leak memory.
2. This is not a var
, so irrelevant.
3. The purpose of a library is reuse, which is a key consideration in Kotlin BTW, so you can copy paste again and again, but it is pointless if you can make it a library and reuse it.
4. Lint is not a compiler. It highlights potential issues, so by definition, it can be wrong, and that's why you can suppress the warnings it generates.
5. The library is documented, and it is counted in words, not tons. Also, this is not Javadoc, but a README, and KDoc. Also, the library follows best practices, and talks about it in the doc (that you probably didn't read before saying it is "tons of Javadoc"). The lint, as I said, highlights potential errors, and the library is not bypassing lint but removing irrelevant warning, as there's already a mechanism to ensure `appCtx`is the application Context
by default and can never leak memory (which anyone's hand written var context: Context
would likely not do).
6. I don't understand the point given all of the above.Alan Evans
11/20/2018, 6:48 PMprivate var internalCtx: Context? = null
louiscad
11/20/2018, 6:58 PMApplication.onCreate()
. I have used this in production for years now. It never fails, and it saved my code from Context
parameter/property pollution for all the places where all I need is the application Context
.Alan Evans
11/20/2018, 7:03 PMlouiscad
11/21/2018, 7:24 AMappCtx
, it's not an "exchange". Don't take what lint says as absolute truth, you know what I said about it. BTW, lint isn't so safe as you can ignore its warnings easily, or even don't notice it. The injectAsAppCtx
function however throws if you pass a context that can leak memory, of course. This function is there for testing and configuration overriding contexts.
Having a need for this god Context
object everywhere in Android is bad API design, but it's been designed more than 10 years ago.
About accessing a path, I agree with you that it's better to make it an explicit dependency, and only then pass the actual value coming from the application Context, or another custom context (e.g. if you need direct boot support).gildor
11/21/2018, 8:03 AMHaving a need for this godWe abstract all API of Context that we use in our projects and just use DI to pass implementations like for resources, starting intents, opening dialogs etcobject everywhere in Android is bad API designContext