I feel like there must be a straight-forward way to achieve this, but I haven't found it so far.
Essentially, in the stock settings app, there are a handful of preferences that are "split" - i.e., tapping on the text of the preference does one thing, while tapping the icon to the right does another.
I tried making a custom preference that extends PreferenceGroup, but it seems like PreferenceGroup doesn't really wrap the child views the way a LinearLayout does, for example, but rather just puts all the child views below it. I tried instead extending from LinearLayout but it seems the PreferenceScreen only allows Preferences as children.
My question is more or less what the best way to do this is:
Make a custom preference that does somehow take other preferences as children and display them correctly (this seems like it would be ideal, but I'm not sure how I'd achieve it)
Make a custom preference that, when tapped on, somehow figures out which part was tapped and runs the correct handler (this seems more straightforward, especially if a lot of it is hardcoded into the Kotlin class for the preference, rather than being configured in the XML)
Something else that I haven't thought of.
Like I said, it seems like this shouldn't be too hard, but I haven't found any other recent questions about it on SO. I did find this question but it was asked and answered in 2012, without super clear instructions. There's also this question which asks about something somewhat similar but is nearly 11 years old and the only answer is fairly useless.
Please let me know if there is something I have totally overlooked (maybe I've been using the wrong search terms??) or if you have any suggestions! Thank you!
So, it doesn't appear that this is very possible with the xml format for a settings page, so I decided to implement my settings activity in Jetpack Compose. My solution is by no means the most elegant (and needs more comments, I know), but how to do this the "proper" way is definitely beyond my knowledge.
EDIT:
I made some changes to the preferences (most notably, ditching SharedPreferences in favor of Preferences DataStore) and to make it easier, I'm just going to put the link to the GitHub where the files are (and then y'all can see them in a full example):
ComposablePreference.kt
SettingsActivity.kt
Hope this is helpful!
Related
I'm trying to make scrollable fragment (horizontally and vertically). Project looks like
this.
Of course this tree will be much bigger and it will be generated in runtime.
What is the best approach to achieve at least something similar? I'm thinking about SurfaceView and drawing everything with Canvas, however every other fragment in my application is using simple material elements, like this (not final) home view. Is it bad practice to make game-like UI just for one fragment? Or maybe it's too much for my needs and standard libraries will be enough?
I'm asking about best approach (good practice and best user experience), not necessarily simplest solution, but answers raising this subject are also very welcome.
Is there any way, specifically in android studio, to see what one's custom dialog would look like without actually running the application? It seems that the Design view of layouts account only for entire-screen designs. It also seems that sometimes the way the "dialog" looks in the design view is wildly different than the way they look live.
I would share some of my code, I know you guys love that, but this isn't exactly a coding question, is it?
You can use third party tools and mirrors. I think the closest you can get is by checking this out.
This is hot swapping in general and you get interactive previews but like I said it is the closest you can get. I haven't worked thoroughly with it but I think this should be what you are looking for.
I want to add a small type selector, which will give the user three options (good, so-so and bad).
Quickness and simplicity are the main goals.
Something like this would be great:
What type of widget should I use? (I'm using android studio)
I didn't downvote, but the reason might be that you are asking for a iOS-ish pattern, not really present in the android guidelines nor ever promoted by Google.
The common way of achieving what you want in a neat, but framework-accepted way, is using RadioButtons inside a horizontal RadioGroup. I believe there's no need to tell you how, as there are dozens of questions here and it is a pretty straightforward task.
If you really want to stick with that pattern, you could use some external library, like this.
After trying to make sense of the Metrics and Grids page of the (fairly new) Android Design website, I gave up on a lot of things. So, basically, I'm trying to find the original layouts that are used in Android 4, so that I can apply the same concepts.
To make this question more objective and not fail under the "too broad" axe of stackoverflow, I ask you for the layout that is used to recreate, exactly and fully, the examples on that page. Did Google provide them in the samples? Maybe a well known didactic repository that strives to conform with standards?
Just as an example, it's not clear what to do to recreate the "48/3 metrics" (16/16/16) in order to make the text fit in it. What if I want to use 1-line of small text? Would it be 16/wrap_content/16, or 16/16/16 to make it consistent with other layouts around the set? What if...
I believe this would not only help the small devs, but also and most importantly, help standardize the look and feel of apps in Android Play. The site is a good start, but far from ideal.
Added details
I never asked a question with this much upvotes, and I didn't even expect that (I have other questions that I regard as "better", but by far not as many votes and favs). Not that I care about votes, of course, but that is to show that there is a great demand for what I'm asking (a bit of an ad populum here, but still...).
Replies to comments
#Ricardo Amaral:
I'm indeed sorry if I wasn't clear enough:
Mandating a standard and requesting unambiguity from it are different issues. One of the reasons I like Android is the degree of freedom we have, so I'm very much aware of the impossibility of mandating most of the common practices.
I believe it relates to the concept of "reinvent the wheel" within the concept of freedom.
Again, those were just examples. Some things are not clear... which are paddings of the outer container, and margins of the inner views? Many times that makes a difference in selectors, dragging etc. etc. etc., and that again translates into a familiar look and feel for the user. One thing feels like splitting hairs, but it quickly adds up to a lot of small differences. And the user notices it... it looks like it lacks that last "finishing touch".
#Michael Slade:
I know they're examples, that they may have been wireframed from templates. As said, I'm already reusing code from the SDK, and I know they're just examples and that we can deviate from them. Again, after all this time, nobody answered.
Optionality benefits from precision. That's what I'm trying to say and ask. Because it's a recommendation doesn't mean its guidelines can be whatever you want them to be. If you do that, it's not the recommendation anymore. That's the whole point of recommendations, by the way: provide an implementarion theory without forcing anyone.
Thanks everyone!
Hate to break it to you but it's likely that the images on the page you like were created with a drawing program, and there are no example to go with them.
Without someone actually going to the effort to create samples for you, your best bet is to go through the samples that come with the android SDK - they will follow the guidelines in most cases.
And remember, they are just guidelines. At the end of the day it's up to you to create a pleasant and smooth user experience, however you see fit.
I'm working on an Android app having an always visible tabbar.
However, each tab potentially contains many nested "screens".
Of course the back-button needs to handle this correctly.
I've now spent most of the day finding out what's the best architecture to achieve this.
There are also several similar questions on stackoverflow, but I couldn't really find an answer working for me. Two proposals I found and tried out:
switch view, see here
work with ActivityGroup, see here
Another approach I thought about is just implement all "screens" as normal activities and have them all have their own tabbar (but looking the same, so for the user it doesn't change).
I've seen that should be possible without too much redundant code by using include statement in layout xml and maybe create a common base class "CustomActivity" which configures the tabbar.
However since I'm not yet experienced with Android, I wanted to ask here before spending more time with try and error style.
Is this an approach which makes sense? If not, what would be a better solution?
Btw: The proposals mentioned above didn't work for me mainly because with neither the back button worked for me.
Thanks for every input!
Use Fragments API, ActivityGroup seems to be deprecated.