Between background fetches and server-sent events (like Rocket.io , local data is going to be updated more often, and, therefore, in smaller chunks. Instead of logging in after 24 hours of inactivity and needing to fetch everything that has happened in the past 24 hours, your app is going to be fetching small chunks of data all by itself during that 24-hour period and should be more-or-less up-to-date at launch.
There could be cases where someone wants to access blueprints or some engineering document that’s several megabytes in size, but those operations could be conducted through an NSURLSessionConfiguration where allowsCellularAccess is set to NO. Optionally, you could add a parameter in the JSON request informing the server that the user is on a cellular network and the server could decide whether they’re requesting too much information for the connection. If a user is trying to access some large data set over a 3G network, you could post an alert informing them it ain’t gonna happen until they get back on wifi. The point is, Rails is as popular as it is largely because it makes assumptions and takes a convention over configuration approach to the most common problems. Maybe something like AFIS can solve 80% of the most common problems elegantly and leave room for devs to solve the remaining 20% on a case-by-case basis. On Oct 17, 2013, at 11:45 AM, Scott Ribe <scott_r...@elevated-dev.com> wrote: > On Oct 17, 2013, at 9:19 AM, Brad Gibbs <bradgi...@mac.com> wrote: > >> As for large data sets, that’s part of the beauty of the NSIncrementalStore >> approach. In its purest form, the full data set wouldn’t exist on any one >> user’s device. Instead, NSIncrementalStore would fetch the data requested >> by the user from the server, as needed, by firing faults. If >> NSIncrementalStore worked as advertised, there would be no need to persist >> the entire data set to a user’s device. > > Which works fine as long as users have always-on connectivity, with > reasonably good bandwidth & latency, and the data they need to work with is > not too huge. > > That's not to pick on you or the particular solution, just to point out that > one reason that there is not a single good solution in this space is that > there is no one-size-fits-all solution simply because there are too many > variables to allow that. > >> I think there’s a huge need for something like this in SMB. > > Agreed. Probably assuming always-on connectivity, since people usually have > 3G or 4G. Do a decent job with managing bandwidth demands and controlling the > number of requests/responses, and in cases where the bandwidth/latency is not > good enough for a decent user experience, oh well... > > -- > Scott Ribe > scott_r...@elevated-dev.com > http://www.elevated-dev.com/ > (303) 722-0567 voice > > > > > > _______________________________________________ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/bradgibbs%40mac.com > > This email sent to bradgi...@mac.com _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
