Java Backend Development: Best Practices for Success
9 min read
01 Dec 2024
Helen
Web Development
Before we start coding our first app, we need to know certain details called "general knowledge" to understand what we are getting into. This is how we understand some of the Java backend problems of our applet download and processing time.
Also, it is necessary to have an obvious idea of the program's structure and the objects it will use. This will help us create a program that is easier to understand, expand, and maintain.
This article will analyze the particularities of a Java application's operating environments and the limitations we must consider. Here are the limitations we will be discussing:
Java is an OOP language; therefore, our programs will be composed of interconnected objects. Before opening our favorite source code editor, we must decide which objects will be the main ones and how they will relate to the rest of the objects.
In our backend developer projects, we will save a lot of time if we outline the objects, decide their interfaces (how they relate to the outside world), and review this outline thoroughly before considering the Java code. We should avoid the temptation to think, "I'll leave this issue open to decide while I code."
As we begin to code, we unconsciously lose the freedom to think and become bogged down in the details: the time to think freely is before coding. This recommendation is valid for almost all backend developer projects except elementary logic programs.
The use of our products/projects generates reactions in users. Everything seen on the screen and the sounds heard make up the user experience of our designed interface. It is essential that when designing, we first need to know how to put ourselves in the user's place instead of giving priority to the technical details of how we are going to solve our problem. We must bear in mind that our tastes do not always coincide with those of the users, and, except for particular web applications, it is preferable to be cautiously innovative.
Several general aspects must be considered when analyzing how our page will be navigated: how the mouse will be controlled, how we will rely on the keyboard for certain actions, etc.
Mouse control may seem obvious, but its functionality is different in a desktop application than in a web application. For starters, Java does not provide direct support for double-clicking, so one of the main mechanisms of user-application communication will need a little analysis.
Java detects the single click, the mouse movement, and the release of the button from the drag-and-drop operation without problems
Still, as a Java backend developer, if we want to use double-clicking, we will have to structure a function (or look for it in the Java libraries) to detect the time elapsed between two clicks and determine that it was a double-click.
Another thing to remember in backend-driven development is that although in Java, you have access to the actions of all three mouse buttons, web users tend to use only the primary button. Alternatively, to give more functionality to mouse input, you can combine the mouse click with the SHIFT or CTRL key press.
Java does not allow us to code apps with support for additional mouse buttons, so we must rely on the keyboard to enable alternative mouse input. When it comes time to decide which keys to accompany the click of the main mouse button, it is not advisable to deviate from the classic keys: Shift and CTRL.
We often carefully design a user interface, choosing the most elegant or striking font, and are proud of the result. But when developing for a Web and multiplatform environment, things are not so simple: not all fonts are installed on all computers, and to avoid surprises in the presentation of the text due to automatic font substitution.
We must determine if the chosen font is available on the systems where we want to use it. Obviously, using the common fonts (Arial, Times New Roman, Courier, and others) will not cause problems.
In Java, it is very easy to produce pages with images, animations, and sounds: so easy that the page is often overloaded with these elements as if it were a black hole that could absorb everything.
Sometimes, you test a page on a local computer, which performs well, but then you get surprised in the live environment. Firstly, not all web users are lucky enough to have access to a top cloud server, and secondly, you are not interested in losing user market share because your pages take minutes to load.
When testing the performance of our pages, we should choose the most common environment for our user network. It is more realistic to think that the average user uses a 56 kbps modem to access the web.
Applets themselves are extremely small and can be downloaded over the network without causing the slightest problem; things are radically different when it comes to graphics and sounds. Fortunately, there are some tips to minimize the download time of these files.
Sounds attract users' attention on our website and are undoubtedly a good mechanism for this purpose, provided they are not abused. This is not only because of the bandwidth they take up but also because of the negative reaction from users, as mentioned in the previous section.
Java works with audio files in the au format, requiring us to convert our recordings to this format so we can listen to them in an applet. This type of format takes up relatively less space than other audio formats but does so at the expense of quality.
All sound files include a few silent seconds at the beginning and end. Even if these seconds are silent, they take up bandwidth during downloading, so it is advisable to trim them. The disadvantage of this trimming is that the sound can start very abruptly, causing an unpleasant sensation.
The secret is choosing the sound fragment so that it does not become tiring and that its repetition becomes manageable to musically inclined users. Since it is possible to superimpose two or more sounds, a staggered combination of sounds can be created where the repetition goes unnoticed.
Given their frequency of use, graphic files are the main culprits of page download times compared to sounds. Java supports the use of GIF (Graphic Interchange Format) and JPEG (Joint Photographic Experts Group) files from the start, and we can use them in our applets.
Regardless of the format used, graphic images are all bandwidth consumers. If our problem is reducing the bandwidth a page uses with images, we have several alternatives.
The first step to reducing the graphic's download time is to adjust its size to what is strictly necessary using cropping tools available in any image management program (PhotoShop, Canva, etc).
The second step to reducing the graphic's download time is to reduce the number of colors in the image display. Instead of using a full-color palette, a reduced palette with the most commonly used colors can be defined, thus achieving shorter download times.
By using a reduced palette, the image is forced to use the closest color, losing color fidelity in exchange for less download time. It is always about finding a balance.
GIF images have a number of valuable advantages. In addition to being images stored with a good degree of compression, they allow transparency, which is the ability to define a color in the image as transparent, and interlacing, which is the ability to appear on the screen as the image is transmitted (as opposed to the sudden appearance of the entire image at the end of the transmission).
JPEG images, on the other hand, have a higher degree of compression and allow a greater number of colors than GIF graphics, but do not allow transparency. Interlacing is a very important capability because it reassures the user who is watching a page download, as it allows them to visually verify that the data transmission is taking place and to evaluate the time remaining in the download.
The choice of graphics format does not allow for a fixed rule: everything depends on what is being displayed, the number of kilobytes of the original images, the number of colors needed, and the number of images. It is very common to conclude a combined choice: some images are displayed well with GIF and others require the use of JPEG.
A few years ago, the most common number of colors that could be represented on a screen was 256 colors, so producing images with more colors represented an effort without reward; however, nowadays it is common for computer screens to be able to represent millions of colors, so the color restriction is not determined by the inability of the average user's equipment to represent those colors but by the download time of the images.
Java is a platform-independent language. This means that our program will be used on a variety of operating systems, and we know from experience that images are not displayed the same way on different platforms, or even on different computers running the same platform.
As Java is implemented on new platforms, we will have more variety in presenting the same image. This problem is combated by adhering as much as possible to basic palettes of established colors. Our efforts to find a certain color will be of little use; it will surely look the way we want it on some platforms, and on the rest, a similar color will modify it.
When developing an applet, we must also take into account the processing time in addition to the bandwidth required for its execution. Normally, our website users have less powerful computers than those we use for software development.
This means that the response times we obtain in our development environment will generally, and with some exceptions, be much shorter than the actual production time on the users' computers. Another device that will also present differences will be the screen.
Therefore, we must not lose sight of the fact that we are developing for users and not for our high-end equipment: valid response times will have to be assessed in execution on medium or slow computers with standard modem connections, not on our equipment, which will surely have a latest-generation processor (or almost). We can rest easy if the applet works well on these medium computers.
Animation is one of the elements that usually captures the attention of web surfers, which is why its use is becoming increasingly widespread in web page design. It is difficult to escape the spell of a well-made animation.
However, we must bear in mind that animation requires processing capacity and will not have the same appeal if it is run on high-end processing equipment as if it is run on an older computer. The same problem applies in reverse: an animation designed for a low-powered computer will practically fly on a modern computer.
What should we do in the face of this dilemma? Should we design for everyone or just for a sector of the market?
To be consistent, we should try to design for the broadest market of users. Fortunately, we can control and adjust the frame rate, inserting delays, if necessary, to the speed of the processor we are lucky enough to have. In Java, this is implemented very simply by means of a loop that checks whether it is time to draw a new frame or continue displaying the previous one.
This solution is valid, but it does not exempt us from trying to reduce the processing carried out within the animation routine to the maximum and from adjusting the size of each image to the minimum possible. Everything we have explained above about optimizing image processing is valid here. Every detail that makes the images lighter will benefit the available bandwidth and contribute to unloading the task from the processor.
Animation routines are strong candidates for solving using threads to better distribute processing. Java is fortunately a language that implements threads with relative ease, so several tasks can run simultaneously.
As a general rule, it is preferable to create a user interface layout before coding anything and to think deeply about its appearance and the actions that can be performed from it. Of course, this initial layout will be modified several times before it fully satisfies us as users and also the real user. Once we are satisfied with the user interface, it is time to consider the objects the program will need.
We have presented the best practices for success in Java backend development. While these might not be complete for what you need, it explains what you need to have in mind. If you need a Java backend project, please don’t hesitate to contact us, we will be happy to help.
Web Performance
Backend Development
Copy link
Relevant Keywords
Popular Blogs that you may like
