iOS and maintaining sync

[David Whittaker]

Hi David,

Having just finished up an iPad app, and having dealt with some of the issues the iOS backgrounding restrictions can create, I'm curious about how you plan to keep data flowing to and from Visi.Pro.  In my case, the client I developed the app for prohibited use of iCloud so I haven't looked too deeply into how well suited that would be for keeping things up to date.  Is use of iCloud part of the plan or did you have another method in mind?

[David Pollak]

On Fri, Nov 25, 2011 at 11:34 AM, David Whittaker <da...@iradix.com> wrote:

Hi David,

Having just finished up an iPad app, and having dealt with some of the issues the iOS backgrounding restrictions can create, I'm curious about how you plan to keep data flowing to and from Visi.Pro.

Please keep in mind that computations in Visi.Pro can happen in the cloud or on the device.  The locus of computation can move.

 

 In my case, the client I developed the app for prohibited use of iCloud so I haven't looked too deeply into how well suited that would be for keeping things up to date.  Is use of iCloud part of the plan or did you have another method in mind?

My goal is to have data feeds flow into the cloud service.  A computation takes place.  Events are queued for the client and if the client is not connected, we'll send a notification to the client.  When the client connects, the client will send events to the server and load events from the server.  Like SQL transactions logs, we should be able to synchronize state across address spaces by replaying events.

Does that answer the question?

Thanks,

David

 

--

Visi.Pro, Cloud Computing for the Rest of Us http://visi.pro

Lift, the simply functional web framework http://liftweb.net

Follow me: http://twitter.com/dpp
Blog: http://goodstuff.im

[David Whittaker]

I think it does answer it.  Having Visi apps actually running in the cloud may be the piece that I was missing.  One of the issues I was having is that my app connected to an existing service, somewhat like your sales force example.  The natural way to have the two communicate seemed to be to have the client regularly poll the server and do something if an event had occurred, but iOS backgrounding limitations made that pretty difficult.  If I had that middle piece available, the piece that could poll the server on the clients behalf and then deliver a push notification to the app when there were events to consume, it would have made things much easier.  I'm not a fan of Apple's decisions on background processes, but I think that might turn out to be a pretty novel way to deal with them.