Faster access to some event parameters or Settings sections

[mvitaly2003]

Currently both event and PPP settings look like a very long lists of chapters pointing to subsections, and it is very boring to play with some settings intensively, e.g. adjust some setting, try how it works, adjust it again etc. One of probably frequently used settings section is mobile cell configuration (starting scanning for new cells, enabling/disabling new cell notifications etc). It would be nice to be able to jump to such settings faster.

Some ideas:

1. In an event settings: hide non-configured chapters by default (may be configurable) and show a paragraph with button for displaying all chapters. So if a user configures 5 parameters, he will only see 5 chapters with these parameters and 'show all' item.
2. (instead of # 1) Remember scroll position in settings in app cache. Event name/ID and page name/ID (there is a number of long setting pages: event preferences/PPP settings, Location scanning, Mobile cell scanning etc) may be used to create a combined unique identifier of a location for which scroll position should be stored/loaded, e.g.: "/Event preferences", "/Event preferences/Mobile cell sensor", "/Application Settings/Mobile cell scanning". I think this should be easier to implement than # 1 because it doesn't require to modify dialogs.
3. (additional) Add widgets or actions for common Settings sections to application so a user could add a widget or create a shortcut using e.g. Shortcut Maker app. E.g. some of such sections are "Location scanning" or "Mobile cell scanning".

[henrichg]

Not, it is not one list of preferences, all preferences (app, event, profile) are separated into sub-preferences. For example, Mobile cells sensor is sub-preference. Sub-preference is another screen.

In app settings is implemented (and used) "scrolling" into sub-preference. This displays sub-preference directly and is used, when it is necessary to direct switch to a specific preference. But scroll in sub-preference is not implemented. For example. "Mobile cell sensor" has preferences with direct link to "Mobile cells scanning" app sub-preference: "Moble cells scanning", "Mobile cells editor". Then is not needed to close event preferences and swith to PPP Settings "Mobile cell scanning".

For profiles and events it is problem, because must be used also profile id, event id.

Hiding non-configured chapters (sub-preferences) by default is bad idea. For each new event is not configured any sensor. Result: open of preferences for this new event do not displays sensor preferences at all. Not good for user.

Widgets for this is also bad idea. Configuring this widget will be very complicated for user.

[mvitaly2003]

I see that settings are separated to subpages, you can cache position for every page separately, it should be easy, just remember scroll position for every dialog (by its id or title, doesn't matter, together with event or profile id/name).

And what about at least a widget/command for opening Mobile cell scanning dialog? Or maybe a main menu entry? Shortcut on desktop would be the fastest way to the dialog though. I don't like too many shortcuts but some are very useful. E.g. I have an intercom app and it exports a command for opening the door, I've added an icon to my desktop for opening the door, it is awesome.

[henrichg]

Maybe scrolling is possible (get and set), I must search, if it is possible, in PreferenceScreen (PPP uses standard API = class PreferenceScreen). But how to save it? For each profile id, event id? + last displayed sub-preference?

Widget/command for opening "Mobile cells scanning" dialog? This is Activity (full screen) with PreferenceScreen, not dialog. Again, in "Mobile cells sensor" exists parameter "Mobile cells scanning" and this opens "Mobile cells scanning" PreferenceScreen as another full screen (not dialog). And you can get back to "Mobile cells sensor" with back gesture/navigation button. Why you then need dialog for this? And this dialog will be accessible from? Home screen as shortcut? Notification? Quick tile? By me is better to use "Mobile cell sensor"/"Mobile cell scanning" for this.

[henrichg]

Or you need to direct open of "Mobile cells scanning"? Not from Editor/Settings or Editor/event/"Mobile cells sensor"? Direct open? Why? Because you often reconfigure cell ids and names? Then you are only one with this needs. Hm, hm. I will think about it.

[mvitaly2003]

But how to save it? For each profile id, event id? + last displayed sub-preference?

Just save into app cache a dictionary with string key describing location (e.g. like I suggested, "event_id\dialog_id", e.g. "/events/At Home/Mobile cells sensor" for "Mobile cells sensor" page of "At Home" event, or "/appsettings/Mobile cells scanning" for global "Mobile cells scanning" dialog) and scroll position value. It will not affect app configuration, just a temporary storage. It is easy, isn't it?

Widget/command for opening "Mobile cells scanning" dialog? This is Activity (full screen) with PreferenceScreen, not dialog.

You're right, it is not a dialog but a settings page. Anyway, yes, this page that may be opened either from app settings or from event parameters is the one that is used frequently. You can open it as if it was opened by user from app settings. One could add an icon to desktop, either a widget or a shortcut, for faster access.

Because you often reconfigure cell ids and names? Then you are only one with this needs.

I think everyone needs to open this page frequently while configuring events, at least until most cells will be added to the database. When I reset cells database, I have to start scanning multiple times and enable/disable notification even more times to be sure that my events won't fail because of an unknown cell.

BTW I've checked with Shortcut Creator, PPP already has a bunch of public activities that may be used for a shortcut, e.g. ".PhoneProfilesPrefsActivity" opens app settings, ".LaunchSamsungEdgeConfigurationActivity" directly opens "Samsung edge panel" settings subpage, also you have some other ".Launch*" activities. It would be enough to add similar activities for some other settings pages...

[henrichg]

"Just save into app cache a dictionary". Yes, but if PreferenceScreen do not supports get latest scroll location and set it, then is not possible to implement this. :-(

"I think everyone needs to open this page frequently while configuring events" No, user needs to configure sensor in Editor, not needed to start sensor preference outside of PPP. Maybe "Mobile cells sensor" is exception.

Public activities are: ActivatorActivity - to open Activator EditorActivity - to open Editor from shortcut PhoneProfilesPrefsActivity - to open settings from widgets,PPP main notification LaunchWidgetIconConfigurationActivity - to open settings from icon widget LaunchWidgetOneRowConfigurationActivity - to open settings from one row widget LaunchWidgetListConfigurationActivity - to open settings from list widget LaunchSamsungEdgeConfigurationActivity - to open settings from Samsung edge panel LaunchWidgetOneRowProfileListConfigurationActivity - to open settings from one row profile list widget ShortcutCreatorActivity - to open list of profiles for creating shortcut to profile BackgroundActivateProfileActivity - for activating profile, restart events from several sources ActionForExternalApplicationActivity - for Tasker support NFCTagWriteActivity, NFCTagReadActivity - for NFC support TileChooserLongClickActivity - for quick tile long click support NotificationsPreferncesActivity - to open PPP main notificaiton settings

Activities, which opens PPP settings (for widgets, PPP notificaiton), opens sub-preference at root of this sub-preference.

[mvitaly2003]

This not exists in PreferenceScreen.

I mean, you can save a file with list of pairs, in any format (JSON, XML, tab-separated text etc.).

No, user needs to configure sensor in Editor, not needed to start sensor preference outside of PPP. Maybe "Mobile cells sensor" is exception.

At this time, I only know that "Mobile cells scanning" page is frequently accessed, so maybe it would be enough to have an activity for this page.

[henrichg]

Added in "Mobile cell scanning" "Shortcut to "Mobile cell scanning"". This creates shortcut to home screen. If you want, test it: https://drive.google.com/file/d/1CR4y2u3V8PCwQK9sw1P88JrlpSdA2Ou4/view?usp=drivesdk

[mvitaly2003]

Thank you, it works:)

But it would be still nice to remember scroll positions in dialogs.

[henrichg]

Added "Hide not used sensors" into Event preferences. https://drive.google.com/file/d/1CR4y2u3V8PCwQK9sw1P88JrlpSdA2Ou4/view?usp=drivesdk

[henrichg]

"But it would be still nice to remember scroll positions in dialogs." In PreferenceScreen not dialog.

Opinion: In "Mobile cells scanning" is visible, even when is at top: "Location system settings" "Mobile cells editor" "Cell registration"

Or you want to remember scroll position in "Mobile cells editor"? But when you change Filter, then is not possible to get scroll, becaiuse list items (cell ids) are changed. Used is database sql query to get cells by set filter.

At first open of "Mobile cells editor" is filter set to "New (N)". And by me, you change it to another.

[mvitaly2003]

No, no need to save position in cell list. Only in long settings pages.

I'll try latest beta to test hiding sensors.

[henrichg]

@Vitaly how?

[mvitaly2003]

Well, it works, however I think it is not very friendly to have global setting in every event that have to be disabled to view all sensors or add a sensor to existing event. Perhaps it would be better to move this setting to Settings/Editor (and maybe enable by default?) and show a button "Show other sensors" instead of the switch in events when something is hidden to show hidden entries temporarily.

[henrichg]

Hide not used sensors by default is not good for user. User must know, which sensors are in event. Yes, for new event (added), all sensors are visible, even when hiding is enabled, but when user enable sensor and save event, all sensors will be hidden, except of enabled sensors. Not good, not good for user. Also in older PPP versions, all sensors are visible and is not good to, in new version, hide all not used sensors by default. The user will be asked where the sensors are.

Moving this parameter into PPP Settings/Editor is also not good. Because even when in release notes of new PPP version will be this parameter listed, users do not read relase notes. :-) And for this reason, never show/hide sensors.

[mvitaly2003]

But they will see "Show unused sensors" item in event settings and, I believe, get the idea. :)

[henrichg]

By default "Hide not used sensors" is false, All sensros are visible. Yes it is global for all events, but it is in [] ("[ Hide not used sensors ]").

What is the difference between "Hide not used sensors" in event and "Show unused sensors" in event? It's the same thing, just the other way around. One hides, the other shows. :-)

[mvitaly2003]

Well, "Show unused sensors" item is only visible when something is hidden and disappears after click, it only does one function, it doesn't affect another events. I doubt that one who likes hiding unused sensors will want to disable hiding.

[henrichg]

And when the user closes the "Event Parameters" screen and opens it again, will the unused sensors be hidden again? And then the user has to click "Show unused sensors" again? And is it user friendly? :-)

[just-Nob]

Me, I personally find the current way of hiding unused sensors to get a better overview very convenient. 😉

[mvitaly2003]

And when the user closes the "Event Parameters" screen and opens it again, will the unused sensors be hidden again? And then the user has to click "Show unused sensors" again? And is it user friendly? :-)

I think that used sensors are usually much more important than unused ones, and the case when you need to see unused sensors is rare, so in that case you have to tap "Show unused sensors" once to see all sensors once w/o enabling displaying unused sensors globally. If you enable one of unused sensors in an event, it will be visible next time w/o clicking "Show unused sensors" again, but other unused sensors will still be initially hidden.

[henrichg]

By me and by @jus-Nob is current implementation OK. Click to "Show unused sensors" is the same as click to "Hide not used sensors".

If user click it to hide sensors, sensors will be hidden all the time in all events. If user needs add new sensor, then only in this situation must click "Hide not used sensors" to add new sensor. And if user want to edit sensor, is user choice to again click "Hide not used sensors", to show only used sensors or scroll into sensor which user want to edit. It is user choice.

[mvitaly2003]

Click to "Show unused sensors" is the same as click to "Hide not used sensors".

Except that clicking "Hide not used sensors" has a side effect (it disables global hiding option). But it is your choice of course, we can only give you ideas. Either way is better than before anyway.

[henrichg]

OK, closed.