Develop Reference

When working with GSON is it mandatory to have classes for JSON objects that are needed to be excluded?

I am trying to use GSON in order to parse a JSON that include some classes and fields that need to be excluded. Do I have to create classes for such objects, and include such fields in classes I create?

As it take Class<object> classOfT as parameter so we have to pass parameter, but if you dont want to make your custom class you can use it by this way.
Gson gson = new Gson();
gson.fromJson("Response Json String", Object.class);
and you can play with that object in many ways.

You can use #Expose annotation for your fields with serialize and deserializeparameters to false

Just don't add the field to the class and ignore it. There is no need to use all input, even with auto-mapping. Whatever has no #SerializedName annotation will not be mapped- #Expose also controls that. But the actual beauty of GSON is parsing such nested nodes to classes of various types.
just see: #SerializedName, #Expose.

Which is better: using a map inside array list or a pojo class to interact with json response

I'm a bit confused, as from a long time i am saving the json response directly to an ArrayList> and displaying to my listView, but now, looking on other people code i noticed that they are using POJO class to interact with JSON, Is it is better way? if it is please explain why? cause using POJO means I have to write extra code, But if saving the response directly to the arraylist make my work done, then why should i use a POJO class?

So, Pojo usage better due to OOP pattern, because you work at runtime with your Java object without intermediate Json parse. Manual json parsing too ugly due to code style(its my opinion).
But if saving the response directly to the arraylist make my work done
If, you collect your object in Maps, you can apply different features out of the box(sort, compare etc) to your map, but in case when your map contains POJO instead of JSONS.
Encapsulation. When you work with dates for examples or with type, its pretty good to use getters/setters for data mapping instead of manual parsing again and again.
4.Object scaling and mapping:
Lets image that we have some object user:
public class User{
int id;
#SerializedName("specific_id_for_blah_blah")
private int mSpecId
#SerializedName("date_of_birthaday")
private String mBDay;
public Date getBirthday() {
return new Date(mBDay);
}
}
What I want to say by this example.
You can map your json to POJO with one line of code only
User user = new Gson.fromJson(response, User.class);
Pretty simple isn't?.
Name serialization. When your response contain key name which looks to long or weird, you can use your own style naming with easy changes, just with small annotation. mSpecId returns value of "specific_id_for_blah_blah"
Platform specific encapsulation. You can use only platform specific object at your runtime, instead parsing operations in your business logic. String with data -> Date or Calendar
Also you can override Object methods in your POJO (equals, hashcode, toString) for your logic spec. operations.
If your serverside change some key you can change name of key in POJO instead looking through where you parse it before. IN same case you can add new field and setter/getter, if some of parameter will be added to your response

There is no right and wrong answer here. It all depends on your use case. If your solution works, and you are happy with it, I don't see why do you need to change it.
If I had to choose, I would go with a POJO class to represent the response, but this is a subjective opinion. I think that you have the following benefits:
It's cleaner - having a separate, dedicated class to represent your payload gives you the ability to be more specific in your code. You are no longer manipulating Maps of key - value pairs, but instances of a specific class, that can have a more specific behaviour. You can specify natural ordering, criteria for equality, etc - things that may be useful for your program's logic
It's simpler - I would prefer calling a getter every time then accessing a map by a property name and getting an Object back. The logic of the program will be much simpler and safer.
It's better in terms of OOP best practices - the whole point behind OOP is to have objects, that define properties and behaviours. IMHO, using POJOs to represent responses forces you to adhere more closely to best practices.
There are also some cases that will fit the no - POJO approach better - for example, if you only display your data, not manipulating it in any way inside the app. Or if you want to shave off some time for the complex parsing that may be needed if you are trying to inflate object hierarchies.
My best suggestion is - profile your app, check your use cases and make an educated decision which approach is better.

Android - Save Parcelable data into a file

I used to use Serializable objects to save them in filesytem and read them in order to do whatever I want. But Serialization is slow when you have to pass data between activities, so I read than it's recommanded to use Parcelable. Then I did it and yeah it's faster ! But now, I have a little problem. Since Parcelable is optimized for IPC, then they aren't serializable and can't be saved into a file. So I would to know if it's possible to do it.
Also, If I decide to implement both Parcelable and Serializable interface for my class, but only use the Parcelable to pass data between my activities, I would be able to save the class into a file. But I guess than since I use serializable (only to save, not to pass data), this is not a good idea hum ?
I thought too to use Gson library, to serialize data from class, and save the JSON into a file, and reuse Gson to deserialize JSON to get my Parcelable object. Does it seems to be a good idea ? What about performance ?
Thanks to all for your answers!
J.

Just do context.getFilesDir() and use a java.io.ObjectInputStream and java.io.ObjectOutputStream.
Also, with regard to "Parcelable not now serializable". This doesn't entirely make a lot of sense since Parcelable in an interface, not a class you extend.
So,
class MyClass implements Parcelable, Serializable {
}
should work just fine. Once you read and write the object to the file system, the Parcelable interface will still work. It's only an interface.
I have to admit I haven't tried it, but it's what I wrote today and I will be writing the unit test tomorrow.
Hope this helps.

Here's another approach if, as you say there is a conflict between the Parcelable and Serializable interfaces. (Again, that doesn't make sense, but I'll trust you until I finish my unit tests tomorrow)...
Think about this:
Parcel p = Parcel.obtain();
p.writeValue(asset);
p.setDataPosition(0);
byte [] b = p.marshall();
p.recycle();
OOPS, just read the javaDoc for marshall() and it says DO NOT STORE TO DISK. It also says, "Use standard serialization to store to disk" (paraphrase).
So, my first answer should do it for you.

Did you try to use shared preferences? If you need to store key values. Moreover it'll be an XML.

Implement parcelable interface using Gson

I'm trying to implement the parcelable interface using Gson. The idea is to create a json string (using gson) and write it to the parcel object.
Could it be a correct way to implement the interface?
The only problem I've encountered is when I deserialize the object. Actually, I use gson to recreate the object.
private MyClass(Parcel in) {
String json = in.readString();
Gson gson = new Gson();
gson.fromJson(json, getClass());
}
The problem is that the fromJson function returns an object that is the object the constructor should create.
The last line of code should be something like
this=gson.fromJson(json, getClass());
So, if this is a correct way to implement Parcelable, how could I solve this problem?

You should read more carefully the Parcelable javadoc. It contains everything you need.
As quoted in the docs :
Interface for classes whose instances can be written to and restored
from a Parcel. Classes implementing the Parcelable interface must also
have a static field called CREATOR, which is an object implementing
the Parcelable.Creator interface.
So you should have the writeToParcel method declared and also use a creator that will produce instances of your class from a Parcel.
The private constructor is an additional helper that you can use to set the value of the fields of an object given a parcel, but not the object itself. In Java, this is a right value, and can't be assigned.
BTW, the goal of parcelisation is to be provide a short term fast serialization process. You should, generally speaking, use a fast and compact data format when you use parcelisation. JSON is not a candidate of choice, but it will work.

Android serialization - will this work with a whole instance of an object?

The response I got to my previous question :
https://stackoverflow.com/questions/15489956/sending-data-structure-through-byte-android
states that I should look into serialization for converting my data to a byte array for transfer via bluetooth.
I have been looking into it but can't find any definite answer that states whether I am able to transfer a whole instance of an object, I was originally thinking of sending several arrays but now I am thinking maybe I can just create an object:
"Test"
parameters:
Test Name - String
Questions - Array of Strings
Question Answers - Array of Strings
Correct Answers - Array of Ints
My programming isn't that great so I was wondering, could I create this class, let the user on one device construct an object and then pass THAT object itself on through serialization (as shown in Java Serializable Object to Byte Array)
Will this ACTUALLY fully work and give me a whole object on the other system from which I can access the data elements I need?
Sorry if this is a stupid question but as I stated before my programming isn't that great and so I get confused sometimes :(
Thanks!

could I create
this class, let the user on one device construct an object and then
pass THAT object itself on through serialization
Short answer: Yes
But don't forget that class have to implement Serializable interface or NotSerializableException will be thrown.
Will this ACTUALLY fully work and give me a whole object on the other
system from which I can access the data elements I need?
Yes but this "other system" must know about this class. So if you create class
public class Foo implements Serializable {
private String name;
private int age;
// getters and setters
}
Application that want to deserialize object, must have this class in build path, simply said.