Chapter 11:Understanding Client-Side Technologies
Download as PPTX, PDF1 like408 views
The document discusses different client-side technologies for creating thin, fat, and rich clients: HTML/JavaScript can create thin clients through web pages but are limited by browser capabilities. J2ME MIDlets allow native-like apps on mobile devices but vary across models. Java applets embed rich functionality in web pages but require network access. Swing provides full-featured desktop apps with native look and feel but may not run well on all systems. Each option has tradeoffs around capabilities, deployment, and network dependence.
Chapter 11:Understanding Client-Side Technologies
- 2. 2
- 3. Using Thin Clients with HTML and the JavaScript API • Exam Objective 7.1 Describe at a high level the basic characteristics, benefits, and drawbacks of creating thinclients using HTML and JavaScript and the related deployment issues and solutions. 3
- 4. HyperText Markup Language • HTML is a markup language used to present static content in the form of web pages. • JavaScript is different than Java; it is a scripting language used to provide interactivity in web pages. • A thin client is an application that is not much more than a user interface that connects to an enterprise server for its data and processing. • HTML and JavaScript are useful for creating user interfaces. • All the user needs to access an HTML application is a web browse • HTML and JavaScript provide only limited user interface components. 4
- 5. Thin-Client +HTML used with JavaScript can create a very rich and dynamic web site. +This site can be used as the front-end of an enterprise application. • However, - this application will not have the same feel as a native application designed for a target environment. -It will be constrained to run inside a web browser and will have some limitations as to what can be done with the user interface. 5
- 6. --An advanced or very custom interface may be impossible or buggy to implement across different web browsers. --Users must always have a network connection to the enterprise server that is hosting the web application. There is no possibility of deploying the application locally on a user’s system. --If the client system has a slow network connection, the responsiveness of the web application will suffer. 6
- 7. Using J2ME MIDlets • Exam Objective 7.2 Describe at a high level the basic characteristics, benefits, drawbacks, and deployment issues related to creating clients using J2ME midlets. 7
- 8. J2ME and MIDlets • J2ME is a subset of the standard Java APIs. • The exact subset is dependent on the profile and configuration of the devices. • The configuration is a general description of the device. A profile is used to define the features of a device and may contain more or less of the Java class libraries based on the resources of the device. • A profile may also be different based on available hardware components. > For example, an embedded device with no screen would have no use for the user interface Java class libraries. 8
- 9. • Mobile phones and PDAs are the most common places to use J2ME. These devices use the Mobile Information Device Profile (MIDP). Applications created with this profile are often called MIDlets. • MIDlets can also be used for enterprise applications that connect to a backend enterprise server. 9
- 10. J2ME makes use of configurations and profiles to classify a nearly infinite number of devices into a few groups that share common features • A configuration is the most basic and general description of the minimum required Java class libraries and includes features that the Java Virtual Machine must support 10
- 11. there are two J2ME configurations: Connected Limited Device Configuration and Connected Device Configuration. 11
- 12. The Connected Limited Device Configuration (CLDC) is a configuration used for resource-limited devices. • It dictates a minimum level of features that the Java Virtual Machine must provide and contains the most basic Java class libraries. • The Mobile Information Device Profile or MIDP is a CLDC profile. • It is the profile nearly all mobile phones implement. • Another common CLDC profile is the Information Module Profile (IMP). IMP is designed for headless systems. Embedded control units and vending machines are two examples of where this profile may be found. • In general, it is a small subset of MIDP, with its most notable exclusion being the Java class libraries for creating graphical user interfaces. 12
- 13. The second J2ME configuration is the Connected Device Configuration (CDC). • This configuration has a more complete set of Java class libraries than the CLDC. • It contains nearly the entire set of Java class libraries from the standard edition of Java, with the exception of the user interface libraries. 13
- 14. Like the CLDC, the CDC has profiles that further define the target device . • The Foundation Profile defines a full implementation of the Java Virtual Machine and most of the Java class libraries, excluding the user interface classes. • The Personal Basis Profile adds the AWT class libraries, in addition to what the Foundation Profile defines. • the Personal Profile includes everything contained in the • previously mentioned profiles, with the addition of support for applets. 14
- 15. • Configurations and profiles are beneficial from a development perspective because they allow you to group similar, but still different, devices together and share common code between them. 15
- 16. J2ME Disadvantages • J2ME does not completely follow the Java motto of “write once, run anywhere.” • Mobile and embedded devices vary too much for this to be true. • Configurations and profiles address this problem to a degree, but the experienced J2ME developer will still find many nuances that exist between devices, especially in areas dealing with user interfaces. • J2ME is not intended for very complex applications. This has more to do with the intended targeted devices than with this edition of Java. • J2ME is ideal for creating applications to look up or record simple information. Creating complex software such as a word processor would quickly push up against the limitations of the device and J2ME libraries. 16
- 17. J2ME Deployment • J2ME MIDlets are generally deployed over a network. They can be manually loaded onto a device, but that isn’t very useful for a large install base. • Typically, they will be loaded by a web server, serving them to clients upon their request. • A MIDlet on a web server will consist of at least two files: a Java Application Descriptor, or JAD, and the Java Archive, or JAR file. • The JAD file is used to describe the MIDlet. It • is a text file that contains information such as the MIDlet’s version, the location of the JAR, the location of the icon (if it exists), and many other attributes. 17
- 18. Using Java Applets as Fat Clients • Exam Objective 7.3 Describe at a high level the basic characteristics, benefits, drawbacks, and deployment issues related to creating fat-clients using Applets. 18
- 19. • An applet’s advantage is its ability to be embedded in a web page but still retain powerful features that would normally be found in a standard desktop application. • The main difference between the two is the way the code is invoked. • An applet will allow the client to access backend enterprise servers such as web servers, web services, and databases. • It also can make use of advanced Java user interface elements such as Swing and multimedia libraries for media playback. 19
- 20. Java Applet Disadvantages • As stated earlier, to execute the applet the Java Virtual Machine must be used. • It also must be a current version. If an applet is executed on an out-of-date Virtual Machine, the applet will attempt to download the latest version. This may create a substantial delay in the startup time of the applet. • Applets have much tighter runtime restrictions than a standard Java application. • They also are executed in a sandbox that gives them limited access to the client-side system. • 20
- 21. • And even if more than one applet is embedded in the same page, intercommunication is impossible. These restrictions may be relaxed but the user must agree to it via a prompt from the Java Virtual Machine. • Since applets are often located inside web pages, they are not able to be executed offline. • The user must have a network connection to the server that contains the applet. • If the user does have a network connection but limited bandwidth, the user may suffer from very slow load times since the applet is reloaded each time it is run. • Some cache is available to help speed up this process, but this is unreliable since it can easily be cleared. 21
- 22. Java Applet Deployment • Applets are easy to deploy. They reside on the web server and are embedded in the web page. When the user accesses the web page, as long as the user has the Java Virtual Machine installed with the Java browser plugin, the applet will load. • The advantage of this system of deployment is that the user never needs to install an application. • From the user’s perspective, they are just visiting a web page. This also allows the programmer to control the deployed version of the applet. • When a new version is released, it can be loaded on the web server and the next time the user visits the site and loads the applet, the newer version will be used. 22
- 23. Using the Java Swing API as a Fat Client • Exam Objective 7.4 Describe at a high level the basic characteristics, benefits, drawbacks, and deployment issues related to creating fat-clients using Swing. 23
- 24. Using the Java Swing API as a Fat Client • Swing extends some of the classes of AWT. However, there is a vast difference on how they render their components. • AWT is considered heavyweight. • This means that they rely on the native system’s windowing components. • An AWT component will utilize the native system to render and control each component used. 24
- 25. • Swing does have the advantage of being skin-able. Skin-able is a term that means the developer can change the look and feel of Swing without having to modify its components. • The source code of a component does not require modification to change its look andfeel. It is distributed with different skins that give it the appearance of a native application on different platforms. 25
- 26. • Swing is a standard part of J2SE. It allows for the creation of fully featured desktop applications. • These applications are often designed to run on a client’s system just like they run on any other native program—oftentimes being indistinguishable. • Swing offers the richest set of user interface components. The applications have full access to the system they are executed on, and can feature a complex interface for performing more demanding tasks. • The only requirement to run a Swing application is to have the Java Virtual Machine installed. • It does not require a network connection unless it is required to connect to a server during runtime. 26
- 27. Java Swing API Disadvantages • Swing has default skins that resemble the native look of many platforms. However, users still may notice subtle differences between a Swing application and a native • or AWT one. • Since Swing is a full-blown toolkit for creating user interfaces, it may not run as well on older hardware or systems that have limited resources. • If your application is simple, sometimes a full Swing application introduces more complexity to a project than needed. • It may be easier for the developer, and user, to create a simple web application with an HTML interface 27
- 28. Java Swing API Deployment • The first method, and the traditional method, is to release your software as a package distributed by CD or for download over the network. The user will then run some form of installer to load the software onto their system. This is good if the software rarely changes.The user will have the software on their computer and will not have to worry about having a good network connection or reloading it from the enterprise server every time. 28
- 29. • The second way to deploy a Swing application is to use Java Web Start. • Java Web Start is a technology developed by Sun Microsystems to deploy Java applications like a Java applet. It allows a full desktop application to be launched from a web browser. • Like an applet, it downloads all of the required files from a remote server. However, unlike an applet, it does not run inside the browser. • It runs on the system similar to a native application. By default, a Web Start application is restricted from accessing the local file system and is limited as to which remote servers it can connect to. • These restrictions can be overcome if the user allows it. 29
- 30. 30
- 31. 31
- 32. 32
- 33. 33
- 34. 34
- 35. 35
- 36. 36
- 37. 37
- 38. 38
- 39. 39
- 40. 40
- 41. 41
- 42. 42
- 43. 43
- 44. 44