VFP and tablet applications

[Mike Lewis]

In another thread (thread184-1723532), AlistairP described a problem he had with a VFP application running on tablet computers. That thread raises some interesting points that could affect all of us.

Alastair's asset tracking application is probably not very different from the sort of commercial data-drive applications that most of us spend our lives developing. Tablets are clearly an important platform. But most tablets today - including those running Windows 8.x - are designed mainly for the consumer market: for people who want to browse their photo collections, listen to music, make Skype calls, access Facebook pages, and the like. What's it like using these devices for running high-volume data-intensive applications - the sort of applications that VFP is designed for? The thread I mentioned refers to a particular problem with event-handling. It seems to me that many of us might face that same problem.

Alastair says that the solution to his problem is partly to re-train the users. Is this something we will all have to do? Or will we have to design our apps in a completely different way to cater for the specific design features of this new hardware?

It would be interesting to hear your views on this.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

I followed and participated in the mentioned thread, so far it seems there is no technical effect with the touch interface comparable to keyboard bouncing, but users used to a better response time at a PC are simply impatient. I still would like Alistair to report, if the indexing is proper. You can't simply see that from the table and check, if all fields are indexed, you have to check all application queries, both join and where clauses, to see if optimizable expressions are used. Single field indexes might not help with many queries, you can index on further expressions, or change the expressions to be able to make use of the simple single field indexes.

I warned SSDs might not be good at data access, you have to look at random access performance more than anything else. It's true that any SSD has randam access times of 0.1 ms, compared to 10-12 ms of normal HDD, but still the charts for SSDs differ, if you look at best random access of 4K blocks than if you look for continuous read, see

http://www.tomshardware.com/charts/ssd-charts-2013/AS-SSD-4K-Q64-Random-Read,2786.html

vs

http://www.tomshardware.com/charts/ssd-charts-2013/AS-SSD-Sequential-Read,2782.html.

There are totally different "best" drives, looking from these perspectives. The problem is, you don't have the control and can't simply replace the drives installed in devices, you have to live with what manufacturers put in there.

Besides that, an ATOM CPU is not the ideal CPU for the windows desktop, and VFP runs on nothing but the desktop part of Windows, of course. Tablet devices are, as Alistair also says, optimized for battery life, not for performance. You might do something with the energy settings. You can typically charge more often, especially you of course don't need the longest running time per charge, if you can get your work done faster anyway, which of course saves more money, too. One thing I did with my Nexus is turned the display brightness to manual and turned it down to 10%. It's the most energy consuming part of any tablet.

Overall, todays market of tablets gets more and more interesting for VFP application usage, as you get a full windows running on such devices. Still there are smartphones "only" supporting the WinRT and needing different programming. Seeing that from the perspective of the VFP developer you would of course advocate Windows devices like the surface pro.

Bye, Olaf.

 

[Olaf Doschke]

One more important thing about SSD speed I learned from bad experience: Don't just trust the manufacturer tech specs or tests, the speed also varies with the controller used, and AMD SATA controllers play bad with Samsung 840 drives, for example.

Bye, Olaf.

 

[mplaza]

The main problem with mobile clients is about connection and state management. Apps should be prepared to manage slow/unreliable connections and connected/disconnected states. The only way to solve this is by implementing MVC with asynchronous data management, and that relies on multitheading.
You can't have a responsive application when you have it locked down downloading data by a 3g connection, or while in a retry/connect loop.

Be it a desktop or mobile solution, today the MVC/Multithreading route is the one to take.

Marco

 

[Mike Lewis]

Olaf and Marco, thanks for those helpful and interesting comments.

For me, one the concerns with VFP-type apps on tablets - and especially with touch screens - is the user interface. As far as I can see, we lose certain useful events, such as right clicks and mouse hovers (or is there a way of simulating these?). And then there's the question of data-entry with on-screen keyboards. Clearly, there'll be many applications where those issues don't matter, but they are real concerns for the traditional type of apps that most of us develop.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[DSummZZZ]

I could see long click replacing right click, but I think mouse hover is something a tablet can't emulate.
Well, unless maybe it becomes doable with a technology similar to what Samsung says it can do with hand motions in front of the screen rather than actual contact with the screen.



-Dave Summers-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm

 

[Olaf Doschke]

UI is a topic well worth own discussions.

I wouldn't miss hovering. Surely the context help (tool tips) and context menu have to be solved different, if the app should be usable by touch. You can of course also use an application in desktop mode with a bluetooth keyboard/mouse. But that's not the normal tablet usage.

Something a colleague does anyway, also on desktops, is putting context buttons anywhere it matters. Small buttons, which replace a right click and/orhovering in showing a popup menu or form with further options and/or tip texts. Because even on the desktop the right click usage is not as well known as the left click.

Bye, Olaf.

 

[craigber]

mplaza: MVC is not the only solution. You could implement client-side caching. If you do this with MSMQ and the update to the server is automatic.

Mike: One issue I see with Alistair's thread is the tablets use Atom processors. I think some of the newer tablets that use the new Intel chips perform better, but have shorter battery life.

Craig Berntson
MCSD, Visual C# MVP,

http://www.craigberntson.com/blog

 

[Olaf Doschke]

I second craig in regard of MVC, I would even go further and say it's wrong here. You rather talk of n tier architecture, no matter if MVC or anything else. The main problem to solve is not the separate implementation of application layers, but the to be expected disconnection. There are many things to solve that, even in VFP in a 2 tier approach with offline views. The main thing to do is to store data local and MVC is no pattern doing that per se4, by design or as default, nor any other 3 tier architecture does so, that is a very specific design.

Bye, Olaf.

 

[mplaza]

Craig: You can use MSQM , but to do so we need a n-tier vfp app using com+ objects, and you'll need to setup and manage component registration, rights, dll versioning etc. Distributed apps can be a pain to mantain and configure. Simple multithreaded data access components are easier to deploy, mantain and debug.

Olaf: You're right, MVC does not mean "all data will be fetched/uploaded asynchronously", but we don't conceive an MVC app that does not use AJAX by design. Maybe I let slip MVC because it implies separation of concerns, practices that makes not only multithreading easier to implement but also to test. Microsoft set the path long time ago ( check "\Microsoft Visual FoxPro 9\Samples\WebServices\Northwind\readme2.jpg" ) and suggested using vfp as an excellent middle tier component development tool to interact with .net. The main principle I suggest is 1) stop connecting directly to sql server over the web, instead use a web service, and 2) use the msxmlhttp component to post/get data in a separate thread by implementing any of the tools I mentioned earlier.



Marco

 

[Olaf Doschke]

Msxmlhttp is an AJAX solution you can use within VFP, right, it's the same base class used in web browsers. Think about a CRUD approach (create/read/update/delete) you can for example use the ODATA way of http requests on the data. It doesn't discharge you from handling http POST or PUT, MERGE or DELETE requests failing, not reaching the server. Be it missing WLAN, no internet connection or whatever reasons, you need to decide whether your app stops working in such scenarios or you store things in a local database, eg SQLite as proposed Local Store in HTML5. This is why craig refers to MSMQ, you can use the message queue, whether you're online or offline, messages will be sent, once a connection is possible again.

And that has less to do with MVC nor AJAX nor the stateless nature of web apps, it has to do with the concern of permanent or long time disconnections, no matter if by error or intended (eg to save money some people only use WLAN connections and no expensive LTE, UMTS or other connections. You can of course always decide your app makes no sense without a connection, eg a search engine can only return results online, an order can only be placed with a connection etc. But there might be cases you can use an app offline, eg write posts offline, then post them, when online again. Or enter inventory counts, then store them when back in the office.

Always On is a topic, but more so with smartphones than with tablets. And that kind of disconnections has other concerns than the isolation you have between client and server also with a stable connection. Even with a stable internet connection you make requests and get back results, you don't have permanent file handles on a http page or xml or json, like you have to DBFs, you don't SKIP and then are at the next record, you SELECT * From table WHERE .... to fetch the next record or page of records, then turn that to xml or json and get it at the client side, put this into a html table, as a simple example. But you can't do even that with no connection for minutes or hours, instead you use MSMQ (not MSQM) or local SQLite or even DBFs or an SQL Server, if you're on a win8 pro surface you have a full blown windows and can work on all these things as well. You just need some additional syncing logic from local DBFs to central DBFs or a central SQL Server. And then you can skip all this web stuff, you can work as you are used to on a desktop, just with your own private per user local database. The only additional task is to sync data.

Bye, Olaf.