Este foro usa cookies
Este foro hace uso de cookies para almacenar su información de inicio de sesión si está registrado, y su última visita si no lo está. Las cookies son pequeños documentos de texto almacenados en su computadora; las cookies establecidas por este foro solo se pueden usar en este sitio web y no representan ningún riesgo de seguridad. Las cookies en este foro también rastrean los temas específicos que ha leído y la última vez que los leyó. Por favor, confirme si acepta o rechaza el establecimiento de estas cookies.

Se almacenará una cookie en su navegador, independientemente de su elección, para evitar que le vuelvan a hacer esta pregunta. Podrá cambiar la configuración de sus cookies en cualquier momento utilizando el enlace en el pie de página.

Calificación:
  • 1 voto(s) - 5 Media
  • 1
  • 2
  • 3
  • 4
  • 5
APP GrxSettings V2_1 (under construction) 02/08/2020
#51
(03-02-2021, 01:02 PM)vdvdvd escribió:
(02-06-2018, 09:22 PM)Grouxho escribió: Added a new feature to the app. Now you can define a broadcast with a common action (defined in a string, grx_common_extra_broadcast). Then you can add to each preference two new attributes (grx:commonBcExtra and grx:commonExtraValue)

The idea is that you can personalize a broadcast sent on preference changes. This allows a new way of updating mods (similar to group keys, but using an existing broadcast receiver) but it is still more flexible

You can play with the extra extring and the extra value to update individual groups of preferences. you only have to register in a broadcast the action defined in the string, and when you receive it, get the extra and process it to know what to update.

I will do an example soon.
@Grouxho 
Does an example for this feature exist? I searched but could not find one with grx.commonBCExtra feature described. Can you send a link to this example exists, please.

I want to use an existing intentreceiver, com.miui.app.ExtraStatusBarManager.REQUEST_RESTART, which is used on miui-roms (xiaomi) to update the statusbar if you change a theme.
Do i understand this correctly and i could only update a defined value and not restart the whole statusbar? This would save battery.

ps: this is the way the intent receiver is implemented, 2. example:
[/url][url=https://4pda.ru/forum/index.php?showtopic=760281&st=3360#entry75329976]MIUI - Модификация и украшательства - 4PDA


Hi. Grx app allows you to design mods in several different ways. When you design a mod to work on fly you have to decide how your code (in systemui in this case) will know that a preference changed.

The normal way is via content observer. We add an observer in our mod code to observe one or several keys. When the observer is informed by the system that the key changed the onchange method is called, etc, as you know. Well Grx allows you to use observers in your mods in different ways.

- Normal  way, you can use in grx keys in global, system and secure settings db. So, in your mod you can register what you need, this is the normal way.
- Using group key. Several keys in grx use a group key and then in your observer you only register this group key. When key changes -> you read all pref keys. You can use a button to change a group key, so, only when user decides your mod code willreact.
- The best way, using grouped values feature i added some months ago. Inside a preference screen you can generate a key with a grouped vaue containing all preference values you want to, using alias for preferences keys. In settings system only 1 key  is stored, individual prefs are saved in the grx sharedpreferences. Your observer only need to register one key (the grouped value key). This save system resources. But the cost is that you need to get the individual values from your grouped values key. I prefer this way, because users are not configuring continuously the preferences. I prefer you spend battry reading prefeences values than using the mods. You can use a buttonn for just when users press it (them) your mod will react.


The other way you can use to say to your mods "hey, you have to update something.." is via broadcasts.

When a preference value changes you can send up to 2 broadcasts, by adding to the pref broadCast1 / broadCast1Extra  (action / extra value) and or broadCast2 / broadCast2Extra  (action / extra value). You have to add manuall y every action - extra value. So, in the receiver you want to use you have to register as many actions as you need.

And finally, i added this common broadcast. You can see an example in demo_groupedkey_bcs.xml. By common i mean that is a pre-defined broadcast action. I added this to make easier the way to use broadcasts. You define this common action in grx_common_extra_broadcast. So, all broadcast sent using this feature will use this action, your receiver should register this action.
In the preferences you can define 2 attributes related with common broadcast (grx:commonBcExtra  and grx:commonBcExtraValue) . This feature is oriented to make easier for modder to warn our mod code to do something, but being really simple to design mods for just to update 1 individual thing.
For example, you can have a mod that can update 10 colors. 5 of them are processed in receiver 1, 5 on receiver 2. Or 5 colors are processed in method a and the other 5 in method b. Playing with the commonBcExtra / commonBcExtraValue you add to the mods you can run less code, not needing to update all colors.

You can get this also with observers, vía registered URIs, obviously.  You can combine several options in Grx, using observers and or broadcasts. And even you can configure in grx the order to run these actions. 

The fact is that you can use in one mod one or several ways for reacting to preferences changes and even you can change the order they are sent - written to our mods.

So, answering to your question. I do not know exactly what you want to do because it´s hard to read russian for me, and web translator is not really good, but yes, you can design your mod to do individual tasks, to update individual items or to update many items at same time, etc.
Grx just provides ways to warn your mod to do things. It´s the mod the one that needs to be designed to do things. On the other hand, you have to look for the balance between saving code updating mods and making more complex code for updating individual things.

Let´s say you are doing a mod that can update 30 icons in sb. You can design your mod to update individual icons, or to update some of them each time, or all at once. Whatever it is the way you decide, Grx preferences, group-grouped keys, bcs, etc allows you to design the code as you need.

Following with the example, If you want individual color pickers in grx for each icon, and you want to update individual icons in your mod, you could you could add the same common extra to the 30 prefs and a different common extra value to each preference. In your mod you have to process this. Depending on how you designed the mod it will be harder or easier. But you have to read settings db anyway.
I could add an addicional couple of extra - value to this with the key name and string representation of the preference value. But the problem is on boots, how i send to all mods these couple of keys -values... Well, i could, but may be when i update the app i add it.
I think it´s enought for now.

I hope this explanation helps
Responder
#52
thank you for your great explanation of how updating mods with grxsettings is possible. Probably best way for me, depending on my own knowledge, is stay with the common broadcastreceiver way you described (pref broadCast1 / broadCast1Extra  (action / extra value) and or broadCast2 / broadCast2Extra  (action / extra value). 

I have to increase my knowledge to implement mods to be able to use your new features like grouped values. This i a great feature, but in the end a mediocre modder like me might not be able to get the implementation done. I have the same problem like many other modders, i just have little spare time for this beautiful hobby, which basically mean i will get better, but only slowly.
[-] Recuento: 1 usuario dice Me Gusta a Invitado por este post:
  • Grouxho (03-02-2021)
Responder
#53
gracias por el tema
Responder


Salto de foro:


Usuarios navegando en este tema: 1 invitado(s)