-
-
Notifications
You must be signed in to change notification settings - Fork 39
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tech debt/Migrate to Androidx settings #240
Tech debt/Migrate to Androidx settings #240
Conversation
@bekuno If I tested correctly, I should be done with this. BUT we lost the summarys per default. Either I can implement some summary providers to preview settings or we have a small behavior change. P.S.: Please test this manually before merging. I really would hate to be the one that breaks stuff in here but I feel like I am "Betriebsbild". |
@SchoolGuy I set DNM for now. Please check your changes. Please divide it in different PR which are logical clear. By the way, the project was already migrated to AndroidX. |
@bekuno Okay I will separate the code optimizations again and will submit them afterwards/separately. They always laugh at me and I can't resist to refactor stuff so it looks better - according to my knowledge and taste. About the rest: These are the required changes. Nothing more. I looked over them again. Using the AndroidX Settings (which we are not using, although we are using AndroidX in general) requires me to fix things which were "working" before. Thus everything you see now can be seen as an atomic change. The two commits after the main one are technically not needed but would leave the application in a different (not so good) looking stage. Thus I would see them as required due to the fact that we want to change as little as possible for the users. If you want to fiddle the changes into separate PRs you are welcome to do so but I then don't understand your pattern in this case. Thus I would love if you could spare us both the back and forth and do it yourself. I thought about splitting this for a full hour and the time addressing your wishes is starting to supersede the time which I need to implement the features... |
Also what I did was the way the official guide is showing as one option: https://developer.android.com/guide/topics/ui/settings/organize-your-settings#split_your_hierarchy_into_multiple_screens One Step further: What we did is no longer supported! https://developer.android.com/guide/topics/ui/settings/organize-your-settings#preferencescreens |
@SchoolGuy Sorry for the confusion. But I was confused - and misread your AndroidX plan. It is fine to migrate the settings management to a modernized state using some AndroidX jetpack functions. I hope that I can test the changes at weekend. |
both are the same links :-/ |
@bekuno I thought they had anchors... Anyway I will get you the quotes when I am in front of a computer and not on my mobile... |
@bekuno Did a ninja edit to the original post |
@bekuno How is the testing going? |
There is something broken:
in |
The initialization was done in L236 |
@bekuno Since this is deprecated since API 29, I will try to fix it via replacing the functionallity of this method. We are using the "current" approach and thus we can't use the deprecated API. I was not able to reproduce your errormessage but I understand how it was produced... |
@bekuno May I remove all Preference compability below 0.9.3. We have overtaken since that version and everything older was a "different" app. Thus I would love if we could cut that. That would enable me to cut out our custom "Preference" class. This would mean we would make the life easier when using SharedPreferences and would not need to criple the implementation of SharedPreferences for backward compatibility of something we don't even support anymore. |
Nvm. I found that there is a 1:1 replacement. We can fix it via other means. Commit is in progress. |
The app was not migrated to a new one. If we implement a new system to store the user configuration then we need a way to migrate the settings from old to new. |
For details see #52. |
So now when we start the application for the very first time (that's why I never got your stacktrace), the application starts successfully. But the usage of settings is in my eyes a pure abomination of the Preferences Framework. I would do it like I did it in lines 250-254. But I guess this is something for another PR because this then requires real migration. The XML Files for the settings do not persist their settings currently. This means everything stays in a single file for now. |
@bekuno Review request. |
src/main/java/menion/android/whereyougo/gui/activity/XmlSettingsActivity.java
Show resolved
Hide resolved
@bekuno It appears that your Jenkins seems to hang? (at least for this PR) |
@bekuno @moving-bits I think it is time for the (hopefully) final review. Things that will be separated:
|
@mucek4 fired cgeo-3 up again. |
Can you exclude the style changes from this PR or are they necessary for the function? |
@bekuno Afaik this is required for AndroidX to work correctly. The reasoning I found is the following: https://developer.android.com/guide/topics/ui/look-and-feel/themes#Customize Although this might not directly feel related to this PR, this is required because we now use Jetpack and they are the "new" Support Library. The other Android Apps I have worked with have followed the same principle. |
Ping @bekuno @moving-bits |
sorry, wasn't actively monitoring this. Did a quick glance & installed the PR locally. Generally LGTM, thanks for all the work you've put into this! A few tiny observations regarding changes in behavior compared to the current implementation:
|
Don't worry
Yes I did this on purpose to make it shorter. Of course with an additional commit this can be changed. Whatever you like better but most of the descriptions can't be read anyway because they are too long. I wanted to keep it simple, in this case this means a change of behavior.
Havn't changed that (at least to my knowledge). If you desire I can also change that.
I added as a fallback to all (maybe I have overseen one) settings that the description gets shown if no value is set. In the case of the language I am also showing this if the language is set to the default one. (see
Yes you asked that before... ;) |
@SchoolGuy With respect to the button order: It would be nice to have this consistent, so I would ask you to update it, if possible. And for the map's preferences: Maybe it's better to do this in a separate PR, to get this PR "out into the wild". (I only wasn't sure whether it was untouched yet or something was missing, that's why I asked.) |
Will do the button order tomorrow. |
@moving-bits @bekuno Ping. How does it look now? :) |
ok from my side. @bekuno? |
So any chance we merge this? I really would love to do the original task with adding a button to let the user check his credentials! Also I would love to modernize many more things. The mapsforge maps are also not done afaik. |
@bekuno |
(Note to the team: PR should be squashed on merging.) |
I did a short test the last days. I did not found any problems. |
// Set language | ||
SharedPreferences sharedPreferences = PreferenceManager.getDefaultSharedPreferences(getApplicationContext()); | ||
String lang = sharedPreferences.getString(getString(R.string.pref_KEY_S_LANGUAGE), ""); | ||
setLocale(this, lang); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we need the language management in different classes (here and in XmlSettingsActivity)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes because the settings are not inheriting from the CustomActivity
anymore but instead are inheriting from AppCompatActivity
. Otherwise we need to change the implementation of the CustomActivity
and this would have drastic effects for the whole application. That' why I duplicated this part. If you desire I can try out if it is possible to use the AppCompatActivity
as a base class for the CustomActivity
.
@bekuno @moving-bits What is missing to merge this? |
Let's merge this one here, has been waiting in line for quite some time already. If there's anything to fix left, we can still open a new issue. Thanks @SchoolGuy for your patience! |
Currently we are using our own settings. This is not desired as this is code we need to maintain. The Jetpack library gives us everything we need via AndroidX. Thus let's use that and reuse what people smarter then us invented. At least that is my proposal. Also this makes #210 stupidly easy to implement.