Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extract emitter shape so it no longer depens on a View. #98

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

pserwylo
Copy link

Now, the interface just specifies x, y, width and height. This allows for either
a Android View object, or alternatively an arbitrary rectangle to be used for emission
locations.

It maintains backward compatibility with the current API by overloading each method which accepts a View. The new method accepts an Emitter, and the old method delegates to the new method, by passing in a new ViewEmitter(view) whenever the new method expects an Emitter.

In the future, this could be further refactored to expose even more flexibility. For example, the entire calculation for initial particle locations into the new Emitter interface. That is to say, instead of it being hard coded to use x, y, width, height (and hence a rectangle emission area), we could instead have an interface which exposes a method generateParticleLocation(). Some emitters may choose to use a rect, others could use a circle. Others could do even more interesting things such as from a point, but randomly distributed around the point according to a Gaussian distribution.

Another future refactoring would be to attach the gravity argument to the Emitter itself. That way the ParticleSystem itself doesn't need to care about whether to anchor particles to the top or bottom of a rectangle area. Instead you would configure this on the emitter object before passing it to the particle system.

Now, the interface just specifies x, y, width and height. This allows
for either
a Android `View` object, or alternatively an arbitrary rectangle to be
used for emission
locations.

It maintains backward compatibility with the current API by overloading
each method which accepts a `View`. The new method accepts an `Emitter`,
and the old method delegates to the new method, by passing in a `new
ViewEmitter(view)` whenever the new method expects an `Emitter`.

In the future, this could be further refactored to expose even more
flexibility. For example, the entire calculation for initial particle
locations into the new `Emitter` interface. That is to say, instead of
it being hard coded to use `x`, `y`, `width`, `height` (and hence a
rectangle emission area), we could instead have an interface which
exposes a method `generateParticleLocation()`. Some emitters may choose
to use a rect, others could use a circle. Others could do even more
interesting things such as from a point, but randomly distributed around
the point according to a Gaussian distribution.

Another future refactoring would be to attach the `gravity` argument to
the `Emitter` itself. That way the `ParticleSystem` itself doesn't need
to care about whether to anchor particles to the top or bottom of a
rectangle area. Instead you would configure this on the emitter object
before passing it to the particle system.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant