When sending a large pojo I want to check for bytes changes and not detail differences in structure. Maybe serialize and hash the pojo in memory but that can fail on an Android device. Any thoughts would be grate. Should a traverse it dom style maybe.
OUT
outputStreamWriter = new OutputStreamWriter( out, "UTF-8");
jsonWriter = new JsonWriter(outputStreamWriter);
jsonWriter.setIndent(" ");
jsonWriter.setIndent("\t");
jsonWriter. beginArray();
mygson.toJson( largeTestPojo, LargeTestPojo.class, jsonWriter );
jsonWriter.endArray();
jsonWriter.flush();
IN
InputStreamReader isr = new InputStreamReader( in, "UTF-8");
StatsTypeAdapterFactory stats = new StatsTypeAdapterFactory();
Gson gson = new GsonBuilder().registerTypeAdapterFactory(stats).create();
jsonReader = new JsonReader( isr );
jsonReader. beginArray();
largeTestPojo= gson.fromJson( jsonReader, LargeTestPojo.class );
jsonReader.endArray();
I want to check for bytes changes and not detail differences in structure
I'm not sure what that means.
Compare large local gson against remote gson
It's not clear to me where the comparison is to occur, whether the complete input and output contents are to be available in the same place or if something like a hash -- as mentioned -- is to be used to represent something on one end or the other.
If the complete input and output structures are available at the point of comparison, then...
I likely wouldn't use the Gson API (or any serialization API) for the task of data structure (or service message) value comparisons. I prefer to use serialization APIs like Gson only for serialization/deserialization tasks, keeping those layers of the system as thin and as simple as reasonable.
So, I'd probably prefer to deserialize into the target LargeTestPojo, and implement a compareTo and/or equals method for it, or just put the two data sets into a map, and compare from there.
Related
There are lots of tutorials out there describing how to fetch JSON objects from the web and map them to Core Data.
I'm currently working on an iOS (later: Android as well) app which loads json objects from web and displays them to the user. In my opinion all this mapping from and to Core Data is an overhead in this case, it would be much easier to save the JSON objects directly and use them as "cache" in the app. Are there libraries/documented ways how to achieve fetching json objects, save them locally and fetch them with a predefined identifier?
I would love to fetch e.g. 10 objects, show them to the user and save the data locally. The next time the user is on that list the local data is shown and in the background the json-file is fetched again to be up-to-date. I guess this is a common use case but I didn't find any tutorials/frameworks enabling exactly this.
You can simply use NSURLCache to cache http responses instead saving JSONs
http://nshipster.com/nsurlcache/
There are many ways to implement this. You can implement cache using either file storage or database depending on the complexity as well as quantity of your data. If you're using files, you just need to store JSON response and load it whenever activity/fragment is crated. What I have done sometimes is store the JSON response in the form of string in a file, and then retrieve it on activity/fragment load. Here's an example of reading and writing string files:
Writing files:
FileOutputStream outputStream = context.openFileOutput("myfilename",Context.MODE_PRIVATE);
String stringToBeSaved = myJSONObject.toString();
outputStream.write(stringToBeSaved.getBytes());
Reading from files
FileInputStream inputStream= context.openFileInput("myfilename");
int c;
String temp="";
while( (c = inputStream.read()) != -1){
temp = temp + Character.toString((char)c);
You can convert this string to JSONObject using :
JSONObject jsonObject = new JSONObject(temp);
Or you can use the string according to your needs.
i would like to ask, how to store json data. I have a JSON file, which i parse using JSON Library. Now i got the data from a file. But i want to store them and show them later again.
The question is, whats the best way to store data? And is it even worth to store them?
I'm thinking about sql database, because its simple and most used.
Official android docs have few examples, so far i searched but if u have better guide, let me know.
Thank you! :)
EDIT1:
Ok, i have json file with data, which i can add to my app using RAW resources. Those data wont change, its a list of recipes, i dont have to download it. I can read the data like this:
InputStream is = mContext.getResources().openRawResource(R.raw.package_01);
Writer writer = new StringWriter();
char[] buffer = new char[1024];
try {
Reader reader = new BufferedReader(new InputStreamReader(is, "UTF-8"));
int n;
while ((n = reader.read(buffer)) != -1) {
writer.write(buffer, 0, n);
}
is.close();
//catchblock
.....
}
and then i can parse the data trought JSONLibrary like this:
try {
//representing []JSON
JSONArray jsonArray = new JSONArray(writer.toString());
if(jsonArray != null){...}
...}
Im sending a HashMap to ListView, which includes name and id. And if the user clicks the ListView/GridView item, there is new Activity started, which shows all parsed data. I need to get match those parsed data with the id.
There are about 200 recipes in the file. The data are parsed on start of the Activity, while Splashscreen is displayed. I´m not sure, if its good idea to parse the data everytime when app starts.
So, is it effitient to parse data everytime the app starts? And if yes, how to keep the parsed data "together"? Should i use HashMap?
I hope i clarified my question :) Thanks for help.
EDIT2:
So after i knew what to do, i tried the suggested solution to use HashMap. Problem was there i got Failed Binder Exception. I have images encoded in Base64, that means i have a very long String, example here. That is a lot of data, there is limit:
The Binder transaction buffer has a limited fixed size, currently 1Mb, which is shared by all transactions in progress for the process.
I´ve tried to save it to
Set<String> titles = new HashSet<String>();
and then to SharedPreferences but the data for each recipe gets mixed.
**So, here it comes again, should i save the data to SQLite database or is there another effective option i can use? **
Thank you!
It really depends on a number of things like: How much data do you have now, how much will you have later, how complicated is the data. You could use something as simple as an array or hashmap; or something as complex as a database. You need to consider what you are trying to do , and find the simplest solution. If you are trying to persist data, you could use shared preferences, database, and internal/external storage (options outlined here).
Without more information it's hard to say what exactly to do. Keep it simple though. If you are getting JSON from a web service, I'd use an ArrayList or HashMap to store the data, rather than persisting it. It is simpler to implement and does the job.
EDIT:
To answer your question: Yes, using a HashMap and parsing each time is fine. You only have 200 fields, and you don't have images, so the time it will take to parse is minimal. Regardless of how you store the data, there is going to some level of "parsing" done. For example, if you store the data in a database, you are going to have to still pull the data, and put it into a HashMap.
I need to import data from a file to my application. The obvious choices are XML and JSON. I have heard that JSON is lightweight and when parsed with Jackson, it gives good performance. But I have also heard that JiBX for XML is fast and uses XMLpull to give good performance. I would like to know which option to go for and why?. Can I get a speed comparison of XML with JiBX and JSON with Jackson? Also, I want to know if Google Gson is better than Jackson for JSON parsing.
Json is the light weight.If you want to use large documents use, JSon with Jackson.
Excellent explanation been given in this article(especially read Note:). Xml you have
different types like DOM,PULL and SAX.But as per my knowledge, JSON is the best. For Large
documents,prefer Jackson. http://www.javabeat.net/2011/05/androids-json-parser/
For Jackson and gson. Have a glance of this link.
Jackson Vs. Gson
So when comparing with xml and json,i always suggest you to use json, since it's a light weight data for android. So it will be fast in loading and display the data. And gson,
it depends based on your project. Please see the above link comparsion.you will cleanly understand.
In addition, Jackson can also do XML if that's what you need, with https://github.com/FasterXML/jackson-dataformat-xml
I also agree in that Jackson+JSON will be faster than any of XML-based solutions (as per https://github.com/eishay/jvm-serializers). JibX is not bad and probably is fast enough for most uses (as do many, many other options). But if speed is your thing, Jackson will be faster of choices you mention.
I agree that in pure performance, JSON is going to be faster than JiBX.
You choice of tools should depend on the data you are transferring.
Use JiBX if you have a concrete data definition. JiBX is especially good at creating and retrieving complex data objects. JiBX will make sure your data is correct and automatically convert your data to and from Java objects.
Use JSON if you want more flexibility. JSON doesn't check to see if your data is correct.
For example, when you create an object in JiBX:
Person person = new Person();
person.name = "Don";
person.age = 52;
When you retrieve the information in JiBX:
System.out.println("Name: " + person.name);
System.out.println("Age: " + person.age);
In JSON, your code would look like this:
JSONObject person = new JSONObject();
person.put("name", "Don");
person.put("age", new Integer(52));
To retrieve the transmitted information:
String name = person.get("name");
long age = person.get("age");
As you can see, the JiBX code is nicer to read, but the JSON is more flexible since you don't have a schema definition.
In either solution, your code is exactly the same in your Android client and your java service/server.
I hope this helps.
Don Corley - JiBX contributor
If you check my previous questions, you will see that they are all in some way related to "\" or "/" for Android and why my implementations of code wasn't working when other people's versions were.
I now know why mine wasn't working.
I am developing for a live client who has access to a content management system, from which I am getting the data. Other than the general checks, they can post anything they want to the site.
They are posting sizes in inches; e.g. 5-1/2
It is this, and this alone, which is screwing up my Restful json.
For example, 1 eigth has become
1\\\/8
Currently, I am doing a string rewrite at the WCF point to catch these 'fractions' and turn them into decimal just so I can continue development. But I can't code for every eventuality and Android/Eclipse fails at JSONArray json=new JSONArray(result);
Would appreciate any input on this.
Dave
On reflection, and further investigation, it isn't the escaped fractions causing the problem.
It is something more fundamental.
Will close the question.
I have searched high and wide for an answer to this, and have finally found it.
I will share for anyone else experiencing the same issue:
It is the WCF Rest service.
Learning WCF and Android at the same time led me to believe that the response from WCF should be a String serialized in the Json format.
To do this, a .Net object, array or whatever would go through DataContractJsonSerializer before being returned as a String to Android for further parsing.
Something like this:
Dim stream1 As MemoryStream = New MemoryStream
Dim ser As DataContractJsonSerializer = New DataContractJsonSerializer(GetType(myType))
ser.WriteObject(stream1, myThing)
Dim _json As String = Encoding.UTF8.GetString(stream1.ToArray())
stream1.Close()
return _json
Wrong.
Keep your object, array or whatever and return that instead; WCF will take care of the proper escaping for you.
For example (this is VB);
IService:
<OperationContract()> _
<WebGet(BodyStyle:=WebMessageBodyStyle.WrappedRequest, RequestFormat:=WebMessageFormat.Json, ResponseFormat:=WebMessageFormat.Json, UriTemplate:="/MyKit/{AccountID}")> _
Function GetKit(ByVal AccountID As String) As MyKit
Service:
Public Function GetKit(ByVal AccountID As String) As MyKit Implements IService1.GetKit
Dim allKit As New MyKit() //Your object
objDal.CommandText = 'run some sql here - or whatever
Using dr As SqlDataReader = "blah"
//populate your object
End Using
Return allKit //return the object, not the string representation of it
End Function
Using DataContractJsonSerializer for sending as Json to Android from WCF effectively 'pre-escapes' the data. When it gets to Android, the Json parser is unable to handle it, because it also escapes the data.
I'm using JSON Framework to update the data of client side from server. I have 30 Pojo Classes and i received the Http Response from server. I create the Object of Reader by using the method
InputStream instream = entity.getContent();
reader = new InputStreamReader(instream, "UNICODE");
And i pass it in the Json Object like this
synchronizationResponse = gson.fromJson(reader, SynchronizationResponse.class);
But this line is giving outOfMemory Exception.
I write the response in a file and found the size of file is around 12MB.
So is their any way to split the response in multiple response.So that i can read and write simultaneously to avoid OOM exception.
Looking for Help
Difficult to say, as long as we do not know, what your SynchronisationResponse Class looks like.
Whatever your content, if you can split it into sub-sections, do so and serialize those.
You can use a JsonReader to parse a large stream of JSON without running out of memory. The details are in the documentation, but basically you create a JsonReader:
JsonReader reader = new JsonReader(new InputStreamReader(instream, "UNICODE"));
and write a recursive descent parser using reader.nextName() to get keys, reader.nextString(), reader.nextInt(), etc. to get values, and reader.beginObject(), reader.endObject(), reader.beginArray(), reader.endArray() to mark object boundaries.
This allows you to read and process one piece at a time, at any granularity, without ever holding the entire structure in memory. If the data is long-lived, you can store it in a database or a file.