It will be. Because they have to have my desktop app in order to use the iOS app.
[quote=477176:@Jon Ogden]I am not going to try to explain or defend what I am doing because you have a mindset based on over-complication of things.
Suffice to say a sever approach would be so wrong for what I am doing.[/quote]
At the end of the day you are of course free to ignore my opinion, all I did was give you my experience of having to support about two thousand employees attempting to syncing devices across the public network. And the only think we found that we could rely on was that given an internet connection the devices could always find there way to our sync server.
Thats fine for your application. Im talking about one or two devices pulling data once or rarely from the desktop app.
I think the key differentiator here is you said “syncing devices across the public network” whereas Jon is interested in a LAN connection between a local desktop and iOS device on the LAN.
I’ve done both, and I agree with you WHEN syncing across the public network. OTOH, I also had a use case where iOS devices had to sync to a local desktop even when the desktop had no internet access. (Think remote sales reps using a laptop with no internet, but needing to exchange data with their iOS device which may be an iPad or iPod with no internet connection either.)
What I did for that use case was have the iOS device send out multicast UDP packets asking for desktop(s) who were listening. The desktop would listen for UDP muticast packets and respond with its own status, IP, etc. The iOS device would display a list of desktops which responded and let them select one. Then TCP was used for the actual data exchange. Which may be complete SQLite db(s) or JSON or whatever as the need required.
Just because using a server over the internet is appropriate for some / most use cases, does not mean it is for all use cases. I’ve had to do both.
[quote=477394:@Douglas Handy]
What I did for that use case was have the iOS device send out multicast UDP packets asking for desktop(s) who were listening. The desktop would listen for UDP muticast packets and respond with its own status, IP, etc. The iOS device would display a list of desktops which responded and let them select one. Then TCP was used for the actual data exchange. Which may be complete SQLite db(s) or JSON or whatever as the need required.[/quote]
Were you using Xojo? How did you use UDP? Thats what I really want to use to find the IP of the machine to sync to but Xojo doesnt have a UDP socket in the iOS framework.
No, not Xojo. And the desktop side began life when the device side was a Palm Pilot, not iOS. Then eventually transitioned to iOS, but predated Xojo for iOS.
That said, I believe MBS has UDP support for iOS. See here
[quote=477397:@Douglas Handy]No, not Xojo. And the desktop side began life when the device side was a Palm Pilot, not iOS. Then eventually transitioned to iOS, but predated Xojo for iOS.
That said, I believe MBS has UDP support for iOS. See here [/quote]
Yeah, Network kit doesn’t have iOS support. Oh wait, this is different than the Network plugin…
Yes, this is specifically for iOS, not part of the desktop plugins.
I have no experience with it – just knew it existed.
OK Greg - Opening this back up again.
I’m doing just what you say - reading the file in on the desktop side using a binary stream and writing the contents of that stream to the TCPSocket. On the iOS side I do the revers. But the file transfer is not happening properly and something is being corrupted.
I first tried passing my encrypted database. It wouldn’t load and manually decrypting it and trying to read it with a database editor gives an error. So I thought maybe something wrong with passing an encrypted file. So I decrypted it and sent it. I can actually open the received file in a text editor and see the data there. However, it still won’t read as a database file.
So now I’ve tried zipping the encrypted database and sending it. Nope. I can’t even unzip the received file.
So something is very wrong that is going on. I’m not quite sure what, but something ain’t right…
Just an idea, but what about trying to base64 encode it…
I thought about that too except how do you base64 encode a binary stream? And I figured that zipping would make it unnecessary. Maybe not?
On desktop you Base64Encode a memoryblock
Dim MB as MemoryBlock = BinStream.Read(Binstream.Length)
Dim base64 As String = EncodeBase64(mb)
On iOS this should work (untested)
[code]declare function initWithBase64EncodedString lib “Foundation” selector “initWithBase64EncodedString:options:” _
(obj_id as ptr, str as CFStringRef, options as Integer) as ptr
declare function alloc lib “Foundation” selector “alloc” (clsRef as ptr) as ptr
declare function writeToFile_ lib “Foundation” selector “writeToFile:atomically:” (obj_id as ptr, path as CFStringRef, atomically as Boolean) as Boolean
//Decode the Base64Encoded String as NSData (iOS Memoryblock)
dim mData as ptr = initWithBase64EncodedString(alloc(NSClassFromString(“NSData”)), Base64EncodedText, 1)
//Write the file
//You will need to define path such as SpecialFolder.Documents.Child(“some file”).Path
if writeToFile_(mData, path, false) then
//all good
End if
[/code]
[quote=478533:@Jeremie Leroy]On desktop you Base64Encode a memoryblock
Dim MB as MemoryBlock = BinStream.Read(Binstream.Length)
Dim base64 As String = EncodeBase64(mb)
[/quote]
I was thinking about that a few minutes ago and figured a memory block was the key.
[quote=478533:@Jeremie Leroy]
On iOS this should work (untested)
[code]declare function initWithBase64EncodedString lib “Foundation” selector “initWithBase64EncodedString:options:” _
(obj_id as ptr, str as CFStringRef, options as Integer) as ptr
declare function alloc lib “Foundation” selector “alloc” (clsRef as ptr) as ptr
declare function writeToFile_ lib FoundationLib selector “writeToFile:atomically:” (obj_id as ptr, path as CFStringRef, atomically as Boolean) as Boolean
//Decode the Base64Encoded String as NSData (iOS Memoryblock)
dim mData as ptr = initWithBase64EncodedString(alloc(NSClassFromString(“NSData”)), Base64EncodedText, 1)
//Write the file
//You will need to define path such as SpecialFolder.Documents.Child(“some file”).Path
if writeToFile_(mData, path, false) then
//all good
End if
[/code][/quote]
This was where I definitely needed the help as Xojo left out functions like EncodeBase64 from iOS. Thank you.
I’ll try this out…
Who-Hoo guys! That did it. Base64Encoding/Decoding was the secret! I’ve successfully transferred the file.
Now, I wonder if I really need to zip it. So that will be my next experiment!
And Jeremy, your decodebase64 code works great on iOS. You should add it to your set of tools.
I’ve managed to transfer the file just fine w/o zipping it as well. The question is: Should I zip it before transfer? I’m tempted to say no, because I just zipped another Sqlite database file on my Mac and it’s slightly LARGER than the original file. Seems like the SQLite format already packs the data w/o too much empty space. Seems like Zipping/Unzipping just adds 2 more process steps and more time.
Comments?
Forgive me if this point has already been covered in this discussion, but if your Socket connection is not secure (and the SQLite db not encrypted), could there be some value in password protecting your zipped file? You could do this by having the password embedded in the sending and receiving apps, so it’s never exposed in your network traffic.
Even though your transfers might be over a LAN, your client might still like the extra level of security regardless.
Just a thought.
FYI they were already included in iOSKit for several years now. They should work the same 
[quote=478543:@Jon Ogden]I’ve managed to transfer the file just fine w/o zipping it as well. The question is: Should I zip it before transfer? I’m tempted to say no, because I just zipped another Sqlite database file on my Mac and it’s slightly LARGER than the original file. Seems like the SQLite format already packs the data w/o too much empty space. Seems like Zipping/Unzipping just adds 2 more process steps and more time.
Comments?[/quote]
I think that will be very much data dependent. I can assure you that will some SQLite db files I transfer, the savings are significant. Others not so much. I have also done transfers of SQLite files both zipped and unzipped and had them work without any other steps such as Base64, but this was not in Xojo so all I can suggest is making sure the file is not hitting an encoding issue. You want the raw bytes transferred; don’t send as a Text stream.
The other advantage I like about sending a zip file, aside from the content length savings, is it gives me a chance to test the integrity of the received file by seeing if the unzip fails. If it does, I leave the previous SQLite db intact and only replace when the unzip is completed correctly.
But again, I am speaking in theoretical terms not in Xojo for iOS as my projects that do this predate Xojo for iOS.
Sorry for the late reply, but I see you have the answer now in any case.