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.
Related
So I'm making a weather app and I found when the app is idle for too long and destroyed that the forecast data is lost. So I think the best solution is to save the data to internal storage and retrieve it when it's needed.
The class containing the data has 2 arrays of other data classes, and it all contains strings, ints and doubles.
What is the best way to save this data? The options I've seen are a preferences file or saving it to a file in local storage.
I didn't think the preferences file would work because it sounds like that is more meant for smaller amounts of data.
I've been trying to save to local storage, but that hasn't been going well. Not too familiar with manually saving bytes to a file, and the Android developer guides aren't very comprehensive at all. I tried to serialize it, but get the not serializeable error. As far as writing the bytes I think I got it correctly written by converting strings to bytes using getBytes, saving the ints as they are, and converting doubles to strings then using getBytes. I'm not sure if that is even the correct way to do it, and I'm not sure how to read the bytes because you have to read a specific number of them. Do I have to find out how many bytes each type of data is going to be? For example finding the type of string encoding and reading the number of bytes for that data type?
What would be the best way of going about this? Should I just use the preferences file? Can someone either tell me how or point me to a resource for reading data from a file like this? Any help would be appreciated.
I tend to use preferences for different amounts of data. Shared preferences save to an xml file. Here is an example:
SharedPreferences.Editor editor = context.getSharedPreferences("pref_name", Context.MODE_PRIVATE).edit();
editor.putString("name", value);
... // add all your other items here to save
editor.commit();
To get the data just do something like this:
SharedPreferences preference = context.getSharedPreferences("pref_name", Context.MODE_PRIVATE);
preference.getString("name", defaultValue);
It is pretty simple and easy to use. I do sometimes save large data sets. For those, I will usually convert the data to json and then save that json as a string. When I get the data I will convert from json to java.
Another option is to use a sqlite database and store all your data there. There are many tutorials and documentation on how to save to a database.
Here is a great read to get you started: https://developer.android.com/guide/topics/data/data-storage.html
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
I was wondering if it was possible to store a hash map with a special key function (similar to the solution posted by Jon Skeet at Using a byte array as Map key) and thus data wrapper inside the android internal storage
And how to get them out again.
Namely, the data underlying it all is char [], but that char [] is wrapped around in this custom class that is used in the hashmap.
The value part is simple string, but the key is the important bit where I need the data inside it to be preserved on each opening of the app.
Do I need to overwrite certain functions in the wrapper to make sure it works with the FileOutputStream? How do I import it back again?
Use Gson to convert the map to a JSON string. Then write that string to disk. To get it back, use Gson again. Prob could accomplish this 5 lines of code. No messing with convertors or parsing needed.
I don't have a direct answer for you. However I can suggest simply saving your hashmap as an xml file. Writing the xml is pretty easy. You will need to write the higher level parts of parsing to read it back.
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.
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.