Develop Reference

Is setting fields line after line from a Firestore document read an anti-pattern?

I have a document on Firestore, from which I read its fields in a fragment. Since it has many fields, I set variables in the Activity that hosts this fragment so that I can pass the data between other fragments. In order to achieve that, I realize that I have to write similar lines of codes over and over again, which got me to thinking if there is a better way.
Two possible solutions that come to my mind:
Structure all these fields in JSON format -> something that wouldn't be suitable in Firestore's document system imo
Put all these fields into a serializable data class which I keep in the activity then pass it around the bundles of fragments -> Seemed to complicated and I would still have to write it.get(foo) as bar for each of the field's of this class' constructor.
Given all these, what is the best approach? Thanks in advance.

You have a several options on how to approach this. There is none that's necessarily better than another. Ultimately, you will pick the one that best suits your needs and preferences.
You can do what you're doing now.
You can go a step further an actually check the types of the values instead of just blindly casting them (which would cause a crash at runtime if they didn't match).
You can provide a Class object to get(String, Class<T>) that can automatically map the fields to properties in a new object of type T, as long as the types also match.
You can call a variety of type-specific versions of get, such as getString()
Ultimately you will have to decide if you are going to trust what you get in the snapshot and allow errors to happen, or trust nothing and check everything. It's up to you.

Rename variables to make the XML ids cleaner

I've been wanting to make the code cleaner, but I do not give it away. I mean...
To name the ids of the views in the XML I use Hungarian notation like this:
<WHAT> <WHERE> <DESCRIPTION> <SIZE>
For example: tvExampleSectionEmptyBig,tvExampleSectionEmptySmall
Previously, using Butter Knife, I did not get too much coding because to do the bindings, I did things like this:
#BindView (R.id.tvExampleSectionEmptyBig) TextView tvEmptyBig;
#BindView (R.id.tvExampleSectionEmptySmall) TextView tvEmptySmall;
The code was much clearer and more reusable since the Hungarian notation used to avoid the confrontation between ids with the same name in different activities, fragments, etc. it was not present in practice more than in XML.
What's going on?
Kotlin has synthetic, which makes your life easier since with putting the id of the view, the binding is done directly, but with such long ids the code is very dirty ... Besides, makes sense that all the views I use in an activity called ExampleSectionActivity, contain within its variable nameExampleSection?
What would I like?
Surely there are better solutions that, but initially, what I feel is to implement a way to rename variables by removing a given String. As I follow a convention in all the names of the ids, it would be something internally in this way:
val tvEmptyBig = tvExampleSectionEmptyBig
val tvEmptySmall = tvExampleSectionEmptySmall
But of course, I would like to do it in an automated way.
On the other hand, I already tried naming the ids without the and to be careful with the imports, but for the moment synthetic fails very occasionally in this respect and I had to rebuild constantly. Especially if I open another instance of Android Studio, which I usually do quite often for consulting other projects I have.
Any idea? :-)

In my opinion, the easies and the most clean thing you can do is this:
private val myTextView: TextView
get() = f_layoyt_text_view
This way you don't have to use ridiculous, at least in 2018, ButterKnife and even more inconvenient findViewById.

For a few weeks, I already take for granted, that with the latest stable updates of Android Studio, there is no problem with repeating names of ids in different activities or fragments. Therefore, it is no longer necessary to put long variable names. Only there is to pay a little bit of attention to the imports, everything works like a charm, more readable and reusable. :-)

Passing objects in Android that I didn't create?

I'm looking for a way of passing an object that I didn't create and cannot modify to implement parcelable in android. I was given a jar file that placed into the project by building a path to it. Now i need to pass the object created from activity to activity so that I may use the contents of the jar file. Right now it is set up so I define it as static, which probably isn't the best way. The only other option I can think of is using putSerializable but I've heard that puts strain on the system. So, what are my other options?

The main problem you have here is if that class has non-accessable private fields (through getters), then you cannot get this data to parcel it. If all private fields are accessable, then you might have several possibilities:
Extending it with a Parcelable subclass (as suggested by Simon in the comments).
Wrapping it in another Parcelable object.
Converting it to an already Parcelable object (e.g. any implementation of Map)
Note that if the object itself is not very big then the performance drop between parcelling and serializing shouldn't be noticeable. So I would go for Serializing and if the performance is not satisfactory then consider other options.

using SimpleXML, how to ignore xml elements I don't have in my object class when deserializing

I'm using SimpleXml on Android to deserialize an xml which I have no control over. Now, every time the xml changes, it brakes my app because I don't have the new element defined in my object class. Is there a way I could specify SimpleXML just to ignore those missmaps? Looked at the documentation and can't find anything to help me solve it.

I'm pretty sure you can get around the strict mapping by replacing your regular #Root declaration with #Root(strict=false), which will eliminate the requirement that every element should match a field in your class definition. More precisely, from the documentation:
This is used to determine whether the object represented should be
parsed in a strict manner. Strict parsing requires that each element
and attribute in the XML document match a field in the class schema.
If an element or attribute does not match a field then the parsing
fails with an exception. Setting strict parsing to false allows
details within the source XML document to be skipped during
deserialization.
There's also an example given in the list of tutorials on the Simple XML project site.

You can specify strict mode to be disabled for all tags for a particular read by adding in "false" as the last parameter. Also from their documentation:
Should there be more than a single object that requires loose mapping then using the Root annotation might not be the ideal solution. In such a scenario the persister itself can be asked to perform loose mapping. Simply pass a boolean to the read method indicating the type of mapping required. By default the persister uses strict mapping, which can be overridden on an object by object basis using the Root annotation, as shown in the above example. However, this default can be overridden as can be seen in the code snippet below.
Contact contact = serializer.read(Contact.class, source, false);

Should keys be placed on a xml to be accessed with R.string.key?

I usually place my keys on an xml and access them with R.string.key_name but someone make me notice that I could have inline strings in the code.
I feel that I might use that key in different places and if I change its name I would just rename in the xml but perhaps that doesn't make too much sense with keys.
What do you think?

Your question conflates two different questions:
Does it make sense to have a single definition of your key?
Does it make sense for this single definition to be within an XML file?
The answer to point 1 is clearly "yes". Duplicating strings used as keys (which need to be the same everywhere for your code to function correctly) is a recipe for pain and heartache.
But what benefit does putting the key in an XML file give you? You're just adding "noise" to your code, and ensuring that whoever reads it has to find, understand and look in at least one additional file.
public static final is the way to go.

Inline literal strings will be a massive pain to change if they get scattered through the code. Localizing them in one place with either the strings.xml or a defining a public final static variable will probably save you a headache later.