Windows Phone application must pass certification criteria. You can find two of them that are strictly connected with application start-up time:
[list icon=”check”]
- the application should show first screen of application in less than 5 seconds. Of course this can be splash screen,
- the application should respond to user actions no later than 20 seconds after launching.
[/list]
You might wonder if this is a lot. From my point of view it is very difficult to overcome these two limitations. However, if we look at application from user’s perspective, waiting 20 seconds for start of application can be terribly annoying. You should be aware that after next 10 seconds screen saver could be launched. For this reason I propose to consider the possibility of improvement of starting time of application.
I assume that such things as:
[list icon=”check”]
- running long operations in different thread than UI thread,
- showing notification to user about the status of on-going operations
[/list]
are obvious and need no explanation.
I go straight to the point. After analysing some Windows Phone applications two approaches can be found. The code that should be execute before each run of application can be inserted to:
Handler of application Launching event – in this case we need to remember about 10 seconds limitation for event handler execution
// Code to execute when the application is launching (eg, from Start) // This code will not execute when the application is reactivated private void Application_Launching(object sender, LaunchingEventArgs e) { // Do something }
In the main page constructor:
public partial class MainPage : PhoneApplicationPage { // Constructor public MainPage() { InitializeComponent(); // Do something }
From my point of view both concepts are not entirely correct. The greatest drawback is that execution of this code will be done before the first page will be displayed. This code will delay its appearance. User of application will need to wait longer for the appearance of any information on phone screen. Moreover this solution can lead to the rejection of our application in certification process. There is a risk that our application will not meet previous mentioned certification criteria.
In order to avoid such situation I propose to delay an execution of this code until the first page will be loaded correctly. This change should improve comfort in application usage. To do this you need just to handle main page Loaded event:
public partial class MainPage : PhoneApplicationPage { // Constructor public MainPage() { InitializeComponent(); this.Loaded += new RoutedEventHandler(MainPage_Loaded); } private void MainPage_Loaded(object sender, RoutedEventArgs e) { // Do something }
After this change your application should start faster. Sometimes this is not enough. In such cases you can delay execution of launching code. To do this I propose to use some timer which will be started in already implemented event handler:
public partial class MainPage : PhoneApplicationPage { private DispatcherTimer timer; // Constructor public MainPage() { InitializeComponent(); this.timer = new DispatcherTimer(); this.timer.Interval = TimeSpan.FromSeconds(1); this.timer.Tick += new EventHandler(timer_Tick); this.Loaded += new RoutedEventHandler(MainPage_Loaded); } private void MainPage_Loaded(object sender, RoutedEventArgs e) { this.timer.Start(); } private void timer_Tick(object sender, EventArgs e) { this.timer.Stop(); // Do something }
This solution allows to define the time of delay as we want.
W sumie to wszystko zależy od sytuacji, która wymaga optymalizacji. Czasem pomaga wrzucenie do Loaded, innym razem warto zastanowić się nad dynamiczną zmianą bindowania z kodu.
Opcją też jest podział ma mniejsze biblioteki.
Niejednokrotnie uproszczenie architektury, też można znacznie przyspieszyć działanie programu. Szczególnie jeśli zoptymalizujemy ilość warstw w programie.
Jakimś rozwiązaniem może też być opóźniona inicjalizacja wszystkiego co się da. Może to jednak wywołać “mulenie” się aplikacji w trakcie użytkowania.
Co do pomysłu z Loaded to trzeba pamiętać że na tym zdarzeniu trochę się dzieje np. następuje uruchomienie DataBingów a to znowu może generować pewien ruch we ViewModelu
Warto się jeszcze zainteresować podzieleniem aplikacji troszeczkę jeżeli aplikacja już jest tak skomplikowana że jest w stanie się uruchamiać ponad 20s (osobiście wolał bym nawet 5s nie przekraczać na ładowanie -- a to i tak jest dużo)
http://mikaelkoskinen.net/post/windows-phone-caliburn-micro-split-app-multiple-assemblies.aspx