UI for choosing reminder type

[felixwiemuth]

Help wanted: You can help by looking up how this could be realized, find or design icons and potentially also do the implemention. You do not need to know anything about the app's implementation.

In the near future, there will be three reminder types: simple notification reminders, nagging reminders and alarm reminders (separate issue will follow soon).

(Recurrence is a feature independent from the reminder type.)

We need a UI in the Add/Edit Reminder dialog that allows to efficiently choose the reminder type while not using too much space.

My idea is to place a selection button next to the reminder text field, where currently the switch for nagging reminders is. Clicking this button will open a floating menu with 3 buttons, each with a corresponding symbol representing one of the reminder types. Clicking one of them closes the menu and the selection button will show the selected symbol, meaning that the respective reminder type is selected.

An example for such a floating menu is the sound/vibration/silent menu on Android 12, reached by clicking a volume button and then clicking on the symbol at the top.

Individual settings for each reminder type can be performed by long-clicking the respective button (either on the selection button, or in the floating menu). The long-click will open a new dialog with further settings, as it is for nagging reminders now, and closing this dialog with an affirmative action will also switch to this reminder type (this is relevant when long-clicking in the floating menu).

In a later, advanced version, I would like to add swipe/pull controls to the reminder type buttons. For example, to change the nagging repeat interval, one could pull the button up or down, which will continuously change the value up or down until releasing.

The symbols used to represent the reminder type should also be used in the reminders list to indicate the reminder type, and maybe also as the notification's symbol.

Tasks

• Button with floating menu
  • Find out how this can be realized. It would be optimal to reuse Android 12's sound/vibration/silent menu.
  • Place the button in ReminderDialogActivity.
  • Implement behaviour that when clicking one of the button in the menu the selected reminder type is updated (a variable in the activity and the symbol of the selection button should be updated).
  • The long-click action and dialogs with further settings are not part of this issue.
• Find or design icons
  • It is always good to reuse standard icons where they fit.
  • Basic notification reminders: a symbol representing a notification
  • Nagging reminders: similar to the one for basic notifications, but with an addition indicating the nagging, for example stripes at the sides as used in symbols indicating vibration, some periods, ...
  • Alarm reminders: could be the bell symbol Android uses for "sound" in the sound/vibration/silent menu

[maxcutlyp]

Hi, I'd like to take a look at this issue.

Android 12's sound/vibration/silent menu seems to use a LayoutInflater - see this XML file that defines the layout and this function that returns the View created by inflating the layout using a LayoutInflater.

You mentioned that the button should go in AddReminderDialogActivity, but would it make more sense to put it in the parent class ReminderDialogActivity so that it can be used in EditReminderDialogActivity as well? This is where naggingSwitch currently is, which it would be replacing. Apologies if I'm wrong here, this is only from a cursory look around the codebase.

Also, I'm not quite sure I understand what the alarm reminder is going to be. It would be useful to know more about it to decide on an icon for it, but based on the name I think something like what is currently used for notifications (ic_lock_idle_alarm) would work for alarm reminders, while a bell symbol could be used for notifications (I think the one you mentioned for alarm reminders would work), and maybe the same bell with a ! through it on the right hand side could work for nagging reminders? I could make a mockup if you'd like, although I'm not much of a designer.

These are of course all just my two cents, let me know what you think.

[felixwiemuth]

Hi, I'd like to take a look at this issue.

Hi @maxcutlyp, thanks a lot for your interest and what you already found out!

Android 12's sound/vibration/silent menu seems to use a LayoutInflater - see this XML file that defines the layout and this function that returns the View created by inflating the layout using a LayoutInflater.

The commit where the global_actions_silent_mode.xml file you point to was last changed might also contain some useful hints ("Implement a new volume panel widget, combining volume and zen mode + conditions"). But I am a bit confused that this is from 2014, while I think the menu I described is rather new. Also, I don't know what they mean with Zen mode.

Your link "this function" doesn't work, can you correct it?

You mentioned that the button should go in AddReminderDialogActivity, but would it make more sense to put it in the parent class ReminderDialogActivity so that it can be used in EditReminderDialogActivity as well?

Of course, you are right, it should be done in ReminderDialogActivity (the Add/Edit subclasses are basically the same UI-wise). I updated the issue.

Also, I'm not quite sure I understand what the alarm reminder is going to be. It would be useful to know more about it to decide on an icon for it, but based on the name I think something like what is currently used for notifications (ic_lock_idle_alarm) would work for alarm reminders, while a bell symbol could be used for notifications (I think the one you mentioned for alarm reminders would work), and maybe the same bell with a ! through it on the right hand side could work for nagging reminders? I could make a mockup if you'd like, although I'm not much of a designer.

An alarm reminder will result in an alarm like alarms from the stock Android alarm clock app. So the icon android.R.drawable.ic_lock_idle_alarm seems suitable, it is also used in the stock alarm clock app for the alarm section. And then I should probably not use this symbol anymore as the notification icon for normal reminders. I'm still missing a writeup about alarm reminders, but I think this should be enough information to implement this feature.

Apparently the bell symbol seems to represent notifications on Android. In Android 12, having a notification channel set to "Default" ("May ring or vibrate based on phone settings") a bell with two stripes at the top (indicating ringing) is shown, whereas having it set to "Silent" the bell is crossed out.

I find the bell symbol a bit unfortunate if it should represent notifications in general, because it suggests that there is a sound while it is up to the user to configure whether the notification channel should make a sound, vibrate, or be silent. If we can find a more neutral symbol to represent notifications that would be better in my opinion. But if it turns out that the bell is the best/most suitable, then that's also fine.

A ! for nagging reminders is a good idea - I think it depends on what symbol we eventually use for normal reminders, and which addition/modification would fit. You are welcome to make mockups if you like.

You are very welcome to go ahead and try to implement the menu. If you want to start making commits, create a branch "feature/reminder-type-selector" in your fork. If you want to include and modify files from the Android Open Source Project, please first commit the unmodified file where you

• include a permanent link to the file(s)'s/directory's origin in the project's public repository (this should include the commit hash; on Github, choose "Copy permalink" from the menu when opening a file) in the commit message
• add an entry to the "Included modified work" in the LICENSE.md file

Then you can replace the copyright header with the project's one and make changes.

Be aware that currently I am refactoring major parts of the project, including conversion to Kotlin (see #27). But as ReminderDialogActivity is still in Java (and probably will stay like this for now) you shouldn't have to worry.

[maxcutlyp]

The commit where the global_actions_silent_mode.xml file you point to was last changed might also contain some useful hints ("Implement a new volume panel widget, combining volume and zen mode + conditions"). But I am a bit confused that this is from 2014, while I think the menu I described is rather new. Also, I don't know what they mean with Zen mode.

Wow, I guess it must have been in the works since 2014. And I'd only be guessing, but maybe "zen mode" refers to the silent (non-vibrate) option, which may have previously been a separate feature? I'm not sure.

Your link "this function" doesn't work, can you correct it?

Whoops! Yes, this is the correct link, and I've edited it in my original comment. For some reason, GitHub's search gave me a file from an old commit, which I naively changed to "master" in the link without testing it, assuming they would be identical. The same function exists in the current master branch, although in a different file (linked above).

I find the bell symbol a bit unfortunate if it should represent notifications in general, because it suggests that there is a sound while it is up to the user to configure whether the notification channel should make a sound, vibrate, or be silent. If we can find a more neutral symbol to represent notifications that would be better in my opinion. But if it turns out that the bell is the best/most suitable, then that's also fine.

I agree. However, it seems like the bell symbol is used almost universally as a generic notification icon, to the point that I think people don't really think of it as "sound" unless it's directly contrasted with a "no sound" symbol, like in Android's silent mode menu (a Google image search for "notification icon" shows almost entirely bells). I'd compare it to the way a floppy disk is still used as a "save" icon even long after floppy disks are no longer used.

I think that a different symbol would be preferable but I can't think of what such a symbol would be, so I think that a bell (without extra lines to indicate sound or a line through it to indicate silence) would be best unless you (or anyone else) can think of something better.

Thank you for the rundown on proper copyright/licensing, I'll make sure to do that as necessary.

[felixwiemuth]

Thanks for the link! If it suffices to implement sth. like the SilentModeTriStateAction class (if that's what implements the menu) that would be great.

I agree. However, it seems like the bell symbol is used almost universally as a generic notification icon, to the point that I think people don't really think of it as "sound" unless it's directly contrasted with a "no sound" symbol, like in Android's silent mode menu (a Google image search for "notification icon" shows almost entirely bells). I'd compare it to the way a floppy disk is still used as a "save" icon even long after floppy disks are no longer used.

Yeah my image search came to the same result. I think too that the bell symbol (in the plain version) is fine then.

Thanks again and I'm curious what you'll come up with :).

[maxcutlyp]

Hey, I'm having some trouble setting up the dev environment. I made a local.properties file and put the Android SDK dir in it (sdk.dir = /path/to/Android/Sdk) but running ./gradlew produces an error (this error is the same regardless of what I put after ./gradlew, other than --help and --version which print the correct respective outputs):

A problem occurred configuring project ':app'.
> Failed to notify project evaluation listener.
   > Could not initialize class com.sun.xml.bind.v2.runtime.reflect.opt.Injector

Is there anything else I should put in the local.properties file?

In case it's useful, here's my ./gradlew --version:

------------------------------------------------------------
Gradle 4.10.1
------------------------------------------------------------

Build time:   2018-09-12 11:33:27 UTC
Revision:     76c9179ea9bddc32810f9125ad97c3315c544919

Kotlin DSL:   1.0-rc-6
Kotlin:       1.2.61
Groovy:       2.4.15
Ant:          Apache Ant(TM) version 1.9.11 compiled on March 23 2018
JVM:          18.0.1.1 (Oracle Corporation 18.0.1.1+2)
OS:           Linux 5.18.2-1-MANJARO amd64

I assume you're using Intellij IDEA from the .idea folder. I'm quite new to Android development, and I haven't used Intellij for it before. I managed to get a "Run Configuration" for SimpleReminder [app:build], which also produces an error:

Could not determine the dependencies of task ':app:lintVitalRelease'.
> Could not resolve all task dependencies for configuration ':app:releaseRuntimeClasspath'.
   > Could not resolve project :sectionedrecyclerviewadapter.
     Required by:
         project :app
      > Unable to find a matching configuration of project :sectionedrecyclerviewadapter: None of the consumable configurations have attributes.

I'm sure I'm doing something wrong, so it would be nice to know how you set your dev environment up. Maybe I missed some build instructions? Thanks!

[felixwiemuth]

Hi, I'm sorry that you got into troubles building the project. It sounds you might be missing the git submodule (sectionedrecyclerviewadapter). Simply run git submodule init and then git submodule update in the project's root directory, and then it hopefully builds.

It should be easiest to use Android Studio; except for installing the right gradle and SDK version, which it will help you with, you shouldn't need to configure anything before being able to build.

If you are still having troubles, you might want to wait until I push the maintenance changes, which remove the submodule and update gradle.

[maxcutlyp]

Thanks, that definitely helped. I had to add lintOptions { abortOnError false } to android { ... } in app/build.gradle though, because I kept getting a linting error that said that "this is a bug in lint or one of the libraries it depends on", and to add the above to ignore it. It's of course not a good solution, but since that bug is fixed in Gradle 3.4.0 and you're in the process of updating it, I don't think it's much of an issue.

Other than that, I've got it built and running in Android Studio! Thanks again for the help :)

[felixwiemuth]

Perfect! Then good luck with the rest, let me know if there are any problems.

[maxcutlyp]

Thanks, will do!

[maxcutlyp]

Update: my initial guesses were quite wrong.

Upon further research, LayoutInflator does not do what I thought it did - my current understanding is that it's basically just a way to load an XML file into a View and modify it before adding it to a parent (see this SO answer for details). In SilentModeTriStateAction, it's used to set the selected option and to add click handlers.

Additionally, I'm reasonably certain that SilentModeTriStateAction is not what is currently used for Android's ringer mode menu. First, the global_actions_silent_mode.xml layout is horizontal (see line 21). Second, the icons are listed in a different order to how they appear in the menu - they should go vibrate, silent, ring but in the layout XML they go silent, vibrate, ring. Third, while I linked to it earlier in GlobalActionsDialogLite.java, it also exists in LegacyGlobalActions.java.

The file the volume dialog is actually in is VolumeDialogImpl.java. This uses the layout from volume_dialog.xml which <include>s volume_ringer_drawer.xml, and that is the layout we want to emulate.

Unfortunately, this means it's a custom solution - we can't just use some preexisting "drawer" class (although DrawerLayout sounds promising from the name, it's unrelated). Fortunately however, the parts of the code in VolumeDialogImpl.java that relate to the drawer are helpfully commented, so it shouldn't be too much of a struggle to replicate it (with the correct licensing, of course). I suspect the biggest challenge will be to decouple the ringer drawer code from the rest of the volume panel code.

I'll try to start actually writing code tomorrow.

Also, for your interest, "zen mode" seems to refer to "do not disturb mode".

[felixwiemuth]

Thanks for tracking down to the actual implementation! It's unfortunate that they apparently didn't implement it in a modular way (a reusable menu).

Maybe it might be worth to first look for libraries that might provide a similar menu? The one from the volume menu seems neat and practical, but it's not necessarily the best. And if there are other menus/buttons that require less work to incorporate, modify (e.g., we want a long-click action) and maintain (e.g., what if at some point we want a 4th option in the menu?) then that might be the better choice.

For example, I once found this Advanced floating action button project (here it is described how to include it as a dependency). This could probably provide what we need, but it's just an example and there might be other good solutions. Optimally, it's a maintained library that keeps up-to-date with platform changes, or at least a somewhat robust implementation that will work fine for long enough.

There is also a Android developer guide on popup menus, but this might be too restricted for our purposes (e.g., can the menu items be custom views/icons, can we have long-click actions on those etc.).

When you begin to work on a concrete solution/attempt, you can open a WIP pull request, and we can discuss details there. Just reference this issue.

P.S. Regarding your confusion concerning the use of LayoutInflator: yes it does instantiate a new View/Layout from an XML resource. Maybe "set the selected option" here means to load the view for the selected option (which could even serve as a way of remembering the selected option) and click handlers can actually also be defined in XML with the onClick attribute. It's only a guess, but probably you don't have to deal with that anyway as it is not the code we were looking for.

[maxcutlyp]

Maybe it might be worth to first look for libraries that might provide a similar menu?

I'm inclined to agree, but I'm honestly not sure what to search for. At the core, we just need some radio buttons, but there's not enough space to fit them in the layout, so we need them to expand and float above the rest of the layout. This problem, I think, is quite niche, although the ringer drawer seems to solve it.

I like the advanced floating action button project you linked, but I'm not sure how well it would work for our situation. I think there are two ways we could use it:

1. Try to replicate the ringer drawer using an FAB. This would mean changing the icon of the main button to match the selected reminder type, and making it the same size as the popout buttons. It would also mean popping out the buttons from different sides depending on the selected option to create a consistent order.
2. Use it as advertised - give the main button its own icon and make it distinct from the popout buttons. This fixes the ordering issue, but I'm not sure if the full size button would fit in the layout without increasing the height of the top row (where the reminder text and nagging switch are) or having it occupy part of the title section (where the "Add/Edit reminder" text is). It would also mean coming up with an icon to represent "reminder type" in general, which I'm open to ideas about. A downside of this option is that users can't tell which reminder type is selected without tapping on it first.

I agree that a popup menu may be too restricted, and it also suffers from the icon issue mentioned above.

None of these, in my opinion, match the elegance of the drawer solution (at least from a user's perspective). I like the idea of having titles next to the buttons, but I think that with good icons and toast text they aren't strictly necessary.

Once I have something concrete to show, I'll open a WIP PR.

[felixwiemuth]

I'm inclined to agree, but I'm honestly not sure what to search for.

I would call what we look for "popup menu", "floating menu", "floating buttons" etc.

Another way to find UI components is to explore other open source apps and see whether there is one with a UI one is looking for, and then find the corresponding code. But probably you are right that it is rather niche and not used so often.

I like the advanced floating action button project you linked, but I'm not sure how well it would work for our situation. I think there are two ways we could use it:

1. Try to replicate the ringer drawer using an FAB. This would mean changing the icon of the main button to match the selected reminder type, and making it the same size as the popout buttons. It would also mean popping out the buttons from different sides depending on the selected option to create a consistent order.
2. Use it as advertised - give the main button its own icon and make it distinct from the popout buttons. This fixes the ordering issue, but I'm not sure if the full size button would fit in the layout without increasing the height of the top row (where the reminder text and nagging switch are) or having it occupy part of the title section (where the "Add/Edit reminder" text is). It would also mean coming up with an icon to represent "reminder type" in general, which I'm open to ideas about. A downside of this option is that users can't tell which reminder type is selected without tapping on it first.

I think option 2 is not really an option, it is essential that the current choice can be seen. And making the display of current choice and the selection button two separate UI elements would be waste of space.

I was thinking of option 1, but without the need to worry about order: the popup menu is always the same, regardless of what is already chosen. I think this is actually quite important, as the user will remember the positions of the different choices, and quickly select an option without much thinking. This would be made more difficult if options change place.

With the advanced floating action button (where I probably would choose the radial one, which uses the available space better) we would use it as advertised, just that the main button gets a fixed place with a smaller size (it shouldn't use more space than the current nagging switch) and its icon is changed whenever a choice is made. Furthermore the main button and the popup buttons need a long-click action. I would guess that none of these is too difficult to achieve.

This solution would look and behave very similar to the original idea of reusing the audio drawer solution. The main difference is where the popup menu/buttons appear and how the animation looks like.

So I would rather base the decision of which to use on how easy it will be to integrate/adapt.

I like the idea of having titles next to the buttons, but I think that with good icons and toast text they aren't strictly necessary.

No, we don't need text next to the button; the icons should be enough, there will be an explanation in the help text and the toast when creating the reminder can confirm the selected choice. In addition, a long-click will open the settings for the selected reminder type where the name will be stated. In addition, if we use the advanced floating action button, there might even be space for labels in the popup choices.

An alternative would be to use a Spinner with a custom layout for the entries - these could be icons, and I assume/hope that one can also attach long-click actions to those and the spinner itself. This solution just doesn't seem as neat as the other two (audio drawer / advanced floating action button).

[maxcutlyp]

I think option 2 is not really an option, it is essential that the current choice can be seen. And making the display of current choice and the selection button two separate UI elements would be waste of space.

Agreed.

the popup menu is always the same, regardless of what is already chosen. I think this is actually quite important, as the user will remember the positions of the different choices, and quickly select an option without much thinking. This would be made more difficult if options change place.

Good point. This would mean that the main button would have the same icon as one of the options though, but I don't think that would be a problem as long as the main button is visually different enough from the submenu buttons.

I probably would choose the radial one, which uses the available space better

I'm worried that since there's a lot going on behind the submenu, the radial one has the potential to be confusing to users. This could be mitigated by fading out the background (like the examples in the bottom corners of the gif in the AFAB readme), although to be honest I think that would be necessary for both types (radial and linear).

if we use the advanced floating action button, there might even be space for labels in the popup choices.

Sorry, I wasn't clear - this is what I meant by "having titles next to the buttons".

An alternative would be to use a Spinner with a custom layout for the entries - these could be icons, and I assume/hope that one can also attach long-click actions to those and the spinner itself. This solution just doesn't seem as neat as the other two (audio drawer / advanced floating action button).

I agree, spinners feel a bit clunky for our use case.

[felixwiemuth]

Good point. This would mean that the main button would have the same icon as one of the options though, but I don't think that would be a problem as long as the main button is visually different enough from the submenu buttons.

Right, there is a chance that one might be confused by same buttons. Although I think that already the positioning and opening animation of the menu buttons might make it clear enough. For example the radial version of the advanced floating action button arranges the buttons in a way such that the main button is standing out as the center. This might be another reason in favour for that version. Another possibility of making it more clear is changing the main button when opening the menu, like in the examples of the advanced floating action button. Instead of turning it into a "close button" with an "x", we could just turn it grey, i.e. we'd have grey versions of the 3 buttons.

I probably would choose the radial one, which uses the available space better

I'm worried that since there's a lot going on behind the submenu, the radial one has the potential to be confusing to users. This could be mitigated by fading out the background (like the examples in the bottom corners of the gif in the AFAB readme), although to be honest I think that would be necessary for both types (radial and linear).

Good point. Another way to make the menu UI be more distinct from the background would be choosing distinct colors for the buttons (as the background is mostly grey with a bit of blue, I could imagine green or white for regular reminders, yellow or purple or orange for nagging reminders and red or orange for alarm reminders). Blurring the background seems like a good idea regardless of how the buttons look like. One option that might be preferred over blurring the whole background could be extending the circular icons of the menu with a bigger transparent circle, forming a blurring margin. Maybe this or something similar can already be achieved by using the depth attribute (I think this adds shadow).

It seems to me that we have a quite good idea now of how it could look like and how it can be integrated into the current UI. I think I would be fine with the floating action button, depending on how easily it can be integrated. You could give it a try, just with dummy buttons and no further functionality and then we'll see.

If you can find other libraries, just post them here and we can take a look as well.

[maxcutlyp]

Instead of turning it into a "close button" with an "x", we could just turn it grey, i.e. we'd have grey versions of the 3 buttons.

I actually like the idea of turning it into a "close button" with an "x". I feel like making it grey tells the user that it's invalid ("greyed out") when in reality clicking on it will just close the submenu.

choosing distinct colors for the buttons

I quite like the current colour scheme of blue and grey, it looks very professional. I worry that adding too many different colours could detract from that and make it look less professional.

One option that might be preferred over blurring the whole background could be extending the circular icons of the menu with a bigger transparent circle, forming a blurring margin.

Do you mean extending one blurred region across all the buttons (in a circle for a radial FAB, or a pill shape for a linear one [similar to the ringer drawer shape]), or do you mean extending each individual submenu button with its own blurred circular region? Personally I think either would work.

Also, I'm running into an issue installing Advanced FABs as a dependency: "Manifest merger failed : uses-sdk:minSdkVersion 16 cannot be smaller than version 21 declared in library [com.github.kelmer44:fabmenus:1.33] as the library might be using APIs not available in 16".

The suggestions it listed were:

1. use a compatible library with a minSdk of at most 16
2. increase this project's minSdk version to at least 21
3. use tools:overrideLibrary="com.kelmer.android.fabmenu" to force usage (may lead to runtime failures)

Personally I think option 2 is the best, unless there's a reason SimpleReminder's minSdk version can't/shouldn't be updated to 21. What do you think?

[felixwiemuth]

I actually like the idea of turning it into a "close button" with an "x". I feel like making it grey tells the user that it's invalid ("greyed out") when in reality clicking on it will just close the submenu.

Yeah you are right about "greyed out", but I think it depends on how it is realized in the end. What I like is that one can still see the current choice while the menu is open. Then clicking on the main button again, which happens to be the button of the currently selected mode, closes the menu but could also be regarded as "choosing the current choice". Let's keep both as an option and see what looks/works best in the end.

I quite like the current colour scheme of blue and grey, it looks very professional. I worry that adding too many different colours could detract from that and make it look less professional.

I agree to some extent. On the other hand, the selected reminder type is very important (e.g., if you want it to be an alarm, you might miss it if you accidentally make it a normal or nagging reminder). Here colors would make it less likely to choose (or keep) the wrong one.

One option that might be preferred over blurring the whole background could be extending the circular icons of the menu with a bigger transparent circle, forming a blurring margin.

Do you mean extending one blurred region across all the buttons (in a circle for a radial FAB, or a pill shape for a linear one [similar to the ringer drawer shape]), or do you mean extending each individual submenu button with its own blurred circular region? Personally I think either would work.

I meant that each submenu button would get a blurring ring around it. The other option you describe also seems reasonable, but I think I'd prefer the former which is probably also easier to realize.

Also, I'm running into an issue installing Advanced FABs as a dependency: "Manifest merger failed : uses-sdk:minSdkVersion 16 cannot be smaller than version 21 declared in library [com.github.kelmer44:fabmenus:1.33] as the library might be using APIs not available in 16".

Oh, that's unfortunate, I wasn't expecting this. Until now it was not much of a problem to keep the minSdk at 16. Increasing it to 21 would mean that the app will only work on Android 5 and above. Regarding that even that is a very old version, it probably won't affect many users; on the other hand it is nice to support older devices when it is not necessary to not do so.

However, probably at some point I'll want or need to increase the minSdk anyway, because libraries or platform features might otherwise not be available, so I'll consider whether it's worth to do it now. There is also the KAU collection of libraries which I was considering to use at some point and they also need minSdk 21.

You could go ahead for now and use minSdk 21. Maybe also give it a try seeing what actually needs higher APIs in the project (you might have to clone the project itself and change the minSdk to 16 there).

[maxcutlyp]

What I like is that one can still see the current choice while the menu is open.

I was thinking this could be done by having the relevant submenu button appear "checked", like the "checkable" example in the Advanced FAB readme and similar to how the ringer drawer shows the current selection.

Let's keep both as an option and see what looks/works best in the end.

Sure.

I quite like the current colour scheme of blue and grey, it looks very professional. I worry that adding too many different colours could detract from that and make it look less professional.

I agree to some extent. On the other hand, the selected reminder type is very important (e.g., if you want it to be an alarm, you might miss it if you accidentally make it a normal or nagging reminder). Here colors would make it less likely to choose (or keep) the wrong one.

True. I think, like above, we should keep both options and see what looks best in the end.

I meant that each submenu button would get a blurring ring around it. The other option you describe also seems reasonable, but I think I'd prefer the former which is probably also easier to realize.

Sounds good, I'll look into it.

Regarding that even that is a very old version, it probably won't affect many users; on the other hand it is nice to support older devices when it is not necessary to not do so.

I agree to an extent, but it's important to remember that the last version before Android 5.0 (Android 4.4) stopped being supported by Google in October 2017, almost 5 years ago.

I'll bump up minSdk to 21 for now, and later in the development cycle I'll take a closer look at the AFAB project to see what it needs from there, and if we're using it - if we aren't, it's probably safe to use tools:overrideLibrary to continue supporting <5.0 devices.

[felixwiemuth]

I was thinking this could be done by having the relevant submenu button appear "checked", like the "checkable" example in the Advanced FAB readme and similar to how the ringer drawer shows the current selection.

Right, that's also an option. But as I understand the example from the Advanced FAB readme, this type of menu also has the behaviour of checkboxes, i.e., it will stay open when making choices instead of closing on a selection.

I'll bump up minSdk to 21 for now, and later in the development cycle I'll take a closer look at the AFAB project to see what it needs from there, and if we're using it - if we aren't, it's probably safe to use tools:overrideLibrary to continue supporting <5.0 devices.

Okay. And actually this also opens the option of partially supporting Android <5.0 by keeping the lower minSdk while using the library even if it depends on the higher Sdk: some functionality might not work on Android <5.0, e.g. choosing the reminder type. Then one might still be able to use the app with just basic reminders. It might crash when trying to use the AFAB - in that case we might even remove the button from the UI when running on Android <5.0, or have a variant with the nagging switch as it is for now. Of course one could also implement a less fancy UI with a Spinner for Android <5.0, but I don't think we want to spend time on that. If someone really wants all functionality on older devices, they'll have to implement it.

[maxcutlyp]

But as I understand the example from the Advanced FAB readme, this type of menu also has the behaviour of checkboxes, i.e., it will stay open when making choices instead of closing on a selection.

That's okay, we can just close it when the user taps on a selection. The main button's icon will change to their selection so they know what they tapped. I'm playing around with it at the moment, you can just call the AdvancedFabMenu.close method in an onClick listener.

Okay. And actually this also opens the option of partially supporting Android <5.0 by keeping the lower minSdk while using the library even if it depends on the higher Sdk: some functionality might not work on Android <5.0, e.g. choosing the reminder type. Then one might still be able to use the app with just basic reminders. It might crash when trying to use the AFAB - in that case we might even remove the button from the UI when running on Android <5.0, or have a variant with the nagging switch as it is for now. Of course one could also implement a less fancy UI with a Spinner for Android <5.0, but I don't think we want to spend time on that. If someone really wants all functionality on older devices, they'll have to implement it.

Agreed.

PS: You can check out my WIP PR if you'd like, #32. There's not much there yet, but it shows how the UI could look. I've got some uncommitted changes that I'll try to tidy up and push tomorrow, mostly related to saving the selection visually and internally.