Yes, this was the feeling we had most of the time when we were working on a project in RCP-SWT as a client side technology.
For those who don't know about RCP-SWT as a technology for Thick Client development, it is the same technology eclipse is built on. Many tools have been developed on RCP-SWT and eclipse is the best example for it. Many technical developer must have used eclipse for their work. It supports number of languages and state of the art features.
Does that mean it is the best technology for UI development? NO!!! I would say, it entirly depends upon what you are going to develop. If you are going to develop a tool yes this might be (note it, I said might be), but, best choice for a solution, I doubt that.
Irrespective of what is the purpose you might find number of technical problems with it. RCP-SWT uses platform widgets to prepare its UI, really I can't find a reason to do that. I mean swing is so easy and matured widget library, why to go native.
It provides so rich (big) API to get your work done. Yes, its true, SWT has a very big API as a framework, but do we need that. Like its plugin framework, for an application which you are going to support and nobody else is going to provide plugins for, should we take extra load of plugin feature. OK, plugin feature might be needed but resolving its classpath issues, dependency issues, export package, import package... this is too much. If I developed a plugin and I want to use it in another plugin why to do all these settings and then resolve issues like these. If I write a plugin and want to use another plugin, I can anyways change the manifest and use it as I want to.
You want to know what was the thing I hated most in RCP-SWT, it was widget constructor. The problem was, there are widgets available, its fine, but if I want to change some thing in it, it won't allow subclassing. Even if supports, then the problem is all the UI work (children creation) is done in its constructor. If I subclass it, I have to call super(); which will create UI and I cant do much after that.
Also the parent object is to be passed in constructor, which is very bad. I can't create widget instances in factory or builder and then assign them to parent when needed. What is this, can't you wrap a widget in a normal class which internally does all the creation thing at appropriate time (Atleast I did it in all my custom widgets, I can set parent anytime and just call createUI later).
One of the weekest point of SWT was its Display object. You want to do something in an event thread then deal with it, sometimes you get exception that you are doing thing in wrong thread and in current thread you can't do UI operation on this widget. Is this the thing I should care about, NO. We lost good amount of time to deal with it and solution was very bad actually. Sometimes we had to keep display thread in wait loop and process the task in another thread. Sometimes SwingUtilities. invokeAndWait came to rescue with two-three levels of inner classing. Shouldn't this be responsibility of component to deal with its thread?
Anyways, this was my (and my team's) experience with RCP-SWT. I know lots of developer will not agree to it, but it is what it is. I won't suggest anybody to go with RCP-SWT for an application development, yes if you are going to develop a tool then you can think of it. But the main question should be, what are you going to get with it? Are you going to develop a tool that can work with other contributions? Do you want to take headache of dealing with issues which are not from your plugins?
BTW, if you are looking for a thik client technology, check out Flex. Flex is the future (atleast looks like). It is a bit of thin and a bit of thick I would say. I will write a blog about my findings on flex shortly.
For those who don't know about RCP-SWT as a technology for Thick Client development, it is the same technology eclipse is built on. Many tools have been developed on RCP-SWT and eclipse is the best example for it. Many technical developer must have used eclipse for their work. It supports number of languages and state of the art features.
Does that mean it is the best technology for UI development? NO!!! I would say, it entirly depends upon what you are going to develop. If you are going to develop a tool yes this might be (note it, I said might be), but, best choice for a solution, I doubt that.
Irrespective of what is the purpose you might find number of technical problems with it. RCP-SWT uses platform widgets to prepare its UI, really I can't find a reason to do that. I mean swing is so easy and matured widget library, why to go native.
It provides so rich (big) API to get your work done. Yes, its true, SWT has a very big API as a framework, but do we need that. Like its plugin framework, for an application which you are going to support and nobody else is going to provide plugins for, should we take extra load of plugin feature. OK, plugin feature might be needed but resolving its classpath issues, dependency issues, export package, import package... this is too much. If I developed a plugin and I want to use it in another plugin why to do all these settings and then resolve issues like these. If I write a plugin and want to use another plugin, I can anyways change the manifest and use it as I want to.
You want to know what was the thing I hated most in RCP-SWT, it was widget constructor. The problem was, there are widgets available, its fine, but if I want to change some thing in it, it won't allow subclassing. Even if supports, then the problem is all the UI work (children creation) is done in its constructor. If I subclass it, I have to call super(); which will create UI and I cant do much after that.
Also the parent object is to be passed in constructor, which is very bad. I can't create widget instances in factory or builder and then assign them to parent when needed. What is this, can't you wrap a widget in a normal class which internally does all the creation thing at appropriate time (Atleast I did it in all my custom widgets, I can set parent anytime and just call createUI later).
One of the weekest point of SWT was its Display object. You want to do something in an event thread then deal with it, sometimes you get exception that you are doing thing in wrong thread and in current thread you can't do UI operation on this widget. Is this the thing I should care about, NO. We lost good amount of time to deal with it and solution was very bad actually. Sometimes we had to keep display thread in wait loop and process the task in another thread. Sometimes SwingUtilities. invokeAndWait came to rescue with two-three levels of inner classing. Shouldn't this be responsibility of component to deal with its thread?
Anyways, this was my (and my team's) experience with RCP-SWT. I know lots of developer will not agree to it, but it is what it is. I won't suggest anybody to go with RCP-SWT for an application development, yes if you are going to develop a tool then you can think of it. But the main question should be, what are you going to get with it? Are you going to develop a tool that can work with other contributions? Do you want to take headache of dealing with issues which are not from your plugins?
BTW, if you are looking for a thik client technology, check out Flex. Flex is the future (atleast looks like). It is a bit of thin and a bit of thick I would say. I will write a blog about my findings on flex shortly.
Comments
Post a Comment