Platform Layer Elements

...but one could if this experiment works.

In the effort underway to create a reliable, flexible, easy-to-use platform framework, my associate Patrick and I have identified three essential cores:  At a minimum, platform support must include input handling, graphics, and audio.

Input Handling

Handling input devices will be fairly straightforward.  Key presses are common across both platforms, and Android's touch input works in much the same way as a normal computer mouse.

I believe the only feature that cannot be explicitly supported in a platform-independent fashion is multitouch, but since the Ouya doesn't support it either, this really isn't a problem.  Most likely, I'll implement support for multitouch and just throw an exception if it's invoked from a non-Android app.

Like the current version of MHFramework, I intend to implement the input handlers to support polling as well as registering event listeners.

Graphics

Without a doubt, the graphics will be the most challenging part of this layer.  I will try to explain the problem.

In Java SE (and therefore in the current version of MHFramework), rendering to the screen is accomplished via the Graphics object.  The Graphics class interacts with Font, Paint, Color, and other classes to perform a variety of tasks, but Graphics and its Graphics2D subclass are at the heart of it all.

In Android, the equivalents are not absolute.  Rendering is accomplished via a Canvas, which also contains several other methods that resemble Java SE's Graphics methods.  However, the Android Paint class takes over some of these responsibilities, as well as the responsibilities of the Color and Font classes.  In essence, there is no way to do a straight one-to-one mapping between these classes.

So, to solve this problem, we will need to address the question of granularity.  Should we attempt to generalize the canvas/graphics object and the paint/color object?  Or should we opt for a much coarser grain and consolidate it into one large rendering class?  Would this lack of cohesion outweigh the overall simplicity and relative ease of use?  Since there is already such heavy coupling between the graphics-related classes, it is my opinion that we should consolidate these things into two separate classes -- one for Java SE and one for Android -- with a common interface to both.

This decision is far from finalized at this point.  I intend to prototype it and see how it goes.

Audio

The audio interface should be remarkably easy.  From what I can tell, the interface to the Android system is nearly identical to the one in the current version of MHFramework.  This should require little more than straightforward delegation to existing implementations.

---

TL;DR: For starters, we'll need to support input, graphics, and audio. Input and audio should be easy. Graphics could prove challenging.

---