using System;

namespace Nuclex.Ninject.Xna {

  /// <summary>Allows code to be executed during the game's initialization phase</summary>
  /// <remarks>
  ///   <para>
  ///     When you try to set up XNA for dependency injection in an application fully
  ///     driven by an IoC container, you'll eventually hit one minor roadblock: the graphics
  ///     device is only created when you call the Game.Run() method. Thus, any components
  ///     consuming a graphics device will crash and burn if they're accessed before that.
  ///   </para>
  ///   <para>
  ///     This is not a theoretical problem, as merely binding a SpriteBatch already
  ///     provokes this issue as soon as you set up a component that accesses it since
  ///     the SpriteBatch immediately tries to pluck the GraphicsDevice from
  ///     the IGraphicsDeviceService it is provided with.
  ///   </para>
  ///   <para>
  ///     The solution is to postpone the initialization of the relevant components until
  ///     after the game has started its second startup phase. This interface, implemented
  ///     by <see cref="NinjectGame" /> (or by yourself if you don't use XNA's Game class)
  ///     provides a hooking point to do so.
  ///   </para>
  /// </remarks>
  public interface IGameInitializer {

    /// <summary>Called when the game is being initialized</summary>
    event EventHandler<EventArgs> Initializing;

    // There are no attachment points for LoadContent() and UnloadContent() as
    // it is expected that you create GameComponents for this instead of attempting
    // to load content that is external to the Game class but responds to its events.

  }

} // namespace Nuclex.Ninject.Xna