ipcam-view
ipcam-view copied to clipboard
lib v2
As proposed by @amadeu01 we should remove rx, guava and old libs no longer needed
@amadeu01 I have no time for this but feel free to create a feature branch and discuss here your proposal for a better clean interface for the lib, if you are interested of course
@niqdev Thanks for mention me. My schedule is quite busy at the moment, but I can have a couple of hours in the middle of the night haha.
I'll bring the ideas here, so we can think of something.
-
I think it is impossible the library be pure Java due to the use of Android SDK, which is fine. But, I could have a core write only in Java which you give only the bitmaps to be used as the user want.
-
We could use Kotlin.
-
As a new version of the library could have behaviour tests or unit tests. I do not have any idea how could write tests for this kind of library. So, instead of writing some documentation. The user can go to the test and learn how to use the library.
+1 for Kotlin and tests, if we can make it more functional, even better. I'm not up to date with the latest changes on Android SDK unfortunately and I never used Kotlin, but I know Scala and I think I should be able at least to follow your changes.
It would be really nice if we could also clean the "core" code which the library wraps like MjpegInputStreamDefault and MjpegViewDefault. If I remember correctly the native C code is not fully integrated and maybe we can even think to remove it. #32 reference an alternative library that it could potentially be used also
We could also implement some travis circleci for run tests and tasks.
I have followed a tutorial about tests, and then I thought would be nice to put some travis and codecov on it amadeu01/ingredisearch
@niqdev I guess functional approach is really nice, I once we do not have to save anything on disk, or sql, or something like that. (Perhaps, buffer the video) When can only consume data and pass other data to some function which is willing to consume that data.
We can reuse some of the configs here for circleci and coveralls if you want. By the way this lib originally born in that project and then I decided to extract it, this is the reason behind those libraries. Now, to get rid of dagger, guava or simply upgrade rx from that app requires to much effort unfortunately.
@niqdev Have you seen that there will be some changes on NDK and ABI Builds on Android studio 3.2 ? I do not know if it is going to have any bad impact to the library, however we can have look at the documentation
sorry for the late response, if we are going to integrate only SimpleMjpegView we can get rid of the NDK
@niqdev I've never worked with NDK in depth. And, I would like to face some trouble and learn with it haha.
So, we could make a "wrapper for the ndk". I mean, we could make other library, that would be only native library. (Code in C/C++).
Then we could integrate it into this library.
Kotlin
I was thinking, if we use kotlin, we could use coroutines which I think could make life easy when get rid of rxjava
If that's the reason +1 if we need NDK, about your link as I said I'm not familiar with Kotlin, so it's up to you