Interesting, thanks so much for the response.
I'll keep this in mind as I continue to develop my app. It's still between custom byte stream, json, thrift, etc.
But MsgPack looks interesting as well and, if anything, these blog posts have brought it into the light for me.
I looked at the java class and what might help is if you can set a buffer size and use that buffer to store the data in the buffer and expand it if necessary. But that seems like a lot of work.
But yeah, not sure if you can optimize based on usage patterns due to the constraint you said.
In any case, great stuff and thanks for the info.
Very interesting discussion.
I work on a 2D MMORPG for Android.
This is extremely relevant to me. I have a few questions though.
What if you take compression and deserialization out of the picture?
For example, in my server I have a hash like data structure that gets turned into JSON for browsers and byte array for mobile clients.
For example, because the data has to be transferred at fast rates and will be going over mobile networks. The size of the packet matters because every millisecond counts.
Then to read the data, I simply read the stream of bytes and build the objects I need on the client.
This has to happen mostly without allocations for example on Android to avoid the GC.
So a few questions:
Does deserializing JSON cause any memory allocations?
If you're not tokenizing the data and don't need to parse it, will it be a significant gain over s serialized byte protocol or JSON?
In any case, I'll experiment on my end and perhaps blog about my own findings.
I don't know, I'm pretty bothered by this. I checked Google Play the day I purchased it and it was only available w/ a contract.
That's why when I saw it at Fry's I bought it because it was unlocked. Should have waited two more days and gotten it at half price. In any case, I'm going to go complain to them about this. I believe they offer price matching.
Indeed, it looks like they're even using requestAnimationFrame.
It's still really slow on Firefox, which I've found to be one of the worst offenders when making canvas games.
The problem here might be fixed by splitting the physics loop from the animation loop.
I think it's doing all the calculations as fast as it draws.
Freaking amazing, I've been utilizing MVC heavily to develop HTML5 games. Mainly borrowing ideas from Android and iPhone development with their layout engines and staying out of the way as much as possible.
I don't think it's coming full circle. They're just properly separating the project code, so that the time critical code is in C/C++ while the scale/fault-tolerant code will be in Erlang.
Same as @wallflower.
Our team is really small (2) so we never really run into that.
I wouldn't want two devs working on the UI at the same time. It's kind of an unspoken rule because just merging anything UI related is a big pain.
Like from the web world, one dev would do the UI html and js, while the other would do the server logic and API.
I try to use the MVC model in my projects, where the XIBs and their accompanying .m files just have basic getters/setters and the xibs are rarely changed.
It's so much easier when you already know how to program anything.
I was a Perl dev and dabbled in Java. I was forced at my job to learn iOS and produce a specific app in less than 3 weeks.
Wasn't pretty, but working under pressure can be good motivation too.
For normal interfaces XIBs are way easier to maintain and handle then a bunch of addSubView calls.
The only things that should be hard coded are interfaces that are too unique or exotic. Even then, XIBs allow you to place arbitrary UIView elements wherever you wish and you can get the best of both worlds.
Now that's the extreme, but this whole don't hit your kids movement is an epidemic.