gitnex/GitNex

Fork 37

Rewrite whole app #1000

New issue

Closed

opened 2021-10-17 08:50:54 +00:00 by qwerty287 · 11 comments

qwerty287 commented

2021-10-17 08:50:54 +00:00

Contributor

This is issue #1000 :)

I know that it may be hard to understand why I suggest to rewrite the whole app (even if you prabably would copy most code), and I don't think it's something that will happen in the near future. However, GitNex has lot of old, duplicated code (e.g. #972 (comment)) and some issues with the architecture and structure (e.g. #826, #876, #885) or other issues/features that would require a big refactor (e.g. #354, #907).
I would suggest rewriting the app (at any point in the future) using:

fragments instead of activities
tea4j-autodeploy
maybe Kotlin instead of Java (preferred language for Android development, runs in JVM and is compatible to Java classes)
Android Jetpack's preference APIs
...

This is issue #1000 :) I know that it may be hard to understand why I suggest to rewrite the whole app (even if you prabably would copy most code), and I don't think it's something that will happen in the near future. However, GitNex has lot of old, duplicated code (e.g. https://codeberg.org/gitnex/GitNex/pulls/972#issuecomment-266513) and some issues with the architecture and structure (e.g. #826, #876, #885) or other issues/features that would require a big refactor (e.g. #354, #907). I would suggest rewriting the app (at any point in the future) using: * fragments instead of activities * `tea4j-autodeploy` * maybe Kotlin instead of Java (preferred language for Android development, runs in JVM and is compatible to Java classes) * Android Jetpack's preference APIs * ...

qwerty287 added the

labels 2021-10-17 08:50:54 +00:00

mmarif commented

2021-10-17 13:59:50 +00:00

Owner

I tend to agree with most parts, but as in software industry for long I know there is no such thing without duplicate code, refactors etc.

There is always room for improvements in every line of code. But the real question is not about it should be done that way. The real question is, is it broken for long, does it need a fix?

So as you slowly grow, things get complicated and some time out of hand.

So let's hope one day we rewrite this app, which to be honest with you I don't see it in far future.. haha

Your points:

This can be done now also, if you think an activity can be replaced with fragment.
Yes, that's our plan.
I don't vouch for Kotlin, just because Google invented it and recommend it up our throat.
No harm in using it.

I tend to agree with most parts, but as in software industry for long I know there is no such thing without duplicate code, refactors etc. There is always room for improvements in every line of code. But the real question is not about it should be done that way. The real question is, is it broken for long, does it need a fix? So as you slowly grow, things get complicated and some time out of hand. So let's hope one day we rewrite this app, which to be honest with you I don't see it in far future.. haha Your points: - This can be done now also, if you think an activity can be replaced with fragment. - Yes, that's our plan. - I don't vouch for Kotlin, just because Google invented it and recommend it up our throat. - No harm in using it.

mmarif commented

2021-10-17 14:03:28 +00:00

Owner

So let's hope one day we rewrite this app, which to be honest with you I don't see it in far future.

By that I meant it depends on resources and time. Rewriting the current code would really need some time and going. Not an easy task.

> So let's hope one day we rewrite this app, which to be honest with you I don't see it in far future. By that I meant it depends on resources and time. Rewriting the current code would really need some time and going. Not an easy task.

qwerty287 commented

2021-10-17 14:11:03 +00:00

Author

Contributor

So let's hope one day we rewrite this app, which to be honest with you I don't see it in far future.

By that I meant it depends on resources and time. Rewriting the current code would really need some time and going. Not an easy task.

Of course that needs a lot of time, but probably you could copy much code of the current app (and that's why I added Long-term and Priority-low labels)

Your points:

This can be done now also, if you think an activity can be replaced with fragment.

Maybe I don't understand your point, but of course you can't change the base class of the activities and rename them to ...Fragment. It's a bit more work.

I don't vouch for Kotlin, just because Google invented it and recommend it up our throat.

I'm fine with this, even if Jetbrains invented it and not Google (but Java is although simpler to understand for most people)

>> So let's hope one day we rewrite this app, which to be honest with you I don't see it in far future. > >By that I meant it depends on resources and time. Rewriting the current code would really need some time and going. Not an easy task. Of course that needs a lot of time, but probably you could copy much code of the current app (and that's why I added `Long-term` and `Priority-low` labels) >Your points: > >This can be done now also, if you think an activity can be replaced with fragment. Maybe I don't understand your point, but of course you can't change the base class of the activities and rename them to `...Fragment`. It's a bit more work. >I don't vouch for Kotlin, just because Google invented it and recommend it up our throat. I'm fine with this, even if Jetbrains invented it and not Google (but Java is although simpler to understand for most people)

qwerty287 commented

2021-10-17 14:15:18 +00:00

Author

Contributor

So as you slowly grow, things get complicated and some time out of hand.

Of course (and unfortunately) a rewrite would only be helpful for a few years until there are so many changes that you have to re-rewrite it.

>So as you slowly grow, things get complicated and some time out of hand. Of course (and unfortunately) a rewrite would only be helpful for a few years until there are so many changes that you have to re-rewrite it.

mmarif commented

2021-10-17 14:18:56 +00:00

Owner

I'm fine with this, even if Jetbrains invented it and not Google (but Java is although simpler to understand for most people)

My bad, yes JetBrains not Google.

Maybe I don't understand your point, but of course you can't change the base class of the activities and rename them to ...Fragment. It's a bit more work.

Yes, will need time. But we can slowly do it one by one. Like I do the refactors for pagination in every release.

Of course (and unfortunately) a rewrite would only be helpful for a few years until there are so many changes that you have to re-rewrite it.

True.

> I'm fine with this, even if Jetbrains invented it and not Google (but Java is although simpler to understand for most people) My bad, yes JetBrains not Google. > Maybe I don't understand your point, but of course you can't change the base class of the activities and rename them to ...Fragment. It's a bit more work. Yes, will need time. But we can slowly do it one by one. Like I do the refactors for pagination in every release. > Of course (and unfortunately) a rewrite would only be helpful for a few years until there are so many changes that you have to re-rewrite it. True.

qwerty287 commented

2021-10-17 15:22:53 +00:00

Author

Contributor

I thought a bit about this and I think I can split this a bit into single points:

of course, the things that are already in this issue tracker
- the issues with tinydb
- activities -> fragments
- tea4j-autodeploy
- and so on
but my main issues with GitNex' structure are, which I mainly wanted to point out with this issue:
- there is way too much duplicated code, mainly classes/files. E.g., we have about 7 adapters for repositories - isn't it possible to use one for every case?
- inefficient code, in most cases there are technologies provided by Android/Android libraries that could be used. One example (and something I would refactor first, since it is also required for the transition from activities to fragments) is the NavGraph library, which is used to control navigation for fragments (the current MainActivity just changes the fragment if you click one of the items in the side bar, but this NavGraph is easier and makes the code more readable (docs: https://developer.android.com/jetpack/androidx/releases/navigation, https://developer.android.com/reference/androidx/navigation/NavGraph; maybe I'll see if I can get a refactor for this into 4.2.0 or any later release).

Maybe a whole rewrite isn't the best idea, but it would be good to refactor smaller or bigger things from time to time.

I thought a bit about this and I think I can split this a bit into single points: * of course, the things that are already in this issue tracker * the issues with tinydb * activities -> fragments * `tea4j-autodeploy` * and so on * but my main issues with GitNex' structure are, which I mainly wanted to point out with this issue: * there is way too much duplicated code, mainly classes/files. E.g., we have about 7 adapters for repositories - isn't it possible to use one for every case? * inefficient code, in most cases there are technologies provided by Android/Android libraries that could be used. One example (and something I would refactor first, since it is also required for the transition from activities to fragments) is the `NavGraph` library, which is used to control navigation for fragments (the current MainActivity just changes the fragment if you click one of the items in the side bar, but this NavGraph is easier and makes the code more readable (docs: https://developer.android.com/jetpack/androidx/releases/navigation, https://developer.android.com/reference/androidx/navigation/NavGraph; maybe I'll see if I can get a refactor for this into 4.2.0 or any later release). Maybe a whole rewrite isn't the best idea, but it would be good to refactor smaller or bigger things from time to time.

6543 commented

2021-10-18 15:17:39 +00:00

Member

I'm aware of that duplicated code thing ... I suggest another route: migrating one big issue at a time. and if posible enforce things with linters.

so lets say ativity -> fragments ... after a release before moving on with new features etc ... sit down, create a extra branch and collaborate on that to make that migration. if done, merge it and keep on with normal bussines?

this way, work load is distributed and you can still deliver value :)

I'm aware of that duplicated code thing ... I suggest another route: migrating one big issue at a time. and if posible enforce things with linters. so lets say ativity -> fragments ... after a release before moving on with new features etc ... sit down, create a extra branch and collaborate on that to make that migration. if done, merge it and keep on with normal bussines? this way, work load is distributed and you can still deliver value :)

👍 2

qwerty287 referenced this issue

2021-11-08 17:20:22 +00:00

WIP: Use AndroidX navigation libraries #1014

qwerty287 referenced this issue

2021-11-08 19:22:15 +00:00

Update and improve some strings #1016

qwerty287 referenced this issue

2021-11-21 13:40:53 +00:00

Remove duplicated code #1020