The GWT RPC mechanism is great for client initiated communication. We're looking for a solid, supported way to do Push notifications from the server to the clients. All the solutions we can find are several years old and don't seem to work with newer versions of Eclipse and GWT.
We're prepared to use the Google App Engine if that helps.
We can roll our own socket code if that helps, as well, but we are Java developers. Writing JavaScript to do socket work would be a last resort, although if that's what it takes and there are examples we could probably handle it.
Any pointers to sample code or suggestions as to packages to use are greatly appreciated.
You could use the Atmosphere Framework. They have a gwt20 module which works great with gwt.
As far as I know there are two possible solutions.
First you can use Errai. Errai has an event bus which also can be used on the server:
https://docs.jboss.org/author/display/ERRAI/Messaging+API+Basics?_sscc=t
I did not use it, but think it is possible to do server push.
The second framework I know is gwt-comet:
https://github.com/rzschech/gwt-comet
I did not use one of them. But if I would look for a server push solution, I would give gwt-comet a try.
While this sounds silly, I haven't been able to find a way to get the IP of the client in Play 2.0. It was available in 1.2.x as Http.Request.remoteAddress, but 2.0 (I primarily checked the Scala API, but I did a quick check of the Java one too) only seems to provide information about the server side of the request in play(.api).mvc.Request. Is there something I'm missing? The closest hack I can think of right now is setting it up behind a reverse proxy and then checking X-Forwarded-For, but this doesn't work too well in dev.
EDIT:Coming back to this answer, this was added in playframework 2.0.2: see release announcement on https://groups.google.com/forum/#!msg/play-framework/Z97GQ2VnR5M/T-STGaeuN68J%5B1-25%5D and more importantly the API documentation at http://www.playframework.org/documentation/api/2.0.2/scala/index.html#play.api.mvc.Request
As you can see there is now support for Request.remoteAddress
Original:
There is currently a bug open for this in the tracker: https://play.lighthouseapp.com/projects/82401/tickets/256-add-back-requestheaderremoteaddress
I think that hacking the play2.0 libraries to include the linked patch is currently the best bet. It is probably still cleaner than to use a proxy with the sole purpose of adding XFF headers, and using those to determine the IP.
Please check this Github project at https://github.com/orefalo/play2-xforward
I took the code from Play1 and ported it to Play2, it should work the same.
Still a work in progress...
I am new to Blackberry app development. I need to call REST webservice from blackberry application using JDE 4.7. I searched but not got any solution. Anyone help pls?
sri
You have to make an HttpConnection request and read the data as an InputStream... have a look at this tutorial Calling REST based web services
I appreciate this an old post - but it has been updated so someone is looking at it, so I thought it appropriate to contribute.
I am sorry, but I can not recommend the code supplied the link from another answer called "Calling REST based web services".
I have made a comment explaining this on the site, along the following lines:
"In my opinion this code is flawed because it does not consider the different connection methods, nor does it consider different encodings. More over it does not consider the Event Thread or provide reasonable error checking and logging. I appreciate that this is just a sample, but I think the author has a responsibility to make people who might use this code aware of how it should be used properly. And this code will cause more problems that it solves. Refer to the supported BlackBerry documentation and web sites for better samples."
Sorry, I am not as familiar as I should be of the questions asked on stackoverflow, but questions like this come up regularly on the BBRY forum here:
http://supportforums.blackberry.com/t5/Java-Development/bd-p/java_dev
I recommend that you go on that forum and type network in the Search box on that site and you be presented with a range of tutorials and KB articles that discuss all aspects of networking. In this particular case I would recommend this:
http://supportforums.blackberry.com/t5/Java-Development/What-Is-Network-API-alternative-for-legacy-OS/ta-p/614822
Networking is not trivial on the BlackBerry, do not expect a cut and paste of the code supplied to work for you. Specifically you should be aware of:
a) The various connection methods, the costs associated with each and the impact that using each might have (e.g. transcoders or caching)
b) The Event Thread, how to get off it and back on when processing a response
c) Logging and reporting so that you can investigate problems when they occur (and they will).
Personally, given that all OS 4.7 devices can be upgraded to OS 5.0 and should be, since OS 5.0 is better, I would forget supporting OS 4.7. Instead look at OS 5.0 and above support and use ConnectionFactory.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
From the following list of frameworks, which one would you use to develop a rich web application and why would you choose it over the others?
Sproutcore
GWT
ExtJS
GXT
SmartGWT
Dojo / Dijit
Flex
Capuccino
Grails
I'm personally tired of browser inconsistencies. If someone else has solved the problem, I'd rather not do it again. That's why I'm getting more interested in front ends like cappuccino and qooxdoo. They are a zero-HTML zero-CSS solution.
These are based on my personal experiences using the frameworks you have mentioned. So yes, it is a bit biased. So as others have said over and over again, define your requirements and which one do you think fits your requirement based on what people have suggested here.
GWT is too verbose eventhough I found many Java developers love GWT because you can unit test it and it's all in Java. But I personally don't like it because it is far from being simple. There are times when I feel I can tweak a little bit with Javascript, but with GWT I am enforced to do it with several lines of Java code.
GXT is too far from GWT these days and you will find it difficult to do things as GXT has its own way of doing things which is way too different from GWT. When complex requirement come up, in the end you are going to go back doing plain GWT. And oh, their technical support is not that good either as I had several bad experiences when asking few questions to them.
Ext-JS is good for simple stuff and the look and feel is really slick. But when things gets more complex, you are going to fight you're way through. Eventhough I have dealt with the GXT tech support, I haven't dealt with the ExtJS tech support since they have different people eventhough it's in one company, so I can't say much.
Flex is nice, really nice. But again it is good for simple stuff. Once things gets more complicated you are going to write lots of actionscript, which is less enjoyable. There are many things that is available out of the box which may be to difficult if you have to code it in Javascript, like multimedia support. And oh, if you are writing for a public website you must consider that not too many user has flash plugin on their browser.
Grails, I'm not sure how you would implement RIA apps with Grails since Grails is just another MVC framework which you need to add your own RIA framework on top of it such as the ones that you have mentioned.
This is strictly a matter of opinion. You will not get any definitive answers from anyone, since anyone that answers will have one or another that they personally prefer.
Try each one for long enough to decide which one is best for your (or your team's) purposes.
That being said, I prefer GWT. Others will invariably disagree with me.
Reasons that I like GWT:
You can share (some) client- and server-side code (as long as your server is written in Java)
GWT makes a lot of advanced performance features really easy (e.g., deferred JS loading, image spriting, CSS obfuscation)
A focus on one-page apps, with third-party support for Places (using the gwt-presenter library)
It's just as easy to add GWT to an existing web page as it is to create a full one-page GWT app
UiBinder allows you to write your UI using a declarative HTML-like syntax; you're not stuck writing Swing-like UI if you don't want to
Browser incompatibilities are (mostly) taken care of by GWT -- you just write Java code, and GWT compiles it to work on every browser
Things that may make GWT not right for you:
If your server is already written in something besides Java, you will still be able to write your UI in GWT, but you'll lose out on some nice features
Compilation time using GWT is a non-trivial cost -- Development Mode mitigates this a lot, but it's still an issue sometimes
As others have mentioned, GWT can be considered "verbose" compared to simple JavaScript libraries like jQuery or ExtJS
Ext GWT has worked well for my project. The premium support has been good.
However the project is for internal use which has allowed deployment to be restricted to one browser on one OS, and no effort has been made to change the default appearance or behaviour of Ext GWT.
Developing entirely within Java is a key benefit as it helps to keep the project manageable as features are added.
I am currently working on a grail/flex hybrid app that is working a lot better than I expected. I have looked at GWT but there were not a lot of books about it at the time and it seemed to stress the leveraging of Swing-like programming techniques which I have never liked. I agree with the comment about trying them all out. Run hello app they all have and measure how hard or easy it is to modify. Also tool (IDEs, Maven, CI...etc) support can be a big factor as well in terms of being immediately productive.
We are using Grails+ExtJS here. Since we try to make an idiomatic ExtJS application, Grails is not fully utilized, though it still makes sense to use Grails instead of, say, JSP, for the server-side part.
Why ExtJS: Because it's a very rich toolkit for GUI-like web applications. Our job is to replace an old Motif GUI, so this is exactly what we need.
Why Grails: Because it gets the job done easily and quickly. For the communication with the ExtJS part, we need a lot of JSON, and in Grails it's like that:
import foo.bar.FooBar
class FooBarController {
def viewFooBars = {
def list = FooBar.getList(session.userId, params.foo, params.bar)
def result = [resultset: list] as JSON
response.setHeader('Content-disposition', 'filename="json"')
response.contentType = "text/json";
render result
}
}
And that's even two or three lines more than necessary...
Unfortunately the answer will be opinionated, GWT in it's purest form is not an eye-candy. That being said, ExtJs GXT is super hunky dory. One of the major issues I face with evolving frameworks is that they are not absolutely defect free, If I remember correctly, GWT 2.0 was shipped out with missing CSS styles for some of the new layouts. I am trying to trouble shoot an issue in ExtJs/GXT since last 5 days :(, frameworks obfuscate a lot of things. I will go with any framework that is absolutely robust and gives appropriate error messages. I haven't worked with others though.
I'd recommend Dojo.
In addition to the massive infrastructure it provides, Dojo 1.6 is also the first (and only) popular JavaScript Library that can be successfully used with the Closure Compiler's Advanced mode, with all the size, performance and obfuscation benefits attached to it -- other than Google's own Closure Library, that is.
http://dojo-toolkit.33424.n3.nabble.com/file/n2636749/Using_the_Dojo_Toolkit_with_the_Closure_Compiler.pdf?by-user=t
In other words, a program using Dojo can be 100% obfuscated -- even the library itself.
Compiled code has exactly the same behavior as plain-text code, except that it is much smaller (average 25% over minifiers), runs much faster (especially on mobile devices), and almost impossible to reverse-engineer, even after passing through a beautifier, because the entire code base (including the library) is obfuscated.
Code that is only "minified" (e.g. YUI compressor, Uglify) can be easily reverse-engineered after passing through a beautifier.
ExtJs is great for creating complex web applications. The API provides anything you can imagine in a webapp and its really easy to extend any component after some time.
You can plug it to any backend (we use django or php) and reuse or extend any component in several different applications.
You'll need severals months to feel comfortable with it. IMHO.
That said, the lib is sometimes a bit too slow for simples uis like a website (then you can use ExtCore). But when it comes to webapps this is not an issue.
Im not a java guy so GWT was not an option for me :/
hope this helps
I do realize this is a duplicate question, however the only other question is quite old, so I would like to know if anyone has had any recent experience with the latest version of wsdl2objc.
I am doing an application that will communicate with SOAP Web services exposed by a third party application (it only exposes them this way unfortunately). As far as I understand all wsdl2objc does is convert the WSDL to something useful in objective C code. I have also done the tutorial icodeblog intro to soap
So has anyone used the latest version of wsdl2objc?, what is your experience with it?, did you run into any problems with it?. Please let me know. Also some code sample would be really great.
Any information available on using SOAP Web Services with iPhone would be appreciated. Thank you.
-Oscar
My most recent experiences with wsdl2objc is that it's on the right road, but not really there yet. It's definitely the kind of program you'd want. It just may or may not be able to handle the WSDLs you actually have.
Short answer: try it and see if it works for your WSDLs. If it does, hooray. If it doesn't, you have two options. For reasonably simple WSDLs, write the SOAP by hand. This often is actually the easiest approach. If the WSDL is complex, then use gSOAP to get to C++ and then wrap the C++ in Objective-C++ (or use the -c option to gSOAP and wrap the resulting C, whichever you're more comfortable with).
I think this gives a good example of how to configure your environment (for noobs like me)
http://blog.futurebytez.com/2010/05/calling-web-services-using-wsdl2objc.html
The official wiki for wsdl2objc (linked in the article) has a code snippet which gives you the basics.