Thanks for clearing things up.
Again, this could with great benifit go into the documentation. I
could do it for you if you let me into the wiki.
Thanks!
--Lennart
On Nov 9, 11:02 pm, Kevin Gaudin <
kevin.gau...@gmail.com> wrote:
> All Android applications run with an Application object instance as a
> context of execution.
>
> You rarely really need to implement your own Application subclass. Some
> people use them to create static fields available in any other application
> component (like global variables), but this not a so good idea. In most
> projects, whatever the type, you usually don't need one and the Android
> framework instantiates the default android.app.Application class.
>
> While reading examples of crash reporter implementation, I often found
> instructions like "In your main Activity, call
> Thread.setDefaultUncaughtExceptionHandler(new
> YourUncaughtExceptionHandler())". But in many real applications, there is
> no such "main activity". There could be many other starting points for your
> application, like a background service, a content provider, or many
> different activities that are triggered by external intents.
>
> So, in complex applications, you would have to pollute many of your classes
> with code to initialize your exception handler... with the risk of calling
> this initialization code several times if you navigate between several
> activities.
>
> My idea was to attach this exception handler at the earliest possible stage
> in the life of an Android application, in order to report all possible
> errors for any component and have a single modification point.
>
> And the earliest possible stage in an application lifecycle where we can
> add some code is android.app.Application.onCreate(), which is
> "<goog_135775015>Called
> when the application is starting, before any other application objects have
> been created."<
http://developer.android.com/reference/android/app/Application.html#o...()>
>
> The call to Thread.setDefaultUncaughtExceptionHandler() is like a global
> setting. Once you set this handler, it is applied to your whole Dalvik
> process. So setting it once at the very beginning of your application life
> ensures that any uncaught exception in any class of your application will
> be reported (even those coming from the android framework code).
>
> You should not consider that subclassing Application only to put the ACRA
> annotation and init call is like implementing a "dummy" application class.
> You just should feel happy that I found some handy API concepts that allow
> you to manage, configure and start the whole crash reporting library for
> your whole app in a single class, with 2 simple lines of code. :-)
>
> It would have required much less work for me to tell you "copy the 400
> lines of code below in the Application.onCreate() method, and don't forget
> to replace the various hardcoded values with whatever you like" :o))))
>
> Finally, a live wallpaper application is an application like any other
> android application,with a special service which can draw on a Surface
> provided by another application. Before it does anything, the Android
> System instantiates its android.app.Application class and calls its
> onCreate() method. There is nothing wrong with implementing an Application
> subclass, it is supported by the official android API and you should not
> feel bad about adding one to your project.
>
> There is still one case where this init method is not enough. Some
> applications can make use of multiple processes (not threads,
> processes<
http://developer.android.com/guide/topics/fundamentals/processes-and-...>),
> and each process would need to initialize its own ACRA instance. This case
> is not covered with the present API.
>
> I hope this is now clearer for you. Please do not hesitate to ask more
> questions so you don't have any doubt about it anymore (or to show me that
> I'm wrong, I don't pretend to know all the android magic).
>
> Kevin
>
> On Wed, Nov 9, 2011 at 8:08 PM, lennart rolland <
lennartroll...@gmail.com>wrote:
>
>
>
> > But is it not so that the application subclass you annotate should
> > actually have some code in it that could crash? If this is not the
> > case then the dependence upon an application class at all would feel
> > very fake since you would just need a dummy application subclass.
>
> > There are no Application subclasses in the cube live wallpaper
> > example, only a WallpaperService and WallpaperEngine. Having to create
> > a dummy Application subclass here feels wrong IMO.
>
> >
http://developer.android.com/resources/samples/CubeLiveWallpaper/src/...