views:

285

answers:

2

Hi,

I'm getting confused re the range of options for development & deploying some simple code & UI to both Windows & Mac. Can anyone assist re a good direction here. I do like Ruby, however if it makes sense to move away from this (e.g. java, c#) then so be it. Which development option would people suggest for this?

REQUIREMENTS 1. Support for Windows & Mac 2. The installation should be one-click and package all required dependencies as much as possible. 3. Scheduling capability required - so either via (a) installed as a service/daemon, or (b) ability for installation to schedule periodic call to script (former is preferred) 4. Functionality component requires - ability to access/parse web-sites, and then ability to make HTTP(S) calls out to my site to store parsed data. So heave on HTTP(S) methods. Proxy support required in app, so ability for user to enter host/port/username/password for the proxy server.

DEV OPTIONS ?? - This is where I need help/advice. Some of the many options that come to mind: 1. Develop in Ruby and then find packaging product to create Windows & Mac installation packages - not sure how doable this is yet? Especially if I need the installation to effectively install as a service. 2. Develop in Java for cross-platform? but then needs users to have installed JRE? 3. Develop as Firefox addon? I'm not across this, but even if you can write custom code, then the issue would be firefox would have to be running I guess. 4. Develop windows & Mac versions separately, for example using Visual Studio Express to develop the windows version (assuming it can do HTTP work & create packages for installing services).

What would people suggest here? (would be nice to write once, push a button and then get the Mac & Windows installation packages spat out)

Thanks

+2  A: 

Mono will support the cross platform Windows and Mac requirement.

Mono allowed me to develop a Windows Forms executable assembly on my Windows environment and then simply execute the exact same executable using Mono on OS X.

Some of the GUI controls behave a little differently, but if you're writing a Service you will probably not be creating a complex GUI.

Checking the mono docs, I see the System.Net.WebClient class is implemented and provides a simple cross platform way to retrieve data over HTTP.

I used Visual Studio 2008 on a Windows machine to develop the application completely as I would any other .NET Windows Forms app. Then the resultant executable can be run directly on the Mac machine by passing it as an argument to the mono runtime.

You probably want to treat installation/deployment as a separate issue from the implementation of the actual application code. You may well need a platform specific installer for each supported platform, but each installer will deploy the same single binary (or set of binaries) on each platform thanks to Mono.

Ash
+2  A: 

I've written cross-platform C++ code and this was the kind of decision we were faced with.

Apologies in advance, but I'm not aware of any cross platform libraries that you can use for this, the systems are sufficiently different that they will require different deployment strategies.

Suggestion 1:

  • build your application in Mono
  • build two deployment strategies, separating the deployment issues into the "installers"
  • on windows deploy with some scripting language or installer application that inserts your app into the task scheduler, or write some simple C# code (see below)
  • on the Mac use the built-in UNIX cron demon to periodically call your app.

I think this strategy is fairly simple. The platform-specific effort is centered on the deployment. The app uses no resources until it runs, and it uses simple mechanisms to activate it. Logging and error handling can be done using the file system.

Suggestion #2:

  • write the platform independent code as an assembly
  • write the platform-specific code for each platform as necessary:
    • on windows that's a windows service or a scheduled app installed with click-once
    • I've been away from a mac long enough that I don;t know what the strategy is there
  • again, additional effort for the deployment

This solution has the overhead of writing more specific code to interface with the particular services that the OS Supports. The benefit is that it should co-exist better with the OS with the additional effort (ie: hook into OS-level resource management, reporting, logging and error management).

Note: C# interface to the Windows task scheduler here Unfortunately it's probably not Mono-compatible.

Oplopanax