JSON
-
After looking at how to bring data from our Apollonian web-service into Unity3D, Android and iOS over the last few weeks, it seemed natural to extend this series to cover HTML. A big thanks to Jeff Geer for suggesting Three.js, which is the HTML5-based framework I ended up adopting for this project. I like Three.js for a number of reasons: just as jQuery (another library I've used in this project, to good effect) attempts to abstract away the messiness inherent in supporting multiple browsers, Three.js does the same for the world of browser-resident 3D. The other main reason I like…
-
In the last post, we saw some code to implement a simple 3D viewer of data coming from our Apollonian web-service on iOS. In this post, we'll add support for touch gestures, as well as a simple message box announcing when the web-service is unavailable. When compared with Android, iOS provides much higher-level gesture information via its UIKit framework: you basically get callbacks to indicate when the screen has been tapped or swiped, or when pinch or rotate gestures have been performed. This is all very helpful, in the sense that you don't have to do so much low-level running…
-
Last week, it was all about Android. This week, I've started taking the plunge into the world of iOS. I've been using a Mac for some time – mainly to wean myself away from being so Windows-centric, but also with a view to working more with AutoCAD for Mac from a development perspective – but this was the first time I'd actually forced myself to write anything for either OS X or iOS. It all came as a bit of a shock, initially, even though I was generally aware of the strangeness of Objective-C with respect to its message-passing syntax.…
-
I hadn't actually planned a 3rd part to this series, but Dennis Ippel kindly spent some time looking at the code posted in the last post, to see where optimisations might be made to increase the sphere count. Consequently, Dennis made some changes to the Rajawali framework to support batch rendering of objects, as well as suggesting some client-side changes that make use of object cloning to avoid the need for replicated vertex buffers, index buffers, textures, etc. – all properties/dependent objects that the code was previously creating per sphere. The results were stunning: with really a modest change to…
-
In the last post, we took a quick look at some basics around developing application for Android, while today we're going to see the code for our Apollonian Viewer application. Or, as my 5 year-old likes to call it, the "sweetie planet" app :-). Last time, I mentioned Dennis Ippel as the author of the Rajawali framework I've used in this app. What I didn't mention is how helpful he has been with getting this app working: Dennis gave hints that unblocked my efforts on a number of occasions, and even implemented new capabilities in Rajawali to enable several of…
-
As mentioned in the last post, today we're going to have some fun pulling data from our recently-implemented, cloud-based web-service into the Unity3D game engine. My intention, here, is to reinforce the fact that exposing web-service APIs really does give you broader reach with your technology. In this case, we'll be calling our web-service – implemented using F#, which we could not have included in our Unity3D project – inside a game engine that could be hosted on any one of a wide variety of operating systems. A few words on Unity3D: according to its web-site, Unity3D is "a feature…
-
A quick recap on the series so far… after introducing the benefits of moving application functionality to the cloud, we spent a couple of posts taking algorithms we'd previously hosted directly inside an AutoCAD and moving them to live behind a locally-hosted web-service. We then took a step back and talked about some issues around architecting applications for the cloud before we went on to make use of our web-service inside AutoCAD. And, most recently, we looked at how to move our web-service from a local system to be hosted in the cloud. And a quick aside, as I watched…
-
Consumption seems to be a relevant topic, coming after the long Easter weekend here in Switzerland… I was laid up with gastric flu on Monday: after having consumed large amounts of food with friends on Saturday and Sunday, I ended up eating nothing for the whole day. I managed to put the finishing touches on the previous post in this series, but beyond that I was pretty useless. Anyway, back to the point. We've looked at the trend of moving to the cloud, and the steps for creating and implementing a RESTful web-service using the new ASP.NET Web API. Now…
-
In the last post, we looked at the core technology we're going to use to expose our web-service, along with the basic project set-up. In today's post, we're going to flesh out this project and see the web-service in action. At this point, I should point out that I've switched back across for VS2010 for the purposes of this post (and its immediate successors), as it really will simplify the eventual integration with Windows Azure. Before we dive into the implementation of our web-service, here are a few words on what we're after… We want to implement two web-service APIs:…
-
I know, I know... I said I'd be posting on IronRuby, but yet again I got distracted <sigh>. Back to that next week, I promise. The good news is that, once again, I managed to get distracted by something pretty cool. 🙂 Earlier in the week I'd stumbled across an article mentioning the Bing API (currently in version 2.0), which allows you to perform programmatic web searches using various web-service related technologies, such as REST, JSON & SOAP. I played around with that, for a while, importing the Bing web service into different versions of Visual Studio (both of which…