On May 12, 2011, at 9:25 AM, Stephen Long wrote: > While my findings are not exactly quantitative or conclusive, it raises > immediate viability concerns. Along with other concerns regarding various > issues of general IDE/debugging performance and issues, are there any plans > to dramatically improve in-app performance?
Use a splash-screen. :-) See also Firefox Mobile, which on my N1 isn't ready for input until ~10s after launching. The problem is that there's a great deal of extra work that needs to be done during app startup, such as initializing the runtime, creating the initial AppDomain, parsing the .apk for assemblies and loading any required assemblies, and this needs to be done before the tapped Activity can even be created (which will likely involve loading additional assemblies & types, along with registering Java native methods so that things Just Work). It may be possible to improve this (speed up runtime init, assembly loading, etc.), but there will always be some degree of overhead involved. Using a splash screen can provide a quicker response while letting the user know that the app can't be used yet. Unfortunately we have no samples for what to do for custom splash screens, but it involves writing a Java activity (the "real" activity) which displays the splash screen (google for Java code) then launches the managed activity through the generated Java proxy. You'll want to investigate e.g. obj/Debug/android/src to see the generated Java proxies (for types & names) and obj/Debug/android/AndroidManifest.xml (which also provides the types & names you can use with Activity.startActivity). - Jon _______________________________________________ Monodroid mailing list Monodroid@lists.ximian.com UNSUBSCRIBE INFORMATION: http://lists.ximian.com/mailman/listinfo/monodroid
