Add class TantalumRuntime about tantalum HOT 5 CLOSED

Extension does feel a big heavy/distasteful. Your earlier suggestion moving away from this lead to the chain() metaphor that is a big step forward in easy augmentation of existing Tasks with a result somewhat like the various JavaScript chaining libraries or ObjectiveC's odd object model.

In this case I rather like it like it is. TantalumMIDlet is just a convenience class. You don't need to use it. There are arguments for alternate convenience class structures, but exending MIDlet is the only way to guarantee we hook into all MIDlet lifecycle events. If we did not extend MIDlet, we rely on the skill and knowledge of the developer to know how to hook in and trigger an orderly shutdown including running shutdown tasks under the various circumstances such as (1) application decides to close, (2) user keypress or other event means the phone decides to close the midlet.

Expert developers can easily make an app without Tantalum MIDlet. Many novices (including me) probably benefit from the hooks we include in this helper class.

Would you be happier with TantalumRuntime as a cross-platform helper class AND TantalumMIDlet as one abstract implementation that calls TantalumRuntime?

from tantalum.

I'm a fan of "TIOOWTDY" (there is only one way to do it), and there is a definite need for a cross platform TantalumRuntime class. However, if you think TantalumMIDlet still delivers value...

Let's go with TantalumRuntime as the cross platform helper class, and TantalumMIDlet as the "convenience" base class (with the provision that TantalumMIDlet would never do anything beynd initializing TantalumRuntime, so that devs using just TantalumRuntime would never "miss out" on features they would get when using TantalumMIDlet).

from tantalum.

Agreed, I'll do surgery to put that in place. TantalumMIDlet pre-made hooks to app event changes will still be there to help but it is easier to do without. It also elegantly addresses my concern that TantalumActvity isn't always the right lifecycle on Android.

TIOOWTDY is a nice principle too, less options often means simpler and more reliable, a minimized design. Staying there as requirements evolve means periodic seismic design shifts to a new, happier place. I resist any structure (artificial backward compatibility, etc) that makes that rapid, independent evolution possible.

from tantalum.

Code was changed and startup simplified to make TantalumMIDlet and TantalumActivity optional. With a few more tweaks we can eliminate these two classes and instead use a template approach where two lines of code (startup, shutdown hooks) are all that is needed. This will make augmenting existing apps with Tantalum more accessible- encourages toe-first experimentation.

Still a couple changes to complete this

from tantalum.

TantalumMIDlet and TantalumActivity have been factored out.

Now just add one line of code near app start, and one when app closes. It feels like heavy than before, not a "framework" just some tools you can experiment with and use as needed.

from tantalum.