Refactor Gui/Backend code to make it stateless and do some other improvements

[smurfy]

Currently the Gui is not statless and has lots of logic shared in all different Gui implementations.

Makeing the Gui and Backend code stateless reduces this logic and probably makeing the Gui faster. Also porting to other Gui frameworks / devices would be easier.

More infos can be found here #52.

But basically this are the bulitpoints:

• Use QAbstractListModel
• Use getter/setter in the gui
• Methods for search etc, should use no parameters and access data set by the setters
• Improve qml performance by using createObject instead of creating them on startup

[leppa]

• Improve qml performance by using createObject instead of creating them on startup

One note regarding this. Main startup performance hogs are pages, due to their complexity and inclusion of other pages. Basically, there are two "big" things that happen: compilation of QML file and creation of its instance.

PageStack in Qt Components (both for Harmattan and Symbian, AFAIK) supports pushing not only pages but components and URLs to pages:

1. In the first case, you put a page into Component QML element and push the id of this Component - this will cause compilation of the Page at application startup but instantiation will happen at the moment you call push(). In some cases it might be enough to improve performance. This case still allows to easily handle page's signals and bind page's properties to something. However, binding to page's properties becomes a bit more complex.
2. In the second case, you don't mention a page in your code at all. You push the page by providing URL to it (e.g., pageStack.push(Qt.resolvedUrl("relative/URL/to/Page.qml"))). This will cause both compilation and instantiation of the page to happen at the moment push() is called. But in the case of a very complex page this approach might introduce noticeable delay between push() is called and the actual page appears. Also, the UI will be unresponsive during this delay. The second case doesn't allow to easily handle page's signals, bind it's properties to something or bind to it's properties.

[leppa]

One more big thing I noticed from the code: every search for station/journey/timetabe leaks one instance of ResultList: the object gets created by the parser but never gets deleted. Furthermore, every ResultItem inside this list gets leaked too. So, theoretically, if you start performing a lot of search requests that return large quantities of items without restarting Fahrplan, it will eventually crash due to running out of memory.

[smurfy]

Continuing the great work of @leppa here for the journey aswell: SHA: 894ab2a0bade4d068bc60fc8971156935597e568 (more in the seperate branch)