Platform-Aware Controls

edited February 2013 in Enyo 2
In reaction to another thread, I took a first cut at a pattern for creating platform-aware controls leveraging the existing enyo theme framework.

The idea is to define a set of controls that each provide the same capability across platforms but are implemented or styled differently. The tab control seems to be a good example which is functionally similar but has unique behavior on each platform. To accomplish this, we'd define a base kind for each capability (Header, FooterToolbar, TabControl, etc...) under the pac.* namespace that would establish the common interface for all platform-specific implementations. Another set of controls (e.g. pac.webos.*) would be defined for each platform, inheriting from the appropriate base kind, which would adapt the interface for the particular platform.

The secret sauce is pac.registerTheme (maybe registerPlatform instead?) which ensures that only the control set relevant for the active platform is ultimately registered as a theme. The app code can then use the generic base name (e.g. "Header") instead of the pac or platform name (e.g. "pac.webos.Header") which would get resolved to the right kind by the enyo theme framework. There's a little more magic hiding in it but i'll leave it at that for now.

Take a look at the fiddle below and let me know what you think. Good idea? Gaping holes? TL;DR?

http://jsfiddle.net/ryanjduffy/4bv3V/7/

Comments

  • This would be awesome!
  • Wicked Awesome! However sometimes you might not be able to achieve a perfect Implementation of a native control and the control looking different might be useful(to prevent user confusion) - ref

    P.S. Nice Commodore 64 joke there!
  • completely agree. the intent is to accelerate the 80% so you're not stuck with if/else blocks to boilerplate the app. each platform will likely have unique interaction patterns that can't be abstracted into a common interface and you'll have to decide if you want to pick a particular implementation or use a generic one. You could also decide to always use a particular platform's implementation in all cases by referencing the kind directly rather than through the theme framework.
  • When I initially gave a little thought to the issue my leaning was something similar - either a plugin system or some way to abstract and package platform specific functionality, and this fits the bill. Any plans to start a repository for the effort?
  • potentially. I'd need some interest from the community to get it going as I don't have the time or devices to build the control library for each platform.
Sign In or Register to comment.