Re: Threadsafe copy of objective c object
Thanks to everyone who has chimed in on this one - you've all been really helpful. Looks like some conclusions are emerging; some selected replies below. On 3 Sep 2013, at 20:21, Tom Davie wrote: > Remove the mutation methods. Make your object immutable, the referential > transparency will give you “free” parallelism. If you want a mutated version > of the object, create a new object. Very good suggestion, though unfortunately my use of UI bindings rather scuppers that one. Otherwise it could be an ideal solution On 3 Sep 2013, at 19:49, Marcel Weiher wrote: > What are the property parameters? A bunch of numbers, maybe some strings? Yep. > Unless there is some dire reason not to do this, I would make a copy on the > main thread every time the UI changes, and stash that copy somewhere the > worker thread can access it easily. That's a really good plan, I realised that last night. I had been stuck thinking about kind of the opposite approach (make a copy on each invocation of the processing algorithm), but this makes a lot of sense. How does this sound: When the UI leads to changes in the (mutable) primary object I'll make a copy stored in an immutable shadow object (from the main thread). Whenever the algorithm is invoked (from a secondary thread in response to receipt of a frame) I retain the immutable shadow object and pass this pointer to the algorithm. From what Jens and others have said, it's my understanding that if the property for the (immutable) shadow object is designated atomic/retain then I wouldn't need a mutex to access it. On 3 Sep 2013, at 18:37, Jens Alfke wrote: > This is one reason why concurrent programming often relies on immutable > objects — because they can be passed around multiple threads safely. > Thread-safe access to mutable objects is a real pain and it’s very easy to > create subtle bugs that only show up very rarely. Wise words that I had rather lost sight of! I was too focused on incremental changes to the original (poor) design... On 3 Sep 2013, at 18:26, Kyle Sluder wrote: > One of the cardinal rules of Audio Units is "Thou Shalt Not Allocate > Memory On The Render Callback Thread." > > malloc takes a lock. Taking a lock is a great way to make you thread > miss its hard-realtime constraint, which leads to glitching and > potentially getting killed by the host. Yes, I learned that one the hard way a while back! ___ 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
Subclassing a View Controller in a Storyboard
Hi All,
If I am using a Storyboard that contains a view controller,
LTWMusicViewController that I'd like to sub-class like so:
LTWRockMusicViewController : LTWMusicViewController
Then in the viewDidLoad method, do:
-(void) viewDidLoad
{
[super viewDidLoad];
self.pMusicCategory = kRockMusicCategory;
}
At present LTWMusicViewController is loaded using:
myViewController = [self.storyboard
instantiateViewController:@"LTWMusicViewController"];
I want LTWRockMusicViewController to use same NIB etc, as
LTWMusicViewController, but just pre-set the self.pMusicCategory property to
Rock.
How do I do this using a Storyboard? I don't really want to copy all the
controls for LTWMusicViewController into LTWMusicViewController.
Thanks in advance,
Dave
___
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
Re: Core Data Initialization
On 3 Sep 2013, at 15:59, Fritz Anderson wrote: > On 2 Sep 2013, at 9:33 AM, Jerry Krinock wrote wise things > about handling mismatches between stores and MOMs, and the practice of > copying a generic store into Documents/ if no store is there. > >> On 2013 Sep 02, at 04:01, Dave wrote: >> >>> 1. Is this advisable? Is it Safe? >> >> It's kind of weird. > > I've done it before, and would be surprised if it were unusual. One would > often want to seed an app with default and constant data, wouldn't one? Yes, of course, but to import a SnapShot of the app.sqlite file isn't the best way of achieving this. In this case anyway, it would be better to hold the default data in some other kind of data file and then write it into the latest Core Data store when the app is first launched. Cheers Dave ___ 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
Re: Core Data Initialization
Op 2 sep 2013, om 13:01 heeft Dave het volgende geschreven: > Is this advisable? Yes, it's in the Core Data FAQ: https://developer.apple.com/library/ios/documentation/Cocoa/Conceptual/CoreData/Articles/cdFAQ.html#//apple_ref/doc/uid/TP40001802-SW5 ___ 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
Re: Core Data Initialization
On 4 Sep 2013, at 12:13, Willeke wrote: > > Op 2 sep 2013, om 13:01 heeft Dave het volgende geschreven: > >> Is this advisable? > > Yes, it's in the Core Data FAQ: > https://developer.apple.com/library/ios/documentation/Cocoa/Conceptual/CoreData/Articles/cdFAQ.html#//apple_ref/doc/uid/TP40001802-SW5 > It doesn't actually say use an Core Data SQLite file, it says use a persistent store which may or may not be the same thing. Using an SQLite file that has been created using an older version of the app is really dodgy for a number of reasons: You have to manually copy the data out of an app from the simulator or a device into your project structure. If you don't do this, if the Model Changes, it may well crash on a clean install. This will be largely hidden at the development stage. It is better to use the same source as the real application will use to build a fresh copy of the Store. In my case the live app uses JSON Server feeds to populate a Core Data Store. So, in this case all I have to do is hold local copies of the JSON files, and on a clean install (the first time the app is launched), change the URL to point to the local files, instead of the usual Server URL. This not only gets the job done safely, but tests your parser and other app components locally. Also you could use test versions of these files to hold known data which makes testing a lot easier in general. All the Best Dave ___ 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
Re: Subclassing a View Controller in a Storyboard
On Sep 4, 2013, at 4:13 AM, cocoa-dev-requ...@lists.apple.com wrote:
> Date: Wed, 04 Sep 2013 10:23:04 +0100
> From: Dave
> Subject: Subclassing a View Controller in a Storyboard
>
> Hi All,
>
> If I am using a Storyboard that contains a view controller,
> LTWMusicViewController that I'd like to sub-class like so:
>
> LTWRockMusicViewController : LTWMusicViewController
>
> Then in the viewDidLoad method, do:
>
> -(void) viewDidLoad
> {
> [super viewDidLoad];
>
> self.pMusicCategory = kRockMusicCategory;
> }
>
>
>
>
> At present LTWMusicViewController is loaded using:
>
> myViewController = [self.storyboard
> instantiateViewController:@"LTWMusicViewController"];
>
>
> I want LTWRockMusicViewController to use same NIB etc, as
> LTWMusicViewController, but just pre-set the self.pMusicCategory property to
> Rock.
>
> How do I do this using a Storyboard? I don't really want to copy all the
> controls for LTWMusicViewController into LTWMusicViewController.
What you're doing has a lot of bad smells:
* If I'm only going to call instantiateViewController, why am I using a
storyboard here at all? If I use a .xib file instead, I can tell the view
controller what .xib to use at its view nib, regardless of it's class.
* If the only difference between this object and that one is
self.pMusicCategory, why am I bothering to subclass? Why not set the music
category of the instance as soon as it is created? Gosh, if I weren't using a
storyboard, I could even have a designated initializer that takes a music
category as a parameter.
* Even if you must use a storyboard, you can set an arbitrary variable in the
resulting instance, using the user-defined runtime attributes.
* If all else fails, implement loadView. Now finding the view is up to you. You
can keep the view in a .xib file even if you are getting the view controller
from a storyboard (delete the view controller's view from the storyboard to
indicate that you will supply it in some other way).
m.
--
matt neuburg, phd = m...@tidbits.com, http://www.apeth.net/matt/
pantes anthropoi tou eidenai oregontai phusei
Programming iOS 6! http://shop.oreilly.com/product/0636920029717.do
RubyFrontier! http://www.apeth.com/RubyFrontierDocs/default.html
TidBITS, Mac news and reviews since 1990, http://www.tidbits.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
Re: Subclassing a View Controller in a Storyboard
On Wed, Sep 4, 2013, at 08:08 AM, Matt Neuburg wrote: > Maybe I just don't understand what the OP is trying to do. It seemed very > strange to me. m. Yes, more context would indeed help. It's not necessarily strange to want to use the same interface with multiple view controllers, but it does go against the grain of how storyboards are designed. --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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSPanel doesn't reposition correctly after screen resize
On Sep 3, 2013, at 16:11:01, Lee Ann Rucker wrote: > NSWindowDidChangeScreenNotification is sent when the window moves to another > screen. NSApplicationDidChangeScreenParametersNotification is when the screen > itself changes. You'll probably have to listen to both of them, but they can > share code. I'm on 10.8 and get ONLY NSWindowDidChangeScreenNotification when I change my screen's resolution. NSApplicationDidChangeScreenParametersNotification is not being sent for this change. > If you look at the result of stringWithSavedFrame, it includes the window's > screen frame. This is how restoration (old and new) adjusts when a window > restores to a different screen configuration. It wouldn't surprise me if > they're keeping the screen frame saved somewhere internally too. The problem here is that both the window bounds and the screen bounds contained in this value have already been updated after the screen size has been changed. It doesn't contain the previous screen size. I guess I'm going to have to keep some custom data in our own structures to make this work. Phooey. Thanks for trying, though. :) -- Steve Mills office: 952-818-3871 home: 952-401-6255 cell: 612-803-6157 ___ 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
Re: Why is translatesAutoresizingMaskIntoConstraints on in my storyboard?
All top level views in XIBs and storyboards have translatesAutoresizingMaskIntoConstraints=YES. This is because most UIKit and AppKit view and controller subclasses are not yet using constraints to layout, so the default of translatesAutoresizingMaskIntoConstraints=YES is least unexpected. As Kyle pointed out translatesAutoresizingMaskIntoConstraints is a property that should be governed by the client of your view, not the view itself, so that's also part of the motivation why ideally you shouldn't need to care about that property when working in the IB document itself. Someday we'll flip the default as more systems migrate to auto layout. Kevin On 19 Aug 2013, at 05:50, Kyle Sluder wrote: > On Aug 19, 2013, at 2:48 AM, Rick Mann wrote: > >> I don't turn this on explicitly. But when I load a UIVieController into a >> view controller container, I'm getting bitching about unsatisfiable >> constraints, including NSAutoresizingMaskLayoutConstraint. But it's all from >> the same storyboard that uses autolayout. Why are there any autoresizing >> constraints? > > You don't control how view controllers position their child view controllers' > views. For example, the root view controller's view is positioned within the > window using -setFrame:, not with constraints. > > Make sure you haven't accidentally created a constraint system that will try > to resize the window. > > --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: > https://lists.apple.com/mailman/options/cocoa-dev/cathey%40apple.com > > This email sent to cat...@apple.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
Re: Threadsafe copy of objective c object
On Sep 4, 2013, at 10:56 , Jonathan Taylor wrote: > On 3 Sep 2013, at 19:49, Marcel Weiher wrote: >> Unless there is some dire reason not to do this, I would make a copy on the >> main thread every time the UI changes, and stash that copy somewhere the >> worker thread can access it easily. > > That's a really good plan, I realised that last night. I had been stuck > thinking about kind of the opposite approach (make a copy on each invocation > of the processing algorithm), but this makes a lot of sense. How does this > sound: > > When the UI leads to changes in the (mutable) primary object I'll make a copy > stored in an immutable shadow object (from the main thread). > Whenever the algorithm is invoked (from a secondary thread in response to > receipt of a frame) I retain the immutable shadow object and pass this > pointer to the algorithm. Sounds pretty good to me. I’d probably stash it in an instance variable. In a sense, this is a variant of the immutability that Ian and Jens suggested: create a copy that you won’t mutate. > From what Jens and others have said, it's my understanding that if the > property for the (immutable) shadow object is designated atomic/retain then I > wouldn't need a mutex to access it. Yep. Marcel ___ 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
Re: Subclassing a View Controller in a Storyboard
On Sep 4, 2013, at 7:02 AM, Matt Neuburg wrote: > > On Sep 4, 2013, at 4:13 AM, cocoa-dev-requ...@lists.apple.com wrote: > > What you're doing has a lot of bad smells: > > * If I'm only going to call instantiateViewController, why am I using a > storyboard here at all? If I use a .xib file instead, I can tell the view > controller what .xib to use at its view nib, regardless of it's class. Storyboards give you access to static table view cells. > > * If the only difference between this object and that one is > self.pMusicCategory, why am I bothering to subclass? You still need to subclass to have a music category property. > Why not set the music category of the instance as soon as it is created? In this example, it is a constant. > Gosh, if I weren't using a storyboard, I could even have a designated > initializer that takes a music category as a parameter. You could do that, but OP is using storyboards. In that case, the proper way to pass that info is in -prepareForSegue:. > > * Even if you must use a storyboard, you can set an arbitrary variable in the > resulting instance, using the user-defined runtime attributes. You can't use symbolic constants here, and it’s shoved into some little-used menu. User-defined runtime attributes are a smell. > > * If all else fails, implement loadView. Why do this when -viewDidLoad is expressly provided for setting up a view after it’s been loaded? OP does not need to customize the loading process. In short, none of your advice is appropriate. --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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data Initialization
On 4 Sep 2013, at 6:33 AM, Dave wrote: > It doesn't actually say use an Core Data SQLite file, it says use a > persistent store which may or may not be the same thing. Using an SQLite file > that has been created using an older version of the app is really dodgy for a > number of reasons: > > You have to manually copy the data out of an app from the simulator or a > device into your project structure. If you don't do this, if the Model > Changes, it may well crash on a clean install. This will be largely hidden at > the development stage. > > It is better to use the same source as the real application will use to build > a fresh copy of the Store. In my case the live app uses JSON Server feeds to > populate a Core Data Store. So, in this case all I have to do is hold local > copies of the JSON files, and on a clean install (the first time the app is > launched), change the URL to point to the local files, instead of the usual > Server URL. I understand you to be saying, as an absolute best practice, that apps that depend on initialized Core Data stores should generate the initial stores from raw (or reformatted) source data. Forgive me if I misunderstand. Problem. I have to synthesize an immutable Core Data store from two .sqlite3 databases (not Core Data), totaling 300 MB, plus 6 MB of XML texts†. The TEIs include an entity to be indexed at every word. The synthesis is not simple; it involves joins of hundreds of thousands of records 3 layers deep. † (Actually SGML/TEI, which means Foundation XML parsers are useless. And Humanities professors abuse the DTD so thoroughly that we need a file-by-file configuration for an all-purpose parser to make semantic sense of it.) Synthesis (using NSOperation where possible) takes four or five hours on a 12-core Mac Pro. That's with local files; pulling a 350 MB database from a server would be amusing, but not practical: Most people don't have the time to replicate this process with their iOS hardware. And no, it can't be pulled in on-demand from a server. We have another app that does something similar, but there are only 77,000 objects derived directly from 20-something XML files (which the originating department kindly converted from TEI), so it's much quicker. But still many minutes. Of _course_ we embed complete Core Data stores in our apps. I'd call anything else insane, but I can't imagine any insane person attempting it. And MOM conflicts are not a problem: We know when our MOM changes (thankfully rarely). When it does, one of us regenerates the store. This happens every ten weeks or so. We endure the time and trouble to drag the current MOM and store into the project directory. Subsequent builds use the new MOM and the store built from it, and there is no question of data/model compatibility (unless we forget, which turns up instantly). Mac-generated stores are completely compatible with iOS Core Data. There is no reason to have the Simulator do it. Migration of user-mutable stores is quite another matter, but that problem is unavoidable, and there are known techniques for addressing it. My guess is that migration is almost always a less-intensive process. Now, I am abusing the point you are making. You probably had it in mind that there are extreme cases where your approach isn't possible. But it should be on the record that there are many cases in which the solution you posed as universal isn't possible. — F ___ 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
Re: Core Data Initialization
On 4 Sep 2013, at 15:54, Fritz Anderson wrote: > On 4 Sep 2013, at 6:33 AM, Dave wrote: > >> It doesn't actually say use an Core Data SQLite file, it says use a >> persistent store which may or may not be the same thing. Using an SQLite >> file that has been created using an older version of the app is really dodgy >> for a number of reasons: >> >> You have to manually copy the data out of an app from the simulator or a >> device into your project structure. If you don't do this, if the Model >> Changes, it may well crash on a clean install. This will be largely hidden >> at the development stage. >> >> It is better to use the same source as the real application will use to >> build a fresh copy of the Store. In my case the live app uses JSON Server >> feeds to populate a Core Data Store. So, in this case all I have to do is >> hold local copies of the JSON files, and on a clean install (the first time >> the app is launched), change the URL to point to the local files, instead of >> the usual Server URL. > > I understand you to be saying, as an absolute best practice, that apps that > depend on initialized Core Data stores should generate the initial stores > from raw (or reformatted) source data. Forgive me if I misunderstand. It's best practise IF it's possible to do it with your App (which I can in this case). If for some reason (like it's too slow) you can't do best practise, then do second best practise and document it! Cheers Dave ___ 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
Re: Subclassing a View Controller in a Storyboard
On 4 Sep 2013, at 15:02, Matt Neuburg wrote:
>
> On Sep 4, 2013, at 4:13 AM, cocoa-dev-requ...@lists.apple.com wrote:
>
>> Date: Wed, 04 Sep 2013 10:23:04 +0100
>> From: Dave
>> Subject: Subclassing a View Controller in a Storyboard
>>
>> Hi All,
>>
>> If I am using a Storyboard that contains a view controller,
>> LTWMusicViewController that I'd like to sub-class like so:
>>
>> LTWRockMusicViewController : LTWMusicViewController
>>
>> Then in the viewDidLoad method, do:
>>
>> -(void) viewDidLoad
>> {
>> [super viewDidLoad];
>>
>> self.pMusicCategory = kRockMusicCategory;
>> }
>>
>>
>>
>>
>> At present LTWMusicViewController is loaded using:
>>
>> myViewController = [self.storyboard
>> instantiateViewController:@"LTWMusicViewController"];
>>
>>
>> I want LTWRockMusicViewController to use same NIB etc, as
>> LTWMusicViewController, but just pre-set the self.pMusicCategory property to
>> Rock.
>>
>> How do I do this using a Storyboard? I don't really want to copy all the
>> controls for LTWMusicViewController into LTWMusicViewController.
>
> What you're doing has a lot of bad smells:
>
> * If I'm only going to call instantiateViewController, why am I using a
> storyboard here at all? If I use a .xib file instead, I can tell the view
> controller what .xib to use at its view nib, regardless of it's class.
This is just one place where it is instantiated normally you don't the base
class is instantiated "as is", plus the App has a lot of other view controllers.
A bit like subclassing any other object really, why else would you subclass
something unless to add or change the behaviour of the Base Class. In this
case, the default is to display all music, but sometimes I want the same
display but limited to RockMusic or whatever.
>
> * If the only difference between this object and that one is
> self.pMusicCategory, why am I bothering to subclass? Why not set the music
> category of the instance as soon as it is created?
The code is already written, I'm trying to adapt it, there is no way I want to
pull apart a storyboard to do just that.
> Gosh, if I weren't using a storyboard, I could even have a designated
> initializer that takes a music category as a parameter.
Well, so would I, but who ever wrote this used a storyboard and I have to use
it!
> * Even if you must use a storyboard, you can set an arbitrary variable in the
> resulting instance, using the user-defined runtime attributes.
At the moment, the viewDidLoad method in the base class sets the Category
property to "ALL", I call this super class AND THEN set the Category to Rock,
thus overriding the initial setting. I can' t see how setting this attribute
will help? Or are you saying in the base class, detect if the Attribute is
present and if not use ALL else use whatever it is set to?
At the moment, the code instantiates the VC and then overwrites the Category
with Rock before it runs. This works ok, but rather than have the calling class
have to set the category.
There is one method that deals with presentingViewController and it is passed
the Class Name, at present, the code does this:
if ([theViewControllerClassName isEqualToString@"LTWRockMusicViewController"]
== YES)
{
// Instantiate LTWMusicViewController and set property.
return;
}
// Instantiate theViewControllerClassName.
>
> * If all else fails, implement loadView. Now finding the view is up to you.
> You can keep the view in a .xib file even if you are getting the view
> controller from a storyboard (delete the view controller's view from the
> storyboard to indicate that you will supply it in some other way).
>
> m.
Not possible because it would break too much else!
Cheers
Dave
___
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
Re: Subclassing a View Controller in a Storyboard
The point is, if the only difference between an LTWMusicViewController and an LTWRockMusicViewController is that the latter defaults to the “Rock” category, then you don’t actually *need* the LTWRockMusicViewController subclass. You just need to ensure that when you want an LTWMusicViewController created with the Rock category, that you ensure it is set as such. So in -prepareForSegue, you get the instance of LTWMusicViewController that is about to be transitioned to, set its category to Rock, and your done. No need for subclassing at all. On Sep 4, 2013, at 1:08 PM, Dave wrote: >> You could do that, but OP is using storyboards. In that case, the proper way >> to pass that info is in -prepareForSegue:. > > I took a look at prepareForSegue, but I'm not sure how it would help here? > > In the Storyboard I have a VC with a name of "LTWMusicViewController", there > is NOT a "LTWRockMusicViewController". > > when LTWMusicViewController - viewDidLoad gets called it sets the category to > ALL. > > when LTWRockMusicViewController - viewDidLoad gets calls [super viewDidLoad] > (in LTWMusicViewController), THEN set the Category to Rock. > > In LTWRockMusicViewController, I want all the functionality and Views etc. of > LTWMusicViewController BUT I want to set the to Rock. > > Since LTWRockMusicViewController is not in the Story board, I can't > instantiate it and so prepareForSegue won't be called. > > I could define prepareForSegue in LTWMusicViewController, BUT I don't want to > do anything special with this VC, I want to do it to > LTWRockMusicViewController. > > Thanks for your help. > > All the Best > Dave > > > > > ___ > > 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/david.duncan%40apple.com > > This email sent to david.dun...@apple.com -- David Duncan ___ 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
Re: iOS Deleting an Entity from Core Data
So you want to issue an app update that will not have that entity and in the same time will not force your users to delete the app and re-install it. To achieve that you will need to do a Core Data Migration. https://developer.apple.com/library/ios/documentation/cocoa/Conceptual/CoreDataVersioning/Articles/Introduction.html#//apple_ref/doc/uid/TP40004399-CH1-SW1 On Wed, Sep 4, 2013 at 3:55 PM, Dave wrote: > Hi, > > I want to remove an Entity from a Core Data Store (SQLite). I deleted it > in the model, but when I run the App now, it crashes with a "Z" table > already created error. I've also removed (AFAIK) all references to this in > the Project. This entity has no relationships and was basically created > ages ago but was never used, I now want to remove from the Store, but I > don't want this to crash for existing users! > > What do I have to do to delete Entity this from an existing Store? > > Thanks in Advance > Dave > > > ___ > > 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/finkel.alex%40gmail.com > > This email sent to finkel.a...@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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Subclassing a View Controller in a Storyboard
On 4 Sep 2013, at 21:12, David Duncan wrote:
> The point is, if the only difference between an LTWMusicViewController and an
> LTWRockMusicViewController is that the latter defaults to the “Rock”
> category, then you don’t actually *need* the LTWRockMusicViewController
> subclass. You just need to ensure that when you want an
> LTWMusicViewController created with the Rock category, that you ensure it is
> set as such.
>
> So in -prepareForSegue, you get the instance of LTWMusicViewController that
> is about to be transitioned to, set its category to Rock, and your done. No
> need for subclassing at all.
>
This code is in a method that takes the VC Class Name as a parameter, so, in
order to do what you suggest I would beed code something like:
Normally the code reads:
myVC = [self.storyboard instantiateViewController: theViewControllerClassName];
//passed to this method.
This works fine for LTWMusicViewController, but if I want
LTWRockMusicViewController, I need to add code to do this:
if ([theViewControllerClassName
isEqualToString:@"LTWRockMusicViewController"] == YES)
{
myVC = [self.storyboard
instantiateViewController:@"LTWMusicViewController"];
myVC.pMusicCategory = Rock;
}
else
myVC = [self.storyboard
instantiateViewController:theViewControllerClassName]; //passed to
this method.
return myVC;
Which is really messy since if I want a Blues, Jazz and HipHop Category, have
to keep adding to the class names to check, which sucks! It's much better OOP
to do the bits that are specific to LTWRockMusicViewController in the
LTWRockMusicViewController class! Why should the initiating method need to know
details of the VC's implementation?
Also, in this example I am showing only myVC.pMusicCategory, there could be
any number of "special" things that LTWRockMusicViewController might want to
do, that's why its overriding the base class!
Normally, if I wasn't using a Storyboard, I just do this:
myViewController = [[theViewControllerClassName class] initWithNib:
theViewControllerClassName bundle:nil];
Which would take care of it nicely, since myViewController will be subclassed
from LTWMusicViewController if theViewControllerClassName ==
LTWRockMusicViewController.
All I want to do is achieve the same thing using a Storyboard, but it's
beginning to look like it's not possible?!?!?
All the Best
Dave
___
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
iOS Deleting an Entity from Core Data
Hi, I want to remove an Entity from a Core Data Store (SQLite). I deleted it in the model, but when I run the App now, it crashes with a "Z" table already created error. I've also removed (AFAIK) all references to this in the Project. This entity has no relationships and was basically created ages ago but was never used, I now want to remove from the Store, but I don't want this to crash for existing users! What do I have to do to delete Entity this from an existing Store? Thanks in Advance Dave ___ 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
Re: Subclassing a View Controller in a Storyboard
> You could do that, but OP is using storyboards. In that case, the proper way > to pass that info is in -prepareForSegue:. I took a look at prepareForSegue, but I'm not sure how it would help here? In the Storyboard I have a VC with a name of "LTWMusicViewController", there is NOT a "LTWRockMusicViewController". when LTWMusicViewController - viewDidLoad gets called it sets the category to ALL. when LTWRockMusicViewController - viewDidLoad gets calls [super viewDidLoad] (in LTWMusicViewController), THEN set the Category to Rock. In LTWRockMusicViewController, I want all the functionality and Views etc. of LTWMusicViewController BUT I want to set the to Rock. Since LTWRockMusicViewController is not in the Story board, I can't instantiate it and so prepareForSegue won't be called. I could define prepareForSegue in LTWMusicViewController, BUT I don't want to do anything special with this VC, I want to do it to LTWRockMusicViewController. Thanks for your help. All the Best Dave ___ 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
NSTimezone and offset
Im working with NSTimezone and I need to get the current timezone offset, but I'm finding this more difficult than I think it should be. I thought it might just be the way I'm looking at things, but I don't think so. If create an NSTimezone object and then send that object a daylightSavingTimeOffset message, I get back, for Chicago, 3600. This is wrong, at least for my purposes, for two reasons: 1) The offset should negative. 2) Chicago is currently observing DST The value I would expect to see returned should be -3000. I get why the value 3600 is correct at least with respect to the magnitude, as I can see I have this link setup for my system: /etc/localtime -> /usr/share/zoneinfo/America/Chicago But, why is it not negative? How do I get the correct offset. TIA ___ 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
Re: NSTimezone and offset
You are confusing the method with secondsFromGMT CDT is 3600 seconds is one hour ahead of CST and the docs could be more clear about this method being self referential rather than GMT referential. Sent from my iPhone On 2013/09/05, at 13:21, Lorenzo Thurman wrote: > Im working with NSTimezone and I need to get the current timezone offset, but > I'm finding this more difficult than I think it should be. I thought it might > just be the way I'm looking at things, but I don't think so. > > If create an NSTimezone object and then send that object a > daylightSavingTimeOffset message, I get back, for Chicago, 3600. This is > wrong, at least for my purposes, for two reasons: > 1) The offset should negative. > 2) Chicago is currently observing DST > > The value I would expect to see returned should be -3000. I get why the value > 3600 is correct at least with respect to the magnitude, as I can see I have > this link setup for my system: > /etc/localtime -> /usr/share/zoneinfo/America/Chicago > > But, why is it not negative? How do I get the correct offset. > TIA > ___ > > 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: > ___ 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
