Rollo62

Hello everybody, I'm just testing some effects of the required Android permission system, and would like to check with you what would be the best practices. I have used and checked the wonderful KastriFree project from Dave, it all worked well to get things solved. There are the two (actually 3) levels "Normal permissions" and "Dangerous permissions": with "Dangerous permissions" its clear: you need to ask the user for interaction via PermissionRequester But how to handle "Normal permissions", lets take WakeLock as an example ? I can check WakeLock in the "uses permissions" list in the IDE, and don't need a PermissionRequester at all. Would it be better to use the same permission requester process also for WakeLock, although its not needed ? What I found so far is, that it will work with the requester, but simply always grant the permission. I personally would tend to use same procedures now, no matter if "Normal" or "Dangerous", just to be consistent, as well as to be ready for future permission changes. Or is there any reason why I should NOT use "Normal" permissions in same way ? Rollo

Yes, but maybe its good practice to do it always with the same procedure - to have same procedure, no matter if dangerous or not, will avoid hard to find setting errors - to ensure that, if Google considered this or that topic as dangerous in the future, my app is already well prepped Maybe for other good reasons too. Is there anything that speaks against such "overuseage" ? Rollo

Dear Primoz, thanks for the nice article. For me personally (this is not that I want to convince everybody), I like and use another pattern quite often in such cases: conn.SetupBridge_FromRelative(url : String); conn.SetupBridge_FromAbsolute(url : String); conn.SetupBridge_FromXxxx( ....); This makes it a lot easier for me to choose the right version, and I got clear parameter lists, on the cost of longer function names, of coarse. Since I'm a friend of long and "speaking" names, this is not a big problem to me, but I can confess this can get nasty in some situations too. Rollo

Your right, but unfortunately ApplyStyleLookup seems not always be consistent, (ApplyStyle in some cases), depending on the component. So I would love to find a common "best practice", which could be used for all controls. Until this may be available, I mostly use rather primitive controls, and I got used to that already well. Some of these simple controls run even well under the "Defaut" platform style, so no need to define "Win", "OSX" styles, etc. separately. But I'm talking here about TRectangle or the like. I understand that the platforms are the reason to have different styles in the first place, but I also would like to have a common set of controls, which could be easily custom-styled and live in the "Default" style. Maybe tít would be possible to define some own control sets, which would be able to handle such styles in a more general way, hopefully one day I will have more time to make such experiments.

I almost forgot XE2 already, beside the name, and only that I was very exited about the possibilites of FMX 🙂 More problematic than the 'rect' I find the FindStyleResource, which not always gives a valid result. So you should take care when and where you ask for FindStyleResource, because sometimes you will get nil. I changed all my settings usually from FormCreate to FormShow, which has other issues then, but its not that easy as in XE2 (or better VCL) any more, your right.

Right, I use a separate form for the Styles editing, and preparing a StyleBook component. With that Stylebook, you can copy and paste by the way, you can use them in other Frames etc. too. The nice thing is that the StyleName property is visible project-wide, and can be used everywhere. Once you have a knd of "common stylebook", its possible to reuse this. Unfortunately the Style system is far from easy to use, but thankfully EMBT offered the export as .style in text. If this option would not be there, I would not touch styles either.

This is all right, I use it only on more primitive controls. But the style concept of FMX is so much more than only changing PNG images. Its possible to add components, animations, etc. You're right, the existing style elements are sometimes hard to configure, but EMBT has added e.g. the TStyleColor Object to ease at least re.coloring. But for own styles you can do a lot more. Rollo

You mean "Edit Custom Style..." will be gone in 10.3, because I still have it stioll available in 10.2.3 ? This would be a major change in possibilities of the style system, from where do you have that information ?

Just a fast test ... You can e.g. add a custum style by rightclick on the Edit1. This will open Stylebook, with some automatic naming. I usually use my own names, e.g. with starting "_", to easier find them again in that possible long list of styles. Analyse the control, and add or change what you like. E.g. you can add TRectangle in the style, as I did here. Other controls may have direct access to colors, rectangles, etc. With the added rectangle, you can add a specific name, here "background_rect", and you can find and access this as you wish. ! The Edit1.StyleLookup must of coarse now get the new style name "_myeditstyle", to switch to that. I hope that helps to show one possible options howto customize the styles. Rollo T223_EditStyle.zip