Alpha version hacks won't activate

[andibuch]

I've tried turning both UI settings on, off, and on again. I've tried rebooting. Nothing is getting the nicknames of Pokemon to change in the alpha version for me – although it worked fine in the beta. Not sure about lures; haven't had an opportunity to test that yet.

I'm on an LG G3 D850 running Fulmics ROM 5.3 (Android Marshmallow 6.0) w/ Xposed framework version 86

[andibuch]

Annnd all of a sudden after another reboot it's working o.o

[andibuch]

Now it seems to be the case that whenever a change is made in the UI, an app reboot of Pokemon GO is necessary for it to take effect, but the phone doesn't require a reboot

[ELynx]

Yes. For now, you need to force stop and start PoGo when you change settings. They are loaded on app load, and stored until another load.
I know that this is not as fast as it may be, but reading settings is a slow process in itself.
So, either change settings and restart the PoGo, or have a delay each time a request is sent, to update settings from UI.
As I have both hacks turned on all of the time, I opted for slower settings-faster experience option.
If anybody is interested - I can make a Alpha/Experimental version where settings are checked every time, or once in 3-ish, 10-ish requests. But for this I will need feedback, to know how it affected user experience.
Also notice that PoGo is working with inventory deltas, or, in simple words, it may ask for and get back only new pokemon, or pokemon with changed status. So, if for some 'mon IVs are in nickname, it may stay this way until something happens (HP change, added to gym, bashed from gym).
So, anybody willing to test what I propose?

[krokofant]

@ELynx Couldn't just a FileObserver singleton be implemented which reloads settings only when changes are made?

Then access settings via a Settings object? That wouldn't impact performance so much would it?

[ELynx]

@krokofant Point is that app instance that actually do the dirty work is a separate application, the PoGo app itself. So, as I understand file should be somewhere on FS, which will require permissions I don't want to ask now.
I use Shared Preferences and corresponding XPosed class XSharedPreferences. This way I minimize UI code and so on, which is not the focus of the app.
So, only problem is that XSharedPreferences description of method reload says

Warning: With enforcing SELinux, this call might be quite expensive.

That is why I don't do it every request.

If you know better way to do settings in Android, you can give it a try, I will gladly use some help.

[krokofant]

@ELynx I'll gladly help but I don't have time this week.

For another Xposed module with dynamic settings we have one Options singleton which implements a FileObserver for the modules settings file. The settings is stored in JSON and made with Moshi. When the settings JSON file is updated the Options is automatically reloaded. The POGO app and xposed module can both use an instance of the Options. When an option is requested it just returns the appropriate field from the singleton without additional file reading.

This does require Storage permissions from the module but that's no biggie. Additionally I imagine it would improve sharing settings with others as it'll just be a plain JSON file.

[ELynx]

@krokofant I started a new issue, #5 for this. I think such way to control modules will greatly benefit to final project.
Is this a module you are talknig about? I will have a look there, may be I can copy-paste it myself :)

[krokofant]

@ELynx Great! Yes that's the one.

To avoid confusing, as to wether or not hacks activate, a simple Toast could be added after a setting changes?

[ELynx]

@krokofant Please post ideas there :) othervise whode discussion will be too distributed.
Yes, a toast with No of settings being on and off, may be this will be enough. Like:

[New settings, 3 on, 5 off]

Resolution - new settings transfer should solve this issue. Stay tuned for progress on #5