Wallpaper structure and class responsibilities

[Martin]

Hello again,

I've continued to mess around with the GLWallpaperService and I'm
really enjoying it. I've got to the point where I've got something
I'd like to spend another week polishing before releasing it on the
market. Though jumping in at the deep end with all this, I'd like to
ask your advice on the correct structure for wallpapers, which classes
should own what etc. I've named the subject generically, in the hope
that this thread will prove useful for other first time
GLWallpaperService users.

Basically, I want to know what the correct setup is for my wallpaper
data and rendering. As I've just been messing with it so far, I've
put everything in my renderer class - textures, particle systems,
world data etc... the lot. Is this the *right* thing to do? Or
should the engine itself own all the data, and the renderer just
renders everything owned stored on the engine class?

I want to make sure my structure and setup is safe for when you swap
from previewing to the actual wallpaper etc. From what I understand,
the system can ask for renderers to be created at multiple times, is
that right?

I think it would be great if someone would be so kind as to detail
what the following classes should "own" and be responsible for:

1. Your wallpaper service class, derived from GLWallpaperService
2. Your engine class, derived from GLEngine
3. Your renderer class, which implements GLWallpaperService.Renderer

Thanks in advance. This is a great discussion group!

[Adam Ratana]

I have found it helpful to have somewhat lightweight code among the 3 classes you mention there, but alos have a renderer delegate class, which the rendering method calls are delegated to, and that delegate can then be composed however you like.  I don't think there's a "right" way to do it, but if reusability is your goal then follow a structure that helps you achieve that.

[Martin]

Cheers for the reply.

I've decided to go with having a unique renderer instance per engine,
and that renderer will contain the wallpaper data - textures, particle
systems etc.

I have seen some people use one renderer instance and all created
engines use that, but given some of the HTC Sense issues with engine's
resuming incorrectly etc... I think it might be best if engines are
truly unique, in terms of data and renderer.