` and `List`. So this will be very handy if you're using generic types on your
24 | app.
25 |
26 | But being immune to type erasure has a cost. We don't want to get into too deep details, but it relies
27 | on some Kodein machinery to wire up types that is known to be a bit slow. In my opinion you
28 | shouldn't worry too much about this fact unless your dependency graph is really complex, not like
29 | the average android apps out there.
30 |
31 | If still you find performance problems, it will probably be related to not using Kodein properly,
32 | and that's the rationale of this course. But anyways, you must know that there is also a Kodein jvm erased
33 | version which is more performant, but does suffer from type erasure. That means you will get into
34 | trouble and will need some tricky workarounds on your code to make it work from time to time.
35 |
36 | So I highly recommend you using the generic one.
37 |
38 | Apart from the jvm artifact, since we're doing Android we will need to add the Kodein Android
39 | artifact, and then we'll be good to go.
40 |
--------------------------------------------------------------------------------
/app/src/androidTest/java/me/jorgecastillo/kodein/recyclerview/RecyclerViewInteraction.java:
--------------------------------------------------------------------------------
1 | package me.jorgecastillo.kodein.recyclerview;
2 |
3 | import android.support.test.espresso.NoMatchingViewException;
4 | import android.view.View;
5 |
6 | import org.hamcrest.Matcher;
7 |
8 | import java.util.List;
9 |
10 | import static android.support.test.espresso.Espresso.onView;
11 | import static android.support.test.espresso.contrib.RecyclerViewActions.scrollToPosition;
12 |
13 | /**
14 | * Copyright 2016 Karumi
15 | *
16 | * Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except
17 | * in compliance with the License. You may obtain a copy of the License at
18 | * http://www.apache.org/licenses/LICENSE-2.0
19 | * Unless required by applicable law or agreed to in writing, software distributed under the License
20 | * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express
21 | * or implied. See the License for the specific language governing permissions and limitations under
22 | * the License.
23 | *
24 | * https://github.com/Karumi/KataSuperHeroesAndroid/blob/master/app/src/androidTest/java/com/karumi/katasuperheroes/recyclerview/RecyclerViewInteraction.java
25 | */
26 | public class RecyclerViewInteraction {
27 |
28 | private Matcher viewMatcher;
29 | private List items;
30 |
31 | private RecyclerViewInteraction(Matcher viewMatcher) {
32 | this.viewMatcher = viewMatcher;
33 | }
34 |
35 | public static RecyclerViewInteraction onRecyclerView(Matcher viewMatcher) {
36 | return new RecyclerViewInteraction<>(viewMatcher);
37 | }
38 |
39 | public RecyclerViewInteraction withItems(List items) {
40 | this.items = items;
41 | return this;
42 | }
43 |
44 | public RecyclerViewInteraction check(ItemViewAssertion itemViewAssertion) {
45 | for (int i = 0; i < items.size(); i++) {
46 | onView(viewMatcher)
47 | .perform(scrollToPosition(i))
48 | .check(new RecyclerItemViewAssertion<>(i, items.get(i), itemViewAssertion));
49 | }
50 | return this;
51 | }
52 |
53 | public interface ItemViewAssertion {
54 | void check(A item, View view, NoMatchingViewException e);
55 | }
56 | }
57 |
--------------------------------------------------------------------------------
/app/src/main/java/me/jorgecastillo/kodein/photoslist/view/PhotosAdapter.kt:
--------------------------------------------------------------------------------
1 | package me.jorgecastillo.kodein.photoslist.view
2 |
3 | import android.annotation.SuppressLint
4 | import android.support.v7.widget.RecyclerView
5 | import android.view.LayoutInflater
6 | import android.view.View
7 | import android.view.ViewGroup
8 | import kotlinx.android.synthetic.main.item_photo.view.*
9 | import me.jorgecastillo.kodein.R
10 | import me.jorgecastillo.kodein.common.domain.model.Photo
11 | import me.jorgecastillo.kodein.common.view.load
12 | import java.text.SimpleDateFormat
13 | import java.util.*
14 |
15 | class PhotosAdapter : RecyclerView.Adapter() {
16 |
17 | private val photos: MutableList = arrayListOf()
18 | var onItemClick: ((String) -> Unit)? = null
19 |
20 | fun addPics(photos: List): Unit {
21 | this.photos.clear()
22 | this.photos.addAll(photos)
23 | notifyDataSetChanged()
24 | }
25 |
26 | override fun onCreateViewHolder(parent: ViewGroup, pos: Int): ViewHolder {
27 | val view = LayoutInflater.from(parent.context)
28 | .inflate(R.layout.item_photo, parent, false)
29 | return ViewHolder(view, onItemClick)
30 | }
31 |
32 | override fun onBindViewHolder(holder: ViewHolder, pos: Int) {
33 | holder.bind(photos[pos])
34 | }
35 |
36 | override fun getItemCount() = photos.size
37 |
38 | class ViewHolder(view: View, private val onItemClick: ((String) -> Unit)?) : RecyclerView.ViewHolder(view) {
39 |
40 | @SuppressLint("SetTextI18n")
41 | fun bind(photo: Photo) {
42 | with(photo) {
43 | itemView.cell.setOnClickListener { onItemClick?.invoke(photo.id) }
44 | itemView.picture.load(photo.url)
45 | itemView.title.text = photo.author
46 | itemView.unsplashLink.text = itemView.resources.getString(R.string.unsplash)
47 |
48 | val date = SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ssZ", Locale.getDefault()).parse(photo.created_at)
49 | itemView.publishedAt.text = SimpleDateFormat("yyyy-MM-dd HH:mm", Locale.getDefault()).format(date)
50 | if (photo.description.isNullOrEmpty()) {
51 | itemView.hashtags.visibility = View.GONE
52 | } else {
53 | itemView.hashtags.visibility = View.VISIBLE
54 | itemView.hashtags.text = photo.description
55 | }
56 | }
57 | }
58 | }
59 | }
60 |
--------------------------------------------------------------------------------
/course/4/Script.md:
--------------------------------------------------------------------------------
1 | # 4: "Your first injection"
2 |
3 | (Inject a simple Logger on the application class using the app scope to show how it works
4 | (run the app).
5 |
6 | Once we have the application container ready, we can start thinking about injecting some
7 | dependencies. Dependencies that we will want to abstract away are the ones that are framework
8 | dependant, most likely.
9 |
10 | Let's say we wanna have a Logger in our app, so we can log stuff arbitrarily from different points in the architecture.
11 | Let's say we wanna use Logcat for it. All good, isn't it?
12 |
13 | Wrong. If I used the Logger directly from those classes, those would be strongly tied to the Android Logcat API,
14 | which is what we want to avoid.
15 |
16 | We need to abstract away the frameworks, since once we start writing tests we will need our code to be framework
17 | independent, so our tests can be easily isolated.
18 |
19 | (Show the code -> Logger interface)
20 |
21 | To abstract away the Logger, we will create an interface that just declares the login actions
22 | available without any wiring to the Logcat API, like the one I got here. For a better API, I'm
23 | declaring the different Log levels using a `sealed class`
24 |
25 | Then, we will create an implementation for it that will be tied to the Android Logcat. On this point it's safe to depend
26 | on a framework, since this class represents implementation details for the logger, so it will be injected. The rest of
27 | the app is never going to depend on it but on the abstraction.
28 |
29 | Once we have the interface and the implementation, we need to tell Kodein that each time a Logger interface is
30 | requested, it should provide an AndroidLogger implementation. To do that, we need to create a binding for linking both
31 | types.
32 |
33 | (Write the binding `bind() with singleton { AndroidLogger() }`)
34 |
35 | Since the Logger is prone to be used across all app execution, it seems reasonable to provide it at the application
36 | scope. That's why we're declaring the binding into the appModule, which is imported on the application Kodein container.
37 |
38 | So we can finally inject our logger anywhere, like here for example, by delegating a property with the Logger type on
39 | the Kodein instance() method. And we'll be ready to use it. (inject it on the application class for the record)
40 |
41 | Note that we always depend on the interface here and not directly the implementation details. That's key to keep our
42 | code agnostic from frameworks.
43 |
--------------------------------------------------------------------------------
/gradlew.bat:
--------------------------------------------------------------------------------
1 | @if "%DEBUG%" == "" @echo off
2 | @rem ##########################################################################
3 | @rem
4 | @rem Gradle startup script for Windows
5 | @rem
6 | @rem ##########################################################################
7 |
8 | @rem Set local scope for the variables with windows NT shell
9 | if "%OS%"=="Windows_NT" setlocal
10 |
11 | set DIRNAME=%~dp0
12 | if "%DIRNAME%" == "" set DIRNAME=.
13 | set APP_BASE_NAME=%~n0
14 | set APP_HOME=%DIRNAME%
15 |
16 | @rem Add default JVM options here. You can also use JAVA_OPTS and GRADLE_OPTS to pass JVM options to this script.
17 | set DEFAULT_JVM_OPTS=
18 |
19 | @rem Find java.exe
20 | if defined JAVA_HOME goto findJavaFromJavaHome
21 |
22 | set JAVA_EXE=java.exe
23 | %JAVA_EXE% -version >NUL 2>&1
24 | if "%ERRORLEVEL%" == "0" goto init
25 |
26 | echo.
27 | echo ERROR: JAVA_HOME is not set and no 'java' command could be found in your PATH.
28 | echo.
29 | echo Please set the JAVA_HOME variable in your environment to match the
30 | echo location of your Java installation.
31 |
32 | goto fail
33 |
34 | :findJavaFromJavaHome
35 | set JAVA_HOME=%JAVA_HOME:"=%
36 | set JAVA_EXE=%JAVA_HOME%/bin/java.exe
37 |
38 | if exist "%JAVA_EXE%" goto init
39 |
40 | echo.
41 | echo ERROR: JAVA_HOME is set to an invalid directory: %JAVA_HOME%
42 | echo.
43 | echo Please set the JAVA_HOME variable in your environment to match the
44 | echo location of your Java installation.
45 |
46 | goto fail
47 |
48 | :init
49 | @rem Get command-line arguments, handling Windows variants
50 |
51 | if not "%OS%" == "Windows_NT" goto win9xME_args
52 |
53 | :win9xME_args
54 | @rem Slurp the command line arguments.
55 | set CMD_LINE_ARGS=
56 | set _SKIP=2
57 |
58 | :win9xME_args_slurp
59 | if "x%~1" == "x" goto execute
60 |
61 | set CMD_LINE_ARGS=%*
62 |
63 | :execute
64 | @rem Setup the command line
65 |
66 | set CLASSPATH=%APP_HOME%\gradle\wrapper\gradle-wrapper.jar
67 |
68 | @rem Execute Gradle
69 | "%JAVA_EXE%" %DEFAULT_JVM_OPTS% %JAVA_OPTS% %GRADLE_OPTS% "-Dorg.gradle.appname=%APP_BASE_NAME%" -classpath "%CLASSPATH%" org.gradle.wrapper.GradleWrapperMain %CMD_LINE_ARGS%
70 |
71 | :end
72 | @rem End local scope for the variables with windows NT shell
73 | if "%ERRORLEVEL%"=="0" goto mainEnd
74 |
75 | :fail
76 | rem Set variable GRADLE_EXIT_CONSOLE if you need the _script_ return code instead of
77 | rem the _cmd.exe /c_ return code!
78 | if not "" == "%GRADLE_EXIT_CONSOLE%" exit 1
79 | exit /b 1
80 |
81 | :mainEnd
82 | if "%OS%"=="Windows_NT" endlocal
83 |
84 | :omega
85 |
--------------------------------------------------------------------------------
/course/15/Script.md:
--------------------------------------------------------------------------------
1 | # 15: "Injecting Custom Views"
2 |
3 | We've learned how to inject applications, activities, and also fragments. But we are still forgetting about another very
4 | important piece of any app: The Custom Views.
5 |
6 | If we have a new look to our graph, we could include custom views on it. Custom View Scope is also part the outermost
7 | circle, along with the fragment one. Both scopes extend the activity one. So, even if you place your custom view into a
8 | fragment, the closestKodein function will return the enclosing activity scope, completely ignoring the fragment one.
9 | You must remember this.
10 |
11 | Custom Views injection is usually resolved using their enclosing Activity or Fragment Scope, and that's completely
12 | legit. But that usually happens because the dependency injection frameworks do not provide an easy enough way to
13 | retrieve the closest scope. But Kodein does with the really smart closestKodein() function.
14 |
15 | Views also use to be quite simple and dumb in terms of logics, so that's another good reason why injecting dependencies
16 | on them is not that usual. But it's still needed from time to time.
17 |
18 | So, if you need to code a complex custom view which requires to get its own dependencies injected, you could easily
19 | create a scope for it.
20 |
21 | As you probably already imagine, creating a custom view scope is exactly equal to what we've already done for the
22 | fragment or the activity scopes.
23 |
24 | Let's say we have a custom view like this one, which is just a dumb textview extension that I'll use as an example. I
25 | have replaced the DescriptionFragment textview with this custom version of it. I can request the closestKodein() here
26 | also, but as I said before, it will return the enclosing activity scope, ignoring the fragment one.
27 |
28 | Now, I just need to extend the KodeinAware interface one more time, and then override the Kodein module property to
29 | provide the bindings required for this scope. Let's just provide the logger here by overriding the one declared in the
30 | application class. Of course this doesn't make a lot of sense, but it's just in purpose of showing how you can inject
31 | dependencies at this level.
32 |
33 | Once we have it provided, we just need to retrieve it using the instance Kodein function as we have already done for any
34 | injected dependencies at any scope until now.
35 |
36 | By using this technique, you will not need to manually inject the custom views when you create your enclosing scopes
37 | like the activity or the fragment one. The custom views will be able to be auto injected, the same way fragments and
38 | activities are.
39 |
--------------------------------------------------------------------------------
/course/10/Script.md:
--------------------------------------------------------------------------------
1 | # 10: "Tagged injections"
2 |
3 | We have learned that bindings are used to link a type and an instance provided for that given type. We have also
4 | learned that instance() can be used as a way to link nested bindings.
5 |
6 | But what happens when there are two bindings for the same type? Let's say you need two different runtime implementations
7 | for the same type provided on the same scope, like two different OkHttp Interceptors for the OkHttpClient.
8 |
9 | You'll get a runtime crash telling you that there's already an existing binding for that given type. Kodein does not
10 | allow multiple bindings for the same type by default, since then it wouldn't be able to know which one to apply.
11 |
12 | So what can we do for these cases? You can use tagged bindings for resolving the ambiguity. This concept is equivalent
13 | to the concept of provider qualified names used in other frameworks like Dagger.
14 |
15 | Let's dig a bit more on this concept with some code.
16 |
17 | (Switch to code -> HttpClient.kt)
18 |
19 | We got this function that builds up an OkHttpClient. Let's say we also have these two interceptors. One will log all the
20 | http requests including parameters, headers, bodies, anything relevant. The other one will apend some headers to every
21 | request.
22 |
23 | Let's say we wanna inject these two on the OkHttpClient. (Switch to HttpClient.kt) First, since my client is provided by
24 | a function, I'll add a couple of interceptors as arguments. First one will be the headers interceptor, and second one
25 | will be the logging one.
26 | The headers one will be appended without any conditions. The Logging one will be appended to the client just for the
27 | Debug variant, since we don't want our logs to be enabled in production.
28 |
29 | But we still need to bind both interceptors in the application scope, where our OkHttpClient is being provided. We could
30 | add an instance() call to fulfill each one of them, but then we'll get a runtime error because of the ambiguity. To
31 | solve that, we can just add a tag name on them.
32 |
33 | Let's name them differently, like "headers" and "logging", for example.
34 |
35 | (add the tags here `httpClient(instance(tag = "headers"), instance(tag = "logging"))`)
36 |
37 | Now, we will need a couple of interceptor bindings qualified with the very same tags, like these two.
38 |
39 | That means that each time an interceptor is requested it'll check the tag value, and if there's a binding available for
40 | the Interceptor type with the same tag, it will use it to provide the dependency.
41 |
42 | And our problem is solved!
43 |
44 | As you can see, our app is running as expected, and looking neat. (Run the app).
45 |
--------------------------------------------------------------------------------
/course/14/Script.md:
--------------------------------------------------------------------------------
1 | # 14: "Injecting Fragments"
2 |
3 | If we look one more time to our scopes graph, we'll find out that fragments scope is always in the outermost circle.
4 | That means it will extend the activity one, which will extend the application one transitively. That means the fragment
5 | scope is going to be the richest one, since it will have visibility on the bindings defined in the other two scopes.
6 |
7 | Let's add a fragment to our app. We will add a very simple one just for showcasing how we can implement a fragment
8 | Kodein scope. For didactic purposes, we are going to replace the description TextView on the DetailActivity with a
9 | fragment which will just render the description by itself.
10 |
11 | Here you have the DescriptionFragment. As you can see, it's very simple. In order to provide a Kodein container for it
12 | we will need to extend the KodeinAware interface one more time. That will simplify things a bit. Afterwards, we will
13 | need to override the kodein property and provide with it a Kodein container for this fragment.
14 |
15 | Note that this is the same thing we did for the Activity scope in the InjectedActivity. Here, we will provide the fragment
16 | scope dependencies, which will be the ones that we do not need to live longer than the Fragment's lifecycle, so whenever
17 | the fragment gets destroyed, those dependencies can be released by the garbage collector.
18 |
19 | And now, we need to use the Kodein magic just a bit. The same way we did for the activity scope, we need to use the
20 | closestKodein() function here to automatically retrieve the activity scope Kodein container. Kodein is smart enough to
21 | find it. If there wasn't an activity scope defined for the enclosing activity, it would automatically return the
22 | application scope to ensure integrity on inheritance.
23 |
24 | Now, our fragment scope would be ready to extend the activity one, the same way we extended the application one from
25 | the activity scope on previous lessons. So we got our new onion layer in place.
26 |
27 | Let's add a very basic presenter like this one. This presenter will get the description by constructor and just render
28 | it when the fragment is resumed.
29 |
30 | Now, let's add a Kodein Module to the DescriptionFragment's scope. We will provide the presenter here using a simple
31 | binding. Since the presenter requires the description to be passed in, we will also request it as an argument of the
32 | module constructor function. Now, on our fragment, we can just import the module and pass in the argument retrieved
33 | from the extras.
34 |
35 | Finally, we will be able to inject our presenter using the fragment scope the same way we've done for other
36 | presenters before.
37 |
--------------------------------------------------------------------------------
/app/src/main/java/me/jorgecastillo/kodein/photoslist/view/PhotoListActivity.kt:
--------------------------------------------------------------------------------
1 | package me.jorgecastillo.kodein.photoslist.view
2 |
3 | import android.os.Bundle
4 | import android.support.design.widget.Snackbar
5 | import android.support.v7.widget.LinearLayoutManager
6 | import android.view.Menu
7 | import android.view.MenuItem
8 | import android.view.View
9 | import kotlinx.android.synthetic.main.activity_photo_list.*
10 | import me.jorgecastillo.kodein.common.di.InjectedActivity
11 | import me.jorgecastillo.kodein.common.domain.model.Photo
12 | import me.jorgecastillo.kodein.photoslist.di.photoListActivityModule
13 | import me.jorgecastillo.kodein.photoslist.presenter.PhotoListPresenter
14 | import me.jorgecastillo.kodein.R
15 | import org.kodein.di.Kodein
16 | import org.kodein.di.generic.instance
17 |
18 | class PhotoListActivity : InjectedActivity(), PhotoListPresenter.View {
19 |
20 | private val presenter by instance()
21 | private val adapter = PhotosAdapter()
22 |
23 | override fun activityModule() = Kodein.Module("photoListActivityModule") {
24 | import(photoListActivityModule())
25 | }
26 |
27 | override fun onCreate(savedInstanceState: Bundle?) {
28 | super.onCreate(savedInstanceState)
29 | setContentView(R.layout.activity_photo_list)
30 | setSupportActionBar(toolbar)
31 | setupPhotosList()
32 | }
33 |
34 | override fun onResume() {
35 | super.onResume()
36 | presenter.resume(this)
37 | }
38 |
39 | override fun onPause() {
40 | super.onPause()
41 | presenter.pause()
42 | }
43 |
44 | override fun onCreateOptionsMenu(menu: Menu): Boolean {
45 | menuInflater.inflate(R.menu.menu_photo_list, menu)
46 | return true
47 | }
48 |
49 | override fun onOptionsItemSelected(item: MenuItem): Boolean = when (item.itemId) {
50 | R.id.action_settings -> true
51 | else -> super.onOptionsItemSelected(item)
52 | }
53 |
54 | private fun setupPhotosList() {
55 | photoList.setHasFixedSize(true)
56 | val layoutManager = LinearLayoutManager(this)
57 | photoList.layoutManager = layoutManager
58 | photoList.adapter = adapter
59 | adapter.onItemClick = ::onItemClick
60 | }
61 |
62 | private fun onItemClick(id: String): Unit {
63 | presenter.onPhotoClick(id)
64 | }
65 |
66 | override fun showLoading() {
67 | loading.visibility = View.VISIBLE
68 | }
69 |
70 | override fun hideLoading() {
71 | loading.visibility = View.GONE
72 | }
73 |
74 | override fun renderPhotos(photos: List) {
75 | adapter.addPics(photos)
76 | }
77 |
78 | override fun displayLoadingPhotosError() {
79 | Snackbar.make(toolbar, R.string.loading_photos_error, Snackbar.LENGTH_SHORT).show()
80 | }
81 | }
82 |
--------------------------------------------------------------------------------
/course/11/Script.md:
--------------------------------------------------------------------------------
1 | # 11: "Constant Injection"
2 |
3 | Up to now, we have been requesting our photos from a network service. Since we don't want to load the photos from
4 | network every single time, we are adding a cache. I've defined this contract for abstracting away the implementation
5 | details of the data source (show PhotosLocalDataSource).
6 |
7 | On it, I have a couple of GET methods for retrieving the complete list of photos or a single one, and there's also a
8 | couple of saving methods to save a complete list or a single one. For the sake of simplicity, I've implemented this contract
9 | using a simple in memory cache like this one.
10 |
11 | (Show InMemoryPhotosDataSource)
12 |
13 | This in-memory implementation uses a simple List to store the items in memory. It also receives a TTL by
14 | constructor, which is the "time to live" we will give to any of the stored photos. That means if a photo has been stored
15 | for longer it will automatically become invalid.
16 |
17 | If you look carefully to the List of items, you will notice that the item stored is not a Photo but something called a
18 | PersistedPhoto. This is going to be a decorator over a Photo that also includes a timestamp in milliseconds reflecting
19 | when the photo was stored.
20 |
21 | Since we know when each photo was stored and also how long is it allowed to be valid, we can consider the whole list
22 | invalid if we find any invalid photo inside of it. In that case, we can just clear the list to remove the photos from
23 | the cache, and then return an error.
24 |
25 | In case we're requesting a single photo, if it turns out to be invalid, we can do the same. Remove it from the list and
26 | return an error.
27 |
28 | Now, we would expect the TTL number to be injected. To do that, we can go to the app module, where we are defining our
29 | application scoped dependencies, and add a tagged instance (instance(tag = "TTL")) when we bind the local data source.
30 |
31 | Now, we can provide the value with another binding, but this time we will actually not use a binding for it, but a
32 | constant. Do not forget to tag the constant binding with the corresponding tag. Constant bindings are always tagged.
33 |
34 | Note that it doesn't use a provider function block, but a constant value straight away. That means the value will be
35 | computed as soon as the Kodein module gets instantiated.
36 |
37 | Of course this can be a too simple example, since we could have directly passed in the constant value to the data
38 | source binding instead of nesting a constant binding. But note that you could also use this feature to inject more
39 | complex constants, which can actually be simple classes.
40 |
41 | Still it's recommended to only use constant bindings for very simple types without inheritance or implementing an
42 | interface. Good choices could be primitive types or data classes that do not need to vary.
43 |
--------------------------------------------------------------------------------
/app/src/main/java/me/jorgecastillo/kodein/common/data/local/InMemoryPhotosDataSource.kt:
--------------------------------------------------------------------------------
1 | package me.jorgecastillo.kodein.common.data.local
2 |
3 | import arrow.core.Either
4 | import arrow.core.left
5 | import arrow.core.right
6 | import me.jorgecastillo.kodein.common.data.network.PhotosNotFound
7 | import me.jorgecastillo.kodein.common.domain.error.Error
8 | import me.jorgecastillo.kodein.common.domain.model.Photo
9 | import me.jorgecastillo.kodein.common.domain.repository.PhotosLocalDataSource
10 |
11 | /**
12 | * This is an in-memory implementation of the photos data source, mostly for simplicity of the example. It could
13 | * potentially be a persistence implementation. It gets a TTL constant injected that determines the Time to Live for
14 | * photos, so photos stored for a longer than the TTL become automatically invalid and removed.
15 | *
16 | * For sake of simplicity the list of photos becomes invalid when any photo inside of it is invalid.
17 | */
18 | class InMemoryPhotosDataSource(private val ttlMillis: Long) : PhotosLocalDataSource {
19 |
20 | private var photos: List = emptyList()
21 |
22 | override fun getAll(): Either> = when {
23 | photos.isEmpty() -> PhotosNotFound().left()
24 | photos.any { it.isInvalid(ttlMillis) } -> PhotosNotFound().left().also { photos = emptyList(); }
25 | else -> photos.map { it.photo }.right()
26 | }
27 |
28 | override fun getPhoto(photoId: String): Either {
29 | val persistedPhoto = photos.find { it.photo.id == photoId }
30 | return when {
31 | persistedPhoto == null -> PhotosNotFound().left()
32 | persistedPhoto.isInvalid(ttlMillis) -> PhotosNotFound().left().also { photos -= persistedPhoto }
33 | else -> persistedPhoto.photo.right()
34 | }
35 | }
36 |
37 | override fun save(photos: List) {
38 | val persistedPhotosToSave = photos.map { PersistedPhoto(System.currentTimeMillis(), it) }
39 |
40 | val photosNotPersistedYet = persistedPhotosToSave - this.photos
41 | val photosAlreadyPersisted = (persistedPhotosToSave intersect this.photos).map {
42 | it.copy(storedTimeMillis = System.currentTimeMillis())
43 | }
44 |
45 | this.photos = photosNotPersistedYet + photosAlreadyPersisted
46 | }
47 |
48 | override fun save(photo: Photo) {
49 | val persistedPhoto = PersistedPhoto(System.currentTimeMillis(), photo)
50 |
51 | this.photos = if (photos.contains(persistedPhoto)) {
52 | photos - persistedPhoto + persistedPhoto
53 | } else
54 | photos + persistedPhoto
55 | }
56 | }
57 |
58 | data class PersistedPhoto(
59 | val storedTimeMillis: Long,
60 | val photo: Photo
61 | ) {
62 | override fun equals(other: Any?): Boolean =
63 | other is PersistedPhoto && photo == other.photo
64 |
65 | override fun hashCode(): Int {
66 | var result = storedTimeMillis.hashCode()
67 | result = 31 * result + photo.hashCode()
68 | return result
69 | }
70 | }
71 |
72 | fun PersistedPhoto.isInvalid(ttlMillis: Long) = System.currentTimeMillis() - storedTimeMillis >= ttlMillis
73 |
--------------------------------------------------------------------------------
/course/7/Script.md:
--------------------------------------------------------------------------------
1 | # 7: "Injecting dependencies on the Activity Scope"
2 |
3 | We are going to inject our first dependency using the activity scope. That means we will need to add our first activity,
4 | like the one we got here. I've coded this PhotoListActivity, which is going to display a list of fancy photos from
5 | interesting authors. There's nothing very interesting to note about how it's done, other than a simple layout with the
6 | list and a toolbar with its own menu. But if you're curious just take a look at the same repository we're you'll find
7 | all the code.
8 |
9 | One key thing to note is that the activity inherits from InjectedActivity. All our activities will need to do so, in
10 | order to inherit the activity scope Kodein instance.
11 |
12 | We are going to inject a specific dependency just needed by this activity, so we will start by overriding the delegate
13 | function activityModule() that we created for it. We will provide our specific bindings on it.
14 |
15 | Let's create and import a photoListActivityModule for that.
16 |
17 | Now we are going to create a presenter so we can inject it. Presenters wrap UI logic for the views, which are the
18 | activities, fragments or custom views. We don't want to dive deeper on how they're encoded since this is not an MVP
19 | course, but note that we will want them to be injected so we can replace them later on easily on tests. Again, please
20 | feel free to have look to the implementation in the repository if you need it.
21 |
22 | (Show BasePresenter)
23 |
24 | Our presenters will inherit from this BasePresenter that I've created to enclose convenience methods that all presenters
25 | will need to implement. One example is the logics to link and unlink the view implementation depending on the lifecycle.
26 |
27 | Now, I'm creating a PhotoListPresenter that will extend from it, and provide it's own view contract.
28 |
29 | Whenever the view resumes it's life, the presenter is linked to do the same, and we will use that time to load our
30 | photos. Whenever photos are loaded, presenter will tell the view to render them.
31 |
32 | And there's still something missing. The view requires an instance of the presenter to work with it, so we're
33 | injecting it. (add private val presenter by instance()). This is the way we will retrieve the
34 | instance, but we also need to bind it on the module we created for it. (write the binding on the module).
35 |
36 | Whenever we launch this activity, we will get it injected and we'll be ready to use it. As you can see, we can already
37 | link the activity onResume and onPause callbacks to the presenter so it links and unlinks the view depending on the
38 | lifecycle.
39 |
40 | Since the presenter is provided on the activity scope and just referenced by it, whenever this activity gets destroyed
41 | it will be able to get collected by garbage collector, and therefore the presenter will also be.
42 |
43 | By adding the bindings on this scope, we're providing it on this given activity scope and not for other activities,
44 | neither the application scope.
45 |
46 | And with this, we've got our activity scope ready and depending on the application one, and also being able to provide
47 | specific bindings per activity. That means we're ready to move on to next lesson!
48 |
--------------------------------------------------------------------------------
/app/src/main/java/me/jorgecastillo/kodein/common/di/AppModules.kt:
--------------------------------------------------------------------------------
1 | package me.jorgecastillo.kodein.common.di
2 |
3 | import android.content.Context
4 | import me.jorgecastillo.kodein.common.data.local.InMemoryPhotosDataSource
5 | import me.jorgecastillo.kodein.common.data.network.UnsplashPhotosDataSource
6 | import me.jorgecastillo.kodein.common.data.network.UnsplashService
7 | import me.jorgecastillo.kodein.common.data.network.http.HeadersInterceptor
8 | import me.jorgecastillo.kodein.common.data.network.http.httpClient
9 | import me.jorgecastillo.kodein.common.data.network.http.loggingInterceptor
10 | import me.jorgecastillo.kodein.common.domain.interactor.Invoker
11 | import me.jorgecastillo.kodein.common.domain.interactor.UseCaseInvoker
12 | import me.jorgecastillo.kodein.common.domain.repository.PhotosLocalDataSource
13 | import me.jorgecastillo.kodein.common.domain.repository.PhotosNetworkDataSource
14 | import me.jorgecastillo.kodein.common.log.AndroidLogger
15 | import me.jorgecastillo.kodein.common.log.Logger
16 | import me.jorgecastillo.kodein.common.router.Navigator
17 | import me.jorgecastillo.kodein.common.router.PhotoAppNavigator
18 | import me.jorgecastillo.kodein.photoslist.domain.repository.PhotosRepository
19 | import okhttp3.Interceptor
20 | import okhttp3.OkHttpClient
21 | import org.kodein.di.Kodein
22 | import org.kodein.di.generic.bind
23 | import org.kodein.di.generic.instance
24 | import org.kodein.di.generic.provider
25 | import org.kodein.di.generic.singleton
26 | import org.kodein.di.generic.with
27 | import retrofit2.Retrofit
28 | import retrofit2.converter.moshi.MoshiConverterFactory
29 | import java.util.concurrent.TimeUnit
30 |
31 | /**
32 | * Application scoped dependencies. Dependencies that we would need to reuse at any point in the
33 | * application lifecycle like singletons will be binded here.
34 | *
35 | * It brings into scope bindings defined in other app scoped modules for better modularity.
36 | */
37 | fun appModule(appContext: Context) = Kodein.Module("appModule") {
38 | bind() with provider { appContext }
39 | bind() with provider { PhotoAppNavigator(instance()) }
40 | bind() with singleton { AndroidLogger() }
41 | bind() with singleton { UseCaseInvoker() }
42 |
43 | import(httpAppModule())
44 | import(photosAppModule())
45 | }
46 |
47 | fun httpAppModule() = Kodein.Module("httpModule") {
48 | bind(tag = "headers") with singleton { HeadersInterceptor() }
49 | bind(tag = "logging") with singleton { loggingInterceptor() }
50 | bind() with singleton {
51 | httpClient(instance(tag = "headers"), instance(tag = "logging"))
52 | }
53 | }
54 |
55 | fun photosAppModule() = Kodein.Module("photoAppModule") {
56 | bind() with singleton {
57 | Retrofit.Builder()
58 | .baseUrl("https://api.unsplash.com")
59 | .client(instance())
60 | .addConverterFactory(MoshiConverterFactory.create())
61 | .build()
62 | .create(UnsplashService::class.java)
63 | }
64 |
65 | constant(tag = "ttl") with TimeUnit.HOURS.toMillis(1)
66 |
67 | bind() with singleton { InMemoryPhotosDataSource(instance(tag = "ttl")) }
68 | bind() with singleton { UnsplashPhotosDataSource(instance()) }
69 | bind() with singleton { PhotosRepository(instance(), instance()) }
70 | }
71 |
--------------------------------------------------------------------------------
/app/src/androidTest/java/me/jorgecastillo/kodein/PhotoListActivityShould.kt:
--------------------------------------------------------------------------------
1 | package me.jorgecastillo.kodein
2 |
3 | import android.app.Activity
4 | import android.support.test.espresso.Espresso.onView
5 | import android.support.test.espresso.assertion.ViewAssertions.matches
6 | import android.support.test.espresso.intent.rule.IntentsTestRule
7 | import android.support.test.espresso.matcher.ViewMatchers.*
8 | import arrow.core.left
9 | import arrow.core.right
10 | import com.nhaarman.mockito_kotlin.whenever
11 | import me.jorgecastillo.kodein.common.data.network.PhotosNotFound
12 | import me.jorgecastillo.kodein.common.domain.interactor.Invoker
13 | import me.jorgecastillo.kodein.common.domain.model.Photo
14 | import me.jorgecastillo.kodein.photoslist.domain.interactor.GetPhotos
15 | import me.jorgecastillo.kodein.photoslist.view.PhotoListActivity
16 | import me.jorgecastillo.kodein.recyclerview.RecyclerViewInteraction
17 | import org.junit.Rule
18 | import org.junit.Test
19 | import org.junit.runner.RunWith
20 | import org.kodein.di.generic.bind
21 | import org.kodein.di.generic.provider
22 | import org.kodein.di.generic.singleton
23 | import org.mockito.Mock
24 | import org.mockito.junit.MockitoJUnitRunner
25 |
26 | /**
27 | * UI tests for the list activity mocking out the domain layer (Use Cases) and any further pieces
28 | * beyond it.
29 | *
30 | * To mock use cases we use Kodein overrides on the application scope, so we override production
31 | * bindings with bindings providing mocks.
32 | */
33 | @RunWith(MockitoJUnitRunner::class)
34 | class PhotoListActivityShould {
35 |
36 | @Mock
37 | private lateinit var getPhotos: GetPhotos
38 |
39 | @Rule
40 | @JvmField
41 | var activityRule: IntentsTestRule =
42 | IntentsTestRule(PhotoListActivity::class.java, true, false)
43 |
44 | @Rule
45 | @JvmField
46 | val overridesRule: OverridesRule = OverridesRule {
47 | bind(overrides = true) with singleton { BlockingUseCaseInvoker() }
48 | bind(overrides = true) with provider { getPhotos }
49 | }
50 |
51 | @Test
52 | fun showPhotosOnSuccessfulLoading() {
53 | givenSuccessfulPhotosLoading(anyPhotos)
54 |
55 | activityRule.launch()
56 |
57 | RecyclerViewInteraction.onRecyclerView(withId(R.id.photoList))
58 | .withItems(anyPhotos)
59 | .check { photo, view, e ->
60 | matches(hasDescendant(withText("AuthorName${photo.id}"))).check(view, e)
61 | }
62 | }
63 |
64 | @Test
65 | fun showFeedbackWhenErrorLoadingPhotos() {
66 | givenErrorLoadingPhotos()
67 |
68 | activityRule.launch()
69 |
70 | onView(withText("Something went wrong when loading images.")).check(matches(isDisplayed()))
71 | }
72 |
73 | private fun givenSuccessfulPhotosLoading(photos: List) {
74 | whenever(getPhotos.run(anyGetPhotosParams)).thenReturn(photos.right())
75 | }
76 |
77 | private fun givenErrorLoadingPhotos() {
78 | whenever(getPhotos.run(anyGetPhotosParams)).thenReturn(PhotosNotFound().left())
79 | }
80 |
81 | companion object {
82 | val anyGetPhotosParams = GetPhotos.Params(1, "landscape")
83 | val anyPhotos: List = (1..3).map {
84 | Photo(it.toString(),
85 | "http:url/$it",
86 | "AuthorName$it",
87 | "Description$it",
88 | "2018-06-16T08:52:46-0500")
89 | }
90 | }
91 | }
92 |
93 | fun IntentsTestRule.launch(): T {
94 | return launchActivity(null)
95 | }
96 |
--------------------------------------------------------------------------------
/course/6/Script.md:
--------------------------------------------------------------------------------
1 | # 6: "Scoped Injection: Activity Scope"
2 |
3 | Scopes define the lifecycle of our dependencies, or in other words, when they're instantiated and when they can be
4 | released by garbage collector.
5 |
6 | We'll want to have at least 2 different scopes. One for the application class, and another one for our activities. But
7 | you can have many more, like another one for fragments, for example.
8 |
9 | When we define a dependency in the application scope, it means it will be able to be provided from anywhere in the app.
10 | So it will not released by garbage collector until the app Kodein instance is released, which will happen just if you
11 | kill the app.
12 | In the other hand, when we define a dependency on the activity scope, just the activity Kodein instance will be able to
13 | provide it. That implies it will be able to be released by garbage collector if the activity holding it is released.
14 |
15 | The scopes have an inheritance hierarchy, so it's like an onion.
16 | * The application scope would be the inner one, and provides all the application wide dependencies, like the Logger.
17 | * The activity scope extends the application one, since it needs to be able to provide all the application dependencies
18 | to complete the dependency graph, but it also adds the activity dependencies on top.
19 | Activity dependencies are the ones that can just live under the lifecycle of an activity, like a ViewModel or a
20 | Presenter for example.
21 | * Fragment Scope is optional but if you add it, it would depend on the activity one, and it would add fragment specific
22 | bindings on top of it.
23 |
24 | (Show code - Application class)
25 |
26 | To emulate this we already have one of the pieces ready: The application scope, which is defined in the application
27 | class.
28 |
29 | Now we would need to build the Activity scope on top of it. To do that, and since we want the scope to be available from
30 | any activity in the app, we are conveniently creating a base activity that will provide the scope. We'll call it
31 | InjectedActivity.
32 |
33 | To build the activity Kodein scope we will need to make it depend on the application one, if you remember the onion. To
34 | get access to the application Kodein scope, we can use the Kodein closestKodein() function, which will automatically
35 | fetch it for us. This function is prepared for android. It will return the application scope when it's called from an
36 | activity, and if you call it from a framgent or a customview, it will return the enclosing activity scope. So it's
37 | perfect to achieve what we want.
38 |
39 | We'll also want to implement KodeinAware on the activity, so we get an automatic instance of Kodein that we can
40 | override. That will be our activity scope.
41 |
42 | This is totally your choice, but you can use a retainedKodein instance instead of a normal one. That gives you a
43 | lifecycle immune Kodein instance, which can survive to configuration changes.
44 |
45 | First thing we do on the activity scope is to extend the application one as expected. This will bring all
46 | the application scoped bindings into scope. Afterwards, I'm adding a base module for all activities that will provide
47 | generic activity scoped dependencies, like the navigator or the activity context itself!
48 |
49 | Afterwards, I can request bindings from a delegate function, so child activities will be able to define their specific
50 | bindings. This is gonna be key. So if there's an activity that needs to bind something apart from the things we're
51 | binding here, like its own ViewModel for example, it will be able to.
52 |
--------------------------------------------------------------------------------
/course/9/Script.md:
--------------------------------------------------------------------------------
1 | # 9: "Injecting Singletons"
2 |
3 | We have a use case to retrieve the photos, but it's just returning a list of stubbed photos. Let's say we want to
4 | fetch them from a network API, like the Unsplash one.
5 |
6 | Use cases are a way to decouple Presenters or ViewModels from the sources of data. So the use case will depend on
7 | a different entity with that given responsibility. A "data source".
8 |
9 | I will add an interface declaring the contract, and then implement it using retrofit and targeting the Unsplash API.
10 | Data sources are usually hidden behind interfaces, since they depend directly on frameworks like android for
11 | persistence, or an HTTP client to make real requests. We don't want to perform real http queries or to store things on
12 | the real data base when we're running our tests. We need our tests to be isolated from frameworks.
13 |
14 | Regardless how we're implementing the data source, it will require a Retrofit service targeting the Unsplash API passed
15 | in to make the HTTP requests. So it will be another nested dependency on the tree.
16 |
17 | Once we got all the pieces in place, we need to provide them on the corresponding Kodein scope. Since we will need to
18 | show the pictures on the photo list activity, let's add the bindings there.
19 |
20 | As you can see, our use case now requires to pass the data source in. We can call instance() for it, and then write the
21 | corresponding binding.
22 |
23 | But let's think for a second, should we write the binding on the activity scope? We're binding a data source.
24 | Data sources are usually accessed from different screens, since they can fulfill different requests. For example: If we
25 | add a detail screen tomorrow, we will need to fetch details for a single photo, and that's gonna be another query on the
26 | same data source. For that reason, data sources are usually provided in the application scope, so they can live during
27 | the whole app execution.
28 |
29 | So let's add the binding to the app module. This binding will be visible from the activity scope, since we're making it
30 | depend on the application one.
31 |
32 | Here, we are linking the interface to the concrete type, so anytime the interface is requested for injection, we provide
33 | the concrete implementation targeting the Unsplash API.
34 |
35 | But there's still something else. Whenever you're declaring a binding you can use a provider like this one, which will
36 | provide a new instance each time it's requested. But a data source sometimes requires to have the same instance all the
37 | time. In other words, you need it to be a Singleton.
38 |
39 | If you need a binding to always provide the same instance for all the cases, you can just use singleton {} for it,
40 | instead of a plain provider. So any time it's injected, the same instance will be returned.
41 |
42 | Singletons work per scope. That means they provide the same instance for the given Kodein container where they are
43 | declared. If you added this binding into the base activity module, it would provide the same instance every time
44 | for the same activity type. But if the activity type varies, it will return a different singleton instance for that one.
45 |
46 | Note that the data source also requires a retrofit service that we can fulfill in the same way. We'll need a binding for
47 | it that we can also provide as a singleton. And for the retrofit service, we can also bind the OkHttpClient instance
48 | used to build it.
49 |
50 | Once you have all the chained bindings in place, you'll be good to go, and start making real requests on your photos activity.
51 |
--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
1 | Android Scoped DI using Kodein
2 | ==============================
3 |
4 | This repo provides an end to end Android app encoded using **Clean Architecture**, and a DI approach based on scopes to
5 | provide testability.
6 |
7 | The repo is a sample project for the [caster.io Kodein course](https://caster.io) about the same subject.
8 |
9 | ## Testing
10 |
11 | * Don't forget to **disable animations** on your emulator for running UI tests, or you could get some race conditions.
12 | * UI tests have been developed using a Nexus 5X API 27 (just in case you wanna replicate the same scenario, to avoid any noise).
13 |
14 | ## Lessons
15 | * **What's Kodein?**: What is Kodein and how is it different from other frameworks like Dagger
16 | * **First steps**: Fetch Kodein dependency on Build gradle. (Explain difference between artifacts kodein-generic-jvm or kodein-erased-jvm)
17 | * **Application Scope**: Start by creating an Application Kodein container to provide application scoped dependencies.
18 | * **Your first injection**: Use the application scope to inject your first dependency (A simple Logger)
19 | * **Lazy injections**: Explain the concept of laziness in DI frameworks and Kodein
20 | * **Scoped Injection - Activity Scope**: Explain the concept of scoped injection by providing a second scope: The
21 | Activity one.
22 | * **Activity scoped dependencies**: Use the activity scope to inject a Presenter, which will just need to live under
23 | that scope.
24 | * **Transitive dependencies**: Inject a use case on presenter to showcase how Kodein solves the problem of nested
25 | transitive dependencies.
26 | * **Injecting Singletons**: Explain why singletons are often needed by providing a singleton instance for a photo data
27 | source.
28 | * **Tagged Injections**: Explain why two bindings for the same type collide and how to resolve the problem with tagged
29 | bindings. Use it to provide two different OkHttp Interceptors.
30 | * **Constant Injection**: Showcase how Kodein allows to define bindings for constants and not just entities. Use the
31 | concept to provide a TTL for the local photos cache.
32 | * **Adding a Detail Activity**: This lesson is a good chance to recap the process we followed for the photos list
33 | activity Kodein scope, but over a new detail activity.
34 | * **Injecting Navigation**: Inject a Navigator in Presenter and showcase how we can provide a different Context instance
35 | per scope, showcasing the benefit of Kodein binding overrides.
36 | * **Injecting Fragments**: We're adding a fragment to the detail activity and showcasing how to create a new scope:
37 | Fragment Scope.
38 | * **Injecting Custom Views**: Let's add a custom view and explain how Kodein allows Custom Views to auto inject, the
39 | same way activities or fragments do.
40 | * **Testing your architecture (mock injection)**: This lesson offers and end to end black box unit testing scenario
41 | where thanks to DI we replace the pieces that depend on frameworks by mocks. DI helps us to replace those at any
42 | arbitrary depth on the dependency tree.
43 | * **Injecting Mocks on your UI tests**: Learn how to write UI tests reusing production Kodein modules for fulfilling
44 | dependencies but replacing just the required parts in the graph thanks to Kodein module overrides.
45 |
46 | ## Screenshots
47 |
48 | 
49 | 
50 |
--------------------------------------------------------------------------------
/course/13/Script.md:
--------------------------------------------------------------------------------
1 | # 13: "Injecting Navigation"
2 |
3 | On the previous lesson we didn't show the logics we use for navigating from one activity to another.
4 |
5 | We will need a click listener in the adapter for every item, which will just forward the click event to the presenter,
6 | as you can see here. We need to pass the photo Id, so the presenter can navigate to the detail for that given photo.
7 |
8 | But the presenter is not performing the navigation by itself, but delegating it to some other entity called Navigator.
9 |
10 | If you think about one of the main purposes of presenters, it's to put a boundary between the view implementation, and
11 | the rest of the app. That means presenters should never depend on any frameworks like the Android SDK.
12 |
13 | Navigation depends on the Android framework since it requires an Android Context, so we cannot implement it here.
14 |
15 | We will create an interface to abstract it away and inject it here. This contract will define all the navigation routes
16 | available for the app. Since this app is quite simple, it will just provide a function to navigate to the detail,
17 | which will require a photoId for it.
18 |
19 | The implementation will get a context injected so it can perform navigation as expected.
20 |
21 | But we still need to provide the navigation into the dependency injection scope. If we think about navigators, we
22 | could think that it requires an activity context to launch another activity. But that is actually not true. You can
23 | start activities using any context, like a Service or even the Application itself. That's because the startActivity
24 | method is defined in the Android Context class, so any entity extending Context will be able to start activities.
25 |
26 | That's how you can launch activities from push notification services, for example.
27 |
28 | That means the binding for the navigator will fit better on the application scope, since it can be used from many
29 | different parts of the app.
30 |
31 | (Show scopes onion graph)
32 |
33 | If we take a brief look to our dependency scopes graph, we can see the application scope is the innermost one.
34 | That means its bindings are inherited by the activity one, and the bindings from both are inherited from the
35 | fragment one.
36 |
37 | So, if we declare the navigator in the application scope, it will clearly get the application context passed in, since
38 | it's the only one visible. But what if we are in an activity scope? wouldn't we want to get the activity context
39 | automatically passed in instead of the application one?
40 |
41 | If we could define the binding in a way that leaves the context as a hole, and then provide a different implementation
42 | of the context for each scope, that should be enough. The fragment scope wouldn't need to provide any context binding
43 | since fragments are not context wrappers. It could just reuse the activity one, which will be visible since the fragment
44 | scope depends on it.
45 |
46 | But this has a new problem, hasn't it? We'll get a runtime error because there are two bindings defined for the Context
47 | type on the activity scope, given that it's extending the application scope.
48 |
49 | But there's a really cool feature from Kodein to resolve this: The Binding overrides.
50 |
51 | What we want to do is to override our application context with the activity one, but just for the activity scope. To do
52 | that, go to the `InjectedActivity` and set the allow overrides property to true when importing the module. Once you
53 | have that, go to the base activity module and mark the context binding as an override like this. And you'll be done.
54 |
55 | Any time a navigator is required, the application module will provide it fulfilling the context instance using the
56 | application context, but if we're into an activity scope, the context will be overriden by the activity one.
57 |
58 | In the same way, if we had a service, we could create a service scope that would extend from the application one,
59 | and could also override the context binding to provide the service context.
60 |
--------------------------------------------------------------------------------
/course/8/Script.md:
--------------------------------------------------------------------------------
1 | # 8: "Transitive Dependencies"
2 |
3 | We have our bindings in place for PhotoListActivity. Whenever it gets launched we'll get our instance of the presenter
4 | injected. We can do that thanks to the binding we have defined on the photoListActivityModule(). But what if we needed
5 | to go further and provide a dependency to the Presenter on construction?
6 |
7 | We'd need a way to also instantiate and provide it. And of course we can do that by declaring another binding.
8 |
9 | We'll showcase that by injecting what we call a UseCase into the presenter. Use cases, also called "interactors", are
10 | part of an architecture called Clean Architecture. Just keep in mind that they exist to pull business logic out from
11 | Presenters or ViewModels so they don't grow massively, and also as a way to make our presenter or ViewModel agnostic
12 | from any data retrieval logics.
13 |
14 | We will be using a base class UseCase to provide a contract for all of them. We will make Parameters a generic type so
15 | each use case can specify it, and the same for the return type.
16 |
17 | Whenever we run the use case, we will perform some business logic or maybe retrieve data from somewhere, and then return
18 | a result.
19 |
20 | Since any use case is an execution unit that can fail or succeed, we're returning Either a domain error or the
21 | successful return type, as you can see here. Either is just a wrapper class to provide that duality into the same type,
22 | so we can avoid using callbacks.
23 |
24 | I'm taking it from a library called Arrow, but you can just write your own, since at the end of the day it's just a
25 | sealed class with two different implementations, one for the error and another one for the success type.
26 |
27 | Note that the error represents a domain error type, which is defined as a sealed class that can take a bunch of expected
28 | errors handled by our domain.
29 |
30 | (Show GetPhotos)
31 |
32 | But lets get to the point. We want to create our use case to get the photos and return them to the presenter. To do
33 | that, we will inherit from the base one. The parameters for it are defined as a data class, as you can see. I'm
34 | providing the page to load and a query string that could be used for searching photos by category or something.
35 |
36 | Then there is the successful return type, which is going to be a list of photos (List) in case everything goes
37 | alright. For now we will return just a bunch of hardcoded photos so it's not gonna fail.
38 |
39 | Once we have our use case ready, we need to inject it on the presenter! To do that, we need to add it to the presenter
40 | constructor. Now let's go back to the photo list activity module. As you can see, this code is not compiling anymore
41 | since we need to pass an instance for the use case to the presenter.
42 |
43 | To do that, we can write a binding for the use case itself, since it's a dependency, and it seems reasonable to make it
44 | live under the activity scope, since we will run the use case from this activity and we probably don't need it to be
45 | available for other unrelated activities. After all, we're retrieving a list of photos that will be rendered on a single
46 | activity. But it's your choice where to put it, and it will always depend on your app.
47 |
48 | Now, we just need a way to wire both bindings. For that, we just need to use the instance() Kodein function, et voilá.
49 |
50 | We will get the use case instance automatically instantiated and passed in when the presenter gets bound. That's how
51 | Kodein works for nested bindings.
52 |
53 | Note that just by using the instance() function you're kind of filling a hole with something that requires to have a
54 | binding declared in scope. The use case binding could even be defined outside of this module, like on the application
55 | scope for example.
56 |
57 | But since we made the activity scope depend on the application one, it will be visible from this scope and the nested
58 | bindings will work as expected. This is key since it gives you a very big flexibility on how to organize your scopes and
59 | your binding modules.
60 |
61 | Once we get our use case we can just use it to request the pictures and render results or errors back on the view,
62 | depending on the case, as you can see here.
63 |
--------------------------------------------------------------------------------
/app/build.gradle:
--------------------------------------------------------------------------------
1 | apply plugin: 'com.android.application'
2 | apply plugin: 'kotlin-kapt'
3 | apply plugin: 'kotlin-android'
4 | apply plugin: 'kotlin-android-extensions'
5 |
6 | android {
7 | compileSdkVersion compile_sdk_version
8 | defaultConfig {
9 | applicationId "me.jorgecastillo.kodein"
10 | minSdkVersion min_sdk_version
11 | targetSdkVersion target_sdk_version
12 | versionCode 1
13 | versionName "1.0"
14 | testInstrumentationRunner "com.github.tmurakami.dexopener.DexOpenerAndroidJUnitRunner"
15 | }
16 | buildTypes {
17 | release {
18 | minifyEnabled false
19 | proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
20 | }
21 | }
22 |
23 | sourceSets {
24 | String sharedTestDir = 'src/sharedTest/java'
25 | test {
26 | java.srcDir sharedTestDir
27 | }
28 | androidTest {
29 | java.srcDir sharedTestDir
30 | }
31 | }
32 | }
33 |
34 | kotlin {
35 | experimental {
36 | coroutines "enable"
37 | }
38 | }
39 |
40 | dependencies {
41 |
42 | implementation "org.kodein.di:kodein-di-core-jvm:6.0.0"
43 | implementation "org.kodein.di:kodein-di-generic-jvm:6.0.0"
44 | implementation "org.kodein.di:kodein-di-framework-android-support:6.0.0"
45 |
46 | implementation "org.jetbrains.kotlin:kotlin-stdlib-jdk7:$kotlin_version"
47 | implementation 'com.android.support:appcompat-v7:28.0.0'
48 | implementation "com.android.support.constraint:constraint-layout:$constraint_layout_version"
49 | implementation 'com.android.support:design:28.0.0'
50 | implementation "com.android.support:cardview-v7:28.0.0"
51 | kapt "android.arch.lifecycle:compiler:$android_arch_components_version"
52 | implementation("android.arch.lifecycle:extensions:$android_arch_components_version") {
53 | exclude group: 'android.arch.lifecycle', module: 'common'
54 | }
55 | implementation "io.arrow-kt:arrow-core:$arrow_version"
56 | implementation "io.arrow-kt:arrow-syntax:$arrow_version"
57 | implementation "io.arrow-kt:arrow-data:$arrow_version"
58 | implementation "org.jetbrains.kotlinx:kotlinx-coroutines-core:$coroutines_version"
59 | implementation "org.jetbrains.kotlinx:kotlinx-coroutines-android:$coroutines_version"
60 | implementation ("com.squareup.picasso:picasso:$picasso_version") {
61 | exclude group: 'com.android.support', module: 'exifinterface'
62 | }
63 |
64 | // network
65 | implementation "com.squareup.okhttp3:okhttp:$okhttp_version"
66 | implementation "com.squareup.okhttp3:logging-interceptor:$okhttp_version"
67 | implementation "com.squareup.retrofit2:retrofit:$retrofit_version"
68 | implementation "com.squareup.retrofit2:converter-moshi:$retrofit_version"
69 | implementation "com.squareup.retrofit2:converter-gson:$retrofit_version"
70 | implementation "com.squareup.retrofit2:converter-jackson:$retrofit_version"
71 | implementation "com.squareup.moshi:moshi:$moshi_version"
72 | implementation "com.squareup.moshi:moshi-kotlin:$moshi_version"
73 | implementation "com.google.code.gson:gson:$gson_version"
74 |
75 | // test
76 | testImplementation 'junit:junit:4.12'
77 | androidTestImplementation "com.android.support.test:runner:$astl_version"
78 | androidTestImplementation "com.android.support.test:rules:$astl_version"
79 | androidTestImplementation "com.android.support.test.espresso:espresso-core:$espresso_version"
80 | androidTestImplementation "com.android.support.test.espresso:espresso-intents:$espresso_version"
81 | androidTestImplementation "com.android.support.test.espresso:espresso-contrib:$espresso_version"
82 | androidTestImplementation "com.android.support.test:runner:$astl_version"
83 | androidTestImplementation "com.nhaarman:mockito-kotlin:$mockito_kotlin"
84 | androidTestImplementation "org.mockito:mockito-core:$mockito_version"
85 | androidTestImplementation "org.mockito:mockito-android:$mockito_version"
86 | androidTestImplementation 'com.github.tmurakami:dexopener:1.0.2'
87 |
88 | testImplementation "com.nhaarman:mockito-kotlin:$mockito_kotlin"
89 | testImplementation "org.mockito:mockito-core:$mockito_version"
90 | }
91 |
--------------------------------------------------------------------------------
/course/12/Script.md:
--------------------------------------------------------------------------------
1 | # 12: "Adding a Detail Activity"
2 |
3 | We already have a photos list activity in place, so the user can scroll on it to enjoy some fancy photos. But we would
4 | love to add a detail activity now, so any time the user clicks on one of the photos we can navigate to the detail.
5 |
6 | We will use this lesson as a chance to briefly recap the different steps we need to follow to create an activity scope,
7 | the same way we did for the photos list activity.
8 |
9 | Detail activity is going to be quite simple. I'll not show you how to encode a simple detail screen, but this will to be
10 | the final look for it. (show detail activity screenshot). As you can see, it's just showing the picture as a header,
11 | also some author attributions and a basic description. There's also a share button to click and share the picture.
12 |
13 | For injecting dependencies, we want to do the same we did for the list activity. We want to have a new activity scope
14 | for this specific activity. To do that, we need to make sure that we are overriding the InjectedActivity, so we can
15 | override the delegate method to provide our specific activity bindings for this one. If you can remember, base
16 | activity provided an activity Kodein instance thanks to being KodeinAware, and it provided some generic dependencies
17 | for all activities on it, plus delegating specific injection to each one of the child activities using this method.
18 |
19 | So, If we go back to the detail, we will create a new module to provide specific bindings for this activity. We wanna
20 | pass the photo Id to the module when building it, because we will need the Id to be passed in to the presenter to load
21 | details for that given photo.
22 |
23 | As you can see, our bindings are quite simple, and equivalent to the ones we provided for the list activity. We want to
24 | provide here the dependencies we think will fit better into the activity scope, like the presenter or the use case to
25 | retrieve a detail. Since the GetPhoto use case is very correlated to the details activity, it feels natural to put the
26 | binding on this specific activity scope. Also note how we're passing the photoId to the presenter on its construction.
27 |
28 | Then you will also notice a new requirement for the use case, which is something called PhotosRepository.
29 |
30 | If you remember we had 2 different data sources, a network one to fetch the photos and
31 | details and a local one to cache them. Both are going to be coordinated by an entity we'll put in the that I'm calling
32 | PhotosRepository.
33 |
34 | Repositories exist like a way for coordinating different sources of data, composing data coming from those different
35 | sources, and even applying caching policies.
36 |
37 | That's why our use case here is requiring a repository instance to be injected. Since the repository is gonna be
38 | used from both screens to get the photos list or the photo detail, we will want to add the binding to the application
39 | scope. (Add it). And of course it's gonna get both data sources injected as parameters.
40 |
41 | If we take a rapid look to the repo, this is how it is (go to it). As you can see, it has a couple of functions to
42 | get all the photos or a single one. It's playing with a bunch of caching policies defined by a sealed class, and
43 | depending on which one we're using we will load photos from the data sources in different order.
44 |
45 | Since we're using LocalFirst as the default policy, that means we are trying to load photos always from the local in
46 | memory cache first, and if they're not available, then we will fetch them from network.
47 |
48 | So, moving back to our activity, we wanna get our DetailPresenter injected on it. The detail presenter will have the
49 | invoker to run the use case, the GetPhoto use case itself, and the photoId, all injected by constructor. We don't want
50 | to move much further about how does it work, and remember you always have the sample repo for that. But note how it uses
51 | the use case to request the details and whenever it gets a response from it, it will order the view to render the
52 | details or an error, in case something was wrong.
53 |
54 | Also, if the view sends an event indicating that the share button was clicked, the presenter will order it to show the
55 | chooser to share the photo.
56 |
57 | And with this, we already got all the pieces in place to run the app and navigate to the detail.
58 |
59 | (Run the app, scroll a bit, navigate to the detail of one of the photos).
60 |
--------------------------------------------------------------------------------
/app/src/test/java/me/jorgecastillo/kodein/GetPhotosEndToEndShould.kt:
--------------------------------------------------------------------------------
1 | package me.jorgecastillo.kodein
2 |
3 | import android.content.Context
4 | import arrow.core.left
5 | import arrow.core.right
6 | import com.nhaarman.mockito_kotlin.verify
7 | import com.nhaarman.mockito_kotlin.whenever
8 | import me.jorgecastillo.kodein.common.data.network.PhotosNotFound
9 | import me.jorgecastillo.kodein.common.di.appModule
10 | import me.jorgecastillo.kodein.common.di.baseActivityModule
11 | import me.jorgecastillo.kodein.common.domain.interactor.Invoker
12 | import me.jorgecastillo.kodein.common.domain.model.Photo
13 | import me.jorgecastillo.kodein.common.domain.repository.PhotosLocalDataSource
14 | import me.jorgecastillo.kodein.common.domain.repository.PhotosNetworkDataSource
15 | import me.jorgecastillo.kodein.common.router.Navigator
16 | import me.jorgecastillo.kodein.photoslist.di.photoListActivityModule
17 | import me.jorgecastillo.kodein.photoslist.domain.interactor.GetPhotos
18 | import me.jorgecastillo.kodein.photoslist.domain.repository.PhotosRepository
19 | import me.jorgecastillo.kodein.photoslist.presenter.PhotoListPresenter
20 | import org.junit.Test
21 | import org.junit.runner.RunWith
22 | import org.kodein.di.Kodein
23 | import org.kodein.di.KodeinAware
24 | import org.kodein.di.generic.bind
25 | import org.kodein.di.generic.instance
26 | import org.kodein.di.generic.provider
27 | import org.kodein.di.generic.singleton
28 | import org.mockito.Mock
29 | import org.mockito.junit.MockitoJUnitRunner
30 |
31 | /**
32 | * End to end test mocking out view implementation, threading and data source implementations. We
33 | * are testing all the resting layers on integration by providing injection of all the parts in
34 | * between both edges by using Kodein.
35 | */
36 | @RunWith(MockitoJUnitRunner::class)
37 | class GetPhotosEndToEndShould : KodeinAware {
38 |
39 | val presenter: PhotoListPresenter by instance()
40 |
41 | @Mock
42 | lateinit var context: Context
43 |
44 | @Mock
45 | lateinit var localDataSource: PhotosLocalDataSource
46 | @Mock
47 | lateinit var networkDataSource: PhotosNetworkDataSource
48 | @Mock
49 | lateinit var navigator: Navigator
50 | @Mock
51 | lateinit var view: PhotoListPresenter.View
52 |
53 | override val kodein = Kodein.lazy {
54 | // production modules
55 | import(appModule(context))
56 | import(photoListActivityModule())
57 |
58 | // overrides
59 | bind(overrides = true) with singleton { BlockingUseCaseInvoker() }
60 | bind(overrides = true) with singleton { navigator }
61 | bind(overrides = true) with singleton { localDataSource }
62 | bind(overrides = true) with singleton { networkDataSource }
63 | }
64 |
65 | @Test
66 | fun showPhotosOnSuccessfulLoadingFromCache() {
67 | givenLocalDataSourcePhotos(anyPhotos)
68 |
69 | presenter.resume(view)
70 |
71 | verify(view).renderPhotos(anyPhotos)
72 | }
73 |
74 | @Test
75 | fun showPhotosWhenNotAvailableOnCacheButOnNetwork() {
76 | givenNoPhotosCached()
77 | givenNetworkDataSourcePhotos(anyPhotos)
78 |
79 | presenter.resume(view)
80 |
81 | verify(view).renderPhotos(anyPhotos)
82 | }
83 |
84 | @Test
85 | fun givesFeedbackWhenLoadingPhotosError() {
86 | givenNoPhotosAvailableOnAnySources()
87 |
88 | presenter.resume(view)
89 |
90 | verify(view).displayLoadingPhotosError()
91 | }
92 |
93 | private fun givenLocalDataSourcePhotos(anyPhotos: List) {
94 | whenever(localDataSource.getAll()).thenReturn(anyPhotos.right())
95 | }
96 |
97 | private fun givenNetworkDataSourcePhotos(anyPhotos: List) {
98 | whenever(networkDataSource.getAll()).thenReturn(anyPhotos.right())
99 | }
100 |
101 | private fun givenNoPhotosCached() {
102 | whenever(localDataSource.getAll()).thenReturn(PhotosNotFound().left())
103 | }
104 |
105 | private fun givenNoPhotosAvailableOnAnySources() {
106 | whenever(localDataSource.getAll()).thenReturn(PhotosNotFound().left())
107 | whenever(networkDataSource.getAll()).thenReturn(PhotosNotFound().left())
108 | }
109 |
110 | companion object {
111 | val anyPhotos: List = (1..3).map {
112 | Photo(it.toString(),
113 | "http:url/$it",
114 | "AuthorName$it",
115 | "Description$it",
116 | "2018-06-16T08:52:46-0500")
117 | }
118 | }
119 | }
120 |
--------------------------------------------------------------------------------
/course/16/Script.md:
--------------------------------------------------------------------------------
1 | # 16: "Testing your architecture (mock injection)"
2 |
3 | It's time to write some tests. You'll need to be smart about what you wanna test and how to do it. Choosing a proper
4 | test scope is key for providing good value with your tests. Be smart about the tests you wanna write and how to add
5 | value with them.
6 |
7 | Let's think first about what we would need to remove for isolating tests and make them repeatable and non flaky. I would
8 | personally remove the pieces that depend on external frameworks. Those can make tests become non deterministic, since
9 | they are affected by external factors.
10 |
11 | My architecture could be something like this. We have the view, then the presenter which uses navigator to
12 | navigate to other activities and also the invoker to run the use cases. The use cases depend on the repository that
13 | relies on a couple of data sources to fetch and store the data.
14 |
15 | But which pieces depend on frameworks here?
16 |
17 | The view implementation is a good one, since we don't want to depend on the android framework in our tests. There's
18 | also the Navigator, since we don't want tests to perform real navigation either. Also the invoker, because it uses
19 | coroutines to suspend threads and that could make our tests to complete before a background task has finished.
20 | And finally we will need to remove data sources, since those depend on android for caching and the http client for
21 | querying the server.
22 |
23 | Let's remove them.
24 |
25 | (Show code - GetPhotosEndtoEndShould)
26 |
27 | This is an end to end test suite for the photos list screen. My intention is to cover the whole call stack in a black
28 | box scenario, not caring about each one of the pieces separately but exercising the whole chain end to
29 | end and then asserting over the final state in the end. Covering bigger scopes has a couple of benefits like not having
30 | tests too close to the implementation and also reducing the amount of tests required.
31 |
32 | Thanks to having a dependency injection system in place, we can rely on it to wire up the whole dependency tree at all
33 | levels. To do that let's make our test class KodeinAware, and then override the kodein instance to include the same
34 | application and activity scopes we use are using in the production code. That will bind dependencies at all levels.
35 |
36 | But this has an obvious problem. The dependencies we wanna pull out like the navigator will still be bound to their
37 | production implementations.
38 |
39 | So let's add some mocks for those. Once we have the mocks in place for all those pieces, we can use the power of Kodein
40 | binding overrides to override just those on the dependency tree.
41 |
42 | For the invoker, we will replace it with a blocking version of it, which is just the same thing but runs the use cases
43 | using the runBlocking coroutines function, which ensures the thread gets blocked until the task completes. That will
44 | avoid any race conditions in tests.
45 |
46 | For the navigator and the data sources, we will provide the mocks we have created so we can configure them later on.
47 | The mock view will be linked in in tests whenever we start the call stack.
48 |
49 | Let's have a look at our tests. First one ensures that photos are retrieved and displayed for the happy case. So, if
50 | we have photos in cache, we will run the presenter passing in the mock view, and then we will just need to verify that
51 | the presenter asks the view to render the retrieved photos, which must be same ones returned from the cache.
52 |
53 | For the given block, we are just abstracting the mocked behavior into a function that makes the given data source to
54 | return the photos we pass in as an argument.
55 |
56 | The following test is quite similar. It also covers when photos are not in cache but can be retrieved from network.
57 | So same story, we configure our local data source to return an error, and then the network data source to retrieve the
58 | needed photos.
59 |
60 | Then we can exercise presenter passing in the mock view and assert for the final call over the view after the whole
61 | chain runs and the photos are retrieved.
62 |
63 | Note that each time we run the whole call stack starting on the presenter, the production presenter, use cases, and
64 | repository are running, and just the pieces that cause side effects are being replaced.
65 |
66 | The last test would test the scenario where photos are not available on any of the data sources, so an error should be
67 | rendered.
68 |
69 | And that's it! With a few tests we have covered our whole architecture.
70 |
--------------------------------------------------------------------------------
/course/17/Script.md:
--------------------------------------------------------------------------------
1 | # 17: "Injecting Mocks on your UI tests"
2 |
3 | This time we are not testing our architecture end to end, but cutting the dependency graph on the use cases, so we
4 | can test our view implementation along with its presenters. This is just one possible approach for writing simple UI
5 | tests, but please feel free to cut the graph wherever it fits better for your codebase.
6 |
7 | (Show test code)
8 |
9 | When you write UI tests for Android, the inversion of control is strong. The Android SDK instantiates the application
10 | and the activities for you, and you don't get any control on that process. That means you cannot perform constructor
11 | injection, and the activity will inject itself on creation using its Kodein container. You will not have any chance to
12 | step in the middle of that process and replace dependencies from your testing environment.
13 |
14 | (Show PhotosApp).
15 |
16 | As a consequence of this, you must find an approach that lets the activity lifecycle complete, so it gets launched, and
17 | then come right after that to override dependencies for that given scope. That's why binding overrides is a key feature
18 | for Dependency Injection frameworks when we write Android UI tests.
19 |
20 | To achieve what we want, lets make a single upgrade to the application class. We are going to declare this
21 | overrideBindings extension property that works over a Kodein.MainBuilder receiver. We will use this to override
22 | bindings once the activities are loaded. Note that we're initializing it as an empty function, so there are not going to
23 | be any binding overrides by default.
24 |
25 | Let's go now to the injected activity, and let's apply those binding overrides defined on the application class right
26 | at the end of the activity scope. app() is just a simple utility function created to retrieve the application class, for
27 | better syntax.
28 |
29 | Once we have that, we'll just need to add the binding overrides we need on our tests to the application class right
30 | before every test runs. And also clean those afterwards, to isolate tests properly.
31 |
32 | One of the best ways to run some code before and after any test can be a JUnit Rule. I've created this OverridesRule,
33 | which receives the same extension property working over the Kodein.MainBuilder type, that will carry out the binding
34 | overrides. Before every test, it takes the application class using the android Instrumentation, and passes the overrides
35 | to it. And after every test it will clear out the bindings.
36 |
37 | We can go back to our test suite now, and provide the bindings we want when creating the Rule. I'm going to override the
38 | invoker to use the blocking version of it one more time, and I will also override the use case binding to provide a
39 | mock. That will give me the chance to configure the mock as I need for every test.
40 |
41 | There's also an activity rule to launch the photo list activity from the tests. And with this, we're ready to start
42 | testing.
43 |
44 | On the first test, I'm asserting that photos are loaded and rendered as expected when the activity is launched. I call
45 | this given method to configure the use case to return the photos I have hardcoded on this collection. After that, I
46 | launch the activity.
47 |
48 | Once the activity is loaded I just need to assert over the items on the list looking for the corresponding author name
49 | for each element. I'm using this smart RecyclerViewInteraction created by Karumi. It takes care of scrolling through the
50 | list and performing assertions for each one of the elements. This should be enough to know that all the pictures are
51 | being rendered, at least for the example. If you wanted to be more strict you would probably want to assert that are the
52 | visible properties for each picture are being rendered as expected.
53 |
54 | The second test asserts that the error snackbar is displayed whenever the use case to load the photos returns an error.
55 | The given step is equivalent, we configure the use case mock to return an error. Then we launch the activity and perform
56 | the assertion.
57 |
58 | These are just two simple examples of how you can write tests with no fear to side effects or race conditions since
59 | you've taken care of replacing the dangerous dependencies with mocks thanks to Kodein overrides. A Dependency Injection
60 | framework like Kodein becomes really handy when writing apps because you can rely on it to wire up the complete
61 | dependency tree, and just replace some given dependencies at any arbitrary level on the tree.
62 |
63 | And with this, you are ready to inject dependencies on any app you write thanks to Kodein. Thanks for watching this
64 | Course. If want to learn more, please follow me. My Twitter handle is JorgeCastilloPR.
65 |
--------------------------------------------------------------------------------
/app/src/main/java/me/jorgecastillo/kodein/detail/view/DetailActivity.kt:
--------------------------------------------------------------------------------
1 | package me.jorgecastillo.kodein.detail.view
2 |
3 | import android.content.Context
4 | import android.content.Intent
5 | import android.os.Bundle
6 | import android.support.design.widget.Snackbar
7 | import android.view.Menu
8 | import android.view.MenuItem
9 | import android.view.View
10 | import com.squareup.picasso.Picasso
11 | import kotlinx.android.synthetic.main.activity_detail.content
12 | import kotlinx.android.synthetic.main.activity_detail.fab
13 | import kotlinx.android.synthetic.main.activity_detail.loading
14 | import kotlinx.android.synthetic.main.activity_detail.picture
15 | import kotlinx.android.synthetic.main.activity_detail.publishedAt
16 | import kotlinx.android.synthetic.main.activity_detail.titleView
17 | import kotlinx.android.synthetic.main.activity_detail.toolbar
18 | import kotlinx.android.synthetic.main.activity_detail.unsplashLink
19 | import me.jorgecastillo.kodein.R
20 | import me.jorgecastillo.kodein.common.di.InjectedActivity
21 | import me.jorgecastillo.kodein.common.domain.model.Photo
22 | import me.jorgecastillo.kodein.common.view.getBitmapUri
23 | import me.jorgecastillo.kodein.detail.description.DescriptionFragment
24 | import me.jorgecastillo.kodein.detail.di.detailActivityModule
25 | import me.jorgecastillo.kodein.detail.presenter.DetailPresenter
26 | import org.kodein.di.Kodein
27 | import org.kodein.di.generic.instance
28 | import java.text.SimpleDateFormat
29 | import java.util.Locale
30 |
31 | class DetailActivity : InjectedActivity(), DetailPresenter.View {
32 |
33 | private val presenter by instance()
34 | private val photoId by lazy {
35 | intent?.extras?.getString(EXTRA_ID) ?: NO_ID
36 | }
37 |
38 | override fun activityModule() = Kodein.Module("detailActivityModule") {
39 | import(detailActivityModule(photoId))
40 | }
41 |
42 | override fun onCreate(savedInstanceState: Bundle?) {
43 | super.onCreate(savedInstanceState)
44 | setContentView(R.layout.activity_detail)
45 | setSupportActionBar(toolbar)
46 | setupShareButton()
47 | }
48 |
49 | override fun onResume() {
50 | super.onResume()
51 | presenter.resume(this)
52 | }
53 |
54 | override fun onPause() {
55 | super.onPause()
56 | presenter.pause()
57 | }
58 |
59 | private fun setupShareButton() {
60 | fab.setOnClickListener {
61 | presenter.onShareButtonClicked()
62 | }
63 | }
64 |
65 | override fun onOptionsItemSelected(item: MenuItem): Boolean = when (item.itemId) {
66 | R.id.action_settings -> true
67 | else -> super.onOptionsItemSelected(item)
68 | }
69 |
70 | override fun onCreateOptionsMenu(menu: Menu): Boolean {
71 | menuInflater.inflate(R.menu.menu_detail, menu)
72 | return true
73 | }
74 |
75 | override fun showLoading() {
76 | loading.visibility = View.VISIBLE
77 | }
78 |
79 | override fun hideLoading() {
80 | loading.visibility = View.GONE
81 | }
82 |
83 | override fun showShareChooser() {
84 | val shareIntent = Intent()
85 | val share = picture.getBitmapUri()
86 | shareIntent.action = "android.intent.action.SEND"
87 | shareIntent.putExtra("android.intent.extra.STREAM", share)
88 | shareIntent.type = "image/jpeg"
89 | startActivity(Intent.createChooser(shareIntent, "Share"))
90 | }
91 |
92 | override fun renderPhoto(photo: Photo) {
93 | Picasso.get()
94 | .load(photo.url)
95 | .into(picture)
96 |
97 | content.visibility = View.VISIBLE
98 | titleView.text = photo.author
99 | unsplashLink.text = getString(R.string.unsplash)
100 |
101 | val date = SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss", Locale.getDefault()).parse(photo.created_at)
102 | publishedAt.text = SimpleDateFormat("yyyy-MM-dd HH:mm", Locale.getDefault()).format(date)
103 |
104 | loadDescriptionFragment(photo.description)
105 | }
106 |
107 | private fun loadDescriptionFragment(description: String?) {
108 | val transaction = supportFragmentManager.beginTransaction()
109 | val descriptionText = description ?: getString(R.string.no_description)
110 | transaction.replace(R.id.fragmentContainer, DescriptionFragment.newInstance(descriptionText))
111 | transaction.commit()
112 | }
113 |
114 | override fun displayLoadingPhotoError() {
115 | Snackbar.make(toolbar, R.string.loading_photo_error, Snackbar.LENGTH_SHORT)
116 | .show()
117 | }
118 |
119 | companion object {
120 | const val EXTRA_ID = "EXTRA_ID"
121 | const val NO_ID = "NO_ID"
122 |
123 | fun getIntent(
124 | source: Context,
125 | id: String
126 | ): Intent {
127 | val intent = Intent(source, DetailActivity::class.java)
128 | intent.putExtra(EXTRA_ID, id)
129 | return intent
130 | }
131 | }
132 | }
133 |
--------------------------------------------------------------------------------
/app/src/main/res/layout/item_photo.xml:
--------------------------------------------------------------------------------
1 |
2 |
13 |
14 |
20 |
21 |
28 |
29 |
33 |
34 |
45 |
46 |
57 |
58 |
69 |
70 |
81 |
82 |
83 |
95 |
96 |
108 |
109 |
110 |
--------------------------------------------------------------------------------
/gradlew:
--------------------------------------------------------------------------------
1 | #!/usr/bin/env sh
2 |
3 | ##############################################################################
4 | ##
5 | ## Gradle start up script for UN*X
6 | ##
7 | ##############################################################################
8 |
9 | # Attempt to set APP_HOME
10 | # Resolve links: $0 may be a link
11 | PRG="$0"
12 | # Need this for relative symlinks.
13 | while [ -h "$PRG" ] ; do
14 | ls=`ls -ld "$PRG"`
15 | link=`expr "$ls" : '.*-> \(.*\)$'`
16 | if expr "$link" : '/.*' > /dev/null; then
17 | PRG="$link"
18 | else
19 | PRG=`dirname "$PRG"`"/$link"
20 | fi
21 | done
22 | SAVED="`pwd`"
23 | cd "`dirname \"$PRG\"`/" >/dev/null
24 | APP_HOME="`pwd -P`"
25 | cd "$SAVED" >/dev/null
26 |
27 | APP_NAME="Gradle"
28 | APP_BASE_NAME=`basename "$0"`
29 |
30 | # Add default JVM options here. You can also use JAVA_OPTS and GRADLE_OPTS to pass JVM options to this script.
31 | DEFAULT_JVM_OPTS=""
32 |
33 | # Use the maximum available, or set MAX_FD != -1 to use that value.
34 | MAX_FD="maximum"
35 |
36 | warn () {
37 | echo "$*"
38 | }
39 |
40 | die () {
41 | echo
42 | echo "$*"
43 | echo
44 | exit 1
45 | }
46 |
47 | # OS specific support (must be 'true' or 'false').
48 | cygwin=false
49 | msys=false
50 | darwin=false
51 | nonstop=false
52 | case "`uname`" in
53 | CYGWIN* )
54 | cygwin=true
55 | ;;
56 | Darwin* )
57 | darwin=true
58 | ;;
59 | MINGW* )
60 | msys=true
61 | ;;
62 | NONSTOP* )
63 | nonstop=true
64 | ;;
65 | esac
66 |
67 | CLASSPATH=$APP_HOME/gradle/wrapper/gradle-wrapper.jar
68 |
69 | # Determine the Java command to use to start the JVM.
70 | if [ -n "$JAVA_HOME" ] ; then
71 | if [ -x "$JAVA_HOME/jre/sh/java" ] ; then
72 | # IBM's JDK on AIX uses strange locations for the executables
73 | JAVACMD="$JAVA_HOME/jre/sh/java"
74 | else
75 | JAVACMD="$JAVA_HOME/bin/java"
76 | fi
77 | if [ ! -x "$JAVACMD" ] ; then
78 | die "ERROR: JAVA_HOME is set to an invalid directory: $JAVA_HOME
79 |
80 | Please set the JAVA_HOME variable in your environment to match the
81 | location of your Java installation."
82 | fi
83 | else
84 | JAVACMD="java"
85 | which java >/dev/null 2>&1 || die "ERROR: JAVA_HOME is not set and no 'java' command could be found in your PATH.
86 |
87 | Please set the JAVA_HOME variable in your environment to match the
88 | location of your Java installation."
89 | fi
90 |
91 | # Increase the maximum file descriptors if we can.
92 | if [ "$cygwin" = "false" -a "$darwin" = "false" -a "$nonstop" = "false" ] ; then
93 | MAX_FD_LIMIT=`ulimit -H -n`
94 | if [ $? -eq 0 ] ; then
95 | if [ "$MAX_FD" = "maximum" -o "$MAX_FD" = "max" ] ; then
96 | MAX_FD="$MAX_FD_LIMIT"
97 | fi
98 | ulimit -n $MAX_FD
99 | if [ $? -ne 0 ] ; then
100 | warn "Could not set maximum file descriptor limit: $MAX_FD"
101 | fi
102 | else
103 | warn "Could not query maximum file descriptor limit: $MAX_FD_LIMIT"
104 | fi
105 | fi
106 |
107 | # For Darwin, add options to specify how the application appears in the dock
108 | if $darwin; then
109 | GRADLE_OPTS="$GRADLE_OPTS \"-Xdock:name=$APP_NAME\" \"-Xdock:icon=$APP_HOME/media/gradle.icns\""
110 | fi
111 |
112 | # For Cygwin, switch paths to Windows format before running java
113 | if $cygwin ; then
114 | APP_HOME=`cygpath --path --mixed "$APP_HOME"`
115 | CLASSPATH=`cygpath --path --mixed "$CLASSPATH"`
116 | JAVACMD=`cygpath --unix "$JAVACMD"`
117 |
118 | # We build the pattern for arguments to be converted via cygpath
119 | ROOTDIRSRAW=`find -L / -maxdepth 1 -mindepth 1 -type d 2>/dev/null`
120 | SEP=""
121 | for dir in $ROOTDIRSRAW ; do
122 | ROOTDIRS="$ROOTDIRS$SEP$dir"
123 | SEP="|"
124 | done
125 | OURCYGPATTERN="(^($ROOTDIRS))"
126 | # Add a user-defined pattern to the cygpath arguments
127 | if [ "$GRADLE_CYGPATTERN" != "" ] ; then
128 | OURCYGPATTERN="$OURCYGPATTERN|($GRADLE_CYGPATTERN)"
129 | fi
130 | # Now convert the arguments - kludge to limit ourselves to /bin/sh
131 | i=0
132 | for arg in "$@" ; do
133 | CHECK=`echo "$arg"|egrep -c "$OURCYGPATTERN" -`
134 | CHECK2=`echo "$arg"|egrep -c "^-"` ### Determine if an option
135 |
136 | if [ $CHECK -ne 0 ] && [ $CHECK2 -eq 0 ] ; then ### Added a condition
137 | eval `echo args$i`=`cygpath --path --ignore --mixed "$arg"`
138 | else
139 | eval `echo args$i`="\"$arg\""
140 | fi
141 | i=$((i+1))
142 | done
143 | case $i in
144 | (0) set -- ;;
145 | (1) set -- "$args0" ;;
146 | (2) set -- "$args0" "$args1" ;;
147 | (3) set -- "$args0" "$args1" "$args2" ;;
148 | (4) set -- "$args0" "$args1" "$args2" "$args3" ;;
149 | (5) set -- "$args0" "$args1" "$args2" "$args3" "$args4" ;;
150 | (6) set -- "$args0" "$args1" "$args2" "$args3" "$args4" "$args5" ;;
151 | (7) set -- "$args0" "$args1" "$args2" "$args3" "$args4" "$args5" "$args6" ;;
152 | (8) set -- "$args0" "$args1" "$args2" "$args3" "$args4" "$args5" "$args6" "$args7" ;;
153 | (9) set -- "$args0" "$args1" "$args2" "$args3" "$args4" "$args5" "$args6" "$args7" "$args8" ;;
154 | esac
155 | fi
156 |
157 | # Escape application args
158 | save () {
159 | for i do printf %s\\n "$i" | sed "s/'/'\\\\''/g;1s/^/'/;\$s/\$/' \\\\/" ; done
160 | echo " "
161 | }
162 | APP_ARGS=$(save "$@")
163 |
164 | # Collect all arguments for the java command, following the shell quoting and substitution rules
165 | eval set -- $DEFAULT_JVM_OPTS $JAVA_OPTS $GRADLE_OPTS "\"-Dorg.gradle.appname=$APP_BASE_NAME\"" -classpath "\"$CLASSPATH\"" org.gradle.wrapper.GradleWrapperMain "$APP_ARGS"
166 |
167 | # by default we should be in the correct project dir, but when run from Finder on Mac, the cwd is wrong
168 | if [ "$(uname)" = "Darwin" ] && [ "$HOME" = "$PWD" ]; then
169 | cd "$(dirname "$0")"
170 | fi
171 |
172 | exec "$JAVACMD" "$@"
173 |
--------------------------------------------------------------------------------
/app/src/main/res/drawable/ic_launcher_background.xml:
--------------------------------------------------------------------------------
1 |
2 |
7 |
10 |
15 |
20 |
25 |
30 |
35 |
40 |
45 |
50 |
55 |
60 |
65 |
70 |
75 |
80 |
85 |
90 |
95 |
100 |
105 |
110 |
115 |
120 |
125 |
130 |
135 |
140 |
145 |
150 |
155 |
160 |
165 |
170 |
171 |
--------------------------------------------------------------------------------
/app/src/main/res/layout/activity_detail.xml:
--------------------------------------------------------------------------------
1 |
2 |
7 |
8 |
13 |
14 |
20 |
21 |
31 |
32 |
40 |
41 |
49 |
50 |
51 |
52 |
56 |
57 |
60 |
61 |
68 |
69 |
77 |
78 |
82 |
83 |
93 |
94 |
104 |
105 |
115 |
116 |
126 |
127 |
128 |
139 |
140 |
145 |
146 |
147 |
148 |
149 |
157 |
158 |
159 |
--------------------------------------------------------------------------------