| |
|
Brief Summary for our Research on GUI-API for building RIA
|
|
|
Today there exists many simple yet powerful and mature viable GUI-APIs (e.g. Windows/VC++ or Java/Swing) for building large and complex desktop GUI-applications comprising dozens to thousands of GUI-components. The essential requirements for fully viable GUI-APIs are defined below. Even a junior developer can be quickly trained to use any such viable mature GUI-API (e.g. Windows/VB) for building large GUI-applications having several dozens of GUI-components.
|
|
|
However it is desirable to build and deploy many future 2D/3D graphics intensive real-time data driven GUI-applications in latest very powerful HTML5 browsers. Hence it is desirable to invent a viable GUI-API that is more flexible and easy to use (than the GUI-APIs for building desktop GUI-applications) for building many times more complex 2D/3D graphics intensive real-time data driven RIA (Rich Internet Applications). We already secured 3 patents for such a GUI-API and the numbers of our US patents are: 7827527, 7840937 & 8527943.
|
|
|
We invented a new kind of highly flexible reusable GUI-classes for presenting GUI-components in RIA (Rich Internet Applications). Any typical GUI-application (i.e. a single executable) comprises of few dozens to even tens of thousands of GUI-components. The GUI-components need to collaborate with each other (e.g. by calling functions of each other). Any GUI-API must provide a set of basic reusable GUI-classes for presenting GUI-components and provide a simple method for 3rd party vendors or for application developers to create any kind of reusable GUI-classes for presenting application specific GUI-components.
|
|
|
To build a GUI-application the developers use various reusable GUI-classes for presenting various GUI-components. That is, to present a Pie-chart, the application developers use a reusable GUI-class of a Pie-chart to instantiate an object instance and implement application logic to access and process necessary application data to use the data for constructing and configuring the object-instance. This process of instantiating an GUI-object instance and using application data for constructing/configuring the object instance (e.g. 11/12 in FIG-1) is repeated for presenting each of the GUI-components (e.g. 21/22) in the application (even if the application has a thousand or a million GUI-components).
|
|
|
|
|
Also most of these components within any application (i.e. an executable) need to collaborate with each other, so a viable GUI-API must also provide a method for implementing communication code between any two components, for example, in order for the 2 GUI-components (e.g. 21 & 22) can collaborate or exchange data with each other (or notify certain events to each other). A viable GUI-API for building RIA (i) must provide a simple method for creating application specific reusable GUI-classes, (ii) must allow using multiple reusable GUI-classes for presenting run-time data driven GUI-components (by accessing and using application data at real-time), and (iii) must provide a simple method for implementing communication code between any two or more GUI-components.
|
|
|
Our patented reusable GUI-classes (e.g. implemented as Java or C# classes) run in servlets to generate application code (e.g. SVG, SliverLight or Flex/Flash). FIG-1 shows (A) how 2 reusable Java (or C#) GUI-classes/objects (i.e. 11 & 12) can be used for generating HTML5/SVG/JavaScript code for presenting two GUI-components (i.e. 21 & 22), and (B) how it is possible to generate JavaScript communication code (e.g. 25/45) for allowing collaboration between any 2 GUI-components (e.g. 41 and 42) in HTML5/SVG application by implementing 1 to 7 lines of simple and very special kind of code 35 at server. The servlet 30 implements application logic in Java (or C#) for accessing and processing application data to initialize the GUI-CCG-objects (31&32) of reusable GUI-CCG-classes & request the objects to generate presentation code (41&42).
|
|
|
Our invention has many silent features, to name couple: One of the data inputs to each of the GUI-CCG-objects is type/version of requesting browser and each CCG-object uses this data for generating compatible presentation code for each requesting browser (e.g. FireFox, Crome, IE) at run-time. The application developers are predominantly Java/C# programmers having expertise in their application domains, but having little experience in web-programming (primitive instructions of complex 2D/3D graphics languages/browsers such as JavaScript, SVG, SilverLight, Flex/MXML). Our GUI-API allows implementing nearly 97% of the servlet (30) in Java/C#. But, in few cases the developers need to implement 1 to 7 lines of server code (35) to generate very simple JavaScript communication code (45) to allow collaboration between any 2 GUI-components (41 & 42).
|
|
|
If given an opportunity, we can demonstrate many RIA (uses Java at web server & SVG/DHTML/JavaScript in browser) having complex hierarchies of GUI-components. We can also demonstrate new kinds of patented ‘Components’ and ‘Component-Based Design’ (more US-patents 8392877 & 8578329), which allow develops to build many times more complex applications than practical even by the desktop GUI-APIs. We have patents for only possible viable server side (e.g. Java/C#) GUI-API targeted at application developers (about 90% of them prefer to avoid mastering complex rapidly evolving/growing/changing HTML5 browsers types). Today we are not seeing 2D/3D graphics intensive run-time data driven RIA having dozens of large GUI-components in web-browsers, because no such viable GUI-API available for application developers (experienced in Java/C#).
|
| |
|
The Target Users of our Invention of GUI-API
|
|
|
Our GUI-API is target at application developers, who are having very little experience in technologies and languages supported by HTML5 browsers, for helping them build and maintain complex 2D/3D graphics intensive data driven applications that can be deployed over internet. I was an application developer created many client server GUI-applications (between 1988 and 1998) using desktop GUI-APIs such as Motif/X11 and Windows/VC++. I did not find any Java GUI-API (for using in JSP/Servlets) for building RIA (Rich Internet Applications) and I didn’t want to master multiple markup languages such HTML, SVG, Flash/Flex, SMIL, DoM/DHTM, XML and scripting languages such as JScript, Canvas or ECMAScript (slightly different implementations in various browsers) & especially maintain for each change. I end up inventing GUI-API for application developers to deploy complex data-driven business applications online.
|
|
|
The software developers who also must create user interfaces can be broadly divided in to two categories (i) application developers and (ii) the web page designers. The application developers must have expertise in developing software in high level languages such as C++, Java or C# and also in must have knowledge in application domain. Traditionally the application developers created desktop applications by using GUI-APIs for desktop platforms such as Windows/VC++, Mitif/X11 or Java/Swing.
|
|
|
The web page or application designers must have expertise in developing software using multiple markup languages such HTML, SVG, Flash/Flex, SMIL, XML, DoM/DHTM, and scripting languages such as JavaScript, Canvas or ECMAScript, which are all supported in the modern web browsers. The web application designers can use any combination of all these languages for presenting each of the large GUI-components in the web-application. Unfortunately each of the browsers supports slightly different variations of these languages, so the developers need to implement slightly different versions of software code for each of the web-browsers.
|
|
|
Furthermore the web-browsers (and plug-ins) are constantly evolving, for example, new versions of web browsers (and plug-ins) are being released each year, where newer versions supporting more and more powerful languages (e.g. by adding new features, improving existing languages and/or supporting new languages). In case of web-application, many components must reflect run-time data, for example, based on user profile and preferences etc. It is a complex task to keep-up each of such data-driven components in the applications with wide range of browsers (ranging from computers, mobile devices to smart phones).
|
|
|
Furthermore application development and evolution by releasing each of the new versions is iterative process, for example, to satisfy unique needs of business (which are often not clear, for example, until end user satisfied with functionality) or to adapt to evolving business needs. In case of real-time data-driven web-applications, the application developers implement the application logic for accessing and processing application data. The web-developers implement presentation-logic by using the application data. It is a very complex and error prone process to change the web-application code that contains extensive application-logic (implemented by application developers) and presentation-logic (implemented by web developers).
|
|
|
In fact, it is practically impossible to build large web-applications that contain multiple large run-time application data driven GUI-components and component-hierarchies. That is the reason we are not finding such large 2D/3D graphics intensive data driven web-application (as complex as even medium size desktop client-server GUI-applications) anywhere in the world. Of course, we might occasionally encounter prototypes or proof of concept web-applications, which are quickly abandoned because it is not practical to refine little-by-little to meet and keep up with real-world needs. Our GUI-API overcomes all these limitations, so it is possible to build more complex applications than practical for desktop platforms (by using GUI-APIs such as Windows/VC++ or Java/Swing). Please review a sample GUI-application at:
http://real-software-components.com/CBD/City_GIS.html
|
|
|
Only a small percent of software developers are web-designers (who mastered most of the HTML5 technologies and languages), and only a small percent of web-designers have sufficient experience in building simple to medium size run-time data-driven RIA (Rich Internet Applications). This is the reason, today it is nearly impossible to find large run-time data-driven RIA (Rich Internet Applications) having multiple large data driven components such as charts or graphs. Our GUI-API is targeted at the software developers for helping them build runtime data driven 3D/2D graphics intensive complex
RIA. So our GUI-API is targeted at large percent of software engineers.
|
| |
