Strategy for translating desktop to web apps

I understand that one can build a Xojo app for any targeted platform for the same app type. So one can create a desktop or console app and deploy it to MacOS, Windows and/or Linux and I guess Rasberry Pi. But … the control library is a bit different for web, so one cannot deploy that same app to a web server. One must create a separate web app and apart from low level support routines that might be able to share with a desktop app, it would appear that you must also copy and modify code to a significant extent.

If there’s an intention to unify the desktop and web abstractions, it’s long term and not in the immediate future.

I guess I am just verifying that the above statements are true. I am at a crossroads where I have to decide if my administrative infrastructure for a planned web API will be a desktop or web app.

Thanks in advance for any insight or experiences here.

Not all “Desktop” code will work cross platform, sometimes we need to employ #if Target directives

what do you mean by Unify? as in write for one target and deploy to all?

Can you be more specific?

NO. All the oposite. Xojo has said that one of the main goals of the new Web framework is to leave behind the idea of web apps behaving like desktop apps.

And with the new classes names like DesktopButton and WebButton, they are going in an oposite direction of the “unification”

I mean there would not be a distinct project type for web. If you have an app that has a GUI, it could be deployed to any supported desktop platform OR to the web. Of course there might be certain constraints where you’d need some conditional code or something wouldn’t be supported (you can’t normally write files to the user’s computer from a browser sandbox for example).

In my case I have an app that is essentially a CRUD app for certain database tables. It would be nice if the same code base could provide that functionality either via the browser or via a standalone app. So I could either navigate to admin.mysite.com or remote into the web server (or a network connected box) and launch a desktop app that talks to the same DB.

If this is the ultimate goal it doesn’t look like it is there yet. This isn’t a criticism BTW, I understand it to be a tall order.

Ah … so it is seen as a bug rather than a feature that you could deploy the same code base to web or desktop. Hm. Well I am not sure I even disagree. I was just curious about what direction it was headed.

If you hypothetically wanted both desktop and web app versions of substantially the same functionality, you could, to a significant extent, avoid copy-and-paste code. It would just require careful design. And you would have to futz with control placement, tab order, and so on in two places unfortunately.

Not.a big deal in practice, other than the need to decide early on which way you want to go.

Not sure why one would want to do both. Especially for corporate internal apps. Web apps are so much better for CRUD type applications, especially in the deploy or update once and serve many users paradigm. I long ago switched to Web apps for database oriented apps that are need to be access by many users. I rarely write a desktop app anymore except when the target is either a very small group of users that need something portable or just for myself because I need something quick and dirty. I do write console apps for shelling out to for some of the web apps and for some daily utilities that need to be run as Task Manager or Cron jobs.

Why not put all the CRUD database logic in an external module that both the web and desktop apps use. The only difference is the UI.

If the database is going to reside on an internet server, then your only option is to create a web app that talks to the database and exposes an API that desktop apps can call.

1 Like

I agree it’s an edge case. Though we do often see web apps that say “the user experience is better in the mobile version”. So sometimes you need to provide both, although ironically, the mobile version could just be a wrapped browser instance anyway.

I am whacking this particular management app out as a desktop app, as a learning experience and partly because the core service they’ll support is written in C# and I’d rather not figure out how to support both a .NET core deployment and a xojo deployment on the same web server. Also if the admin functions are not exposed as an endpoint and can only be run by remoting into the server then that’s arguably more secure and less work setting up authentication and such. The VPN and RDP client logins will provide security. Finally … only myself and possibly one other person will need to use them.

xojo not have a project group to compile all in one project :frowning:
having the business logic at least in classes is very helpful. (means not spread in events)

about desktop deploy in intranet if people have a shared drive
you can start it from nas via link.
deploy in windows enviroment is just copy the build folder to nas (if all exe’s are closed).
not necessary to use a setup for each build.

currently i made my own office app with many tables for input and view in blazor because
xojo web 2 not fit my requirement.

1 Like