I don’t have a degree in comp sci and, while I program in Cocoa and Rails on a
daily basis, it’s not my primary job function, so, I’m sure I don’t fully
appreciate a statement like “Core Data has no semantics for asynchronous,
failed, or cancelable operations.” I’m not in any way trying to pick
Actually, there is no reason CoreData can't be used in this manner, but there
are things that will have to be dealt with outside of CoreData. How do you
deal with two people making changes to the same record concurrently as an
example ( this is not an issue exclusive to CoreData, but multi-user
Alex,
> Can’t you use NSIncrementalStore to talk with REST services as a backend for
> Core Data? I remember seeing some articles on this.
That's what AFIncrementalStore/AFRESTClient does. It uses AFNetworking to
communicate with the web service:
https://github.com/AFNetworking/AFIncremental
Dru,
I am not sure if I understand you, but here it goes!
> Actually, there is no reason CoreData can't be used in this manner, but there
> are things that will have to be dealt with outside of CoreData. How do you
> deal with two people making changes to the same record concurrently as an
>
Flavio responded while I was editing, so, this is just re-iterating some of his
points.
I’m not sure whether you (Dru) were responding to my post, or just responding
to the thread, in general.
Using a Rails API-based backend with a PostgreSQL database means that Core Data
doesn’t have to scale
On Oct 17, 2013, at 11:03 AM, Flavio Donadio wrote:
> Dru,
>
>
> I am not sure if I understand you, but here it goes!
>
>> Actually, there is no reason CoreData can't be used in this manner, but
>> there are things that will have to be dealt with outside of CoreData. How
>> do you deal wit
On Oct 17, 2013, at 9:19 AM, Brad Gibbs 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 f
On Oct 17, 2013, at 11:45 AM, Scott Ribe wrote:
>
>> 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 request
Dru,
> [...] if you use CoreData on the server as well, you get into issues where
> things are a little more complex.
Well, this is a path that I'm pretty much convinced that wouldn't work. Almost
everyone on this list told me it would be a bad idea.
But it would solve the "two identical mod
YES, that was it. I KNEW I saw a project for this, but couldn’t find it via
Google anymore.
On Oct 17, 2013, at 8:40 AM, Flavio Donadio wrote:
> Alex,
>
>
>> Can’t you use NSIncrementalStore to talk with REST services as a backend for
>> Core Data? I remember seeing some articles on this.
>
Mattt also has a Rack Middleware project called Rack::CoreData that links to a
Core Data model and builds out a RESTful web service based on the Core Data
model.
https://github.com/mattt/rack-core-data
and a more comprehensive solution that incorporates AFIS, AFN, Rack::CoreData,
Passbook and
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 b
On Oct 17, 2013, at 8:19 AM, Brad Gibbs wrote:
> Core Data is still a local cache being used by a single user, but instead of
> persisting to the local disk, it’s persisting to the Postgres server.
But not directly, right? You said there was a Rails app in the middle serving
up a REST API.
On Oct 17, 2013, at 10:49 AM, Jens Alfke wrote:
>
> On Oct 17, 2013, at 8:19 AM, Brad Gibbs wrote:
>
>> Core Data is still a local cache being used by a single user, but instead of
>> persisting to the local disk, it’s persisting to the Postgres server.
>
> But not directly, right? You said
On Thu, Oct 17, 2013, at 09:04 AM, Alex Kac wrote:
> YES, that was it. I KNEW I saw a project for this, but couldn’t find it
> via Google anymore.
Please don't use AFIncrementalStore. It's just a bad idea for all the
reasons that are mentioned in the "Fallacies of Network Programming"
Jens refers
Oh I have no need for it. I’m just saying I’ve seen it. My experience with
databases comes from over 25 years in writing c/s apps using enterprise Oracle,
SQLServer, etc.. down to transactional local databases such as btrieve. Most of
my experience in the above comes from the 90s/early 2000s doi
This has been driving me crazy, and hopefully someone on the list will know
off the top…
I remember coming across a reference somewhere recently to a constant
defined in Foundation or Core Foundations (I think!) that has a zero value,
and semantically means "I choose no options". Something that wo
You make some great points, Jens.
Yes, the scenario I’m considering is a Rails server, hosted on Heroku, backed
by a Postgres database.
Regarding your point about Core Data not being atomic:
1. It sounds like a perfectly reasonable and valid argument, but, then, why
would Apple release NSIncre
I am not sure that there is a catch-all 'no options' constant.
I did find framework specific examples like
kCFDateFormatterNoStyle, kCFNumberFormatterNoStyle, kCollectionDontWantTag,
kCollectionDontWantId, kCollectionDontWantSize,
kCollectionDontWantAttributes, kCollectionDontWantIndex,
kCollecti
Jens,
> I haven’t dug all the way into NSIncrementalStore yet. But the assumption
> you’re making is that you can take an architecture that works for a local
> single-user database, and transparently make it work over a worldwide network
> with lots of users just by [colorful metaphor ahead, n
On Oct 17, 2013, at 10:48 AM, Sixten Otto wrote:
> I remember coming across a reference somewhere recently to a constant
> defined in Foundation or Core Foundations (I think!) that has a zero value,
> and semantically means "I choose no options".
I know of no constant that would apply universall
I have an NSArray Controller that manages an array of Dictionaries that
contain two NSString objects "Name" and "Identifier"
The Name field is shown in an NSTable and is user editable while the
Identifier is generated when the dictionary is created and is used to
reference the object by the app (s
On Thu, Oct 17, 2013 at 11:22 AM, Seth Willits wrote:
> I would be hesitant to get used to such a constant.
>
I'll bite: why?
> Many APIs have their own constants for default options. (Search for
> DefaultOptions, OptionsDefault, NoOptions, and OptionsNone.)
>
Obviously. And those generally s
On Oct 17, 2013, at 11:05 AM, Brad Gibbs wrote:
> Regarding your point about Core Data not being atomic:
> 1. It sounds like a perfectly reasonable and valid argument, but, then, why
> would Apple release NSIncrementalStore at all? What purpose would it serve?
It would work well for other _
On Oct 17, 2013, at 11:55 AM, Sixten Otto wrote:
> On Thu, Oct 17, 2013 at 11:22 AM, Seth Willits wrote:
>> I would be hesitant to get used to such a constant.
>
> I'll bite: why?
As each API is potentially different from others, it's best to use the
constants provided. Using a constant from a
On Oct 17, 2013, at 14:35 , Seth Willits wrote:
> It's too easy in my mind to misuse a "universal" constant.
Yeah. It seems to me there are two prime reasons to use a specific constant:
1. Apple's SDKs are gradually moving towards using enums that can be (somewhat)
type-checked at compile time
Thanks again, Jens, for the lengthy and thoughtful response. I’ve been looking
at Couchbase for a couple of years now (wasn’t it initially called Couchbase
Mobile?), and I’ve used Blip in the past. Great stuff.
I read through some of the Couchbase Lite conceptual documentation. Since
we’ve b
On Thu, Oct 17, 2013 at 3:15 PM, Quincey Morris <
quinceymor...@rivergatesoftware.com> wrote:
> Yeah. It seems to me there are two prime reasons to use a specific
> constant:
>
But I'm explicitly talking about APIs where there exists no such constant,
and calling code would generally use a litera
On Oct 17, 2013, at 9:49 AM, Jens Alfke wrote:
> But NSIncrementalStore doesn’t have a notion of a transaction, because
> CoreData doesn’t care about concurrency, because it’s not multi-user.
This is not the case.
- NSIncrementalStore’s notion of a transaction is an instance of
NSPersistentSt
is there any way to build a call to a C function on the fly? I mean something
like pass a string to a method, and have it call the function of that name?
--
Shane Stanley
'AppleScriptObjC Explored'
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple
On Oct 17, 2013, at 9:48 PM, Shane Stanley wrote:
> is there any way to build a call to a C function on the fly? I mean something
> like pass a string to a method, and have it call the function of that name?
No. That's an Objective-C feature that's not present in standard C.
Charles
You actually can, by using dlsym(3) to resolve the symbol, cast it to the
appropriate function pointer and call it.
For example:
int (*myfunc)(int, int) = dlsym(RTLD_DEFAULT, myfunc_name);
if (myfunc)
printf(“%d”, myfunc(2, 3));
else
fprintf(stderr, “error: cannot resolve symbol: %s”, my
On Oct 17, 2013, at 10:40 PM, Maxthon Chan wrote:
> You actually can, by using dlsym(3) to resolve the symbol, cast it to the
> appropriate function pointer and call it.
>
> For example:
>
> int (*myfunc)(int, int) = dlsym(RTLD_DEFAULT, myfunc_name);
> if (myfunc)
> printf(“%d”, myfunc(2,
You can certainly move everything into a library, also you can prevent
executables from being stripped in Xcode.
Sent from my iPhone
> On 2013年10月18日, at 11:54, Charles Srstka wrote:
>
> Loadable bundles and libraries don't get stripped. Executables, since they
> don't need to be loaded by an
I knew I was going to want to do something like that myself so created a small
test project.
You need to have the scrollview, the clipview, and the document view all layer
backed for it to work with the scrollview magnification. You shouldn't need to
explicitly set the autoresizesSubviews on. I
35 matches
Mail list logo
