I'm using Google's firebase-database SDK for Android, v9.0.1. I have my app hooked up to Firebase and can read and write data at various locations.
However, I cannot get a specific boolean field to bind using dataSnapshot.getValue(PingReport.class) and I keep getting an error in my logs that says No setter/field for isUp found on class com.myapp.PingReport when the field clearly exists in my model.
Here's the JSON in the Firebase database:
{
"durationMs": 364,
"isUp": true,
"timestampMillis": 1464916019971
}
and here's the model class:
public class PingReport {
private long durationMs;
private boolean isUp;
private long timestampMillis;
public PingReport() {
// required by Firebase
}
public PingReport(long durationMs, boolean isUp, long timestampMillis) {
this.durationMs = durationMs;
this.isUp = isUp;
this.timestampMillis = timestampMillis;
}
public long getDurationMs() {
return durationMs;
}
public boolean isUp() {
return isUp;
}
public long getTimestampMillis() {
return timestampMillis;
}
}
If I call getDurationMs() or getTimestampMillis() the correct values are returned, but the value returned from isUp() is always false. I have tried different combinations of naming it up and isUp and mUp and adding setters setUp(boolean up) and setIsUp(boolean isUp), but nothing seems to work. The documentation for the Android SDK not very detailed. Is there some trick or detail I'm overlooking?
If your boolean field is named isUp, then the getter must be named isIsUp() or getIsUp(). Alternatively, if you want a getter named isUp, the field name would be up.
Alternatively, you can use the #PropertyName annotation from Firebase Database to handle this. Also, it's better to include setters as well.
Pass a custom Java object, if the class that defines it has a default constructor that takes no arguments and has public getters for the properties to be assigned.
public class PingReport {
private long durationMs;
private boolean isUp;
private long timestampMillis;
public PingReport() {
// required by Firebase
}
public PingReport(long durationMs, boolean isUp, long timestampMillis) {
this.durationMs = durationMs;
this.isUp = isUp;
this.timestampMillis = timestampMillis;
}
public long getDurationMs() {
return durationMs;
}
#PropertyName("isUp")
public boolean isUp() {
return isUp;
}
public long getTimestampMillis() {
return timestampMillis;
}
}
I ran into this problem in Kotlin. I had several boolean values. All of them were set properly except for the one that started with is. To fix this, I made it a custom getter and that fixed the problem:
data class FirebaseEvent(
val description: String? = null,
val disableLogin: Boolean? = null,
val isDVR: Boolean? = null
) {
fun getIsDVR(): Boolean? {
// this is needed to trick Kotlin into using this getter instead of generating its own which breaks firebase
return isDVR
}
}
Don't use "is" with your variable name specifically with Firebase Realtime Database. I also had the same problem, I have to change my variable name from "isUserExist" to "userExist" ! Crippy Firebase!
Your getter for isUp() is not following the normal convention. Have you tried public boolean getIsUp()?
You should check the naming convention in java.
Try to use:
private boolean up;
public boolean isUp() {
return up;
}
if you are using Kotlin then use PropertyName on getter and setter of the variable so that you bypass kotlin generated getters/setters names.
using this annotation on the variable itself doesn't help because it doesnt affect the generated setters and setters.
data class(
#get:PropertyName("isRead")
#set:PropertyName("isRead")
var isRead: Boolean? = null
)
you can check this question for more info about java
Dont use the primitive "boolean" type but use "Boolean" class instead.
Related
Hi all I can't think of a better example to illustrate my point so do let me know If my example has some errors. But hopefully this example will get my point through.
class A {
String CATEGORY = "A";
public String getCATEGORY() {
return CATEGORY;
}
}
class B extends A {
String CATEGORY = "B";
#Override
public String getCATEGORY() {
return CATEGORY;
}
}
class C extends A {
String CATEGORY = "C";
#Override
public String getCATEGORY() {
return CATEGORY;
}
}
public class MyClass {
private List<A> array = Arrays.asList(new A(), new B(), new C());
public MyClass() {}
}
Now if I upload MyClass onto firebase using setValue for example, firebase will show me the properties of class A, B and C. However, when I read the data from firebase and call sth like getValue(MyClass.class) the List it returns me are all of type A and the subclasses are not preserved. Is there a workaround to allow firebase to preserve the class types uploaded?
If you use Firebase's default serializer, it simply writes all public properties and fields to the database. Say that you store a single instance of each class, it'd be:
-L1234567890: {
cATEGORY: "A"
},
-L1234567891: {
cATEGORY: "B"
},
-L1234567892: {
cATEGORY: "C"
},
There won't be enough knowledge in the database for the SDK to reinflate the correct sub-class. While you and I can see that the cATEGORY value matches the class name, the Firebase SDK has no such knowledge.
It won't be too hard to write your own custom deserializer for this data though, taking a DataSnapshot with the values above and reinflating the correct class and values.
You could also do a hybrid: detect the class type directly, and then tell Firebase what class to read:
String cat = snapshot.child("cATEGORY").getValue(String.class)
Class clazz = "C".equals(cat) ? C.class : "B".equals(cat) ? B.class : A.clas;
A object = snapshot.getValue(clazz);
I'm implementing the MVP design pattern. My presenter receives the new values from the view. I want to manage the state of a next button by automatically check if everything is valid when values are updated on the view.
In my form I have an optional part which is displayed only if the user select the correct option.
In this optional part I have a binary question. If the part is not displayed I need to set the value of the question to null on the Presenter side.
For example, the user select the option and the optional part is displayed. The user select the answer. Then the user change the option and the optional part is hidden. In that case I need to set the answer to the optional question to null, for the answer to not be already selected if the user display the optional part again.
To do so, I call a method on the Presenter with a null value instead of true/false.
Here is the code:
private final PublishSubject<Boolean> mObsOptionalAnswer = PublishSubject.create();
public MyPresenter(){
// Combine all the values together to enable/disable the next button
Observable.combineLatest(
// ... other fields
// I need this to return false if the optional part is
// displayed but nothing is selected
mObsOptionalAnswer.map(this::isValid),
(...) -> ...
).subscrible(enable ->{
mView.enableBtn(enable);
});
}
public void myFunction(Boolean isSomething){
// ... some code
mObsOptionalAnswer.onNext(isSomething);
}
private boolean isValid(Boolean value){
return value != null;
}
The problem is, since RxJava 2, null values are not allowed in the onNext() method.
So, how am I supposed to manage that?
If you want to be able to send a null value, you can use a wrapper. In this configuration, you send the wrapper, which isn't null even if the value itself is.
public class BooleanWrapper {
public final Boolean value;
public BooleanWrapper(Boolean value) {
this.value = value;
}
}
Your PublishSubject<Boolean> becomes a PublishSubject<BooleanWrapper> and you just have to create the wrapper and de-reference your Boolean when needed :
mObsOptionalAnswer.onNext(new BooleanWrapper(isSomething));
and
mObsOptionalAnswer.map(wrapper -> this.isValid(wrapper.value))
If you need to do that more than once in your code, you can create a generic wrapper (as described by this tutorial) :
public class Optional<M> {
private final M optional;
public Optional(#Nullable M optional) {
this.optional = optional;
}
public boolean isEmpty() {
return this.optional == null;
}
public M get() {
return optional;
}
}
you could use a constante Boolean object
public static final Boolean RESET_VALUE = new Boolean(false);
and you can emit this instead of emitting null. The receiver would have to check against this instance and behaving accordingly. Eg.
.subscrible(enable ->{
if (enable != RESET_VALUE) {
mView.enableBtn(enable);
}
});
As a Java developer, the concept of a backing field is a bit foreign to me. Given:
class Sample {
var counter = 0 // the initializer value is written directly to the backing field
set(value) {
if (value >= 0) field = value
}
}
What's this backing field good for? Kotlin docs said:
Classes in Kotlin cannot have fields. However, sometimes it is necessary to have a backing field when using custom accessors.
Why? What's the difference with using the properties name itself inside the setter, eg.*
class Sample {
var counter = 0
set(value) {
if (value >= 0) this.counter = value // or just counter = value?
}
}
Because, say if you don't have field keyword, you won't be able to actually set/get the value in the get() or set(value). It enables you to access the backing field in the custom accessors.
This is the equivalent Java code of your sample:
class Sample {
private int counter = 0;
public void setCounter(int value) {
if (value >= 0) setCounter(value);
}
public int getCounter() {
return counter;
}
}
Apparently this is not good, as the setter is just an infinte recursion into itself, never changing anything. Remember in kotlin whenever you write foo.bar = value it will be translated into a setter call instead of a PUTFIELD.
EDIT: Java has fields while Kotlin has properties, which is a rather higher level concept than fields.
There are two types of properties: one with a backing field, one without.
A property with a backing field will store the value in the form of a field. That field makes storing value in memory possible. An example of such property is the first and second properties of Pair. That property will change the in-memory representation of Pair.
A property without a backing field will have to store their value in other ways than directly storing it in memory. It must be computed from other properties, or, the object itself. An example of such property is the indices extension property of List, which is not backed by a field, but a computed result based on size property. So it won't change the in-memory representation of List (which it can't do at all because Java is statically typed).
Initially, I too had a tough time understanding this concept. So let me explain it to you with the help of an example.
Consider this Kotlin class
class DummyClass {
var size = 0;
var isEmpty
get() = size == 0
set(value) {
size = size * 2
}
}
Now when we look at the code, we can see that it has 2 properties i.e - size (with default accessors) and isEmpty(with custom accessors). But it has only 1 field i.e. size. To understand that it has only 1 field, let us see the Java equivalent of this class.
Go to Tools -> Kotlin -> Show Kotlin ByteCode in Android Studio. Click on Decompile.
public final class DummyClass {
private int size;
public final int getSize() {
return this.size;
}
public final void setSize(int var1) {
this.size = var1;
}
public final boolean isEmpty() {
return this.size == 0;
}
public final void setEmpty(boolean value) {
this.size *= 2;
}
}
Clearly we can see that the java class has only getter and setter functions for isEmpty, and there is no field declared for it. Similarly in Kotlin, there is no backing field for property isEmpty, since the property doesn't depend on that field at all. Thus no backing field.
Now let us remove the custom getter and setter of isEmpty property.
class DummyClass {
var size = 0;
var isEmpty = false
}
And the Java equivalent of the above class is
public final class DummyClass {
private int size;
private boolean isEmpty;
public final int getSize() {
return this.size;
}
public final void setSize(int var1) {
this.size = var1;
}
public final boolean isEmpty() {
return this.isEmpty;
}
public final void setEmpty(boolean var1) {
this.isEmpty = var1;
}
}
Here we see both the fields size and isEmpty. isEmpty is a backing field because the getter and setter for isEmpty property depend upon it.
Backing fields are good for running validation or triggering events on state change. Think of the times you've added code to a Java setter/getter. Backing fields would be useful in similar scenarios. You would use backing fields when you needed to control or have visibility over setters/getters.
When assigning the field with the field name itself, you're actually invoking the setter (i.e. set(value)). In the example you have, this.counter = value would recurse into set(value) until we overflow our stack. Using field bypasses the setter (or getter) code.
My understanding is using field identifier as a reference to the property's value in get or set, when you want to change or use the property's value in get or set.
For example:
class A{
var a:Int=1
get(){return field * 2} // Similiar to Java: public int geta(){return this.a * 2}
set(value) {field = value + 1}
}
Then:
var t = A()
println(t.a) // OUTPUT: 2, equal to Java code: println(t.a * 2)
t.a = 2 // The real action is similar to Java code: t.a = t.a +1
println(t.a) // OUTPUT: 6, equal to Java code: println(t.a * 2)
The terminology backing field is filled with mystery. The keyword used is field. The get/set methods, follows immediately next to the member variable that is about to be get or set through this door protective methods mechanism. The field keyword just refers to the member variable that is to be set or get. At present Kotlin, you cannot refer to the member variable directly inside the get or set protective door methods because it will unfortunately result to infinite recursion because it will re-invoke the get or set and thus leds the runtime down into the deep abyss.
In C# though, you can directly reference the member variable inside the getter/setter methods. I am citing this comparison to present the idea that this field keyword is how the present Kotlin is implementing it but I do hope it will be removed in later versions and allow us to directly reference the member variable directly without resulting to infinite recursion.
I've been trying to add Realm in my Android app. Their docs are pretty well explained & easy to follow. But it fails to explain this one particular area. I'm unable to figure out the practical use for the #Ignore annotation. I know that fields under this annotation are not persisted.
Can someone please share a few use cases. Also I wanted to know the scope of such fields. I mean, if I set an #Ignore field to some value, would that value be available to the other classes in my app for that particular launch session. If yes, then how do we access it? If no (which I guess is the case), then why do we need such a field anyway?
I've searched here and on web but couldn't find the relevant information. If out of my ignorance, I've missed upon some resource, please guide me to it.
Thanks.
Accordingly to the official documentation (see https://realm.io/docs/java/latest/) #Ignore is useful in two cases:
When you use GSON integration and your JSON contains more data than you want to store, but you still would like to parse it, and use right after.
You can't create custom getters and setter in classes extending RealmObject, since they are going to be overridden. But in case you want to have some custom logic anyway, ignored fields can be used as a hack to do that, because Realm doesn't override their getter & setters. Example:
package io.realm.entities;
import io.realm.RealmObject;
import io.realm.annotations.Ignore;
public class StringOnly extends RealmObject {
private String name;
#Ignore
private String kingName;
// custom setter
public void setKingName(String kingName) { setName("King " + kingName); }
// custom getter
public String getKingName() { return getName(); }
// setter and getter for 'name'
}
Ignored fields are accessible only from the object they were set in (same as with regular objects in Java).
UPDATE: As the #The-null-Pointer- pointed out in the comments the second point is out of date. Realm now allows having custom getters and setters in Realm models.
Here's a couple of real-world use cases:
1 - Get user's fullname:
public class User extends RealmObject {
private String first;
private String last;
#Ignore
private String fullName;
public String getFullName() {
return getFirst() + " " + getLast();
}
Get JSON representation of object:
public class User extends RealmObject {
private String first;
private String last;
#Ignore
private JSONObject Json;
public JSONObject getJson() {
try {
JSONObject dict = new JSONObject();
dict.put("first", getFirst());
dict.put("last", getLast());
return dict;
} catch (JSONException e) {
// log the exception
}
return null;
}
I've found it useful to define field names for when I am querying. For example
User.java
public class User extends RealmObject {
#Index
public String name;
#Ignore
public static final String NAME = "name";
}
And then later on I can do something like:
realm.where(User.class).equalTo(User.NAME, "John").findFirst();
This way if the schema changes from say name to id I don't have to hunt down every occurrence of "name".
Please see the the official documentation about #Ignore annotation:
The annotation #Ignore implies that a field should not be persisted to disk. Ignored fields are useful if your input contains more fields than your model, and you don’t wish to have many special cases for handling these unused data fields.
In my android app, I persist a workout object to realm. In one of my activities, I create an object with this code:
realm.beginTransaction();
Workout w = realm.createObject(Workout.class);
w.setmWorkoutId(UUID.randomUUID().toString());
realm.commitTransaction();
Here is my workout class:
public class Workout extends RealmObject{
private String mWorkoutId;
private int restSecsLeft;
private boolean prevSetOver = true;
private boolean workoutOver = false;
public Workout(){}
public String getmWorkoutId() {
return mWorkoutId;
}
public void setmWorkoutId(String mWorkoutId) {
this.mWorkoutId = mWorkoutId;
}
public int getRestSecsLeft() {
return restSecsLeft;
}
public void setRestSecsLeft(int restSecsLeft) {
this.restSecsLeft = restSecsLeft;
}
public boolean getPrevSetOver() {
return prevSetOver;
}
public void setPrevSetOver(boolean prevSetOver) {
this.prevSetOver = prevSetOver;
}
public boolean getWorkoutOver() {
return workoutOver;
}
public void setWorkoutOver(boolean workoutOver) {
this.workoutOver = workoutOver;
}
}
I have a service that runs after a workout is created, and after debugging odd behavior, have found an instance where the value of prevSetOver that is saved in a workout RealmObject is different than the value returned from w.getPrevSetOver(). I am not sure how this is happening--I do not change the value of the variable prevSetOver after an object is instantiated. I am a new realm user and do not understand how this is happening. The picture I have attatched is a screenshot of the w.prevSetOver() method and the RealmObject having different values.
There are more variables in the debugger in this screen, I left most of them out in my post for simplicity's sake.
It is the right behaviour of Realm.
Realm generates Proxy object which inherit from your Workout when compiling. And read/write data from/to Realm is actually implemented by the Proxy Object through overriding getters/setters. The original Object's member field won't be changed by Realm.
When Realm.createObject() get called, it does return a Proxy object, whose member fields are not what you expected.
You still can create a instance of the original model object which we call it standalone object (means it is not managed by Realm) by calling Workout w = new Workout(). This would act just like normal Java object. And you still can copy it to Realm by calling w = realm.copyToRealmOrUpdate(w). Notice we changed the w's value to the return value. The function will return a Proxy object which is managed by Realm now.
realm.beginTransaction();
Workout w = realm.createObject(Workout.class);
w.setmWorkoutId(UUID.randomUUID().toString());
realm.copyToRealm(w); //<-- u need
realm.commitTransaction();
is better add Primarykey, changed u String variable to long
#PrimaryKey
private long mWorkoutId;