Related
everyone, maybe on many occasions you have come across someone who has many winforms applications developed in visual studio. Well, in my case, I have a fairly complete system made in a winforms environment and I need to transfer it to the web since a client changed his entire team to use mac. Someone has a recommendation because I would not like to have to start from scratch to reprogram everything. I also did not bother the customer by asking him to install virtual machines.
In advance, thanks for any suggestions
Converting Winforms to ASPX aka Webforms? Probably not a good idea: Webforms is discontinued. I would prefer Blazor, that is built on ASP.net Core. With outstanding interface performances.
You don't have much of a choice.
this really comes down to two systems having VAST different architectures.
Even on the desktop? You can no more convert a complex FoxPro application to vb.net. Or convert a ms-access system to FoxPro. They all would have been built from the ground up with 100's, if not 1000's of little design choices based on the given tool set.
This is kind of like the difference between a car, and say a airplane. They are both machines for transportation. But even things like the seats. One (the car) might have big comfortable seats - power assisted tilt etc. The goal is comfort, and total over all space and weight of that seat is not all that huge of a design goal.
Now, take the design for a seat in the airplane. It has to be lighter, thinner, probably use more fireproof materials. So 100's if not 1000's of SMALL design choices along the way will result in a seat for that car, or the plane.
It just a seat, right? So, since the architecture between the desktop and the web is much like the difference between a car and a helicopter? then little of the 100's if not 1000's of design criteria you used to create that desktop application simply will not apply, and thus the work can't be salvaged.
However, if you had used WPF in place of win forms for the desktop application? Then you can salvage a LOT more, since both the web application and the desktop application will have "mark-up" used to create the form/display in question.
In fact, this is one reason developers will choose WPF over winforms. (it allows easier migration to the web). And for those coming from web development? They will find WPF forms and layout VERY similar to how they do web development.
And the other reason of course is now with css, HTML5 and a whole bunch of other new things for the web? Well, then web developers actually have MORE UI choices then the desktop now!. So, WFP is an attempt to leverage many/much of the web based new technologies into desktop development. So while winforms don't support a graphics in a button? WPF does support this - so does the web.
But, ask any WPF developer? The cost + time for WPF desktop applications is a LOT more work. And so is creating web based. Some claim they can develop just as fast with WPF applications for the desktop - that's not what I seen - and NOT even close!! You find for the web, as much as 2 times, and often 3-5 times the cost compared to desktop.
Now to take a huge application and re-write because of a few Mac's? Well, that is crazy. You would setup terminal services, and have those Mac use remote desktop to run that application. Thus, the Mac's don't need VM's or anything.
But, there is no automated conversion system, and like parts, sets and doors from a car? They don't work nor fit on a helicopter. Too much difference of a architecture is at play here.
I guess this would depend on the size, scope and estimated cost of the existing application. But to allow workers at home (remote), people on the road, and that of allowing Macs to use that software? I don't see why terminal services is not a solution - and that can be setup in less then 1 day as opposed to a whole re-write of the given application (to run on a few Macs? - doubt that can justify a re-write).
If you're asking how to take the code you wrote over the years to create Winform-based, rich user experiences and adapt it for the web, then you will be disappointed.
The best you can hope for is to have such a clean separation of concerns in your existing app that it would allow you to salvage all code that's not UI dependent and use it in the backend of a whole new application. Everything else will have to be rewritten from scratch.
If your client still wants to use your Winform-based app in a Mac environment, he'll have to use a VM.
I am going to develop a new GUI for an existing C++ application. The application works on Windows and Linux, and the communication with GUI is through client/server.
What are the pros and cons between Eclipse RCP and Qt?
Some pros of Qt:
C++ stuff will generally perform better; however, this is arguable.
Qt is the base of Meego, the mobile platform sponsored by Intel, AMD and others; however, its current momentum seems not too high to me. This means you can also create applications for various mobile and generally embedded devices
There are a lot of Qt-based applications out there.
It has a WYSIWYG designer.
Good for small to large projects especially because of QtQuick, which allows the creation of small applications in no time and with almost zero knowledge about C++
Qt has an amazing wrapper in Python called PyQt (there is also the PySide of course), which allows rapid development and slick prototyping. People often use PyQt (or PySide) for the UI-side of a Qt application because of that. You can of course combine with ease Python and Qt in the same application taking advantage of all their strengths (but also weaknesses). This allows relatively fast and smooth development cycles even for large projects
Some cons of Qt:
The code of Qt-based applications make use of some elements that are not part of C++, which have to be converted into C++ by a special preprocessor called moc (Meta-Object Compiler) prior to the actual compilation. You and your build system have to take that into account.
Nokia (former owner of Qt, since it acquired Trollech) has sold it to Digia. However, this does not imply their involvement in the development of the open source Qt has changed.
Some pros of Eclipse RCP:
Eclipse RCP is far more than a graphical toolkit:
It sports a plugin-based architecture that can help distributing functionality among different components (plugins) and keeping control over dependencies among such components (plugins). Eclipse plugin system relies on their own implementation of the Java component system specification called OSGi.
It provides a mechanism to enable decoupled application extensibility called extension points.
There are many Eclipse plugins that you can use in your application and many of them have distribution licenses that are friendly to commercial products.
It has a WYSIWYG designer.
Some cons of Eclipse RCP:
Eclipse uses a custom windowing toolkit called SWT; on each platform it relies on the native graphical layer. On Linux, it relies on Gtk+ (although it's also possible to use Motif), which in my experience (and other's) has performance problems, mostly with widgets that are updated at high rates. Actually many of us embed Swing elements in Eclipse RCP applications to overcome performance problems while keeping Eclipse's extensible architecture; this, however, can bring integration problems. There's a version of SWT that uses Qt as backend, but its incorporation into Eclipse's codebase seems stagnated since October 2010.
Startup time (understood as the time elapsed since the application is launched until it shows up a window) of Eclipse RCP applications can be very long.
If you intend to integrate C++ stuff with Java by means of JNI, be aware that some people find it difficult.
Eclipse has lots and lots of bugs. Eclipse's bugzilla is a very useful resource for the RCP developer.
The more you want you Eclipse RCP application's look&feel and behaviour to differ from Eclipse IDE, the more troubles you will get into.
Eclipse RCP development has a big learning curve, in my opinion.
Using Eclipse RCP for small projects is basically a suicide (unless you are restricting yourself to only creating a plugin or similar). It is meant for medium to large and very large projects due to the complexity of its infrastructure, resource requirements and the above mentioned steep learning curve.
Eclipse RCP is not for mobile development because...it's RCP (Rich Client Platform). If you want to go mobile, this is not for you.
Both their distribution licenses (LGPL/GPL/commercial for Qt, EPL for Eclipse) are flexible enough for most uses, in my opinion. Nevertheless, I am not a lawyer, so I may be mistaken about that.
And of course, other factors like the experience of the developers, their technical skills, the size of the team, concrete requirements, etc, should be taken into account.
BTW, I have much experience in Eclipse RCP but only theoretical knowledge on Qt, so I may be biased/mistaken in my statements.
Now that Qt has an LGPL license I would choose Qt any day of the week over Eclipse RCP.
I have used both to create fairly complex applications.
Since you can use eclipse to develop c++, I am assuming that we are comparing mostly swt/jface vs Qt, and not the eclipse development environment itself.
Some things I have noticed having used both:
1) Qt has better documentation and samples
Other than some half-baked examples on the web, I could find little useful eclipse documentation.
2) Qt has a lot more 'professional' users
There are many professional companies out there using Qt as their UI framework. Given it's three platform support (Windows, Linux, Mac), it is very flexible, and has a lot of backing.
3) Qt tends to be more complete and mature -
Using Eclipse I noticed that quite often the controls, and packages that were available were only partially done, and not quite complete. They were typically developed for someone's use, and only coded as far as that. Qt's controls were almost always a complete design.
4) Styling.
Both Qt and Eclipse render using local platform libraries, so your UI will 'look' like other UIs on the platform you are running on (i.e. Linux vs Windows). However, Qt also provides fairly sophisticated styling functionality that allows you to easily alter the look of any control, and gives you much more control over the look of your application.
With the new declarative language (Qt 4.7.*) you are approaching WPF level of control which is really amazing.
5) UI Designer:
Qt has a much richer Designer that allows you to layout your form, and do basic testing without having to compile any code. The designer also gives you the capability to add interactions between the controls on your form. Ex. Click this button - disable this option
Eclipse also has a form designer, although my experience with it is limited. I did try to use it a couple of times with very limited success. Finally I coded every form by hand through code. That is painful.
6) Interfacing with existing source code
If you don't have this problem, then you are very lucky. Because Qt is c++ based it integrates seamlessly with legacy C and C++ code. Integrating Java and C is not easy.
7) Drawing Libraries
I tried coding some hand-drawn shapes using the swt libraries and was forced to bypass large parts of the swt drawing library, because of the cludge that was in there. Using Qt to do something similar was no trouble at all.
8) Tree and List Models
Eclipse does provide some nice out of the box functionality for propagated data into trees, and lists and things. It is almost as good in Qt, although a little trickier to set up.
9) Application Layout
Eclipse provides some nice functionality to manage 'view's (dock panels), and 'perspectives' (workflows) that if you decide to use them makes life nice and easy. Qt requires you to do this yourself. Qt does have dock panel functionality, but when building a rich application you have to set this up yourself.
Extra Note:
Qt has also provided some extra libraries to support things like xml, etc... So this helps bridge the gap a little between c++ and java for things like this.
I'm pretty familiar with using Adobe Flex & AS3, and compared with writing apps in JS/HTML I think it's very cool. However, since AIR is essentially a non-browser version of Flex with benefits like local storage, it seems to be competing as a cross-platform desktop application platform... and in that space it's much less mature than more established desktop technologies.
So what's the advantage of creating a desktop application using AIR compared to something like Java (or C++ using a cross-platform GUI library like wxWidgets)? Java's equally capable of communicating with the server for instance, I'm not quite sure what AIR adds when competing head-to-head in the desktop development world?
In my opinion the biggest advantage is productivity (if you are interested only on desktop)- it's much more faster to build a nice UI using Flex compared with Java Swing for example (try to build a transition in Swing). Also the new components from Flex4 allows to do component skinning much easier.
However (as written by Groky) you should take into account also the disadvantages. It would help if you write down what are the main features of your planned app and check how they are handled by various platforms. For example if multithreading is needed AIR is a bad choice.
AIR takes the goodness of Flash Platform cross-platform and as of 10.1 across many cutting edge mobile platforms as well not to mention that Google is actively working with Adobe on the mobile AIR for Android. That's the key perspective here and I think you don't doubt the fact that Google's open-source platform will be big. Android devices make the fastest growing chunk of mobile platforms already. Also, think of the upcoming Chrome OS. Is AIR going to have a role there? I bet it will.
IMHO AIR makes it a lot easier to deploy rich applications across platforms. Rich Applications as in terms of Flash Platform.
See what Wired has done with Adobe on ePublishing. That should answer this question well.
In my experience there is only one advantage:
Cross-platform
However there are a number of disadvantages:
No communication with native platform except by installing a separate server!
Native window handling is very primitive (no modal dialogs!)
Less mature (i.e. buggy)
Fair Question. Well to begin with AIR is not "a non-browser version of Flex" or "a non-browser version of Flash" ADOBE AIR is a run-time that hosts applications created in a variety of protocols including: HTML, JavaScript, AS3. If one is so inclined tools like ADOBE Alchemy will let users who prefer C++/ JAVA to compile code into SWCs and SWFs.
From a designer's perspective ADOBE FLASH, DREAM WEAVER, and FLASHBUILDER provide seamless desktop application development. While from a developers stand point the same code used for web based content becomes available creating desktop application with little to no recoding. This is all without mentioning the ability to leverage existing E-commerce and web based marketing APIs and SDKs; creating a dynamic intelligent experience for the end user on the desktop.
For me and my company, the main advantage is that it's the same code on our website as in our AIR app. This could be a Flex app or HTML/JS app, but you keep the same single codebase.
AIR 2.0 will address Groky's issues, with access to native applications, better window handling, and much less memory intensive, which led to lots of bugs in 1.0/1.5.
If you don't have a web app already, and you're not locked into AS/JS, then there's no real reason to go with AIR over Java/.Net/PxWidgets... unless you like the look of the latest Flex 4 components, which is quite nice.
I think it's because:
Cross platform
Very easy to develop - learning AS/JS/HTML is much easier than learning C++/Java/MFC. Most of the requirements are not that strict. I developed many tools with AIR/Flash for myself to save me hours of work. If I do that in C++, I will surely waste more.
Until recently I'd considered myself to be a pretty good web programmer (coming up for 10yrs commercial experience on a variety of e-commerce, static and enterprise applications). I'm self taught and have always used the Microsoft product stack (ASP, ASP.NET)...
My applications are always functional, relatively bug free, but have never been lightening quick. As a frequent web user I always found this to be the norm... how fast are the websites from the big tech players (eBay, Facebook, Microsoft, IBM, Dell, Telerik etc etc) - in truth none are particularly fast. I always attributed this to "the way things are with web apps"...
...then I cam across a product called Jira from atlasian and this has stopped me in my tracks...
This application is fast, and I mean blindingly fast.. too fast to time the switches between pages, fully live content, lots of images and data and cross references etc etc...
I run this on an intranet, with a large application DB, and this is running on a very normal server (single processor, SATA HDD, 8GB RAM).
Am I missing something?? Are my programming techniques that bad?? I am wondering if this speed gain is down to it being written in Java and running on Tomcat.
Does anyone have any benchmarks to compare JSP / ASP or Tomcat / IIS???
Thanks,
Mark
NOTE: this isn't a blatant plug for Jira. I don't work for them or have any affiliation to them... but I would like to be able to write applications like them :)
YMMV. But one of the longest-lived Things That Aren't True Anymore is the assertion that "Java Is Slow". Excepting floating-point (where most Java implementations aren't at liberty to use the floating-point hardware), Java is generally as fast or faster than compiled code. Some of the best and brightest have spent years of effort ensuring this, including such things as dynamic recompilation/re-optimization of code based on run-time metrics - something that statically-compiled languages like C or assembler cannot boast.
ASP is sort of the opposite extreme, since the original ASP had to recompile each page request each and every time it was made. ASPX addressed this by allowing retention of the compiled page code. That got rid of a lot of useless overhead.
A more compelling reason to prefer Java over ASPanything/IIS is freedom. A Java/Tomcat webapp will run under almost any OS on almost any hardware. IIS runs on Windows. Period. And for the most part, that also means Intel. Not Sparc, Not zSeries. Maybe you don't care. But then again, maybe next week IBM will offer your employer a can't-refuse deal on a mainframe.
I don't have benchmarks, and there are a lot of things that can make one platform preferable. But I permanently gave up on the "Java is slow" idea when I encountered the Poseidon UML tool with its cool real-time graphics UI and the FreeMind mindmapper tool. A small hit to startup the JVM, but after that, you'd never know what language you were working under.
The great debate. Java vs. .Net.
When .Net first came out there was an application written called "The Pet Shop." Which was a .Net port of Sun's J2EE reference application, "The Pet Store". It was announced that Microsoft's implementation was "faster."
As with anything, especially anything to do with marketing, you have to dig deeper to find the truth.
Any technology can be fast with enough hardware and the correct design.
In my experience there are two factors to speed: What type of hardware is used and how you architect your application (this includes database tuning).
Caching at various levels (response, db, etc.) makes a huge different in responsiveness of a web application. There is also a lot of things that are done to reduce time consuming operations like db connection pooling, sql statement caching, etc. As much as I'd like to say Java is better :-), I think in this case the performance is due to the way Jira was written and the fact that it's being run internally (probably with few users as compared to eBay, Facebook, Microsoft). This site, Stackoverflow, uses ASP.NET MVC and IIS and is very responsive and my guess (since code is not open sourced, yet) is that they use many of the same techniques you would find in Jira or any other web application built to scale.
I think that it is not typically the frameworks and languages used that make an application slow. In my experience, some frameworks like JSF or .NET server side controls give developers alot of freedom to make too many database calls and look things up too often, but that's definitely not the fault of the framework used.
Keep your application as light as possible and focus on keeping the data sent to the client as small as possible, and you will have a fast application. It's usually faster to develop fast applications too.
The Jira folks have written a best in class application (and charge for it) - nice work crocodile dundees.
I also suggest to consider also two aspects:
the maintenance activities: logging and deployment. In my opinion under a unix like server is more easier to log, deploy, and maintain new release than doing the same on a Windows server.
if the project require to use some open source application (i.e. Alfresco repository) Java is better solutions
People's opinion is mostly biased. Most people have never really tried the other while claiming the other is slower. I wouldn't trust any answer: it's mere opinion. It's boring to always read the same 4 cents again and again.
I have been building enterprise software for the last 10 years. In this time we have seen enterprise applications move from client server to thin clients. We have also seen the move to hosted solutions, albeit under a few names (asp, SaaS, cloud computing). With all these changes the impetuous has been mainly from driven from the IT department not the end user. In the first rounds of these revolutions the user experience was reduced in the name of single point of management and reduced desktop footprint.
During this time there have been many attempts to give the user a rich experience while still satisfying the crotchety IT department. The first was by the industry leader Microsoft in the form of the ActiveX control. The guys from Sun then followed suit with the applet and then more recently java webstart. All of these solutions seemed to scratch the itch but never gained wide expectance by the more stringent IT departments.
Then flex came on the scene from Macromedia. What did they do differently? Is it sustainable? Does Microsoft’s emulation with Silverlight prove they have changed the rules of the game? Will Web programming be changed forever?
Adobe have succeeded because almost all users of the main browsers on the main platforms already have installed the only runtime component required for Flex; which is the Flash player. The Flash player has already demonstrated that it isn't a vector for Bad Stuff; it runs in its own sandbox in the browser, isolated from the hardware and the OS. So no new (and potentially dangerous) software is installed.
There exists a substantial developer community for Flash technology, and the addition of some new controls in Flash, and maturity in ActionScript for writing software, has tipped it over the threshold for being fully useful as a RUI.
(Activex is Windows-0nly; Anything in java is perceived as destabilizing and too heavy; and java hasn't managed to wangle its way into ubiquity, nor will it probably ever do so. So both generally get installed by edict, rather than user choice. This in spite of the fact that Adobe is probably the most disruptive source of unrequested "update-checkers" and other near-malware we deal with in our ecosystem.)
Microsoft started out with Silverlight pretty aggressively, requiring only the installation of the equivalent of the Flash runtime; but it's not ubiquitous even on Windows machines yet; penetration to other platforms is quite a way in the future; and MS hasn't proven to have the political smarts to appear harmless yet. But don't count it out. I think they've moved a step back by switching to .NET languages (with a limited CLR) for development; this seems to me to be the same strategy that has deoxygenated their WinCE strategy; but again we'll see. But at least they have made an obvious move away from language agnosticism to appearing to want to coerce developers into .NETland.
Web programming is changing forever one way or another; users will demand a better, more fine-grained UI; there's no perfect answer in sight yet, but at least there is competition for hearts and minds. I think the most encouraging signs come from Microsoft's strong move into platform-neutral stuff like MVC, Iron Stuff, and increasingly unpolluted code streams to the browser.
My take on Flex's success:
1- Adobe made the right move in opensourcing not only AIR, but Flex, the Flash VM, and the PDF standard now as well.
2- Flex's rich Flash heritage (it runs on any Flash enabled browser) means that the vast majority of browsers already support it and do not need to download a large plugin to access it.
3- Adobe embraced all the major server-side technologies and provided support for them so that a PHP. MS, or Java shop would all feel comfortable using Adobe's client side technology.
Previously, Flex was closed-source, expensive, and even relied on a server-side installation, which negated it's reach even though the Flash client was so widely available.
YouTube and the general ubiquity of
Flash video entrenched the Flash
player into over 95% of the browsers
that are accessing the public
Internet.
Incorporating Flex GUI for form
design with widgets and an extremely
well designed GUI SDK was a major
turning point for the Flash player.
Flex 2 and Flashplayer 9 were the
tipping points of when this
technology really jelled. Enterprise
developers began to quickly realize
that this technology was just the
right approach for doing their
applications. (At JavaOne in 2006,
Adobe Flex 2 was the most impressive
and pivatol technology that I saw
there.)
The Flash runtime has just enough
stuff to run RIA GUI well in a web
browser sandbox setting - Java
applets required the full JRE (about
16 MB). The Flash runtime was a much
leaner and smarter design for its
intended purpose. (Sun has only now
begun to remedy this for Java via
their JavaFX and redesigned JRE that
can download a few MB as sufficient
to run a web applet. They don't have
anything like YouTube Flash video to
drive their installations, though.)
Writing Flex RIA applications is a
very leveraged experience compared
to writing old-school web
HTML/JavaScript AJAX apps. Can
achieve a great deal more and have
less effort to accomplish such.
Adobe bolstered Flex with other
important pieces, such as BlazeDS
(and now they're cooperating with
SpringSource to make BlazeDS and
Spring-Framework a smoother
integration).
The single-thread GUI in combination
to async service calls (or
messaging), and ActionScript3
closures is great programming model:
Flex Async I/O vs Java and C#
Explicit Threading
Likewise, Adobe Flex has a great
implementation of properties,
events, and databinding.
A declarative language, ala MXML, is
indeed a better approach to
describing a form (what is
essentially the view in the MVC
pattern). It is more concise than
equivalent imperative ActionScript
code that would accomplish the same
thing, and thus clearer. The
hierarchical structure of MXML
script tends to naturally match well
to the panel/widget construction of
views as well.
With Flex RIA approach, the MVC
pattern can be implemented
completely on the client tier. Web
frameworks that implemented MVC in
the middle-tier - with the
presentation layer executing in the
remote client-tier, was a
fundamentally flawed approach to
MVC. MVC should be done right at the
tier that is directly user-facing.
(Once again, Adobe Flex does things
right architecturally.)
Despite that HTML/DOM/JavaScript is
considered the pervasive standard of
the Internet web, the Adobe Flash
player is actually a more ubiquitous
and consistent standard - spanning
different browsers and operating
system platforms. The
HTML/DOM/JavaScript standard is in
actuality a fragmented mess that
grows more fragmented everyday as
Google and Microsoft drive different
directions on things regarding the
web browser. Adobe Flash player ends
up being a wonderful end-run around
this dilemma. It's a great
programming experience for the
coders and has sufficient ubiquity
for the business suits.
Adobe is smartly well supporting the
major platforms of Windows, Mac OS
X, and Linux. They pay special
attention to the Linux platform.
This will pay off in the long term
as developers are already settling
on Linux to do their development
from, and it's used extensively for
servers hosting their middle-tier.
Adobe's recent 64-bit Flash player
for Linux is just a marvel. They
already have AIR 1.5 available on
Linux. They are doing a decent job
there of supporting the platform
that the developers care about.