Desktop app ideas

Miscellaneous Topics
#1

I have been tapped to rewrite a desktop app from scratch. It currently exists as a VB app using an access database. Our field sales team spends their day in the field then when they get home(or before they go out) they VPN into the office, run this desktop app and communicate with the server to upload the days collected data and download updated cube data, app changes, etc. During the day they use this app to record data from store to store, so it is used all day, but only “online” with eh server a few minutes each day.

I am considering rewriting this in java. What recommendations do you guys have for the type of communication I should use to exchange data with the server once or twice a day? Webstart comes to mind for app updates, etc. The project leader has deemed an xml architecture and to throw away the access db.

C# has also come to mind.

Comments, thoughts, suggestions?

#2

Not sure whether its applicable or live any more, but there was an XML dialect designed for this sort of thing, SyncML.

http://www.openmobilealliance.org/syncml/

Kev

#3

Does your project leader actually know what they are talking about? XML is no worse than access but if you are working with any volume it is no better either. I would suggest a real database.

If you did do decide to use C# it is exceedingly easy to integrate XML web services- you can do it in a drag and drop kind of way from Visual Studio. I don’t know how well java works equivalent to that because I haven’t really used it much for serious client-side work. You almost certainly do want to use web services to manage the communication - they work over http and for a once or twice a day job they are ideal.

#4

thnks to both of you. The server side db is SQL Server, there needs to be a db on the client for use when he is not “connected” to the office, which is 90% of his day. Yeah, I have done quite a bit of work with xml and c# on web apps, and it is nice and fast to develop. Hadnt done and socket work with c# and I have with java as a possible comm link. Webstart also sounded good as an app launcher and updater.

Thnks again and can always use more input.
M

#5

If you are talking to a real database then you might nwant to look at JDBC or JDO.

#6

Oh right- for that XML would probably be my choice for the client data storage in that case. You sound to be pretty much on the right track with that.

#7

Great! thanks. If I build a server component to talk with, it will def be JDBC. May use web services as well for some data peices, thanks again all!

#8

[quote]Oh right- for that XML would probably be my choice for the client data storage in that case. You sound to be pretty much on the right track with that.
[/quote]
I think that depends a bit on how much data we’re talking about. If there’s lots of data in XML which you want to query using XPath, it will take lots of memory. I suspect using a database will be both easier and potentially better performing.
If the database is relatively simple, a simple database will do. There are simple and fast java based databases available in open source, with JDBC driver (check sourceforge for example), or if you want more db features, maybe hypersonic will be an option (also java based so perhaps easier to package and install with your app than a native one like access or mysql).

If talking webservices, I found the wizards for that in JBuilder very easy too. Import a wsdl and it generates the code for you, or use ‘export class to webservice’ and it will do everything including testing it using JUnit and deploy it in the app.server.

Erik

#9

Ah yea… I almost forgot about it. Thanks for the reminder Erik :slight_smile:

Found that one:
http://hsqldb.sourceforge.net/

Hypersonic itself seems to be down:
http://hsql.oron.ch

However there is a demo application wich includes the jar… in this article:
http://www.developer.com/db/article.php/629261

Well… hsqldb looks quite usable :slight_smile:

#10

I think hsqldb is the hsql source continued by a new bunch of people since the guy who developet hsql lost intrest or something like that.

#11

[quote]I think hsqldb is the hsql source continued by a new bunch of people since the guy who developet hsql lost intrest or something like that.
[/quote]
This is the homepage of the HSQL Database Engine (HSQLDB) Project hosted at SourceForge. We have as our charter the continuation of Thomas Mueller’s closed Hypersonic SQL Project and have actively developed and released four new versions of the database since April 2001. The latest release version features a wide range of new functionality.

It’s all there… no need to guess :slight_smile:

#12

Aggh! Why does everyone keep trying to use XML for everything? It’s shite!

Communications to server: RMI, by far and away one of the bestest features of Java, if you want to write serverside logic to handle things; or JDBC, direct to the database, seeing as you’re going through a VPN. There is no need for any crazy intermediate XML bollocks in the middle.

And clientside data storage - serialize objects to flat files. No need to incur the complexity of a database for something this simple surely?

Cas :slight_smile:

#13

[quote]Aggh! Why does everyone keep trying to use XML for everything? It’s shite!

Communications to server: RMI, by far and away one of the bestest features of Java, if you want to write serverside logic to handle things; or JDBC, direct to the database, seeing as you’re going through a VPN. There is no need for any crazy intermediate XML bollocks in the middle.
[/quote]
Apparently XML is the universal default hammer… for everything you can imagine (::)).

In my last project I had to use it… sure it didn’t make any sense, but the man in charge decided that we have to implement it with xml because it’s “cool” and “new” (seriously heh)… same scenario btw… client<->server… nothing between that.

[quote]And clientside data storage - serialize objects to flat files. No need to incur the complexity of a database for something this simple surely?
[/quote]
Well sometimes it makes sense… and you’ll still have the option to use a “serious” database if someone demands it (heh I know someone will ask for that). In my current case it’s much cleaner with a database-ish thing than doing it with flat files (would be hell on earth) or with xml.

In first place I wanted to do it with xml, because most of our customers won’t be able (or willing) to install a proper database. However, if the tests run well I’ll happyly switch over to HSQLDB.

edit: -one word :>

#14

[quote]Aggh! Why does everyone keep trying to use XML for everything? It’s shite!
[/quote]
Because… XML is God’s gift to mankind. But, like every other gift (life, fire, sex - depending on your religion ;)), man has managed to completely screw it up and use the gift totally inappropriately.

So. Now we’re stuck with hundreds of thousands of morons who think XML is “Xtreme Multi-purpose Language for doing anything I can possibly think of”. More practically, and tragically, the majority of pointless XML usage seems IME to be in the vain hope that “If we use XML, then it will automatically be able to communicate with all the other products that use XML”. Few people ever get as far as using common architectures so that the XML from one can even physically be communicated to the other, let alone agreeing on common schemas :(.

Oh, and there’s all those who think it’s automatically “more readable for humans”, despite all evidence to the contrary. Most of the Swing-as-XML toolkits provide ample evidence of how appallingly hard to read XML is for humans :(.

Back on topic…isn’t there a JDBC driver for XML files? (cackles evilly). At least you could do it in JDBC, and fulfil the “have to use XML” criteria, and then relatively quickly swap to MySQL/etc as soon as the project owner realises/accepts the tragic mistake…

#15

XML can be a very handy, but I agree it’s often used as a hammer for a screw: It works, but the result is messy. I found XML very usable for having a standard for document exchanging in b2b applications for example. With XSLT you can easily translate it to inhouse formats, and the documents can be easily validated against schema’s and dtd’s defining the document structure. IMHO, XML is a step forward after EDI, IDOC and all that.
XML for config files are handy too, but it’s not the right tool for data storage or exchanging data which does not need something like schema validation or possible transformation to other formats. XML is then just a whole lot of overhead. I mean whoever thought that describing every instance of a field by tags is a clever idea if you want to store lots of data?!
And JDBC for XML files? I mean, really… ::slight_smile:
Furthermore, even though webservices are easy to create with JBuilder and Visual Studio, they’re often just overkill for what they’re used for.
I also think the ‘readable for humans’ argument for XML is usually just silly: The XML documents are most of the time not meant to be read by humans.
If XML is ‘shite’ then just spray it on the land so that the crops grow better and stay away from the smell. :stuck_out_tongue:

[quote]In first place I wanted to do it with xml, because most of our customers won’t be able (or willing) to install a proper database. However, if the tests run well I’ll happyly switch over to HSQLDB.
[/quote]
We came across those problems as well. Like ‘hey, we use SQL Server and dont want another db to maintain’. Solution: Silently install a db together with your app and just don’t tell them there’s one hidden somewhere. ;D.

#16

Thanks again. Since we will only be connecting to the “server” or office thru vpn, once maybe twice daily, any data needed for the next days work will be downloaed(updates only) then during normal business hours the next day, the client will use its own local datasource. Then when they get home around 5pm’ish, they will connect to the office (like above) and send updates to server, server will process, then send back an update of all data, applicatin updates, etc…
The data, in some cases, may be fairly large.

You guys have put some great info up, tahnkagain.

M