I’ve been using DHTMLX Touch for a few months now and really like it. My next project is a site that needs to run similarly on desktop, tablet, and smartphone. Naturally I want to use Touch. I generally develop on a desktop and everything in Touch works well, except any Control that needs to scroll, like a Grid. You have to emulate swiping with drag and drop.
What do you recommend as the best way to develop a cross device page?
If I were to use something like the DHTMLX Calendar in my page, how well does that respond to touch devices? I’m assuming taps are the same as clicks. And how well does it co-exist with DHTMLX Touch?
The best approach would be to use dhtmlxSuite (desktop components) for desktop version and dhtmlxTouch for tablet and smartphone.
But if you need to choose only one package (dhtmlxSuite or dhtmlxTouch) for both versions, we would probably recommend to use dhtmlxSuite. dhtmlxTouch was not designed to work on desktop, so there can be issues with desktop scrolling.
If I were to use something like the DHTMLX Calendar in my page, how well does that respond to touch devices?
Did you mean dhtmlxScheduler ? The latest Scheduler version can be used on touch devices. Also there is mobile version of Scheduler. In my opinion it would be better for smartphones than desktop scheduler that was designed for bigger screens.
And how well does it co-exist with DHTMLX Touch?
If Touch is used on a page, it sets event listeners that can block event listening for other libraries. However, there is a mode that allows to limit event listening and handle only Touch components and elements created inside them:
docs.dhtmlx.com/touch/doku.php?i … ouch_limit
My only concern with using Touch for one and Suite for another is maintaining two versions. I haven’t used the Suite but it looks like it doesn’t use the same method to generate the page as Touch does. My logic/js could work for both, but events, hooks to my functions, etc would be different.
Have you any thoughts on responsive web design? With Touch we would draw pages based on initial size then monitor the page size and redraw if changed. With Suite I’m guessing it fits in better with having the css reformat the page using media queries.
Too many choices and decisions!
Our desktop library allows to create full-screen UI. However, it does not listen to orientationchange event. So, you will need to call resize methods for layout manually. Also desktop layout does not provide such property like gravity ( sets row/column proportions), that is supported in Touch layout.
Hi, I also develop an application for desktop and mobile devices. Because the environments are so different, I have found that to achieve the best possible results, it requires the use of 2 products.
Separating the code makes it possible to build highly customized UIs, which to me is more important than maintaining a single code base.
On the back-end, each code base has a handler for accepting data changes and they forward the request to a master program-api which touches the database and returns a status code to the handler. I do this many times for each logical module.
This provides the most flexibility allowing the desktop and mobile UIs to adapt as needed while at the same time minimizing the back-end code.