is what you see on display, it has container with controls, it handles menu and cba buttons... There could be displayed only one view at the time. switching between views is coded in Symbian CEikAppUi class.
in Avkon each view has a container which is container for controls like edits, texts, grids (same as them, also container is derived from CCoeControl class). It is simply control which owns other controls. You can define more than one container in view and switch between them, which is cheaper and faster than switching between views. This is not typical Symbian way, it is so much used only in Series 60. It is not necessary to use containers, you can also put the controls directly into view. But when application is initialized, all views are created, co all controls which are directly in the views will be created. Containers are created and destroyed typically in DoActivateL() and DoDeactivateL() methods.
Also container is window-owned and it ows non-window owned controls which shares container window space which result in less communication between applications and window-server, so it is faster
it occupies typically bottom part (1/3) of the screen and overlaps underlaying view (view cannot overlap view). It is used for informing user typicaly "Do you really want to delete this?" Yes/No).
I saw in Series 60 apps it's used the view architecture.
If I use this type of architecture, for myAppUi class I've to derive from CAknViewAppUi instead of CAknAppUi. What's the difference between these classes? Are there any difference in behaviour(softkeys, commands, ect do work the same way in CAknAppui and in CAknViewAppUi)?
it is highly recomended to use CAknViewAppUi, which is derived from CAknAppUi and adds to this class some support for views. I didnt saw the Avkon application using CAknAppUi directly, but it should be possible.
The Series 60 platform support traditional Symbian architecture, so you could use EIKON classes instead of Avkon ones, but if you want to derive your views from CAknView you need do use CAknViewAppUi. But if you want to derive your views directly from CCoeControl class implementing MCoeView and other mixin class (as on UIQ for example) you could also do it, but I think your applicatoin will not have a standard Series 60 behaviour.
Result is that you must use CAknViewAppUi if you want derive your views from CAknView (views has some appui functionality like menus, command buttons...).