Problem/rationale: Launching GS plugin view outside GS application when GS application is not already running may fail. This was caused by application inter working combined with GS application's asynchronized plugin loading. High level functionality for external view launching goes: 1. Application framework starts desired application 2. Application framework calls view-activation on the desired application view. 3. Desired view handles the activation call-back by drawing itself on screen or whatever required.

Starting from phase 2, things can go wrong: when GS start-up call returns, GS has not yet loaded all the plugins and the views owned by plugins are not added yet to the view-framework view list. Calling non-existing view will naturally fail.

Solution: When GS start-up is called, populate view-frameworks view list with all the views provided by GS application before function return. Kind of: This would ruin GS's asynchronous plugin loading and would cause devastating freeze-up times on GS start-up. Hence, on GS start-up we're not actually loading the plugins nor the real views. We use light-weight dummy views (aka CGSShimmedView) wich we add into view-framework view list immedieately on start-up. If it happens so, that the view framework-decides to call view activation on one of these dummy views, dummy view will load manually the real plugin view and switch it with the dummy view. Dummy views are created by CGSPluginAndViewIdCache on GS-application start-up.

Different use scenarios:

1. First GS-application start on a new device, create cache & save as file.