Plain Old Java Objects


Great you want take a look
at the app that I’m making?>>Sure.>>And wait for it.>>I’m not sure what I’m looking at. It says house shopping list. And then there is nothing underneath
like who am I shopping with? What items are we buying? You have anymore data on this?>>Well it’s an early prototype.>>Okay.>>Okay but I hear you saying it
seems like you want more data.>>Bingo
>>How did the initial user test go? Did they like it?>>They seemed underwhelmed. J.P., the users want more
data to be shown in the app.>>Well, we should give
the people what they want.>>Yeah.>>Implementing a list of
list ends sounds hard and a bit beyond version 0.1, but we could
start by trying to store two pieces of data with a shopping list instead
of just the name of the list. We could store the name and the owner. The owner will need to be a dummy value
though since we don’t have any user accounts working.>>Well I have heard that you can
convert simple Java objects into firebase database JSON. So we could make the shopping list
an object with two fields and then store it in the database. I’ll take a look at it
with our developer. When you’re working in Java and
storing data. You might find that it be really great
if you could just save an object to the database. In this case I bet you’d really
like to store shopping list object which let’s say has a name and
an owner to start. Now it is possible it fire
base to make a hash map with a collection of key value pairs,
and then you can use that hash map to
change your data and fire base. You can easily forget a key
value pair though, so this is not the recommended
way to do it. The expert recommended way to
do this is to make a POJO. AKA a plain old Java object. And then you can use Firebase’s
built in serialization capabilities to both put Java objects into the
database and take back out Java objects. To allow the Firebase STK to do this, our object structure needs to
adhere to a few simple rules. And here they are. Let’s go ahead and
take a look at each of these. The first rule, is that every instance
variable must match your children’s key names in Firebase. When your object goes into Firebase,
it’s basically going to look like this. You’ll have some sort of root node and
then a bunch of properties that correspond to member
variables of the object. And these keys here need to match
the member variable names exactly. Also, the types for all these variables should be Java
types that Firebase could handle. And those types are booleans, strings, logs, doubles, lists containing
objects that are any of these, maps containing strings and
objects that are any of these. And any other Firebase POJOs. These two values happen to be strings,
so we’re all set there. Rule two, you must have at least an
empty constructor in your POJO object. You can make other constructors, and you
don’t need to use the empty constructor but it does need to be there. And rule three is that you need a public
getter method for every member variable. For example here’s a public
getter method for owner. It should say get in the member
variable’s name in CamelCase. Okay, so let’s do this in the code.

3 Replies to “Plain Old Java Objects”

Leave a Reply

Your email address will not be published. Required fields are marked *