Xojo.Data.GenerateJSON troubles

Xojo 2015r1
El Capitan 10.11.6

The example code below, taken from the LOCAL documentation (Xojo.Data) returns: This item does not exists and highlight Xojo.Data.

[code] Dim d As New Dictionary
d.Value(“Team”) = “Red Sox”
d.Value(“City”) = “Boston”

Dim json As Text
json = Xojo.Data.GenerateJSON(d)[/code]

Nota: I am searching how to import / export data as .json. I do not reach level 0. The above report is just a way to say that I do not understand anything to start coding.

Short story:
a. I want to be able to export into a json file a Listbox contents,
b. I want to be able to import a json file contents into a Listbox,
c. I want to be able to import a json file into a TextField / TextArea. I think this is the easiest, but since I started with step a above…

Make sure you specify Xojo.Core.Dictionary as well.

I tried in vain:

Dim d As New Xojo.Core.Dictionary

but the code above works with the current Xojo. :frowning:

It probably was a bug in 2015r1…

AFAIK, in JASON, I have to save a pair of data: I have to store for each row the column name: cell contents. This create a far larger file / takes far more time to generate the file.
My generated code create a json file that is FOUR times the size of the original text file (100KB less than my XML file):

Type Weight
txt 127KB
json 545KB
xml 651KB

I understand the fashion (everybody want to use GIF, XML, JSON, whetever new stuff tomorrow, etc.), but not the use of weight storage file (and slower read/write and so on). Am I right ?

The tradeoff is speed/size vs. interoperability. The absolute smallest/fastest would be a binary file of your own design. The problem is that the file is only useful for your own application. Nobody else can read and decipher it. The next step would be to use a text file of some kind. At least a human could read it and figure out what’s in it. The next step was XML. It is structured in a way that a generic algorithm can unpack it and, if it has some commonly agreed upon structure or tags, make use of it. Then there’s JSON. It’s a step backward from human readability, but it is native to the web. You can post a json string to a website, and the data will be available to the website automatically as variables.

It’s all about sharing information. If you don’t care about sharing, use some private structure that affords you the best speed and size.

Hi Tim,

Thank you for your clear, clean and easy to understand explanation.

I implemented an Export to (Tab / Return) Text (from the SQLite database file).

Then, I was thinking… “Why don’t I add CSV, XML and JSON ?

CSV and XML are done, and JSON… I had hard times to start the TAB / Return text, then I spend time on the internet to try to acquire the knowledge, then… and now I am asking myself is it worth the spend price ?

Nota: I get an eye on what I have on my hard disk in term of .json file, and all I get was very small files excepted one whose structure looks like what we can display in a Listbox. I created a method that generate a JSON file (look alike, but I may not be 100% compatible to the standard). It was that file I compared to xml, csv / text…
www.w3schools.com said: JSON is a lightweight data-interchange format… Where is the lightweight ? :wink:

At this time in the application reformating, all I can see in json is a marketing advantage. Functionally, txt and CSV are absolutely enough (but this is just what I feel).

I’ve made a brand new search session using a different point of view and found an old entry in the forum with shared code. I took the second shared code (Classic Xojo Code) and add code befor and after what was shared.

My testing SQLite data base file is 164KB on disk (1969 entries with 11 fields/1 RecordSet). The ellapsed time is 648 Ticks only for the db read / json conversion. If I includ the save process, this time doubles (I issued a Return key press as soon as the OK button appears / no file name change) if I include the save to disk time (just to get an idea of the ellapsed time.
To do the same task for xml, the process time is less than 1 second (I do not used Ticks, but I checked a file creation / modification times… that are the same, same date / time including the seconds).

No, I do not recall the URL to the original Conversation / I thank the sharing persons / here is my current testing code (all in one PushButton as a lazy person !).

Xojo 2015r1 / El Capitan / MacBook Pro Mid-2014 / RAM: 8GB / SSD.

[code] Dim jsonArray As New JSONItem
Dim js As JSONItem
Dim dbFile As FolderItem
Dim db As New SQLiteDatabase
Dim SQLiteFT As New FileType
Dim dataRS As RecordSet
Dim Loop_Idx As Integer
// To compute the process time
Dim Ticks_Start As Integer
Dim Ticks_End As Integer

// Build a temporary SQLite FileType
SQLiteFT.Extensions = “sqlite;cdb;rdb”
SQLiteFT.Name = “SQLite Document”
// Icon_Pict = SQLiteFT.Icon()

// Get the file
dbFile = GetOpenFolderItem(SQLiteFT)
If dbFile = Nil Then Return
db.DatabaseFile = dbFile
If Not db.Connect Then
MsgBox("The database couldn’t be opened. Error: " + db.ErrorMessage)

Return

End If

// SQLite part
db.SQLExecute(“BEGIN TRANSACTION”)

// Get the start ticks…
Ticks_Start = Ticks

// dataRS = db.SQLSelect(“SELECT * FROM sqlite_master”) // Original code, changed to line below
dataRS = db.SQLSelect(“SELECT * FROM Foo”) // Replace Foo with your own Table name…

// Loop thru the file
While Not dataRS.EOF
// Get a New JSONItem
js = new JSONItem

// Go thru the RecordSet
For Loop_Idx = 1  to dataRS.FieldCount
  // Build the JSONItem
  js.Value(dataRS.IdxField(Loop_Idx).Name) = dataRS.IdxField(Loop_Idx).Value
Next

// Append a new entry into the array
jsonArray.Append js

// Read the next RecordSet
dataRS.MoveNext

Wend

// Report the data to the TA (TextArea)
TA.Text = jsonArray.ToString

// Get the end ticks
Ticks_End = Ticks // 648 Ticks

// Export the data into a json file
Dim file As FolderItem
Dim fileStream As TextOutputStream

file = GetSaveFolderItem("", “MyInfo.json”)
If file <> Nil Then
fileStream = TextOutputStream.Create(file)
fileStream.WriteLine(jsonArray.ToString)
fileStream.Close
End If

// Close the SQLdataBase
db.Close

// Ticks_End = Ticks // Time doubles [I click in save as soon as possible]
// You can use GetFolderItem to avoid the Save dialog
// You can use End_Ticks to report the write ellapsed time
// I know that I get around 10 seconds process time for both cases.

// Report the process time:
MsgBox “” + EndOfLine + EndOfLine +_
“Start: " + Str(Ticks_Start) + " Ticks” + EndOfLine +_
“End: " + Str(Ticks_End) + " Ticks” + EndOfLine +_
“Ellapsed time: " + Str(Ticks_End - Ticks_Start) + " Ticks” + EndOfLine[/code]

Ignore the Ticks / Time ellapsing lines of code.
Also, there is no Try in the TextOutputStream (it is a code taken from the language reference, and I do not wanted to wast time to add it: this is a proof of concept code / texting code.

PS: if you found an error, have a trick to speed up the process, etc. Feel free to share it here, so the next person who search in the Forum wil get a better Classic example.

Now I have to write the Read json file / fill the Listbox (fill a SQLite Data Base file) from the above generated file.

A couple of thoughts.

You do not need to start a transaction, since you’re not updating the database.

Calculate the elapsed time before you load the textarea. JsonItem.ToString may be taking a long time.

JSON is lightweight compared to a database, which requires specialized software to access, and compared to XML.

Thanks Tim.

I just recall why I wanted to know the ellapsed time: it tooks times to generate the json data, so I was curious.

Yes, including the TextArea display time is a bit unfair, (yes, I did it !), but it was part of my user experience (time I was waiting).
You are right, it add time, time the real user will do not wait since no one will report the json data inside the software (excepted for some use, maybe, but not mine).

I found the original discussion I based the code above on: here .

Thanks pals (John Walker, Paul Lefebvre and Jrmie Leroy) for the question and two examples.

(I do not closed the Tab, so I had the URL :slight_smile: ).

I just finished to remove (in a copy of the code) the time elapsing code and the display of the result in the TextArea.

The speed gain is tremendous until the TextOutputStream.Write(json.ToString). This part is a bit slow.

But: this is a trade off for my user. If (s)he want speed, do not use this export to JSON, else, drink a cup of tea and come back later :wink: