Skip to content

Conversation

@LoredanaZdranc
Copy link
Contributor

This branch contains:

  • Room integration with @insert, @query, and @delete examples
  • Locale changer demo
  • General error handling
  • General loading handler
  • Network handler to check internet connection
  • MotionLayout example

…) and finish its setup. Created classes for favorite users screen (fragment, module, view model, layout)
# Conflicts:
#	app/src/main/java/com/base_android_template/App.kt
…issue where FavoriteGithubUsersViewModel cannot be injected
…tabase in order to avoid null fields and created a method to map the GithubUserResponse to GithubUserEntity. Implemented insertGithubUsers(), getGithubUsers() and deleteGithubUsers() methods into GithubUsersListDao. Implemented the "Either", "NetworkHandler" and "ExceptionHandler" classes. Added an interface and its implementation for remote Github users list call. Implemented the DatabaseModule to inject room database related classes. Changed the implementation of GithubUsersListUseCase to fetch the list from server and to save it locally in database if the server returns success. Changed the logic in GithubUsersListViewModel to fetch firstly the local users list and if list is empty to call the server endpoint. Updated the adapter, view holder and diffUtil callback clasess to use GithubUserEntity instead of GIthubUserResponse
…ponseCall and NetworkResponseAdapterFactory classes.
…nguage in Hawk when changing it. Removed language menu in MainActivity's toolbar. Implemented a BindingAdapters method responsible to set from layout the checked changed listener on RadioGroup
…e message. Animate using MotionLayout the title and the message when scrolling the users list.
@LoredanaZdranc LoredanaZdranc self-assigned this Mar 17, 2021
@NegreaVlad NegreaVlad changed the base branch from main to develop March 21, 2021 09:48
@NegreaVlad
Copy link

I changed the into branch to develop to avoid changes that were already reviewed

Copy link

@NegreaVlad NegreaVlad left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I reviewed some code, but not all of it. This is a partial review

<application
android:allowBackup="true"
android:name=".App"
android:allowBackup="false"

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we want this?


factory<UILoading> { UILoadingImplementation() }

single { ExceptionHandler() }

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this class doesn't implement an interface, there is no benefit of injecting it

}

private suspend fun makeRequest(block: suspend () -> Response<List<GithubUserResponse>>): Either<Exception, List<GithubUserResponse>> {
if (!networkHandler.hasNetworkConnection()) {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think it makes sense to check if there is an active network connection here, before making the call.
If we want to know if the error occurred because of no network, we can check that when getting 404 response

object NetworkException : Exception()
object ServerException : Exception()
object SaveGithubUsersException : Exception()
object EmptyLocalGithubUsersLisException : Exception()

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"EmptyLocalGithubUsersLisException" -> EmptyLocalGithubUsersListException

@@ -0,0 +1,9 @@
package com.base_android_template.shared.network

sealed class Exception {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Having a general network exception is not good IMO because this class will get very large and you cannot understand anything.
Not all projects require the identification of network is down, or other general errors that can happen for all API calls.
I would like to have an error specific for each use case i.e a sealed class like this with errors specific only for github users and a GeneralError. We will not propagate more info downwards because I don't think it's needed for this project.
If certain error need to be treated in a certain way across all the app, then we can create a base class for errors, but it's not needed now.
The API can return a retrofit response which is analysed in the use case


class ExceptionHandler {

fun handleGeneralException(exception: Throwable): Either.Failure<Exception> = when (exception) {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The naming is wrong. "Handle" means something final. The exception is handled here and that's it. This is just a mapper

return try {
val response = block.invoke()
handleResponse(response)
} catch (exception: Throwable) {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To avoid a too general catch, catch only java.io.IOException

override fun onActivityCreated(savedInstanceState: Bundle?) {
super.onActivityCreated(savedInstanceState)

viewModel.exception.observe(viewLifecycleOwner, {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This just calls view model logic. It doesn't do anything UI related. Why not put it in view model?


companion object {

fun mapToGithubUserEntity(githubUserResponse: GithubUserResponse) =

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can implement an extension function instead of this. The call is cleaner IMO and we cannot use it without an instance of GithubUserResponse

}
}

fun getRemoteGithubUsers() {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the logic of fetching from network or local database should be inside the use case, but I need to read more about this in order to provide good feedback.

… the Github users errors to handle in this way the errors by usecases
…odel. Moved the logic inside GithubUsersFragment -> onActivitCreated() to GithubUserViewModel. Implemented the SingleLiveEvent class to not clear every time the live data value
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants