Usage of JSON for a daily activity journal - c#

To keep track of my new year resolutions I created a file daily.log in the following format.
8:40 AM 1/2/2013
begin:755am
activity:enquired about 3x3 black board;bought book [beginning html 5]
waste:facebook;
meeting:old friend;mechanic
programming:none
blogpost:[asp.net deployment]
do:buy black board
done:
end:1045pm
I am in the process of creating a simple C# console application which would ask me a few questions and fill this file accordingly. One of the future features to this tool would be to display a simple dashboard style web page for measuring the progress of resolutions among other things.
I would to like to use a data serialization or configuration file format for storing daily activity information in this manner, because mature tools are available for these formats rather than for plain text.
I never used JSON before and am wondering whether the JSON format can be used independently with C# (no javascript involved), and even if I can, whether the usage of JSON is appropriate in this case.
If not JSON, its superset YAML? or are any other alternatives that suit well for this purpose?

You can use JSON.NET in C# without using javascript. And I believe this data can be modeled in JSON format.

If your goal is to work with external tools to have them recognize and be able to work with your files, a better bet than JSON would be to use XML. This format is stricter (and you can use XML Schema to validate the format) and there are way more tools that are able to work with XML than there are for JSON.
The .NET Framework also contains extensive support for XML, in the System.Xml namespace (see http://msdn.microsoft.com/en-us/library/system.xml(v=vs.100).aspx).
That being said, there is no reason why JSON would not work with C#. I have personally used the JSON.NET library for most JSON work and it works beautifully (see http://james.newtonking.com/projects/json-net.aspx). Mind you, the data you show in your example is not valid JSON.
Good luck!

Related

Custom documentation topics when using /doc

I'm working on parsing out the XML file that is generated when you pass /doc as a compiler option. We had previously been using VSDocman to handle the parsing and documentation website generation, along with custom topics. We ultimately didn't like the web site generated by VSDocman though and want to do something more robust with MVC.
It's easy enough to parse the XML file, but I'd like to also add custom topics like I can in VSDocman to the XML file. Is that not possible with the built in documentation support in Visual Studio? Will I have to create a custom XML file that manages all of that, writing it manually (or building a custom tool to generate it) and parsing it during my /doc parsing?
Microsoft itself does not define a standard format for extra documentation. Thus, you have to decide what tool to use next and then use the format it supports.
Besides, XML is so flexible that you can try to transform it from one format to another, so I assume it is not a big deal.

Object serialization - from C# or java to Objective C

Server side - C# or java
Client side Objective C
I need a way to serialize an object in C#\java and de-serialize it in Objective C.
I'm new to Objective C and I was wondering where I can get information about this issue.
Thanks.
Apart from the obvious JSON/XML solutions, protobuf may also be interesting. There are Java//c++/python backends for it and 3rd parties have created backends for C# and objective-c (never used that one though) as well.
The main advantages are it being much, much faster to parse[1], much smaller[2] since it's a binary format and the fact that versioning was an important factor from the beginning.
[1] google claims 20-100times compared to XML
[2] 3-10times according to the same source
Another technology similar to protobufs is Apache Thrift.
Apache Thrift is a software framework for scalable cross-language services development. Apache Thrift allows you to define data types and service interfaces in a simple definition file. Taking that file as input, the compiler generates code to be used to easily build RPC clients and servers that communicate seamlessly across programming languages.
JSON for relatively straight forward object graphs
XML/REST for more complex object graphs (distinction between Arrays / Collections / nested arrays etc)
Sudzc. I am using it. It is pretty easy to invoke a Webservice from i-os app.
You dont have to write code to serialize object.
JSON is probably the best choice, because:
It is simple to use
It is human-readable
It is data-based rather than being tied to any more complex object model
You will be able to find decent libraries for import/export in most languages.
Serialisation of more complex objects is IMHO not a good idea from the perspective of portability since often one language/platform has no effective way of expressing a concept from another language / platform. e.g. as soon as you start declaring "types" or "classes" of serialised objects you run into the thorny issue of differing object models between languages.
On iOS there are couple of JSON frameworks and libraries with an Objective-C API:
JSONKit
SBJson
TouchJson
are probably the most prominent.
JSONKit is fast and simple, but can only parse a contiguous portion of JSON text. This means, you need to save downloaded data into a temporary file, or you need to save all downloaded JSON text into a NSMutableData object (kept in memory). Only after the JSON text has been downloaded completely you can start parsing.
SBJson is more flexible to use. It provides an additional "SAX style" interface, can parse partial input and can parse more than one JSON document per "input" (for example several JSON documents per network connection). This is very handy when you want to connect to a "streaming API" (e.g. Twitter Streaming API), where many JSON documents can arrive per connection. The drawback is, it is a much slower than JSONKit.
TouchJson is even somewhat slower than SBJson.
My personal preference is some other, though. It is faster than JSONKit (20% faster on arm), has an additional SAX style API, can handle "streaming APIs", can simultaneously download and parse, can handle very large JSON strings without severely impacting memory foot-print, while it is especially easy to use with NSURLConnection. (Well, I'm probably biased since I'm the author).
You can take a look at JPJson (Apache License v2):
JPJson - it's still in beta, though.

Deserializing a java serialized file in C#

I have a have a java project that serializes some objects and ints to a file with functions like
ObjectOutputStream oos = new ObjectOutputStream(fos);
oos.writeInt(RANK_SIZE);
oos.writeObject(_firstArray);
oos.writeObject(_level[3]);
oos.writeObject(_level[4]);
...
Now I have trouble deserializing that file with C# (tried the BinaryFormatter) as it apparently can only deserialize the whole file into a single object (or arrays, but I have different objects with different lenghts).
I tried first to port the generation of these files to C#, but failed miserably. These files are small and I don't must to generate them myself.
Do I need to alter the way those files are generated in Java or can I deserialize it in any way?
There is nothing in the standard .NET framework which knows how to deserialize Java objects. You could, in theory, use the Java serialization spec and write your own deserialization code in C#. But it would be a large and complex project, and I don't think you'd find many customers interested in using it.
Far, far easier would be to change the way you serialize the data to use a portable format: JSON, or some form of XML. There are both Java and C# libraries to deal with such formats and the total effort would be orders of magnitude less. I would vastly prefer this second approach.
Maybe an at first sight counterintuitive solution might be to serialize them to some commonly understandable format like JSON? I'm not even sure the binary format for serialized objects in Java is guaranteed to remain unchanged between Java versions....
Jackson is my personal favorite when it comes to Java JSON libraries.
http://www.ikvm.net/ IKVM can do it perfectly.

Saving map data in a 2d ORPG

I'm trying to figure out how I can best save the map data for a 2d ORPG engine I am developing, the file would contain tile data (Is it blocked, what actual graphics would it use, and various other properties).
I am currently using a binary format but I think this might be a bit too limited and hard to debug, what alternatives are there, I was thinking about perhaps JSON or XML but I don't know if there are any other better options.
It has to work with C++ and C# and preferably also with Python.
Personally, I would stick with a binary format. Whatever method you choose, it's going to be a pain in the ass to edit by hand anyway, so you may as well stick to binary which gives you a size and speed advantage.
You're also going to want a map editor anyway so that you do not have to edit it by hand.
XML is well supported across basically every language. It may become verbose for large maps, however, depending on how you encode the map data in XML.
JSON might not be a good choice, simply because I don't think it supports multiline strings, which would be helpful (although not really necessary)
YAML is another alternative, though it's not as well-known.
You could just stick to binary - most maps would be a pain to edit by hand, no matter what format you pick (though I've heard of Starcraft maps being edited with hex editors...) Just use whatever seems easiest for you.
Additionally, check out the Tiled map editor (http://www.mapeditor.org/), which lets you edit maps (with custom tile properties, I think) and save it in an XML based format, including optional GZip for compression.
Lua is also a possibility which can be used as a config file with tables. It's been a while since I worked with Python but doesn't it also support a AJAX style data structure? You could simply use Python files if you are already using it.

Binary serialization of Silverlight XAML object

I'm working on Silverlight application that needs to display complex 2d vector graphics.
It downloads zipped XAML file from the server, parses it (XamlRead) and injects to the layout root on the page.
This works fine for fairly small xaml files. The problems is that I need to make it work with much bigger file (lots more content in it). For example one of my uncompressed xaml files is 20 MB large and XamlRead method takes tool long to parse it. My question is if is there a way to do all the parsing on the server side. It would best to just store serialized binary output of XamlRead method as BLOB in the database. However when I try to serialize it, I'm getting a message that "Canvas object is not marked as serializable". I will really appreciate any advices .
Silverlight doesn't have much binary serialization built in; however, protobuf-net works on Silverlight and may help plug this gap. In the current build you can only really serialize types you control (due to adding attributes) - however, I'm in the middle of a big refactor to (among other things) add support for serializing types without attributes.
I expect it to be about 2 more weeks before this is available as a (hopefully) stable build, but you're welcome to take a look at it then.
Note that you will still need to give it some help (telling it what you want it to serialize), but it may be useful.
In particular, the data format ("protocol buffers") is designed to be both dense and efficient to process, which should increase the parse speed. See here for more (numbers are from main .NET, not Silverlight)
I've found the SharpSerializer package very easy to use for fast binary serlization in Silverlight: http://www.sharpserializer.com/en/index.html. You do not need to use the Serializable attribute -- however it only serializes public members.
If parsing is really the problem, it might help to use pre-compiled XAMLs called 'BAML'. This is a binary representation of the XAML file. Since the binary format has a much much cheaper parser instead of the too generic XML, this helps a lot. BAML is also used internally by the .NET compiler to generate more compact files.
For more information, see also http://stuff.seans.com/2008/07/13/hello-wpf-world-part-2-why-xaml/

Categories

Resources