LiveCode Forums.

Hi Klaus,

I did not know that bug report address.

Tried it and we will see what happens.

thanks for the hint.

regards

Bend

I have a few questions about iOS SQLite support: 1.) Can you access SQLite on iPad/iPhone creating tables and querying data? 2.) Can you access an external SQL Server database over Wi-Fi from one's iPhone/iPad from a LiveCode solution?

Thanks

Hi shackman,

externals, and database access is done via externals in LiveCode, are not yet supported in
LC mobile for iOS, so the answer to both of your questions is: Not (yet)


Best

Klaus

Is RunRev planning on a future update that will support access to external databases over Wi-Fi and the internal SQLite database on the iPad using iOS version? Any rumors or statements to that effect. Our projects would require this fairly soon.

Thanks,

Gary

Hi Gary,

yep, externals have high priority according to Mr. Miller, CEO of RunRev.
But since I am just a "user" I cannot tell you any timeframe.


Best

Klaus

First quarter next year at the latest. Really as soon as we can. "Off the record" January is the goal internally (but as ever could be subject to change depending on how the schedule goes).

Just to add to this - there are other ways to access remove databases that don't rely on externals/revdb. You can use HTTP and HTTP post to access data through a web service, for example and that is something you can do now without waiting for the database support.

Thanks for the information Kevin! Greatly appreciated.

Gary

Since it seemed like we had pretty much reached a dead end here on the forum, I had sent an email to Runtime Revolution support regarding the problems of saving a data stack with a launcher stack and running in the iOS. I'm not sure if a "bug report" was done by anyone else???

I have still not been able to make the "launcher" method work (which is also called the "splash" method), but thought I would post the Runtime Revolutions support response here, in case it might be helpful to others working on the same problem. I am not sure that this is all just theoretical or if anyone has actually ever been able to get a launcher method to actually work on the iOS as I was not pointed to any example stacks that worked by Runtime Revolutions support or anyone else on the forum.

For anyone reading this thread for the first time and trying to get a modifiable database app to work in the iOS where you can add records and modify fields, this is where things stand at this time on Dec 21st, 2010: I had previously been able to save the database stack as a custom property in the launcher stack with help from Klaus' instructions and then Bernd's uploaded stacks to this forum, but was still unable to save any changes made to the database stack once it was saved into the iOS. Bernd had posted his stacks but they were read only and Klaus had suggested a "bug report" to Runtime Revolution. I provided links to Bernd's stacks to Runtime Revolution support in my correspondence to them.

I have continued to use Bernd's uploaded stacks, named "standalone" for the launcher stack and "database" as the stack I want to be able to modify. (I see in the forum that 6 others have downloaded the database file, and the standalone has been downloaded 11 times as of today, so please post if you have been able to make them writable). IF there is a "bug," Runtime Revolution is not acknowledging it to me.

This was the response I received from Jacqueline of Runtime Revolution support:

"You can still do this. Store your DB stack as a custom property and write it to
disk when your iApp is opened. Note that there are strict restrictions on the
folders that an iApp can write to. Apple enforces a sandbox that all apps must
stay within. See the iOS documentation for a description of allowable folders and
which you have permissions to write to."

I wasn't exactly sure to which specific "iOS documentation" Jacqueline was referring to, but I looked again at "How do I read/write to files on the iPhone?" at http://lessons.runrev.com/spaces/lesson ... he-iPhone- and I focused on the following:

"The iPhoneOS imposes strict controls over what you can and cannot access. Each application in iPhoneOS is stored in its own 'sandbox' folder (referred to as the home folder. An application is free to read and write files within this folder and its descendants, but is not allowed to access anything outside of this.
When an application is installed on a phone (or in the simulator) a number of initial folders are created for use by the application. You can locate the paths to these folders using the specialFolderPath() function.

home – the (unique) folder containing the application bundle and its associated data and folders.

documents – the folder in which the application should store any document data (this folder is backed up by iTunes on sync)

cache – the folder in which the application should store any transient data that needs to be preserved between launches (this folder is not backed up by iTunes on sync)

temporary – the folder in which the application should store any temporary data that is not needed between launches (this folder is not backed up by iTunes on sync)

engine – the folder containing the built standalone engine (i.e. the bundle). This is useful for constructing paths to resources that have been copied into the bundle at build time."

Bernd had a button with the following script and am wondering if instead of "on mouseup," (according to what Jacqueline is saying), it should be "on OpenStack??"

on mouseUp
put (specialFolderPath("Documents") & "/database.rev") into tPathToDatabase
put the cDatabaseStack of this stack into url(specialfolderpath("Documents") & "/database.rev")
go stack specialfolderpath("Documents") & ("/database.rev")
close stack "standalone"
end mouseUp

This then opens the database stack that has the stack script:

on closeStack
save this stack
end closeStack

Still, it is read only, though.

Of course, these "paths" are all still about as clear as mud to me. I keep playing with script variations of what Bernd and Klaus provided.

I would be very interested if anyone else is actually able to get a launcher stack method to work in the iOS as it supposedly should in theory. I am becoming a sceptic, though. I think this would be a pretty common expectation and need for those developing for either the iPhone or iPad environments and am sure there must be others out there trying to get this to work. In "theory" it should work, but so far, there is no indication that anyone has actually made it work in practicality. If it is so simple, as some seem to imply, I am just wondering why no one can actually show an example that works? I thank Bernd for his examples even if they were just read only but you would think if others could make it read/write as Jacqueline and others suggest, that there would be some example of it somewhere?? Maybe that many people haven't downloaded the iOS version of LiveCode?? I know it is fairly new but it seems like a lot of people would want to use it because it does seem like it should be easier than the Apple SDK- -- in theory anyway- I know for me, the prospect of creating a database app on an iPhone as simply as creating a Hypercard stack was pretty exciting. It still would be if I could just get past this roadblock- and I think this problem would be a roadblock for a lot of others as well. Frustrating.

I just want to add, that although I am a "newbie" to Revolution Runtime LiveCode, I am not a total newbie to scripting or databases. I did pretty well with Hypercard years ago and was able to easily accomplish exactly what I am trying to accomplish in Livecode, (although admittedly it was not cross platform and it was many years ago). I have used Filemaker at various times through the years and I have also used 4D extensively over the years. I have been able to overcome what were perceived as roadblocks in the past, and I am hoping, that eventually, I will be able to overcome this one in Runtime Revolution's LiveCode.

Thanks for any feedback anyone has, especially if you can actually upload an example stack of a launcher method with database that I can download and study that actually works in the iOS simulator!

Hi sylvanr,

actually I got beyond the "read only" stage if I leave out (comment out) in the window of this stack. Just go stack xyz. In your/our case database.
Then you are actually able to write into the fields etc.
That is the good news

The bad new is:
I dont get it to save the changes to the stack.
I tried on closestack and on shutdownrequest. No go. I did not try very long though. It still might be possible to save the stack which would solve a lot of problems right there.
So one step closer but still not there.

Kind regards
Bernd

Hi Sylvan,

a little progress report:

If I make a button to save the database stack then it saves, but not always. Still trying to figure out why not always. I have to push the save button twice to get it to save. (All this in the simulator) Might have to do with the focus, not shure. Or a timing problem. Who knows. Further studies are needed...

But basically the stack is savable in the documents folder.

Kind regards

Bernd

Bernd, going back to your original stacks that you uploaded. The "goDatabase" button has the following script, correct?:

on mouseUp
put (specialFolderPath("Documents") & "/database.rev") into tPathToDatabase
if there is not a file tPathToDatabase then
put the cDatabaseStack of this stack into url ("binfile:" & specialfolderpath("Documents") & "/database.rev")
go stack tPathToDatabase in window of this stack
else
gostack tPathToDatabase in window of this stack
end if
end mouseUp

When I click on this, it does take me to the database stack and the keyboard pops up, but then everything seems locked. It does not allow any modifications. When I played with it, and used some of the lines of script found elsewhere, I could get it to go to the database stack and the keyboard popped up but it was not locked and I could modify the text. I couldn't get that far with the "binfile" but maybe that is critical to saving data?? This is the script I used:

on mouseUp
put (specialFolderPath("Documents") & "/database.rev") into tPathToDatabase
put the cDatabaseStack of this stack into url(specialfolderpath("Documents") & "/database.rev")
go stack specialfolderpath("Documents") & ("/database.rev")
close stack "standalone"
end mouseUp

I also added a button with the script:

on mouseUp
save this stack
end mouseUp

Still nothing gets saved though but I am able to open the database stack and make modifications in one of the fields. I'm also not sure if a path is needed with that "save this stack?" Again, I'm just stumbling along in the dark.

Well as Santa never arrived in this thread...

I don't think it is possible to do what you want on the iOS device due to Apple 's sandboxing limitations. If you where allowed to save stacks in the Documents folder (which you can do) and then modify that stack and save it again you would in fact be able to alter the code of your running application, which is not allowed in the current version of the developer license agreement. This has nothing to do with LiveCode! I guess there is an Apple enforced limitation that you can't open stacks from places where you are allowed to save files! So you have to take another approach for the iOS platform.

If your data is small you can add all of your data to an array and then save that array to a "document". (Check arrayEncode and arrayDecode in the dictionary)

If you have a larger dataset I guess you will have to implement a save for each "card", as the iOS devices are very limited in RAM. You can still collect all data across the card in an array and save the array to a file. My suggestion would be to create a subfolder for every "document" and save the individual card data to one file.

I have successfully tested the first approach and the second shouldn't be much harder to implement...

I received a response from Jacqueline at RunRev Livecode support saying that she was going to talk to one of the engineers about the problem when they return after the holidays. It is still her understanding that saving stacks should work as long as they are located in of the approved sandbox folders (Documents, in this case). There may be a bug with that or something else that needs to be done to enable it. She says that she will find out but the engineers won't return from the holiday until Jan 4th. Hopefully, we will have a definitive answer after that.