====== Project preconditions ======

\\

//At least for the last five years there is strong intention on the market of supplying different remotely accessible on-line services and software which can keep out a user from installation and centralize the user data management. In other words: user software + user data which are available everywhere where Internet exists. Ancient WEB, despite of all marketing renovation (AJAX, WEB 2.0, etc), still cannot be adjusted to the modern trends. Even taking in account all significant investments coming into the area every second. What's wrong ?
//

\\

Two aspects make IT life worse:
\\
<box blue round 90%>
\\      
\\
   * __**[[home:projects:gravity:engineering|Software development is still ENGINEERING !]]**__

   * __**[[home:projects:gravity:dead-web|Web as an ANTIQUE value of our fathers.]]**__
\\
</box>
\\










====== Less words more performance. ======

\\

Demo is the best way to to demonstrate and present a project features. Gravity provides rich set of various UI components what can be a good subject for presentation. Provided demo is samples central applet which:
   * Demonstrates approximately 80 different samples united in one Java applet.
   * Doesn't require any installation actions on your PC/PDA, delivered as a Java applet.
   * You should not care about version of Java Plug-in has installed for your browser. It works even under old Microsoft Java that was a part of Internet Explorer installation some time ago.

<box red round 40%>
<style center>
**[[http://www.gravitysoft.org/applets/samples/run.html|PRESS HERE TO START DEMO]]**
</style>

</box>

\\

====== Gravity - light weight software platform ======

\\
Gravity is a software platform which provides various components to build applications working for different devices (PDA, PC, etc), different environments and languages basing on unified concept. One of the main purpose of the project is providing common approach to unite, solution which is an example of high quality of its design and implementation. Basically declared statements are trivial. Trivial sounds boring but trivial in many cases is far from easy to do.

\\
<style center>
**Gravity principles**
</style>
<style center>
**V**
</style>

<columns - - ->
**__To unite__:**
  * different platforms and languages: .NET, J2ME, Eclipse, Ruby, etc
  * various types of devices: PDA, PC, Phones, etc
  * people :)

NEWCOL

**__To have:__**
  * small size, high performance, low system resources requirements 
  * rich set of components 
  * simple, well dedicated architecture and design.

NEWCOL

**__To be:__**
  * highly extendable 
  * generally free (GPL)
  * excellent choice to create remote applications: cross out <del>WEB</del> and all the marketing "innovations": AJAX, WEB 2.x :)

</columns>

\\




====== Gravity principles details ======

\\

There has been several statements announced in previous chapter. Some of them is too abstract and common. Just to throw daylight upon what high quality means let me put clarification how I am archiving it:     

\\

  * **Clear dependencies model**. In most cases it is big problem to understand dependencies you have between components. As soon as you start investigating which packages are required to compile a module you can meet a situation you need practically all stuff. Unfortunately cyclic dependencies are usual thing today. For example Eclipse is a good illustration of "depend on all" situation. Gravity platform is designed  to have clear picture of supplied modules and its dependencies. Use only what you really need.
  
  * **Do code review**. That what many projects actually loose. I cannot have remember a code review has been required or mentioned as a project step. But it is worth to do since it helpful for both sides: developers and developing project. Doing code review software developers lean new things what make them more professional. Code review improves project quality.  

  * **Ignore backward compatible**. It is not something special if people do mistakes, this is human nature. It is normal when new experience gives your more knowledge and you can see further. If you stick to backward compatibility you close the door for your new experience and you cannot demolish errors you have done before. Gravity doesn't guaranty a new version will be able run old code, nevertheless you like it or not.  

  * **Spend 30-50% of development time to design**. Design is tremendously important step which is often messed up with technologies selection. If you have good tools set it doesn't mean you can build a house. Firstly you have to understand how to build a house and only after that select appropriate tools. 

  * **Take care of performance and system resources**. One of the project aim is to have a platform working on different devices including PDA and Smart Phones. Such class of devices imposes limitations regarding available system resources (CPU, memory, etc). Every line of Gravity source code should be written with a glance to this fact. Another important thing is high performance and reasonable resources requirements can be considered as achievement of good quality of the product.