C#

Introducing Printomi

I’m extremely proud to announce the launch of a project I have been working on for quite a while now.

Printomi is a service for social games that allows players to take snapshots of their worlds and upload them to their own personal gallery. Players can like, comment share and order poster prints of their virtual creations.

The way it works is we provide the game owner with a tiny API that is used to interface with Printomi. The bulk of the Printomi client is downloaded at runtime from the Printomi servers. This is good for two reasons. Firstly by keeping down the size of the code that must be embedded into the game we can keep down the initial load time the player must sit through before they can play the game. Secondly we can upload changes and fixes to Printomi without requiring the game owner to recompile their code.

Once downloaded the printomi client is ready to be be used. In the case of Gourmet Ranch a themed button is shown to the player inviting them to click:

Once clicked (or activated by the JavaScript API) the main Printomi window opens:

The window has controls to zoom in and move the print about allowing the player to get the perfect angle of their world:

Once happy the player can then saves the print to the printomi servers. While the image is uploading the user can continue to play the game. Once the upload is complete the window is opened once more offering to show the player their print.

Printomi is tightly integrated with Facebook so that it’s as easy as possible for new users to get started:

Once connected the new print is then available for viewing, sharing, liking, commenting, etc:

In addition the prints are organised into galleries so that users can browse the uploads of others:

If a user particularly likes one print then they can order it as a poster:

Currently we only offer posters to people living in the US however we plan on opening it up to other countries when we can.

To print to such a large poster (24×18″ @ 150DPI) and maintain the quality of the final product we must capture a large number of pixels. For example here is a comparison between what a user would see on printomi.com and what we store behind the scenes:

The technology that lets us capture these large images and store them in a compressed way (to conserve disk space and therefore cost) is quite complex and will have to wait for a later post.

Printomi is currently only available to a small subset of the Gourmet Ranch user base but we are performing a steady-rollout to everyone, so if you don’t have access to the button in Gourmet Ranch just yet then don’t worry it should be available for you soon!

Printomi is a culmination of many many hours of hard work, late nights and stress. But its been worth it! I’ve had a blast throughout the whole process and am proud of the result. I have also learnt a whole bunch in the process. I have had to work with so many technologies to pull this off, to name a few: AS3, C++, C#, ASP.Net, MySQL, IIS, AWS. I have particularly enjoyed the C# work having largely abandoned the language since my early work with it.

If you would like to support me or if you would like to keep up to date with the goings on with Printomi then you can like us on Facebook or follow us on Twitter :)

Windows 7 Taskbar Performance Monitor v0.2

Been a long time since I have updated this little project of mine. Yep, just checked, its been almost a year since.

Oddly enough this is one of my projects I actually use on a daily basis at home and work. Im not sure why I haven’t updated it since as there have been some rather gaping bugs in it which have been very annoying but apparently not annoying enough to encourage myself to fix them or to stop using it.

Anyways, I have finally decided to fix some of the most anoying issues namely:

  • It no longer crashes when the network is lost
  • It now correctly reports the amount of physical memory used

Theres no auto-updating feature built into the tool so if you are looking for the upgrade head over to the google code page to grab it: http://code.google.com/p/win7-taskbar-mon/downloads/list

Wow! Just noticed that over 2000 people have downloaded the first version, didn’t think it was that popular!

Oh yes, I have also uploaded the latest source for this version: http://code.google.com/p/win7-taskbar-mon/source/checkout

Enjoy!

Inputtie Development History – Networking

This is part two in my series of posts on the development history of Inputtie.

In this post I talk about the challenge of device discovery and networking in the Inputtie app.

Zero Configure Networking

I knew I wanted Inputtie to be as simple to get running as simply starting it up. For this to happen Inputtie would need to discover all other devices on the network also running Inputtie. So how to do this?

Well, as it happened I had been reading at the time about Apple’s Bonjour which was designed to do just what I needed. It is a combination of a multi-cast and DNS lookup service that allows it to detect other Bonjour capable devices on the network. Sounds perfect.

So I got to work on implementing their Java API. After many trials and tribulations I eventually had it working.. kinda. It was detecting other devices sure, but every now and then it would sporadically disconnect from the network. I couldn’t for the life of me work out why. I posted on forums and even tried to read the reams of source to see what was going on but alas to no avail.

After much deliberation I decided to look for another solution to the problem of Zero Conf. networking. Next up were a whole host of other attempts. I tried JmDNS which is was supposedly very similar to Bonjour. I also experimented with JGroups. I had limited success with all of them and in the end only really succeeded in wasting several months worth of development time.

The Solution

In the end the solution (and the one currently employed in Inputtie) was the simplest. After months of messing around with these libraries I had learnt quite abit about how they performed their magic. At the heart of it they either used multi-cast or broadcasting to announce a device on a network. Broadcasting can be thought of as a sort of sonar pulse. The broadcasting computer sends a message on a specific IP address then another device listens for the message and proceeds to open a Socket for a more private form of communication. From Wikipedia:

A broadcast address is a logical address at which all devices connected to a multiple-access communications network are enabled to receive datagrams. A message sent to a broadcast address is typically received by all network-attached hosts, rather than by a specific host.

I decided that if these libraries could use broadcasting for discovery then so could I and if I wrote it myself I could keep it simple. So I set to work coding an example in Java. In no time at all I had it running and surprisingly it worked! Sure it wasnt as robust as the established libraries, it didn’t handle devices disconnecting from the network, different network subnets or IPv6 but it was simple and at least it worked!

Broadcasting in Adobe AIR

As I mentioned in a previous post Inputtie went through many re-writes during development from its original form in Java through C++, C Sharp and finally Adobe AIR. With the latest (it was still in beta when I started development) version of Adobe AIR 2.0 several new APIs were made available for use, one of them being new classes designed specifically for peer to peer (P2P) networking. With these new APIs I believed I should be able to implement network broadcasting much in the same was I was doing in Java. Unfortunately however it seemed that Adobe was restricting the use of broadcast to their new P2P service Cirrus.

There was however another crucial API released with AIR 2.0; the NativeProcess API. With this a developer is able to easily execute and communicate with a program written in another language. What this meant for Inputtie was that I could write the user interface in AIR and then use NativeProcess to call Java code that would perform actions not available in AIR, such as Broadcasting. (incidentally it also is a great way to do multi-threading in Air ;) )

So the current solution in Inputtie is to use NativeProcess from AIR to communicate with a small headless (no user-interface) Java process that does the broadcasting and listening for broadcasts. Once the Java process detects an incoming broadcast it passes the information back to AIR.

EDIT: If anyone is interested in seeing the source to my previous (failed) attempt just drop me a comment or an email and I would be happy to share.

1 2 3  Scroll to top