Add class that handles ServerValue

[SUPERCILEX]

• If this has been discussed in an issue, make sure to mention the issue number here. If not, go file an issue about this to make sure this is a desirable change.
  • Include a class that handles Firebase.ServerValues.TIMESTAMP #19
• If this is a new feature please co-ordinate with someone on FirebaseUI-iOS to make sure that we can implement this on both platforms and maintain feature parity.
  • Anyone?

Example usage:

// After calling ref.getValue(Team.class)

public class Team extends Timestamp {
    public Team() {
        // Example with no config
        getTimestamp();
    }

    // Example getter override
    @PropertyName("timestamp" /* Or any other name as long as you create your own
    getters and setters, but then there is no point in extending Timestamp */)
    public Map<String, String> getCustomTimestamp() {
        if (mShouldUpdateTimestamp) {
            return ServerValue.TIMESTAMP;
        } else {
            return null;
        }
    }

[puf]

ServerValue.TIMESTAMP also exists on iOS:
https://firebase.google.com/docs/database/ios/offline-capabilities#server-timestamps

On Sun, Oct 2, 2016 at 11:19 AM Alex Saveau [email protected]
wrote:

• If this has been discussed in an issue, make sure to mention the
  issue number here. If not, go file an issue about this to make sure this is
  a desirable change.
  • Include a class that handles Firebase.ServerValues.TIMESTAMP #19 Include a class that handles Firebase.ServerValues.TIMESTAMP #19
• If this is a new feature please co-ordinate with someone on
  FirebaseUI-iOS https://github.com/firebase/firebaseui-ios to make
  sure that we can implement this on both platforms and maintain feature
  parity.
  • Is this a thing on IOS?

Example usage:

// After calling ref.getValue(Team.class)
public class Team extends Timestamp {
public Team() {
// Example with no config
getTimestamp();
}

// Example getter override
@PropertyName("timestamp" /* Or any other name as long as you create your own    getters and setters, but then there is no point in extending Timestamp */)
public Map<String, String> getCustomTimestamp() {
    if (mShouldUpdateTimestamp) {
        return ServerValue.TIMESTAMP;
    } else {
        return null;
    }
}

---

You can view, comment on, or merge this pull request online at:

#335
Commit Summary

• Merge pull request Feature Request: Add support for the ViewHolder pattern for the FirebaseListAdapter #21 from firebase/master
• Add ServerValue support

File Changes

• A database/src/main/java/com/firebase/ui/database/Timestamp.java
  https://github.com/firebase/FirebaseUI-Android/pull/335/files#diff-0
  (25)

Patch Links:

• https://github.com/firebase/FirebaseUI-Android/pull/335.patch
• https://github.com/firebase/FirebaseUI-Android/pull/335.diff

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#335, or mute the
thread
https://github.com/notifications/unsubscribe-auth/AA3w32fv7Yx8pu4kf6wLBLmh-TTWkuY-ks5qv_WqgaJpZM4KMEwv
.

[SUPERCILEX]

This isn't a huge feature so hopefully it will be quick to implement on iOS. I left some thoughts below about null timestamps.

[SUPERCILEX]

Should I check to see if mTimestamp is 0 (null) here? If so, I would return the system time. Thoughts?

[samtstern]

I don't think we'd want to return system time, that's not the same as unset. I prefer how it is now, it's the least opinionated and most likely to solve the original problem (serialization/deserialization of time stamps is annoying)

[samtstern]

@SUPERCILEX I am a little confused by your intended usage. When I first saw this one I imagined it as a class you'd use in an instance variable, something like:

public class MyObject {

   public String name;

   // Easier to use than plain Object
   public Timestamp timestamp;

}

But your PR description implies that the major usage method is extending Timestamp, which I find counter-intuitive. Could you explain a little?

[SUPERCILEX]

@samtstern I was extending just because it was more convenient for me. However, while trying to figure out how to make public Timestamp timestamp work, I ran into some issues. When extending, the data is single level, but when using Timestamp as a variable, I get nested data like so:

timestamp: {
    timestamp: 0000000
},
other data

Is it possible with Firebase to flatten an object into another object? (merge variables from one object into another)

[puf]

Nope. The Object graph must exactly match the JSON tree with the default
JSON/POJO codec. Once you do your own mapping, you can of course do
whatever you want.

But for timestamp it'll always be tricky, since the value-type that is
written (JSON: { ".sv": "timestamp" }) is different from the value-type
that you read (number).

On Sun, Oct 9, 2016 at 1:09 AM Alex Saveau [email protected] wrote:

@samtstern https://github.com/samtstern I was extending just because it
was more convenient for me. However, while trying to figure out how to make public
Timestamp timestamp work, I ran into some issues. When extending, the
data is single level, but when using Timestamp as a variable, I get
nested data like so:

timestamp: {
timestamp: 0000000
},
other data

Is it possible with Firebase to flatten an object into another object?
(merge variables from one object into another)

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#335 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA3w3whskr1ZPtmtvEBMnQ3ydRHsvjaHks5qyCK5gaJpZM4KMEwv
.

[SUPERCILEX]

So is it fine to have a nested timestamp like that? I really don't like it, but if you say there is no other way...

[puf]

@samstern: can you think of a way to annotate a class to write one type and
read another?

On Sun, Oct 9, 2016 at 9:21 AM Alex Saveau [email protected] wrote:

So is it fine to have a nested timestamp like that? I really don't like
it, but if you say there is no other way...

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#335 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA3w37WmasJt4S7I63a8SAO_r07nwgKYks5qyJYGgaJpZM4KMEwv
.

[samtstern]

@puf sorry for the delay here ... not that I know of. Upon further thought I don't think this feature belongs in FirebaseUI because it will have to be some sort of compromise 😐

[SUPERCILEX]

Closing because of the tradeoffs.