Thursday, September 23, 2010

Porting a desktop app to the web

With the ability to build web applications coming to REAL Studio soon, I'm sure many of you are thinking about creating a web version of some of your desktop projects. Whether you are going to continue to have both a desktop and a web version and wish to share code between them, or you plan to move your project entirely to the web, there are some changes you may have to make to do so.

Primarily, these changes are in three areas: communication with user interface controls, reporting and graphics.

Communicating with User Interface Controls
Although the user interface controls in our web framework are for the most part very close to their desktop equivalents, they don't share any code with those desktop equivalents. As a result, they are not the same classes under the hood so you can't have code that directly talks to both a desktop pushbutton and a web button. So the first thing you have to do (if you haven't done this already) is separate this code from the UI.

I have started porting a desktop project to the web recently. The project is a very fancy calculator of sorts. The user fills in 10 or so fields, chooses some options and the app calculates the advantages of doing one thing instead of another. The window is filled with methods, each of which is essentially a formula. Anytime the user changes a value in a field, a bunch of these methods run and update StaticText controls that show the results. Since these methods can be directly accessing controls (even via parameters unless I only pass in values), I have to change the way the methods get their data.

To port this to the web, I created a class (which I called "scenario" since one set of data and results is a scenario in this case). I moved all the methods to that class and then created properties for each of the fields on the window. I added a property to the window that holds a reference to a Scenario object and I create that object in the open event of the window. The fields now just update the properties and the methods use those properties rather than the fields themselves. Once I was sure that worked and produced the same results as before, I made the class an external file so I could share it with the web project.

Once I had made this change, I imported the Scenario class into my web project and added code to the controls on the page to update the same properties. So if you have your code and UI closely tied together (as I did), you will need to separate them first. You can do that today in preparation for building your web version. Incidentally, this kind of separation is just good design as well. And by using the class as an external item in both the desktop and web projects, I can fix or enhance the code in this class from either project.

If your desktop project prints, then you'll need to take a different approach for the web. Printing for a desktop project means drawing into a graphics object or using the Report Editor. Using a graphics object isn't a great solution for the web because you can't send it right to the printer. You would have to display it on a page. Sending page-sized graphics over the internet is not a great idea regardless of what tool you use to build your web app. And the Report Editor is not supported for web applications right now. The best solution is to create a page which you lay out for printing. Then you just fill in values, most likely into labels (the statictext control of the web framework) and present the page to the user. They can then print the page directly from their browser.

There's not much in the way of overhead when it comes to using graphics in a desktop application. In a web app however, the varying speeds of the Internet between your app and the user's browser, will impact the responsiveness of your app so you need to be thinking about how to optimize when it comes to sending large amounts of data from the app to the browser. Large pictures will be time-consuming. You can make them smaller by using JPEGs. But if possible try to avoid using pictures. There are other ways, in some (certainly not all) cases, to use controls such as rectangles combined with styles to create graphics that are smaller and can be cached automatically by the browser. For example, to create a monthly calendar, use rectangles and labels rather than drawing the whole thing in a big picture.

In summary, there are some things you can do now to start preparing your desktop project to become a web project. There are also things you can start thinking about in terms of how you will approach printing and graphics in your web application. It's going to take some trial and error to find the techniques that make the most sense for you.


Karen said...

Decent Bargraphs could be coded generically just using WebObjects if we could use control arrays to clone objects.

Other things like graphs do need graphics and the smaller the file the better...

Jpeg are are often not optimal because they don't support transparency and are lossy.

For many things we draw ourselves (not photographs) , GIF or PNG-8 would be best because because the are very small, loss less (so display exactly as drawn) and support transparency.

As for printing, while it may be difficult, I think the ultimate solution would be for us to be able to create PDF using RB drawing APIs for Object2D and raster drawing.

Almost every browser on the face of the earth can handle PDFs either natively or has plugin for it installed, which would make printing easy.

Printing the way you suggest has a number of limitations but could suffice for things that are not too formal.

Geoff Perlman said...

I agree that there are times when PNG is appropriate and in the long run, PDF is the way to go for printing. However, creating PDFs is not something we have available at the moment so creating pages is the best solution.

Karen said...

Just to be clear, i was not talking about 'normal' PNG which is PNG24 and RB already supports.

I'm taking about PNG8 which gives lossless compression with much smaller small files because it uses indexed color and supports transparent pixels. Small is important obviously because of bandwidth issues

That or GIF (which also uses indexed color and supports transparent pixels) is what is best for things like graphs and animation that we could produce in code.

These formats give sharp graphics - not the fuzzies of low quality JPEGS, but still have very small file sizes.

GIF and PNG8 were specifically designed for online graphics. Being able to create either of them in the WE would make doing more things practical...

I've noticed some websites use Flash to present crisp looking graphs on the fly (JPEGS with small files don't look that good).

If we could create graphics on the fly in GIF or PNG8 format we could do as well or better visually and more efficiently without a plugin.

Anyway JPEGs are not the whole solution to web graphics and bandwidth issues. They are best for actual photographs, but for most things we would create on the fly GIF or PNG8 would be much more appropriate.

Unknown said...

Monkey Bread Software makes a great PDF creator. I use it all the time, DynaPDF. Should work well for creating PDF's on the fly to publish in WE apps.

Kundalini said...

Thanks Geoff, for your continuing updates. I'm excited to begin porting my favorite project to the web. So I want to put in a word in favor of Hierarchical Listbox -- that control will be crucial for me. Hopefully you'll be making it a high priority in WE?

Unknown said...

We use DynaPDF ourself for a demo web app. You can check it here:

Doing PDF is not easy. Font embedding, picture encoding, metadata, annotations and all this little goodies make it complicated. There are a few free RB classes, but you'll quickly come back to us :-)


S James Parsons Jr said...

REAL studio web addition, has great WebObjects/ animated graphics, but what web formate are they in, HMTL5? I just want to know if that stunning visual candy is supported on the iPad.

Geoff Perlman said...

Actually it's all CSS animation. At this point I don't think he have anything in Web Edition yet that is HTML5 only but we do have plans for some new features in the future that will be.

William Wagner said...

I didn't know that it's even possible. Creating web apps versions of your desktop apps is a great idea.

web design Perth