Develop Reference

Implement a split preference in Android

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!

Android vs configuration changed

I apologize for my English but translated with google. I'd like to understand why Google with Android restarts the activity at each change and you lose all the data displayed. How do you solve this problem? Could not they make it optional this thing?
On every forum I read to use the methods onSaveInstanceState, onRestoreInstanceState, onConfigurationChanged, but how to use them is not explained well. If I have a complex application, with many objects, with EditText, with Markers, Polygons, I'm forced to save everything by hand with temporary variables? There is another way faster and easier to do it? Do you have any practical example to show me? I hope you know help me understand, thank you all.

It is an optional thing. In your manifest, add android:configChanges="orientation|screenSize" to your activity and it will turn off that behavior.
Really there's only 1 good circumstance to not override it- if you have no AsyncTasks, no Threads, no Loaders, no bound services, AND you have separate layout.xml files for landscape and portrait. That's about the only time it doesn't cause more pain to recreate than it saves. It's google's biggest screwup in the API.

Android extend multiple activity types

I'm wanting to extend both a MapActivity and a FragmentActivity. I know Java doesn't allow multiple inheritance, so how do I do this? I've read something about a 'composite' type, but I've never implemented one so I don't know how to go about doing that.
Someone else HAS to have run into this before, how did you solve it?
EDIT: The reason I want this is because I have 3 activities in tabs; a map, an image gallery, and a settings list view. The code for all three of these "acitivities" is inside one big MapActivity called "Main". Yes I know this is ugly, and not good programming practice, and I don't remember why I wrote it this way. I think it was because I was reading most people recommended NOT having separate activities for separate tabs... which if I decided to split them into separate activities, I wouldn't have this problem anymore.

I have no idea why you would want such a thing, but I suppose the easiest solution is something like ActivityGroup, something similar to how TabbedActivity works.

I ended up solving this by going in and modifying the source of the Android support package and deploying my app with that. Outlined here, all I did was make FragmentActivity (android.support.v4.app) extend MapActivity. I don't think the reverse works... though maybe, and it would require you having the source of the mapping library you're using (in the case of Google Maps - no go)

Multiple Activites in one class on Android

I was wondering if instead of having to create a new class for each activity is it possible to create mulitiple activities within one class?
So define various layout xml for various activities within one class, instead of having to create new classes for each activity.
Thanks

No, you should put each activity in seperate class. Take a look at this question. Someone is wondering just the same thing as you.

Ricky,
Yes, you may have multiple "Activities" defined inside a single class. But there are a lot of obstacles and issues with doing so. Before I answer this question, two things must be understood:
What you are asking goes against the Android guidelines for development, and those guidelines are enforced in as many ways as they can be during the compilation process, so nothing I say here is insured to work across any or all API versions of the Android SDK.
Different development environments do their own checks and compile in slightly different ways. I will be speaking from the Eclipse side of development.
Techniques listed here are for education, but introduce a lot of issues. For self education and theory, it is a wonderful practice to explore. However, the goal of this answer is to educate you as to why the guideline should be followed rather than sidestepped.
Requirements for an Activity
The first thing to understand is that Android has specific points that must be met for an Activity to be run. It must: a) be declared in the manifest; b) have an intent-filter describing how it is to be used; c) be a public class; d) be a top-level class.
Multiple Activities, Same Parent Class
This means that you may create an Activity inside of another class (an inner Activity, so to speak), but it must be declared static and public. This limits your Activity in a huge number of ways. Calls to methods or members that are instance-related (not static) to the parent class are not possible. So you lose a lot of time and code hacking around this.
Second, it affects your Android XML declaration for your Activity. This is where the real trouble comes in, because while it can be done, it is very specific and there is not any supporting documentation to make that happen. But that's okay, you wanted to know if you could make ONE class for your Activities.
Multiple Activities, Same Class
Well, Android determines which Activity to run based on its Intent. You could declare the same class multiple times, but with different Names and Intent-filters. If this is the case, then you would have to determine what to do based on the Intent and the extras included. This would be done in your onCreate() method.
Doing things in this manner would mean that you would have to code for two Activities in every place that you would normally deal with one. This would make it much harder to track down bugs to support your product. It would also make every routine operation take longer as you would have to decide which method to perform. For instance, if you overrode onDraw(), you would have to know which Activity you were drawing. Its ultimately just a big schmorgasborg (sp? does anyone know how to spell that word?) of "what do I do?!"
The Real Question
Why would you want to do this anyway?
1. If the answer is to save yourself time navigating your own project, believe me... That won't really happen. Your code will be harder to read, interpret and debug.
If the answer is that you want to save file space, I would reconsider your project's priorities.
If the answer is that you want to share functionality, consider extending Activity and then extending your new sub class. How do you think they made the ListActivity or TabActivity to begin with?
If you want to save state, you can place state in SharedPreferences or your Application object (if you have extended it).
As you can see, no matter your needs, there are many other ways to go about it in a way that doesn't cause you or anyone else a hassle.
Hope this helps,
FuzzicalLogic

best practice for UI management in app with omnipresent tabbar

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.