Hello everyone,
Who is using our JSONMBS class and for what exactly?
I plan to upgrade it with more features, but prefer to not break existing usages.
Best regards,
Christian
1 Like
I convert a Dictionary to JSONMBS to pass data through a URLConnection to a middleware server and back. It mainly handles small text data, but also some large binary data via Base64.
'Convert to JSON
Var tempDictionary As New Dictionary
Var tempVariant As Variant
…
tempVariant = tempDictionary
tempJSONMBS = JSONMBS.Convert(tempVariant)
'use tempJSONMBS.toString
As long as I can still convert a Dictionary to JSONMBS and back, I’m happy.
What are the advantages of JSONMBS vs Xojo’s JSON classes/methods? If I knew that, maybe I’d use it 
Sometimes the benefits of MBS are obvious, e.g. when something doesn’t exist in Xojo, but it’d be great in other cases if the MBS documentation would give some explanations of -why- the MBS classes are better or more useful.
3 Likes
I have some legacy code using it.
There was a time when JSONMBS was, at least in many aspects, performing much faster than the Xojo JSONItem class. I guess there should be a thread about performance tests somewhere here, dated a few years back.
I think I remember that Xojo improved the internal class’ performance, so the tests results might not be valid anymore.
On the other hand, JSONMBS needs much more verbosity, like having to use a class factory when you want to add some kind of value.
@Christian_Schmitz I am using it in a client’s project for gathering information sent to a server, but redesign if necessary would not cause too much trouble.
EDIT: Found the thread: JSONItem replacement - #47 by Kem_Tekinay
Yes, I remembered that, but Kem’s tests are ancient and new benchmarks as of Xojo 2021 would be very helpful.
I’m mostly interested in the speed of JSON lookups through a child or two vs making a dictionary of the child once, then looking up in the child dictionary in my loops. The former makes code cleaner, but I suspect the latter is much faster.
That’s the main reason I haven’t bothered trying it.
Looks like I have in about a dozen projects, all originally dating back years, so at the time I would have used it because of the performance advantages. If I had to refactor to something else, it would not be a big deal to me.
New benchmarks comparing the various JSON and Dictionary alternatives since Xojo 2021 would be enlightening though…
That’s well out of date now, and JSONItem is substantially faster.
So I am about to switch to using a new JSON library which can do more.
The new class should cover > 90% of both old JSONMBS and JSONItem to be a drop in for both.
And it gets a few new features like iterators.
The Convert function will stay of course for @David_Cox.
2 Likes
You may be thinking of The ZAZ: JSON Performance Tests Round 2 which is very out of date these days. I always intended to run another set of tests with Einhugur, but never got around to it. These days, you can’t really go wrong, but I suspect MBS is still the performance king if you need the absolute fastest parsing.
< Instead of derailing this thread, I have created a new one. My apologies, Christian >
Updated JSON Speed Tests Project
1 Like
or not
in fact i use the 3 of the tests, i’m suprised mbs is not way faster than build in
We use it for all JSON processing…
…and they way we are using it is according to the example project we’ve created with you: JSONItem clone
So basically it is the replacement for Xojo’s JSONItem which we are using via your Plugins.
As long as that example project continues to work “as it is” it’s probably fine for us 
For JSONItem_MBS, you would need to remove this in the constructor since the parsing constructor now raises an exception:
If (mJSON.Handle = 0) or (mJSON.ParseError <> "") Then
Raise New JSONException("JSONMBS ParseError: " + mJSON.ParseError, mJSON.Handle)
End If
and for FromJSON, you need to handle the new types:
Case JSONMBS.kTypeFalse
Return False
Case JSONMBS.kTypeNumber
If pJSON.IsInt64 Then Return pJSON.ValueInteger
Return pJSON.ValueDouble
Case JSONMBS.kTypeString
Return pJSON.ValueString
Case JSONMBS.kTypeTrue
Return True
replaced with:
Case JSONMBS.kTypeDouble
Return pJSON.ValueDouble
Case JSONMBS.kTypeInt64
Return pJSON.ValueInt64
Case JSONMBS.kTypeUInt64
Return pJSON.ValueUInt64
Case JSONMBS.kTypeString
If pJSON.IsInt64 Then Return pJSON.ValueInt64
If pJSON.IsNumber Then Return pJSON.ValueDouble
Return pJSON.ValueString
Case JSONMBS.kTypeSingle
Return pJSON.ValueDouble
or just use JSONMBS as JSONItem replacement itself.
With JSON, something is missing : the currency type.
This is strange because using amounts is very common.
There are 3 ways to use currencies : convert them to double with the risk of having something such as : 125.589999999…
Convert them to string to get “125.59” (with quotes that is quite strange for an amount).
The 3rd way is to build the json as a string and do what we want.
I’ll like to have something like
myJson.value(“amount”) = myCurrencyValue and getting : {…“amount” : 125.59, …}
Or the fourth way, which I’ve seen most often, is to treat the currency as an integer. Multiply by 100 for storage, and divide by 100 for displaying to the user.
1 Like
Our json class stores numbers with string representation.
So a currency can go in and out without trouble.
heu… if this json is in reply of an api, you never know who and what will treat it. (“hey guy, don’t forget to divide this amount by 100 !..”)
Gag : with the same json built with a postgreslql json function :
Xojo jsonitem.tostring gives : “theAmount”:1572078.99,…
Postman gives : “theAmount”:1572078.9899999999907,…
It is, and APIs are where I’ve seen this. All environments will have this problem. JSON is more-or-less typeless. So using an integer is a reliable way to avoid the problem entirely.
That said, it sure would be nice if Xojo were to apply some sort of formatting rules so you would get something like what you see in Postman. But Xojo is aiming for accuracy, and doubles aren’t very accurate. Which… again… is why integers are a common solution.
1 Like