What is difference between serialization and database storage In java? Doesnt serialization actually mean storing data in a database on server?
Let's think of the database like a bowl.
If you want to keep stuff from going everywhere, you put it in the bowl.
Your stuff is the data you want to store. Right now it's out there, on the table, in a box.
So we're going to take the stuff out of that box. The problem is, the stuff in our box probably won't fit into the bowl. How do we fix that?
We need to change it into the type of object that will fit into our bowl. We need to serialize it.
Our serialized data will fit in the bowl now. So we take our serialized data and we pour it into the bowl, and we have the most important meal of the day.
In case this was all really complicated. Simplified: to serialize is to change, and a database is a place to store stuff. Often, you change stuff before you store it.
Serialization can be used to prepare an object for database storage - it is a the process of converting an object into a storable or transmittable format, such as a string or a stream of bytes.
We can't store a java object into most normal storage types as-is - but if we for instance serialize it into JSON we can store it. We can then retrieve the JSON at a later point from the storage and deserialize it to get back an object the same as our original object, given that the serialization and deserialization is properly implemented.
Of course, this doesn't have to entail database storage - having the object serialized into a JSON stream for instance also allows us to transmit it over the internet to be deserialized on another computer.
No. Not at all. Serialization in Java is an API which generates a storeable version of an object that you can later load back from disk (or wherever you store it) and make it back into an object with (hopefully!) the same state as it once had. There are alternatives to it such as Google Protobufs which are better for networked applications, but it is good enough for most simple uses.
Serialization is the process of converting a data structure into a form that can be persisted (saved on a hard drive) in any way. It can be binary, xml, plain text, html, ... usually the goal is to be able to deserialize, that is restore back the state of your data structure at the time it was persisted.
A database is just the place (and not the way) where you store your data.
Related
I download big json files 8x(2mb) and used Gson to convert them into java objects. Now I need to make these objects available to all the activities. is it safe to save them as static variables?
You must be very lucky to avoid the out of the memory exception.
I would probably store the object to Room database(or any sort of SQL) while parsing and read when required.
Or just store the JSON as a binary file and read again necessary bits when its required since I don't know the usage of the JSON data I can't comment on more... But definitely avoid storing in the static variables.
So I am working on my app, and it parses data from the LoL (League of Legends) API, so far so good, but the only problem is that if the user closes the app, and reopens it parses the data again. I want the objects I parsed from the JSON data to be saved, once it initially parses them, instead of redownloading them every time I reopen the app. It slows my app down.
There are a few ways to do that, but they all basically doing the same thing: serialize/de-serialize objects. The difference will be mostly what kind of persistence storage and what serialization mechanism are you using.
As for persistence you can use for example file, data base, etc.
Java provides human-unreadable binary serialization. Instead you can use JSON, XML, etc. formats. I assume Java built-in serialization will be the fastest, but it won't be deserialize if your class changed in the mean time.
Local persistence also would allow to map objects you parsed into database and load them pieces by pieces as needed.
Save your JSON data as a string in Android SharedPreferences. It is the most convenient and fastest method for you.
Using SharedPreferences
I think i am little bit confused on this part . As Why we use files in serialization in order to store our save objects that we read later, why dont we just skip serialization and store it into database and read it from there. Aint this is similar
1) Can a non-serialised java object be sent over the network to be executed by another JVM or stored in local file storage to get the data restored?
2) What is the difference between serialising and storing the java object vs storing the java object without serialising it?
Serialization is a way to represent a java object as a series of bytes. Its just a format nothing more.
A "build-in" java serialization is a class that provides an API for conversion of the java object to a series of bytes. That's it. Of course, deserialization is a "complementary" process that allows to convert this binary stream back to the object.
The serialization/deserialization itself has nothing to do with the "sending over the network" thing. Its just convenient to send a binary stream that can be created from the object with the serialization.
Even more, sometimes the built-in serialization is not an optimal way to get the binary stream, because sometimes the object can be converted by using less bytes.
So you can use you're custom protocol, provide your own customization for serialization (for example, Externalizable)
or even use third party libraries like Apache Avro
I think this effectively answers both of your questions:
You can turn the non-serialized object (I guess the one that doesn't implement "Serializable" interface) to the series of bytes (byte stream) by yourself if you want and then send it over the network, store in a binary file, whatsoever.
Of course you'll have to understand how to read this binary format for converting back.
Since serialization is just a protocol of conversion and not a "storage related thing", the answer is obvious.
Hope this helps.
In short, you don't store a non-serialized object in java. So I would say no to both questions.
Edit: ObjectOutputStream and ObjectInputStream can write primitives as well as serializable objects, if that's what you are using.
1) Can a non-serialised java object be sent over the network to be
executed by another JVM or stored in local file storage to get the
data restored?
An object is marshalled using ObjectOutputStream to be sent over the wire. Serialization is a Java standard way of storing the state of an object. You can devise your own of doing the same but there is no point re-inventing the wheel unless you see a big problem in the standard way.
2) What is the difference between serialising and storing the java
object vs storing the java object without serialising it?
Serialization stores the state of the object using ObjectOuputStream and can de de-serialized using ObjectInputStream. Serialized object can be saved to a file or can be sent over the network. Serialization is the standard way to achieve all this. But you can always invent your ways to do so if you really have a point to.
The purpose of serialization is to store the state of objects in a self contained way that doesn't require raw memory references, run time state etc. In other words, objects can be represented as a string of bits that can be stored on disk, sent over a network etc.
I am writing a server in java that allows clients to play a game similar to 20 questions. The game itself is basically a binary tree with nodes that are questions about an object and leaves that are guesses at the object's identity. When the game guesses wrong it needs to be able to get the right answer from the player and add it to the tree. This data is then saved to a random access file.
The question is: How do you go about representing a tree within a file so that the data can be reaccessed as a tree at a later time.
If you know where I can find information on keeping data structures like trees organized as such when writing/reading to files then please link it. Thanks a lot.
Thanks for the quick answers everyone. This is a school project so it has some odd requirements like using random access files and telnet.
This data is then saved to a random access file.
That's the hard way to solve your problem (the "random access" bit, I mean).
The problem you are really trying to solve is how to persist a "complicated" data structure. In fact, there are a number of ways that this can be done. Here are some of them ...
Use Java persistence. This is simple to implement; make sure that your data structure is serializable, and then its just a few lines of code to serialize and few more lines to deserialize. The downsides are:
Serialized objects can be fragile in the face of code changes.
Serialization is not incremental. You write/read the whole graph each time.
If you have multiple separate serialized graphs, you need some scheme to name and manage them.
Use XML. This is more work to implement than Java persistence, but it has the advantage of being less fragile. And if something does go wrong, there's a chance you can fix it with XSLT or a text editor. (There are XML "binding" libraries that eliminate a lot of the glue coding.)
Use an SQL database. This addresses all of the downsides of Java persistence, but involves more coding ... and using a different computational model to access the persistent data (query versus graph navigation).
Use a database and an Object Relational Mapping technology; e.g. a JPA or JDO implementation. (Hibernate is a popular choice). These bridge between the database and in-memory views of data in a more or less transparent fashion, and avoids a lot of the glue code that you need to write in the SQL database and XML cases.
I think you're looking for serialization. Try this:
http://java.sun.com/developer/technicalArticles/Programming/serialization/
As mentioned, serialization is what you are looking for. It allows you to write an object to a file, and read it back later with minimal effort. The file will automatically be read back in as your object type. This makes things much easier than trying to store the object yourself using XML.
Java serialization has some pitfalls (like when you update your class). I would serialize in a text format. Json is my first choice here but xml and yaml would work as well.
This way you would have a file that doesn't rely on the binary version of your class.
There are several java libraries: http://www.json.org
Some examples:
http://code.google.com/p/json-simple/wiki/DecodingExamples
http://code.google.com/p/json-simple/wiki/EncodingExamples
And to save and read from the file you can use the Commons Io:
import org.apache.commons.io.FileUtis;
import java.io.File;
...
File dataFile = new File("yourfile.json");
String data = FileUtils.readFileToString(dataFile);
FileUtils.writeStringToFile(dataFile, content);