- try using Paging Library from google, it simplifies your paging logic by a lot, you won't have that many loose variables hanging around your
Presenter
- better usage of RxJava
you have loadNewPhotos()
, where you call from here:
view_pager.addOnPageChangeListener(object : ViewPager.OnPageChangeListener {
override fun onPageScrollStateChanged(state: Int) {
}
override fun onPageScrolled(position: Int, positionOffset: Float, positionOffsetPixels: Int) {
}
override fun onPageSelected(position: Int) {
mPresenter.loadNewPhotos(FlickrUtils.API_KEY, position)
}
})
you can actually use a Subject
to redirect this onPageSelected
signal.
view_pager.addOnPageChangeListener(object : ViewPager.OnPageChangeListener {
override fun onPageScrollStateChanged(state: Int) {
}
override fun onPageScrolled(position: Int, positionOffset: Float, positionOffsetPixels: Int) {
}
override fun onPageSelected(position: Int) {
pageSelectedSubject.onNext(position)
}
})
pass your subject into your presenter
// somewhere....
Presenter(pageSelectedSubject.hide(), ....)
Following this pattern, your Presenter will have a bunch of Observable
s from various inputs, you can store them inside a class.
Now, inside your Presenter, you can do everything you need by choosing which streams you want.
Presenter(inputObservables: Contract.Input){
init {
Observable.merge (inputObservables.onCreateObs, inputObservables.refreshObs, BiFunction {
dataSource.fetchItems()
}.subscribe....
Observable.....
}
}
After you achieve this, you can make better use of RxJava operators, instead of having a huge subscribe
chunk.
This is an example. Note that this repo is not maintained!
- Use
RecyclerView
ListAdapter
: https://developer.android.com/reference/android/support/v7/recyclerview/extensions/ListAdapter
- better usage of Kotlin, as pointed in the Reddit threads, you need better understanding of it. I suggest Kotlin in Action book.
- null safety, you need to decide what is null and what is not up front in kotlin, by doing that, you almost never need to use
!!
- way too much
?
usage, I didn't take a closer look, but I feel like many of them can be lateinit
, or lazy
or some sort of delegate
. if we use ?
too much, kotlin null safety will be wasted, it's like writing Java code.
There are more things (nit pickings) that I can point out, but I think those are the more critical things that I can point out โ๏ธ Those are just my personal opinion, and by no means is the only correct way, so just read through. I wish to learn too, that's why I'm reviewing your code to learn from the code base ๐
Some further improvement that you can do is to check out how to use Room db, and keep a single point of truth, it will keep data consistency throughout different screens of your app. Also check out MVVM or Redux architecture. MVVM is very similar to MVP, but Redux is very different, but it will gain deterministic state flow, it's not at all popular in Android, but I think it's a good architecture.
This project showcased the TimeTravel in Android Studio for Redux: https://github.com/kittinunf/remote-redux-devtools-android
Regarding 1 day interview project.
There are two sides of making the interview project time into 1 day. Consider:
- if the project deadline is 1 day, you waste at most one day to showcase your current skillset. It however gives pressure and stress to the candidate.
- candidate might think that if he/she failed, it's due to the time constraint, it is likely not the case, because other applicants will also use 1 day
- if the project deadline is 7 days, candidate will spend every night working on it. Similarly other applicants will use 7 days too
- at the end, when the candidate still failed to get it. he/she will be even more upset, since the person invested an entire week on it.
- how about no assignment at all? just 2 hours interview?
- that is possible too, but the more information you can get from the candidate, the better it is to make the most accurate hire, it is the best for both parties
- shouldn't we have the interview first, then only pass the project to the candidate?
- this depends on the strategy of the hiring company:
- do they want to spend more time of the candidates? if yes, let them do the assignment as screening
- do they want to spend more time of their developers doing interview, but saving candidates time from doing the assignment? if yes, then do the interview first, let them do assignment only if they pass the interview
Lastly, I can see very good effort from your repo if it is done in 1 day! despite the stuff that can be improved, I think you did a great job ๐ even included test :)
-- a random dev