As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I want to develop an application where server pushes a lot of data to client. (20 kb every 20 milliseconds) 500kbps. All of the data are double/float values.
I am trying to answer the question, if there is something inherent to desktop apps (Java Swing app) which will make it a better option for this use case as compared to a web app where data will be pushed over http.
Is there something about Java swing app and how data transfer takes place there from server to client, that makes them faster as compared to web apps (tomcat as app server .. JS at client side).
And how answer varies, if I say that web server and application are on the same local network.
My vote is desktop, but I'm bias (when the only tool you have is a hammer...)
My first thought is threads and custom networking. You get the added benefit of push and pull protocols as you need (yeah you can get this in a web environment to, but Java was designed for this, AJAX has been bent this need)
I'd also push a diverse and customisable UI toolkit, but one might argue that you can achieve this using HTML, but I've, personally, found the Swing toolkit faster to get running & easier to maintain, IMHO.
The downside would have to the need to install the app on each client machine and deal with updating
That's my general opinion anyway, hope it helps
The other question is, what does the app need to do?
It is highly unlikely that the UI will be displaying 1000 meters all at once. The users will most likely be looking at small number of meters at a time. The UI only needs to be updated for the meters that are displayed on the screen. This should cut down on the load considerably. Assuming that networking and cache database components will be about the same for both web as well as desktop app, the real differentiator then becomes how fast the charts/graphs can be rendered, and how often or how many people will be inclined to use it.
MadProgrammer's suggestion of prototyping make sense. The test data gained from the prototypes would answer the performance question.
Web based will be more useful/valuable because it can be used from any desktop, tablet or smartphone. I am assuming that it is desirable to get the data in front of as many users as possible, anytime and anywhere. Also, I don't think human eye can detect 20ms updates. You could probably make that longer and users would not even notice it. Movies are about 25 frames a second, i.e. 40ms/frame.
How many concurrent user are you anticipating? I don't think that should affect the solution as both can be made scalable.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I need some help on how to choose a technology for developing mobile apps. I have decided to use phonegap (cordova library) and Jquery mobile with HTML and complete my device APIs and UI parts.
Now I am in a dilemma, on which technology to use to connect to a database -
1. PHP
2. .NET
3. JAVA
I heard/read PHP is light-weight and is easy to work with but .NET is more robust and secured. Now, I am unsure of what exactly security here means? Does it mean PHP is not a secured way to handle database operations?
Can anyone please guide me on how to decide on a technology and take my development to a higher level?
I can give you more inputs as required. :)
Many thanks.
If you never ever touched any of these technologies you should use the easiest one.
Your priority should be like this, I will rank then from according to their usability/simplicity:
1. PHP
Good:
By far simpliest of them all. In a matter of days you can learn more then enough to create your basic server. No matter do you want to handle only REST calls or do full a page creation on a server side.
It has largest overall support and you will easily find hosting, if you already don't have it. It works on all current desktop OS's like Windows, Linux and MacOS.
Bad:
Not that much. If I have to think of any I would say that it is a smaller brother of Java and .NET.
2. .NET
Good
My favorite, more secure (but not that much secure) then PHP. It requires much more time to handle and use right. Like with Java I prefer its syntax over PHP. Still more readable syntax then Java, specially if you delve into something more complex.
Bad:
But, as it is a Microsoft technology it will run only on a Windows platform. Skipp it if this is a turn off for you.
3. Java
Good:
Almost best of both worlds. Better and more powerful syntax then PHP and unlike .NET you can run it on any available platform. Like .NET it requires more time to master correctly then PHP.
Bad:
Java is usually used in large corporate projects and you will not find that much help over some basic stuff and usage. Even if you master it correctly you will still need to delve into Java EE if you want to create anything decent and robust, basically it is a largest time sink if you only need to create one server application. Other problem is memory consumption, that is why you will see much less available Java hosting platforms the it is case with .NET and PHP.
Conclusion
If you don't have that much time and you are not sure you are ever going to use it again then stick to PHP. If you are planing on using this technology for a longer period then stick to .NET. And finally if you are going to use it in a longer period but Windows platform is a turn off then stick to Java.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I've been reading up on both GAE and GWT, and it seems that if you are deploying GWT apps to GAE then the following APIs are unnecessary:
PageSpeed
Channel API
Since GWT is already super-optimizing all client-side code, and includes all the necessary AJAX mechanisms to produce a "single page web app", then it seems to me that both of these can be ignored when deploying a GWT app to GAE.
My understanding of both these APIs is that PageSpeed helps optimize client-side code (GWT already does this), and that the Channel API is utilized for long-polling (which GWT obsolesces).
If I am incorrect, please help me understand why. Or, help illustrate scenarios where a GWT app would still benefit from these APIs. Thanks in advance!
I don't think they are entirely irrelevant.
PageSpeed: To be honest I don#t have much experience with PageSpeed. GWT does a lot of optimization to make sure that loading resources is fast (disclaimer: if you are using ClientBundle). As a result you might not see much of a speed increase when you activate PageSpeed for your GWT app. However according to the documentation it says:
PageSpeed Service will not serve stale HTML to your users. Typically
95% of the bytes needed to render a page are cacheable, but the HTML
itself is not. PageSpeed Service speeds up loading of your page by
caching the cacheable parts of your page (amongst other techniques).
This includes resources such as images, JavaScript and CSS. Please
refer to the information on controlling what resources PageSpeed
Service caches.
So you probably can achieve caching of static resoruces yourself by configuring the web-server serving them to cache them, however I guess PageSpeed will do that for you out of the box. Furthermore it seems that Google will prefetch the resources and then serve them from their servers which might be optimized for serving static resources compared to GAE.
I would recommend to try it out and see how much it helps.
Channel API: Channel API might be quite useful for your GWT app. Long-polling has a different use case compared to traditional AJAX calls. For example if you want to create a web based chat app in GWT, you can use the Channel API to support "real-time" communication between the clients and the backend.
So Channel API definately has its use case although 90% of the times you will probably use normal AJAX calls.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I am going to work on an complex application.Application is about to create lakhs of form dynamically, on those form rules can be apply dynamically and transactions of that forms.
For this application points that must be keep in mind are below:
1.Fast Loading:
1.1 Intial application load time must be smaller.
1.2 As there are lacs of forms then controls many in count of lakhs of lakhs with all properties.So while fetching forms from DB it should be fast.
2.Control Richness:
Which ever frame work used, It should be rich in controls, Control like:Date, Date Time Picker, Grid,TextBox,TextAera,Combox etc.
3.Browser Comapibilty
It should be compatible with all browser.
4.Resolution Indepedance
Application should be resolution independent.i.e It should work for every resolution and for every browser.
5.Mobile Compatibility
For this purpose I just started with a demo application.For this I selected GWT2.0.3 + gwt-ext,Hibernate
Hibernate is satisfying all the need regarding back end.But I am not satisfied with GWT as there loading issues,Browser issuse.
So I just need assistance for selecting frame work.Please also suggest me about the pattern
i.e. MVP,MVC.
I also searched abut spring framework But not much aware of it.
So please suggest me regarding this.
I am surprised you found issues with GWT. Personally I feel, it is one of the cleanest front-end implementations. (did you face issues integrating it with hybernate maybe?)
Anyways, another framework that is java style based (extends gwt and is richer) is Smart GWT that you can look into. I did a detailed comparison here which answers your questions - GWT,Smart GWT,GWT-ext comparison
If you are not looking for a java style based front end, you should look at jQuery too. http://jquery.com/. It even has a version optimized for touch http://jquerymobile.com/
EDIT -
1) You could even look at flex, which is a flash based. http://www.adobe.com/products/flex/
2) Also, if web based forms is the major area, look at Grails http://www.grails.org/
Point 1. Since you consider using Hibernate try "Extra‐lazy" collection fetching and lazy attribute fetching. The elements of the collection are accessed from the database as needed. I think it is a configuration issue to start up faster.
You will probably get faster startup if you use JDBC instead, but Hibernate will cut a lot of development time.
Also the JavaScript files containing your client application may take a lot of initial time to load, so split your application in smaller parts.
and 2. GWT covers your Control Richness issues and gives you a fairly reasonable Browser Compatibility. Gives you everything you have in a desktop Java Application.
About "all browsers": You can not have GUI Richness and Netscape 1.0 compatibility. JavaScript was not invented before Netscape 2.0
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
To my experience, most of java applications on desktop platforms are less responsive than a similar application written in c++ or some other natively compiled language. Which is understandable considering that java only compiles to intermediate language.
And by responsiveness here I mean the general feel of how the application responds to mouse clicks and keyboard events, the little lags between the user clicking somewhere and the program actually redrawing all the needed things to represent the response to that click. Most often these lags are so small that you don't see them as lag, but you get a feeling that the whole aplication gets a little slow.
Examples of such java applications that I would see as less responsive are Azureus, java-based versions of Zend studio, Eclipse, and a couple of my own swing-based java projects.
Is this really the case? Can a java application ever be as responsive as a native application? Should it perhaps be compiled in some different way? (although you would think that if that was possible, big products such as Zend studio would do that already)
Application responsiveness in Java is frequently down to bad/inefficient programming. While a Java UI is heavier than one written in C/C++, on a recent computer (last few years or so) shouldn't struggle with a well coded application.
Most recent benchmarks show Java 1.6 to be of comparative speed to C/C++ (infact in the last cross language benchmarks I saw it sat snugly between the two in terms of performance).
I think a symptom of Java and the IDEs people use to write it is that it is a forgiving language that lets you do things the wrong way (read, less good way), without complaining too much while C++ would just fall over, forcing you to write better software.
As a personal note, I've seen Java applications where the devs attached a single listener to every element in the UI, then that listener had an enormous if...elseif...elseif... to check the tooltip string that was passed back from the event object.
javac compiles to an intermediate byte code. However the JVM compiles to native code based on how the code is used dynamically (something static compilers cannot do) For GUIs most of the real work is done in native code components so you shouldn't see a real difference.
Many real time trading systems are developed using Java and respond in less than 100 micro-seconds. i.e. 0.0001 seconds. If you have a responsiveness issue, its not the language at fault.
BTW: Eclipse uses SWT which is a native library.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I'm planning to build a small multiplayer game which could be run as a java applet or a flash file in the web browser. I haven't done any server programming before, so I'm wondering what sort of server architecture i should have.
It'll be easy for me to create perl/php files on the server, which the java/flash code contacts to update the player position/actions, etc. But I'm considering whether i should get a dedicated web host, which OS to use, which database, etc. Also, the amount of bandwidth used and scalability is a consideration.
Another option could be using a cloud hosting system (as opposed to a dedicated server), so they would take care of adding additional machines as the game grows. As long as each server ran the core perl/php files for updating the database, it should work fine.
Yet another option could be using Google app engine.
Any thoughts regarding the server architecture, OS/database choice, and whether my method of using perl/php/python scripts for server-side programing is a good one, will be appreciated!
You need to clarify more about the game, and think more about architecture rather than specific implementation details.
The main question is whether your game is going to be in real time, turn based, or long-delay based (e.g., email chess). Another question is whether or not you are going to be freezing the state for subsequent reloads.
I would highly recommend figuring out in advance whether or not all players in the same game are going to be hosted on the same server (e.g., 1000 of 4 player matches compared to 4 matches of 1000 players each). If possible, go with the first and stick everyone who is in the same game under the same server. You will have a hard enough time synchronizing multiple clients to one server, rather than having multiple servers against which players are synchronized. Otherwise, the definition of consistency is problematic.
If possible, have each client communicate with the server and then the server distributing updates to the clients. This way you have one "official state", and can do a variety of conflict resolutions, phantoms, etc. Peer to peer gives better performance in faster games (e.g., FPSs) but introduces tons of problems.
I cannot for the life of me see any convincing reason to do this and perl or PHP. Your game is not web based, why write it in a web oriented language? Use good old J2EE for the server, and exchange data with your clients via XML and AJAX. If possible, run a real Java application on clients rather than servlets. You can then benefit from using JMS which will take a huge load off your back by abstracting a lot of the communication details for you.
For your server architecture, you might have a look at Three Rings' code. They have written a number of very scalable games in Java (both client- and server-side).
I would also discourage from using PHP, also HTTP isnt the best idea as it is stateless and talkative. I was working for some time in company currently developing really massive multiplayer game. The back-end is plain JVM (being connected thru tomcat by multiple clients and from mobiles one per client). So I know the less data you transfer the smaller buffers you need on server -> more clients on one machine and also a bit faster responses. Also consider security, https is quite expensive, especially if you need to transfer graphics and sounds. Binnary protocol of your own with non-browser client container would do the best (good choice is switchable protocol for the development-debugging time). Maybe sounds complicated but it isn't.
#Sarah nice hint, thanks too ;)