Re: Sync Services for Multi-machine Core Data App?

[Steve Steinitz]

(Apologies - I found this in my drafts folder - better late than never?)


Hi Nick,

On 7/03/11, Nick Zitzmann wrote:


My question: is [using Sync Services for a large Core Data database] a good 
idea?



No.


Thanks for that clear answer.


Sync Services scales poorly and works best with up to a few thousand
small records. Creating multi-megabyte records, or millions of small
records, will cause syncing to take a long time


Thanks for that helpful rule of thumb.

Our database is neither: a couple hundred thousand small records 
and perhaps 30K new records per year.  Would that be any more feasible?



(especially if you have identity properties set),


Really?  Identity properties slow it down?  I thought it would 
be the opposite.



and probably take several gigabytes of RAM just to run a session.


Thanks for sharing your real-world experience.  I was under the 
impression that Leopard brought performance improvements to Sync Services.


That aside, an occasional 3-gigabyte of ram for a full pull from 
The Truth would be fine.  Only a hundred or two records change 
per day.



We make a sync client, and before we built it for X86-64, we had
several users crash it by attempting to sync too much data.


Are you saying the X86-64 version works better?  Works well?


If you need a multi-machine database-driven application, then you
should use ODBC, not CoreData, with either MySQL or PostgreSQL or some
commercial engine on the back end.


Your advice is likely good but it doesn't sound much fun.  I 
like Core Data.  And I'd dislike life if I had to write SQL.  
Worst case, I'll just keep my NAS shared database.


Besides possible performance issues are there other serious Sync 
Services issues?


I suppose I should post a similar question on Apple's Sync 
Services forum and see if I get as unequivocal an answer as your 'No'.


Cheers,

Steve

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: UI Design on iPad

[Kirk]

Trust me. You need to read the docs until you understand why this is totally 
the wrong direction to be taking. 

Make a whole-hearted commitment to using the standard UI as much as possible. 
After all, it is a big part of why the platform is #1.  

When you properly use standard UI elements, you get a UI that users already 
understand. 

To see a major blunder in this area, check out MS's Photosynth iApp. Wonderful 
functionality crippled by a pointlessly non-standard UI. 

MS couldn't bring themselves to even use proper platform terminology -- for 
example they say the images are saved on the "device" instead of the Camera 
Roll. Result -- confused users. 

Don't try to import the esthetics and habits of an also-ran mobile platform 
into your iOS app. That is the path to failure, as well as pointless extra work!



___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reminder: Join me in Pearltrees

[praveenmatanam]

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sync Services for Multi-machine Core Data App?

[Nick Zitzmann]

On Apr 23, 2011, at 3:54 AM, Steve Steinitz wrote:

>> Sync Services scales poorly and works best with up to a few thousand
>> small records. Creating multi-megabyte records, or millions of small
>> records, will cause syncing to take a long time
> 
> Thanks for that helpful rule of thumb.
> 
> Our database is neither: a couple hundred thousand small records and perhaps 
> 30K new records per year.  Would that be any more feasible?

No. 30,000 records is a lot to sync.

>> (especially if you have identity properties set),
> 
> Really?  Identity properties slow it down?  I thought it would be the 
> opposite.

They do, because changes to identity properties force the mingler to check all 
other records of the same entity in order to see if they have identical values. 
If they do, then the mingler merges the records.

>> and probably take several gigabytes of RAM just to run a session.
> 
> Thanks for sharing your real-world experience.  I was under the impression 
> that Leopard brought performance improvements to Sync Services.

But that still takes a lot of memory.

> That aside, an occasional 3-gigabyte of ram for a full pull from The Truth 
> would be fine.  Only a hundred or two records change per day.

And unless your users have more than 4 GB of RAM installed, then that will make 
the computer unresponsive for the life of the sync, which is probably not what 
you want to happen.

>> We make a sync client, and before we built it for X86-64, we had
>> several users crash it by attempting to sync too much data.
> 
> Are you saying the X86-64 version works better?  Works well?

No, I'm saying that it will survive allocating more than 4 GB of RAM inside the 
process. 32-bit apps have a 4 GB RAM limit, and trying to go over that will 
crash the process. 64-bit apps are currently limited to allocating no more than 
the amount of built-in RAM plus the free space of the swap volume.

>> If you need a multi-machine database-driven application, then you
>> should use ODBC, not CoreData, with either MySQL or PostgreSQL or some
>> commercial engine on the back end.
> 
> Your advice is likely good but it doesn't sound much fun.  

I never said designing scalable systems was fun. But in the end, it's worth it. 
I just spent a month improving the scalability of a non-Sync Services sync 
engine to the point where it can process thousands of record changes in a time 
frame measured in a few seconds rather than a few minutes, and everyone's happy 
now.

> Besides possible performance issues are there other serious Sync Services 
> issues?

Not really. Sync Services was really glitchy in early versions of Tiger, but 
the serious serious problems were fixed in Leopard, or in Tiger point releases. 
As long as you're not still targeting Tiger users, the only thing you have to 
worry about are know-it-all clients that feel the need to "correct" changes you 
push to it (I'm looking at you, iCal), which is unlikely to happen if you're 
working with your own schema.

Nick Zitzmann




___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSColorWell inside a custom NSCell

[Ken Ferry]

On Thu, Apr 21, 2011 at 5:52 PM, Graham Cox  wrote:

>
> On 21/04/2011, at 4:17 PM, Bryan Hansen wrote:
>
> > Am I on the right track with this? Is there a better way to get a bunch
> of movable colorwells within a custom control?
>
>
> I'd say no, you're not on the right track and yes, there's a better way.
>
> What you're attempting is probably doable, but the purpose of cells is to
> allow their re-use in a number of different situations - buttons, tables,
> matrices and so on. Since you're just making a custom control for a single
> purpose, using cells is just a lot of extra effort without a benefit (not to
> mention the extensive and ad-hoc nature of the NSCell API which invariable
> needs much customisation for every new situation).
>
> I've written a gradient control similar to what you're doing, with movable
> colour wells inside a bar. The original implementation used cells and it was
> a complex, overwrought mess. I later rewrote it as a single custom NSView
> which reduced the amount of code by 60% or so, and it worked a lot better (a
> good sign that you are doing it right!). The movable wells were simply
> elements drawn as needed in the right places.


That works, but if the stock NSColorWell drawing and behavior is already
what you want, you can use normal NSColorWell objects as subviews.  Your
uber view might be in charge of positioning them.

But definitely, if you don't need to put this in a table, no reason to deal
with cells here.

-Ken


> I did need to perform some tricks to get them to interact with the usual
> instances of NSColorWell in terms of getting the focus of the color panel -
> originally I did this using swizzling but when that was deprecated I did it
> some other way (the details momentarily escape me, but it "played nice").
>
> If you are interested in my implementation, I'm happy to share the code -
> contact me offlist. There are numerous problems you'd need to solve if you
> rolled your own - for example, since the movable well has some rectangular
> size, it's possible for two or more of these to overlap within the overall
> control. You need to handle that, as well as the already mentioned issue of
> getting Color Panel focus in conjunction with any other NSColorWell
> instances that exist in your app.
>
> You can preview the design here: http://gradientpanel.com/ though that
> project is pretty much dead, and uses the old complex design. The revised
> one looks the same however.
>
> --Graham
>
>
> ___
>
> 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:
> http://lists.apple.com/mailman/options/cocoa-dev/kenferry%40gmail.com
>
> This email sent to kenfe...@gmail.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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Xcode 4 auto-importing Objective C categories from static library

[Bradley S. O'Hearne]

Since transitioning to Xcode 4, I have discovered a very curious shift in the 
way Objective C categories are handled in static libraries. In general, if you 
create an Objective C category, you have to import that category into an 
implementation (.m) class in order for that category's additions to be visible 
and used. That worked great in Xcode 3, as you can control what categories 
methods appear wherever by merits of using the import (or not). However, in 
Xcode 4, all categories defined in a static library used in a dependent project 
are by definition visible, even if not imported. 

Here's an example. I have a common static library I have created to hold a lot 
of my frequently-used utility code, and commonly used categories. One such 
category in my static library is called UIViewController+Utils. If I create a 
brand new Xcode project (I used the iOS Tab Bar Application template), and add 
the static library to the project using the menu just so that it shows in the 
project, all of the view controllers in that template project are inheriting 
the view controller behavior from the category. I have not added *any* import 
statements or touched one line of code in that new project. I can visually see 
that these category methods from my UIViewController+Utils category in my 
static library because if I pull up the MainWindow.xib file, and click on the 
TabBarController object, I can see some actions defined by my category in the 
Connections Inspector. Also, any methods overridden by the category will 
exhibit the category's behavior in any base class (in other words, all view 
controllers will be by default effected by UIViewController categories, even 
though they don't import those categories). 

This is no bueno. I do not want all of my static library's categories to be 
used regardless of whether an import statement exists or not. Unless there is 
something obvious I am missing here, this would seem to call into question any 
use of categories in static libraries, and I have a major code refactoring 
required to reorganize how code is shared between projects. 

Can anyone shed some light on this? Why would UIViewControllers bear the 
effects of a UIViewController category in a static library if no import 
statements for that category or any other class which imports it anywhere in 
the project? 

Thanks.

Brad
___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Xcode 4 auto-importing Objective C categories from static library

[Stephen J. Butler]

On Sat, Apr 23, 2011 at 3:36 PM, Bradley S. O'Hearne
 wrote:
> Since transitioning to Xcode 4, I have discovered a very curious shift in the 
> way Objective C categories are handled in static libraries. In general, if 
> you create an Objective C category, you have to import that category into an 
> implementation (.m) class in order for that category's additions to be 
> visible and used. That worked great in Xcode 3, as you can control what 
> categories methods appear wherever by merits of using the import (or not). 
> However, in Xcode 4, all categories defined in a static library used in a 
> dependent project are by definition visible, even if not imported.

It's always been this way at runtime. When a category is loaded it
changes the behavior of all instances of a class that it modifies, no
ifs/ands/buts. It's loaded by the DYLD, and that has no concept of
your imports/includes. From the Obj-C docs:

""Category methods can do anything that methods defined in the class
proper can do. At runtime, there’s no difference. The methods the
category adds to the class are inherited by all the class’s
subclasses, just like other methods.""

Now the tools, on the other hand, were less smart in Xcode3 and below.
Autocomplete, IB message browser, etc only knew about the
messages/properties visible to the immediate code block (via import,
include, etc). That Apple has fixed this in Xcode 4 to better match
reality is a GOOD THING.
___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Xcode 4 auto-importing Objective C categories from static library

[Bradley S. O'Hearne]

Thanks for the response, Stephen. I was under the impression that category 
modification was limited to the types within which they are imported. Thanks 
for expanding my knowledge of categories!

Cheers, 

Brad

On Apr 23, 2011, at 3:22 PM, Stephen J. Butler wrote:

> On Sat, Apr 23, 2011 at 3:36 PM, Bradley S. O'Hearne
>  wrote:
>> Since transitioning to Xcode 4, I have discovered a very curious shift in 
>> the way Objective C categories are handled in static libraries. In general, 
>> if you create an Objective C category, you have to import that category into 
>> an implementation (.m) class in order for that category's additions to be 
>> visible and used. That worked great in Xcode 3, as you can control what 
>> categories methods appear wherever by merits of using the import (or not). 
>> However, in Xcode 4, all categories defined in a static library used in a 
>> dependent project are by definition visible, even if not imported.
> 
> It's always been this way at runtime. When a category is loaded it
> changes the behavior of all instances of a class that it modifies, no
> ifs/ands/buts. It's loaded by the DYLD, and that has no concept of
> your imports/includes. From the Obj-C docs:
> 
> ""Category methods can do anything that methods defined in the class
> proper can do. At runtime, there’s no difference. The methods the
> category adds to the class are inherited by all the class’s
> subclasses, just like other methods.""
> 
> Now the tools, on the other hand, were less smart in Xcode3 and below.
> Autocomplete, IB message browser, etc only knew about the
> messages/properties visible to the immediate code block (via import,
> include, etc). That Apple has fixed this in Xcode 4 to better match
> reality is a GOOD THING.

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Xcode 4 auto-importing Objective C categories from static library

[Kyle Sluder]

On Sat, Apr 23, 2011 at 3:22 PM, Stephen J. Butler
 wrote:
> Now the tools, on the other hand, were less smart in Xcode3 and below.
> Autocomplete, IB message browser, etc only knew about the
> messages/properties visible to the immediate code block (via import,
> include, etc). That Apple has fixed this in Xcode 4 to better match
> reality is a GOOD THING.

I'd say it is not a good thing as it stands, because all it does is
make it more likely that you're going to run into a compiler error in
the next five minutes. There's no indication that the method you're
trying to call is declared in a header you haven't imported. There's
just a generic "Could not find method -someCategoryMethod". Visual
Studio will at least automatically add using directives (similar in
purpose to Objective-C #import statements) if you attempt to reference
an identifier that it knows about but is in a namespace you haven't
imported yet.

Discussion about Xcode 4's behavior of showing all category methods
regardless of #import directives really belongs on the xcode-users
list, in the Developer Forums at http://devforums.apple.com , and/or
in the Bug Reporter at http://bugreport.apple.com.

Now, as for runtime behavior, as Stephen said it has *always* been the
case that the mere act of loading code containing a category code will
add that category's methods to the class, regardless of the #import
directives used at compile time.

--Kyle Sluder
___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sync Services for Multi-machine Core Data App?

[Eli Bach]

On Apr 23, 2011, at 3:54 AM, Steve Steinitz wrote:

> Your advice is likely good but it doesn't sound much fun.  I like Core Data.  
> And I'd dislike life if I had to write SQL.  Worst case, I'll just keep my 
> NAS shared database.
> 
> Besides possible performance issues are there other serious Sync Services 
> issues?
> 
> I suppose I should post a similar question on Apple's Sync Services forum and 
> see if I get as unequivocal an answer as your 'No'.

BaseTen has an open-source framework that works very similar to CoreData, but 
uses a network connection to PostGres for the backend.  It adds support for 
multi-user conflicts, but I haven't explored that part yet.




Eli

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com