In the time since it's come a long way--due to the work of a few very smart people.
I haven't done a lot with PhoneGap/Cordova for a while nor talked/blogged about it. Fortunately those other people have.
There is, however, something that many people still seem confused about and I'd like to try and clear it up now. The confusion is that the impression that the architecture diagram of a multi-platform PG/C app should look something like this.
The assumption is that because the UI for each version of the app will be written in HTML, CSS & JavaScript they should all be the same.
THIS IS WRONG!
That was never the intention.
For each version of the app that is built, it should have a UI that is appropriate to and targets the platform it will run on. The above diagram should actually look something like this.
PG/C allows you to create native apps with "web" technologies. It doesn't mean you should create an app that looks the same on each platform.
If you're building apps with PG/C then please keep this in mind.
What about the idea that the UI layer differences can hopefully be handled as part of the development environment with libraries such as Kendo or better versions of jQuery Mobile etc, so the underlying UI code can be portable.
ReplyDeleteShouldn't the fact of whether the toolbar is on the top or the bottom, and what theme the widget set is, be easily handled by an abstraction which allows you to work on a single UI codebase which describes behaviour?
@Mark You raise an interesting point. By using something like JQM you can go some way to creating a single code base with a UI that adapts to the device it is on.
ReplyDeleteHowever, this will only go so far and is probably only suitable for simpler apps on a small number of platforms.
As the complexity of an application grows it's more likley (I feel) that you'll start touching on those areas where there are more subtle differences between platforms, and which aren't catered for by such tools and you risk dipping into the uncanny valley.
As you start targetting more platforms the differences between those platforms are also likley to grow to such a point that you may not want to do the same thing on every page or in the same way.
The cannonical example would be the difference between "tablets" and "phones" where the difference in available screen real estate mean you'll probably want to have different pages/views which structure the application in different ways. There are also differences in conventions across some platforms where some will use an "edit-in-place" convention where another will use a separate page.
I'm not putting down a single adaptive UI through a tool. It's fine for simple apps but will never handle all cases and as the complexity of the application and the number of target platforms grows it will become near impossible to recreate a native experience to the point it's indistinguishable.