is there an elegant way to achieve something like this: ``` interface PreferenceAccessor { val f...

# android

[matt tighe]

is there an elegant way to achieve something like this:

interface PreferenceAccessor {
    val fileName: String
    val context: Context
    val prefs: SharedPreferences 
            get() = context.getSharedPreferences(fileName, Context.MODE_PRIVATE)
}

class PrefAccessorImpl(ctx: Context): PreferenceAccessor {
    override val fileName: String
        get() = "somePrefFileName"
    override val context: Context
        get() = ctx
}

What I’m looking for is a way to define a bunch of shared preference implementations with different file names, but save on the boilerplate of using context to initialize them. i’d also like to avoid having Context objects actually injected

[florent]

this doesn't seems to be an optimum way to use an interface as the interface assume that the implementation will be using sharedPreferences. Why not simply declare a method on a class that take String as a parameter and return the fileName?

[Eric Martori]

you can have extension functions that directly have the filename injected:
fun Context.namePreferences() = this.getSharedPreferences("name", Context.MODE_PRIVATE)

[Eric Martori]

this way you can have as many functions as you need to access the different shared preferences, with minimum boiler plate and without have to pass instances of Context around

[matt tighe]

i don’t hate the extension function idea, except for the fact that i rely pretty heavily on mockito for unit testing, so i’d need to inject preference objects still, since they can’t be mocked

[matt tighe]

what i’m really trying to achieve here is separation of responsibility for different aspects of the cache. so something like

class PrefAccessor1(ctx: Context) {
    private val cacheFileName1 = "1"
    private val prefs = ctx.getSharedPreferences(cacheFileName1, Context.MODE_PRIVATE)

    // Business logic specific to this section of the cache
}

class PrefAccessor2(ctx: Context) {
    private val cacheFileName1 = "2"
    private val prefs = ctx.getSharedPreferences(cacheFileName2, Context.MODE_PRIVATE)

    // Business logic specific to this section of the cache
}

[matt tighe]

but i’m looking for a way to codify that they all follow the same contract of
A: having different preference file names
B: all initialize the preferences the same way

[matt tighe]

all while not having references to Context in them, as they could be long-living

[Ianmedeiros]

do you inject with dagger or yourself?

[Ianmedeiros]

If it’s yourself, retain the ctx.applicationContext

[Ianmedeiros]

if it’s with dagger, you can receive Application instead of Context

[Ianmedeiros]

and provide Application in initialization

[Ianmedeiros]

But I am not sure that business logic should be in preferenceaccessor

[Ianmedeiros]

it’s better to inject the sharedpref in your business logic

[Al Warren]

So, somewhere you're going to need to use Context to retrieve preferences whether it's android preferences or from a file. Whether they're long-lived or not shouldn't matter because once you retrieve them they're just objects. They're not changing while android is away are they?

[Paulius Ruminas]

Your application must work when all cacheing is disabled so putting business logic into the cache would not be wise. If you want to unit test that logic that would be inside of the cache you would need android context which does not make sense.

[Eric Martori]

You should specify the implementation details in the interface. But you can have a base abstract implementation and let the final implementations fill in the blanks.

interface Cache {
    fun cache(item: Any) //this would depend on how you will use them, maybe use generics, etc
    fun getCached(key: Any) //this would depend on how you will use them, maybe use generics, etc
}

abstract class NamedPreferencesCache(name: String, ctx: Context) : Cache {
    protected val preferences = ctx.getSharedPreferences(name, Context.MODE_PRIVATE)
    //common caching logic
}

class FirstPreferencesCache(ctx: Context) : NamedPreferencesCache("first", ctx) {
    //specific caching logic
}

[Eric Martori]

Also, as some already said you should have business logic in the caches, only caching logic

[Eric Martori]

For the context part there is no way to avoid it unless you make a wrapper for retrieving preferences and inject that instead of the context. But then you have the dependency on the SharedPreferences.
In the end, to test the data layer completely you will have dependencies to one or the other because your code depends on them.

[matt tighe]

SharedPreference dependency isn’t bad for me because A: it’s easily mockable and B: it’s not a god object

[matt tighe]

your solution was pretty much exactly what i was looking for