Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chris Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

VFP to HTML forms and back again - mobile development

Status
Not open for further replies.

KarenLloyd

Programmer
Nov 23, 2005
141
GB
Hi Gurus

I need some direction - can you advise me please?

First, I apologise if much of this thread relates to HTML, but it starts and ends in VFP 6.0

I need to create the processes for completing forms created with HTML and submitting the data via email, where it can be processed into a VFP application. This needs to do the following:

1) Send data from VFP to a mobile device and serve this in an HTML form
2) Allow forms to be prepopulated with the data or opened as new, empty forms
3) Allow form data to be saved locally when a device is offline
4) Allow a saved form to be re-opened, repopulated and updated, until complete
5) Send submitted forms via email, for extraction and processing back into VFP
6) It must also be possible to review and update the forms from a PC, laptop or mobile device. The mobile device has not been decided yet, but it is safe to say that it may not be a Windows product.

The first problem is that I cannot use a URL to pre-fill a form as the text descriptions may be too long in some cases.

So I thought of using the FileSystemObject to control HTML files within local folders, writing out a new filename.htm (from a template) with the appropriate form values coded into the HTML body. Then the htm file could not only be saved locally, but also sent via email and downloaded to the folder on a different device as well.

But now I don't know whether this is a workable solution. The file management instructions will vary depending on the device/platform, it may be Android (it won't be Apple). There are also potential problems with storing files locally on a device, or devices removing files to recover storage.

It seems that I am constantly finding out how not to do this job. I could write this kind of dynamic html file processing with VFP, but VFP will not work on a mobile device, which then brings me back to using SQL with a database of some form. So I have sort of come full circle, and am not sure how to proceed as I can not rely on using HTML and JavaScript for the offline form handling.

I don't know which way to go next - Active Visual FoxPro has been suggested in previous threads, and I think that will let me use a combination of VFP coding and HTML. So should I abandon the idea of saving client-side HTML files and dive into Active VFP, and all that is involved...? Does anyone have experience of creating a similar application previously, or do you have any other suggestions for me please?

Thanks in advance

Kind regards

Karen
 
I think your fixation on HTML is misplaced. You actually have several different requirements. You need to separate them in your own mind.

HTML is not a data storage tool. HTML is not a data transmission tool. HTML is not a data entry tool (although it is often used for that). HTML is not a lot of things. HTML is a document structure tool.

You're dealing in data, not documents, I think.

You need a data repository. That could be VFP or it could be SQL Server or any other database. This certainly isn't a new requirement.

Then you need a way to communicate data into and out of that repository. That could be a web service, and AFP is one of dozens of technologies that could construct that. Once you've engineered the storage mechanism and the I/O to get data in and out, then you can consider how you want to display the data wherever it needs to be displayed.

Don't start with HTML as the goal. You might use it along the way. You might even display HTML in a VFP application using the web browser control. But don't make the mistake of looking for an all-HTML solution to a data handling job.
 
Thanks danfreeman for your reply.

The only reason that I seem focused on the HTML first is because we have generated complex forms for the customer using SpreadsheetConverter software.

I need to take ten steps back and work this out based on a tiny data set, imagining that its for me and not the customer, and just see whether how I can send data, download into a local file, work on it offline, save it and then send via email or FTP (or however) later on when there is a connection.

My questions are really how to do this on the client side in an app offline - whether I can do this by generating and maintaining single HTML page files such as item1.htm, item2.htm etc in a local folder and then submit and archive/remove daily, or whether I need to do this via a client side database.

And then whether I can do this with a combination of VFP and web coding with something such as ActiveVFP, or if I try to do the whole mobile side of the development with HTML, CSS, JavaScript and SQL.

As you can see - I am a bit out of my depth (so perhaps I should outsource the work - and then not wake up at 3am thinking about work!)

Thanks

Karen
 
Karen,

I can't add much to this discussion. But re your first requirement: Send data from VFP to a mobile device .....

A lot depends on what kind of mobile device we are talking about. Or, more specifically, what development / database tools it supports. For example, if the device was an Intel-based Windows 8 tablet, it might support VFP, which makes the whole thing a lot easier. On the other hand, if it was an iPad, you would be restricted to the Apple development world, which is much more restrictive (at least, I would consider it so).

One common denominator that virtually all devices support is HTML (and usually CSS and Javascript). So for that reason, you might be right in focusing on HTML. The problem is that neither HTML, nor CSS, nor Javascript can help you with local storage. For that, you will need some sort of programming tool or database on the device. And, if you need to support multiple device types (iPad and Windows 8, for instance), you will have to find a tool that is supported on those devices.

This probably doesn't help you very much, but it is something to keep in mind.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy
 
Karen,

I can feel your pain. You really have to have a different mind set for web application, no matter if for mobile devices or not. In a web application scneario, you have data & code at a webserver, putting data inside a HTML element in form element vlaues, there is no such thing as a cursor in the browser, you send over a html form element with a set of input text elements, preset to current records values. The user can then modify data, hit submit and send over all the form data back to some script receiving it as array, for example, in PHP, which I know best.

So actually it's like working with a form, that you dynamically create with a number of controls and fill the values, like you could do with a VFP textbox.value unbound, not using the Controlsource. And then in a save button collect all the values of all textboxes, stuff them into an array and pass that on to some script then puzzling that array elements back into the table.

Pretty uncomfortable.

This is different, if you do ASP.NET, but in the end the browser page and the database are really disconnected, no matter what technology you use, several frameworks and libraries just can make it seem, like there was a binding as you know it from destop form controls. ActiveVFP is not different in that matter, but at least the progamming language is known, then.

Instead of a main.prg entry point starting once, then running, until the user ends the application, you have scripts that always start from scratch with each single step a user makes when requesting a form and sending back some form values. There is a web technique called AJAX, which enables a browser to not need to render a whole page new, but only send some data and receive an answer and then process that and incorporate it into an already loaded HTML form, so you can work like in an interactive desktop or VFP form, as you know it. But that's already quite advanced, before you go there, you have to learn HTML form and how they work.

Bye, Olaf.
 
Hi Mike / Hi Olaf

Thank you for getting back to me. This is a tough one.

I know enough HTML, CSS and JavaScript to display a form on the mobile device.

It is the storage and the data updates to the device that are the problems for me.

I will see what I can find out for ActiveVFP before making a decision.

Thank you

Regards

Karen



 
OK - ActiveVFP is not really what I need at this time, as the mobile application needs to work offline.

I have to look to HTML5, JavaScript and SQL for the mobile side... Should be fun! =D

 
>It is the storage and the data updates to the device that are the problems for me.
Okay, but there'S not much a browser is allowed to do with the rendered HTML. If you don't automate a browser on the mobile device, which I think would also only be possible with Internet Explorer, via Javascript you don't have any file system connection, do you? So your whole local storage in this kind of apps is the current browser session. It would differ, if you embed this HTML solution into an APP, but then you'd either need to add native programming for iOS, Android and Win8 RT (and some more), or use something like PhoneGap for that matter.

If you aim for a browser only solution, I think the current browser session is about the end. Cookies are specified as max 4kb and a browser needs to accept 20 per domain, if the user allows it and doesn't restrict this via security settings, so this is no good data storage. There are some more specifications in HTML5 for local storage of data, but you depend very much on the used browser, if and how this works.

What I found is, Javascript in the HTML5 specification allows you to store simple key/value pairs via localStorage.setItem("key", "value"); and localStorage.getItem("key") to get them and localStorage.removeItem("key"); to delete that item. Then localStorage.clear(); to clear all local store values for your domain. The value might be XML from single values to records to whole tables, but it doesn't really compare to the comfort of SQL, does it?

I think the more usual solution is not to store anything on th mobile device, it's mobile, it's connected, your storage is on the webserver side, nowhere else.

Bye, Olaf.



 
Hi Olaf

Thank you for the additional information. The problem is that the mobile devices will not always be online, due to location / reception - there may not always be an Internet connection. The forms need to be completed and the data stored locally, and then submitted via the Internet when a connection is available. It won't be a huge amount of data, but it has to be stored on the device.

Originally the intention was for the forms to be handled via the Internet, sending the data by email, which would not have posed such problems. (But a change of requirements calls for a change of specification plus increased work and headache)

I read that I can make use of the Cache Manifest for the static HTML forms and may be able to manage some small client-side database with SQLite, so I am going to do some tests there first.

Of course, if the devices were Windows I would not have to go off in this direction at all... I like a challenge, but not of this magnitude.

Kind regards

Karen
 
I found this article this morning: Create offline Web applications on mobile devices with HTML5...


...with sample application in - OfflineWebAppSrc.zip

So I uploaded the test pages to my web space and accessed them from my iphone using Safari. I then switched on Airplane mode to take the service offline and updated the table - now stored locally on my phone.

When I go back online, the table is still opened from the phone, which is what I want.

There is more information available at
The database support also works with Chrome.

I now need to find out what I can do using SQLite and what the limitations are, before I can go any further.

I know that this additional information is all web related and not VFP, but I thought I should add this info to the thread in case anyone might find it useful later.

Thank you again for your support.

Best wishes

Karen
 
Karen

As Olaf mentioned , one of the great NEW features of HTML5 is local storage. This allows you to store 10mb of data,locally on the browser, which you can use for the kind of situation you are describing. There is no "data-base" as such , but you could use XML to serialise your local data back and forth from your browser to your connected ( or disconnected ) data-base. I dont think any of the VFP interfaces like Active VFP etc would be a good choice here , dotNet really shines when it comes to XML , linking between javascript/code-behind etc , so in efect you have an " XML data-base"

and so the stack I would suggest is

ASP MVC , jQuery mobile , HTML5 for the front-end
HTML5 local storage and XML as the temporary off-line data-base
SQLITE , SQLSERVER as the back-end , does not matter

and this approach of course is totally web-based , cross-browser , cross OS system etc

it's a very steep learning curve though , so might be best to just put some kind of tender for requirements together, along these concept lines , and send it out for competent suppliers to offer proposals

sean m
 
Hi Sean.

You are right, there is so much to it and it would be crazy to try to do it all myself.

Proving the next set of tests go well, I will list of the aspects involved and look for some assistance.

I appreciate your input, thank you.

Karen

 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top