Re: Application Design
Thanks Steve. For completeness - what's the proper way to perform the
cleanup? Should another static method be created that releases the singleton
instance when the app is closed? i.e.
+ (void)releaseSharedInterface
{
[sharedInstance release];
sharedInsance = nil;
}
D
On 1 June 2011 09:54, Dan Hopwood d...@biasdevelopment.com wrote:
Great, thanks a lot Steve - very helpful.
D
On 31 May 2011 18:44, Steve Christensen puns...@mac.com wrote:
How about providing a singleton class method? Then you just
include WebServiceInterface.h where needed. No need to have a global
variable.
@implementation WebServiceInterface
...
+ (WebServiceInterface*) sharedInterface
{
static WebServiceInterface* sharedInstance = nil;
if (sharedInstance == nil)
sharedInstance = [[WebServiceInterface alloc] init];
return sharedInstance;
}
...
@end
foo = [[WebServiceInterface sharedInterface] someMethod];
On May 31, 2011, at 3:25 AM, Dan Hopwood wrote:
Thanks for all your answers, they make complete sense.
I have one more related question. I have developed a custom, stateful
WebServiceInterface object, which manages all connection requests made to an
XML-RPC server. Being stateful, I initialise this object when the app
launches and at the moment I store a pointer to it in a header file, which I
include in all view controllers. This allows me to make a request for data
from anywhere. In a similar way, I feel that storing a global pointer is not
best practise and can't help but think there is a more elegant way of doing
this. One option I have considered if storing/initialising the object in the
app delegate and then creating a utility method in the delegate that wraps
the object call. Is this the best solution or is there a design pattern I am
unaware of?
Many thanks!
On 28 May 2011 19:15, Conrad Shultz con...@synthetiqsolutions.comwrote:
On May 28, 2011, at 6:11, Dan Hopwood d...@biasdevelopment.com wrote:
Thanks for your response Steve. I have considered using the
nsnotification service but what if you need to not only let another
object know when an event has occurred but you also need to send that
object some data? For example a user selects an option in a table -
the selection must be conveyed in some way to the vc I'm pushing on
the nav controller stack so that it's view is dynamic depending on the
selection. As far as I'm aware that is not possible using
notifications.
That's very doable with notifications. See the object and userInfo
methods in NSNotification and corresponding methods in NSNotificationCenter.
In general I create a new vc/nib for *every* screen I have in the app.
Let's take a navigation app as an example. Are you saying that the
hierarchy should be:
- 'root view controller' (has overall control, contains navigation
logic and sends data between the containing view controllers)
-- 'nav controller'
-- 'all view controllers to be pushed/popped'
...where the nav controller and its view controllers are stored and
initialised inside the 'root view controller'?
Well, I'd say the view controllers aren't stored inside the root view
controller; they are pushed onto the navigation stack as and when needed.
Unless you are doing some caching, I wouldn't store the view controllers
outside the navigation stack. (If you do implement caching, make sure you
respond to memory warnings by flushing the cache!)
In a navigation based application I feel that your architecture is
simplified by design. Since only one view controller (notwithstanding modal
view controllers) is on screen at any time, and they are all arranged
hierarchically, parents should configure their children before pushing them
onto the stack. When children need to communicate back to their parents (for
example, if you push an editor view controller from a summary view
controller, which needs to be updated when the editor view controller makes
changes), you can use KVO or notifications, but if the communication is by
design of interest only to the parent and child view controllers, just make
the parent the delegate of the child. So if the child, say, had a list of
favorite URLs for the user to select, it could call something like [delegate
didSelectFavorite:url] which would cause the parent to be updated (and
change appearance when the child is popped off the stack).
--
Director, Bias Development Ltd.
*e* d...@biasdevelopment.com
*m* +44 (0) 7748 544356
___
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: Application Design
Why do you need to do any explicit cleanup on app termination? App memory
disappears (poof!) so it's not like you're leaking anything. Is your class
holding onto some state that must be written out to disk, for example?
On Jun 1, 2011, at 3:54 AM, Dan Hopwood wrote:
Thanks Steve. For completeness - what's the proper way to perform the
cleanup? Should another static method be created that releases the singleton
instance when the app is closed? i.e.
+ (void)releaseSharedInterface
{
[sharedInstance release];
sharedInsance = nil;
}
D
On 1 June 2011 09:54, Dan Hopwood d...@biasdevelopment.com wrote:
Great, thanks a lot Steve - very helpful.
D
On 31 May 2011 18:44, Steve Christensen puns...@mac.com wrote:
How about providing a singleton class method? Then you just include
WebServiceInterface.h where needed. No need to have a global variable.
@implementation WebServiceInterface
...
+ (WebServiceInterface*) sharedInterface
{
static WebServiceInterface* sharedInstance = nil;
if (sharedInstance == nil)
sharedInstance = [[WebServiceInterface alloc] init];
return sharedInstance;
}
...
@end
foo = [[WebServiceInterface sharedInterface] someMethod];
On May 31, 2011, at 3:25 AM, Dan Hopwood wrote:
Thanks for all your answers, they make complete sense.
I have one more related question. I have developed a custom, stateful
WebServiceInterface object, which manages all connection requests made to an
XML-RPC server. Being stateful, I initialise this object when the app
launches and at the moment I store a pointer to it in a header file, which I
include in all view controllers. This allows me to make a request for data
from anywhere. In a similar way, I feel that storing a global pointer is not
best practise and can't help but think there is a more elegant way of doing
this. One option I have considered if storing/initialising the object in the
app delegate and then creating a utility method in the delegate that wraps
the object call. Is this the best solution or is there a design pattern I am
unaware of?
Many thanks!
On 28 May 2011 19:15, Conrad Shultz con...@synthetiqsolutions.com wrote:
On May 28, 2011, at 6:11, Dan Hopwood d...@biasdevelopment.com wrote:
Thanks for your response Steve. I have considered using the
nsnotification service but what if you need to not only let another
object know when an event has occurred but you also need to send that
object some data? For example a user selects an option in a table -
the selection must be conveyed in some way to the vc I'm pushing on
the nav controller stack so that it's view is dynamic depending on the
selection. As far as I'm aware that is not possible using
notifications.
That's very doable with notifications. See the object and userInfo
methods in NSNotification and corresponding methods in NSNotificationCenter.
In general I create a new vc/nib for *every* screen I have in the app.
Let's take a navigation app as an example. Are you saying that the
hierarchy should be:
- 'root view controller' (has overall control, contains navigation
logic and sends data between the containing view controllers)
-- 'nav controller'
-- 'all view controllers to be pushed/popped'
...where the nav controller and its view controllers are stored and
initialised inside the 'root view controller'?
Well, I'd say the view controllers aren't stored inside the root view
controller; they are pushed onto the navigation stack as and when needed.
Unless you are doing some caching, I wouldn't store the view controllers
outside the navigation stack. (If you do implement caching, make sure you
respond to memory warnings by flushing the cache!)
In a navigation based application I feel that your architecture is
simplified by design. Since only one view controller (notwithstanding modal
view controllers) is on screen at any time, and they are all arranged
hierarchically, parents should configure their children before pushing them
onto the stack. When children need to communicate back to their parents (for
example, if you push an editor view controller from a summary view
controller, which needs to be updated when the editor view controller makes
changes), you can use KVO or notifications, but if the communication is by
design of interest only to the parent and child view controllers, just make
the parent the delegate of the child. So if the child, say, had a list of
favorite URLs for the user to select, it could call something like [delegate
didSelectFavorite:url] which would cause the parent to be updated (and
change appearance when the child is popped off the stack).
___
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
Re: Application Design
I'll caution you as written that singleton is not be thread safe. Often you
don't care, because you only have one thread or because creating 2 webservice
clients may not be a problem for you.
On Jun 1, 2011, at 3:54 AM, Dan Hopwood d...@biasdevelopment.com wrote:
Thanks Steve. For completeness - what's the proper way to perform the
cleanup? Should another static method be created that releases the singleton
instance when the app is closed? i.e.
+ (void)releaseSharedInterface
{
[sharedInstance release];
sharedInsance = nil;
}
D
On 1 June 2011 09:54, Dan Hopwood d...@biasdevelopment.com wrote:
Great, thanks a lot Steve - very helpful.
D
On 31 May 2011 18:44, Steve Christensen puns...@mac.com wrote:
How about providing a singleton class method? Then you just
include WebServiceInterface.h where needed. No need to have a global
variable.
@implementation WebServiceInterface
...
+ (WebServiceInterface*) sharedInterface
{
static WebServiceInterface* sharedInstance = nil;
if (sharedInstance == nil)
sharedInstance = [[WebServiceInterface alloc] init];
return sharedInstance;
}
...
@end
foo = [[WebServiceInterface sharedInterface] someMethod];
On May 31, 2011, at 3:25 AM, Dan Hopwood wrote:
Thanks for all your answers, they make complete sense.
I have one more related question. I have developed a custom, stateful
WebServiceInterface object, which manages all connection requests made to an
XML-RPC server. Being stateful, I initialise this object when the app
launches and at the moment I store a pointer to it in a header file, which I
include in all view controllers. This allows me to make a request for data
from anywhere. In a similar way, I feel that storing a global pointer is not
best practise and can't help but think there is a more elegant way of doing
this. One option I have considered if storing/initialising the object in the
app delegate and then creating a utility method in the delegate that wraps
the object call. Is this the best solution or is there a design pattern I am
unaware of?
Many thanks!
On 28 May 2011 19:15, Conrad Shultz con...@synthetiqsolutions.comwrote:
On May 28, 2011, at 6:11, Dan Hopwood d...@biasdevelopment.com wrote:
Thanks for your response Steve. I have considered using the
nsnotification service but what if you need to not only let another
object know when an event has occurred but you also need to send that
object some data? For example a user selects an option in a table -
the selection must be conveyed in some way to the vc I'm pushing on
the nav controller stack so that it's view is dynamic depending on the
selection. As far as I'm aware that is not possible using
notifications.
That's very doable with notifications. See the object and userInfo
methods in NSNotification and corresponding methods in
NSNotificationCenter.
In general I create a new vc/nib for *every* screen I have in the app.
Let's take a navigation app as an example. Are you saying that the
hierarchy should be:
- 'root view controller' (has overall control, contains navigation
logic and sends data between the containing view controllers)
-- 'nav controller'
-- 'all view controllers to be pushed/popped'
...where the nav controller and its view controllers are stored and
initialised inside the 'root view controller'?
Well, I'd say the view controllers aren't stored inside the root view
controller; they are pushed onto the navigation stack as and when needed.
Unless you are doing some caching, I wouldn't store the view controllers
outside the navigation stack. (If you do implement caching, make sure you
respond to memory warnings by flushing the cache!)
In a navigation based application I feel that your architecture is
simplified by design. Since only one view controller (notwithstanding
modal
view controllers) is on screen at any time, and they are all arranged
hierarchically, parents should configure their children before pushing them
onto the stack. When children need to communicate back to their parents
(for
example, if you push an editor view controller from a summary view
controller, which needs to be updated when the editor view controller makes
changes), you can use KVO or notifications, but if the communication is by
design of interest only to the parent and child view controllers, just make
the parent the delegate of the child. So if the child, say, had a list of
favorite URLs for the user to select, it could call something like
[delegate
didSelectFavorite:url] which would cause the parent to be updated (and
change appearance when the child is popped off the stack).
--
Director, Bias Development Ltd.
*e* d...@biasdevelopment.com
*m* +44 (0) 7748 544356
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the
Re: Application Design
Yep, that's true. I was going for the simple case since, unless you
specifically plan to reference the singleton from multiple threads, you don't
need to do anything more fancy.
On Jun 1, 2011, at 5:05 PM, Andrew Thompson wrote:
I'll caution you as written that singleton is not be thread safe. Often you
don't care, because you only have one thread or because creating 2 webservice
clients may not be a problem for you.
On Jun 1, 2011, at 3:54 AM, Dan Hopwood d...@biasdevelopment.com wrote:
Thanks Steve. For completeness - what's the proper way to perform the
cleanup? Should another static method be created that releases the singleton
instance when the app is closed? i.e.
+ (void)releaseSharedInterface
{
[sharedInstance release];
sharedInsance = nil;
}
D
On 1 June 2011 09:54, Dan Hopwood d...@biasdevelopment.com wrote:
Great, thanks a lot Steve - very helpful.
D
On 31 May 2011 18:44, Steve Christensen puns...@mac.com wrote:
How about providing a singleton class method? Then you just
include WebServiceInterface.h where needed. No need to have a global
variable.
@implementation WebServiceInterface
...
+ (WebServiceInterface*) sharedInterface
{
static WebServiceInterface* sharedInstance = nil;
if (sharedInstance == nil)
sharedInstance = [[WebServiceInterface alloc] init];
return sharedInstance;
}
...
@end
foo = [[WebServiceInterface sharedInterface] someMethod];
On May 31, 2011, at 3:25 AM, Dan Hopwood wrote:
Thanks for all your answers, they make complete sense.
I have one more related question. I have developed a custom, stateful
WebServiceInterface object, which manages all connection requests made to
an
XML-RPC server. Being stateful, I initialise this object when the app
launches and at the moment I store a pointer to it in a header file, which
I
include in all view controllers. This allows me to make a request for data
from anywhere. In a similar way, I feel that storing a global pointer is
not
best practise and can't help but think there is a more elegant way of doing
this. One option I have considered if storing/initialising the object in
the
app delegate and then creating a utility method in the delegate that wraps
the object call. Is this the best solution or is there a design pattern I
am
unaware of?
Many thanks!
On 28 May 2011 19:15, Conrad Shultz con...@synthetiqsolutions.comwrote:
On May 28, 2011, at 6:11, Dan Hopwood d...@biasdevelopment.com wrote:
Thanks for your response Steve. I have considered using the
nsnotification service but what if you need to not only let another
object know when an event has occurred but you also need to send that
object some data? For example a user selects an option in a table -
the selection must be conveyed in some way to the vc I'm pushing on
the nav controller stack so that it's view is dynamic depending on the
selection. As far as I'm aware that is not possible using
notifications.
That's very doable with notifications. See the object and userInfo
methods in NSNotification and corresponding methods in
NSNotificationCenter.
In general I create a new vc/nib for *every* screen I have in the app.
Let's take a navigation app as an example. Are you saying that the
hierarchy should be:
- 'root view controller' (has overall control, contains navigation
logic and sends data between the containing view controllers)
-- 'nav controller'
-- 'all view controllers to be pushed/popped'
...where the nav controller and its view controllers are stored and
initialised inside the 'root view controller'?
Well, I'd say the view controllers aren't stored inside the root view
controller; they are pushed onto the navigation stack as and when needed.
Unless you are doing some caching, I wouldn't store the view controllers
outside the navigation stack. (If you do implement caching, make sure you
respond to memory warnings by flushing the cache!)
In a navigation based application I feel that your architecture is
simplified by design. Since only one view controller (notwithstanding
modal
view controllers) is on screen at any time, and they are all arranged
hierarchically, parents should configure their children before pushing
them
onto the stack. When children need to communicate back to their parents
(for
example, if you push an editor view controller from a summary view
controller, which needs to be updated when the editor view controller
makes
changes), you can use KVO or notifications, but if the communication is by
design of interest only to the parent and child view controllers, just
make
the parent the delegate of the child. So if the child, say, had a list of
favorite URLs for the user to select, it could call something like
[delegate
didSelectFavorite:url] which would cause the parent to be updated (and
change appearance when the child is popped off the stack).
Re: Application Design
Thanks for all your answers, they make complete sense. I have one more related question. I have developed a custom, stateful WebServiceInterface object, which manages all connection requests made to an XML-RPC server. Being stateful, I initialise this object when the app launches and at the moment I store a pointer to it in a header file, which I include in all view controllers. This allows me to make a request for data from anywhere. In a similar way, I feel that storing a global pointer is not best practise and can't help but think there is a more elegant way of doing this. One option I have considered if storing/initialising the object in the app delegate and then creating a utility method in the delegate that wraps the object call. Is this the best solution or is there a design pattern I am unaware of? Many thanks! On 28 May 2011 19:15, Conrad Shultz con...@synthetiqsolutions.com wrote: On May 28, 2011, at 6:11, Dan Hopwood d...@biasdevelopment.com wrote: Thanks for your response Steve. I have considered using the nsnotification service but what if you need to not only let another object know when an event has occurred but you also need to send that object some data? For example a user selects an option in a table - the selection must be conveyed in some way to the vc I'm pushing on the nav controller stack so that it's view is dynamic depending on the selection. As far as I'm aware that is not possible using notifications. That's very doable with notifications. See the object and userInfo methods in NSNotification and corresponding methods in NSNotificationCenter. In general I create a new vc/nib for *every* screen I have in the app. Let's take a navigation app as an example. Are you saying that the hierarchy should be: - 'root view controller' (has overall control, contains navigation logic and sends data between the containing view controllers) -- 'nav controller' -- 'all view controllers to be pushed/popped' ...where the nav controller and its view controllers are stored and initialised inside the 'root view controller'? Well, I'd say the view controllers aren't stored inside the root view controller; they are pushed onto the navigation stack as and when needed. Unless you are doing some caching, I wouldn't store the view controllers outside the navigation stack. (If you do implement caching, make sure you respond to memory warnings by flushing the cache!) In a navigation based application I feel that your architecture is simplified by design. Since only one view controller (notwithstanding modal view controllers) is on screen at any time, and they are all arranged hierarchically, parents should configure their children before pushing them onto the stack. When children need to communicate back to their parents (for example, if you push an editor view controller from a summary view controller, which needs to be updated when the editor view controller makes changes), you can use KVO or notifications, but if the communication is by design of interest only to the parent and child view controllers, just make the parent the delegate of the child. So if the child, say, had a list of favorite URLs for the user to select, it could call something like [delegate didSelectFavorite:url] which would cause the parent to be updated (and change appearance when the child is popped off the stack). (Sent from my iPad.) -- Conrad Shultz www.synthetiqsolutions.com -- Director, Bias Development Ltd. *e* d...@biasdevelopment.com *m* +44 (0) 7748 544356 ___ 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: Application Design
How about providing a singleton class method? Then you just include
WebServiceInterface.h where needed. No need to have a global variable.
@implementation WebServiceInterface
...
+ (WebServiceInterface*) sharedInterface
{
static WebServiceInterface* sharedInstance = nil;
if (sharedInstance == nil)
sharedInstance = [[WebServiceInterface alloc] init];
return sharedInstance;
}
...
@end
foo = [[WebServiceInterface sharedInterface] someMethod];
On May 31, 2011, at 3:25 AM, Dan Hopwood wrote:
Thanks for all your answers, they make complete sense.
I have one more related question. I have developed a custom, stateful
WebServiceInterface object, which manages all connection requests made to an
XML-RPC server. Being stateful, I initialise this object when the app
launches and at the moment I store a pointer to it in a header file, which I
include in all view controllers. This allows me to make a request for data
from anywhere. In a similar way, I feel that storing a global pointer is not
best practise and can't help but think there is a more elegant way of doing
this. One option I have considered if storing/initialising the object in the
app delegate and then creating a utility method in the delegate that wraps
the object call. Is this the best solution or is there a design pattern I am
unaware of?
Many thanks!
On 28 May 2011 19:15, Conrad Shultz con...@synthetiqsolutions.com wrote:
On May 28, 2011, at 6:11, Dan Hopwood d...@biasdevelopment.com wrote:
Thanks for your response Steve. I have considered using the
nsnotification service but what if you need to not only let another
object know when an event has occurred but you also need to send that
object some data? For example a user selects an option in a table -
the selection must be conveyed in some way to the vc I'm pushing on
the nav controller stack so that it's view is dynamic depending on the
selection. As far as I'm aware that is not possible using
notifications.
That's very doable with notifications. See the object and userInfo
methods in NSNotification and corresponding methods in NSNotificationCenter.
In general I create a new vc/nib for *every* screen I have in the app.
Let's take a navigation app as an example. Are you saying that the
hierarchy should be:
- 'root view controller' (has overall control, contains navigation
logic and sends data between the containing view controllers)
-- 'nav controller'
-- 'all view controllers to be pushed/popped'
...where the nav controller and its view controllers are stored and
initialised inside the 'root view controller'?
Well, I'd say the view controllers aren't stored inside the root view
controller; they are pushed onto the navigation stack as and when needed.
Unless you are doing some caching, I wouldn't store the view controllers
outside the navigation stack. (If you do implement caching, make sure you
respond to memory warnings by flushing the cache!)
In a navigation based application I feel that your architecture is simplified
by design. Since only one view controller (notwithstanding modal view
controllers) is on screen at any time, and they are all arranged
hierarchically, parents should configure their children before pushing them
onto the stack. When children need to communicate back to their parents (for
example, if you push an editor view controller from a summary view
controller, which needs to be updated when the editor view controller makes
changes), you can use KVO or notifications, but if the communication is by
design of interest only to the parent and child view controllers, just make
the parent the delegate of the child. So if the child, say, had a list of
favorite URLs for the user to select, it could call something like [delegate
didSelectFavorite:url] which would cause the parent to be updated (and change
appearance when the child is popped off the stack).
___
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: Application Design
Thanks for your response Steve. I have considered using the nsnotification service but what if you need to not only let another object know when an event has occurred but you also need to send that object some data? For example a user selects an option in a table - the selection must be conveyed in some way to the vc I'm pushing on the nav controller stack so that it's view is dynamic depending on the selection. As far as I'm aware that is not possible using notifications. In general I create a new vc/nib for *every* screen I have in the app. Let's take a navigation app as an example. Are you saying that the hierarchy should be: - 'root view controller' (has overall control, contains navigation logic and sends data between the containing view controllers) -- 'nav controller' -- 'all view controllers to be pushed/popped' ...where the nav controller and its view controllers are stored and initialised inside the 'root view controller'? Many thanks, Dan Sent from my iPad On May 27, 2011, at 20:19, Steve Christensen puns...@mac.com wrote: A view controller controls a specific view hierarchy so it shouldn't be reaching explicitly out to other view controllers to tell them to do something. Depending on your specific situation, interested objects could register for notifications when certain things change in the world, then one object could just broadcast that something changed and not worry about what other objects care. Or you could synch a controller's state (and possibly its view(s)) in its -viewWillAppear: method since in many cases only a single controller's view hierarchy is visible at any one time. On May 27, 2011, at 11:13 AM, Dan Hopwood wrote: I have been writing iPhone applications for a while now, with not too many problems but I feel like I haven't fully grasped how an application should be structured in terms of storing application objects. e.g. up to now, I've created a header file, declared all the main objects e.g. app delegate, view controllers, utilities and initialised them in the app delegate. For each class, I then just include the header file, which gives me access to all the objects, should I need to send them messages on certain UI events. Another option I have considered is storing them all in the app delegate instead and creating utility methods in the app delegate that delegate out to the objects from one place. E.g. a VC would then call the app delegate each time it needs to interact with another VC. If neither of these options is valid, which I suspect is the case (certainly global pointers is considered to be bad practise), then how do you store these pointers to that they are accessible in some way by all the VCs. Sending in the required pointers on initialisation of each VC (and storing a copy in each class) is the only other option I can think of but this seems annoyingly unelegant. Thoughts and suggestions much appreciated. ___ 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: Application Design
On May 28, 2011, at 6:11, Dan Hopwood d...@biasdevelopment.com wrote: Thanks for your response Steve. I have considered using the nsnotification service but what if you need to not only let another object know when an event has occurred but you also need to send that object some data? For example a user selects an option in a table - the selection must be conveyed in some way to the vc I'm pushing on the nav controller stack so that it's view is dynamic depending on the selection. As far as I'm aware that is not possible using notifications. That's very doable with notifications. See the object and userInfo methods in NSNotification and corresponding methods in NSNotificationCenter. In general I create a new vc/nib for *every* screen I have in the app. Let's take a navigation app as an example. Are you saying that the hierarchy should be: - 'root view controller' (has overall control, contains navigation logic and sends data between the containing view controllers) -- 'nav controller' -- 'all view controllers to be pushed/popped' ...where the nav controller and its view controllers are stored and initialised inside the 'root view controller'? Well, I'd say the view controllers aren't stored inside the root view controller; they are pushed onto the navigation stack as and when needed. Unless you are doing some caching, I wouldn't store the view controllers outside the navigation stack. (If you do implement caching, make sure you respond to memory warnings by flushing the cache!) In a navigation based application I feel that your architecture is simplified by design. Since only one view controller (notwithstanding modal view controllers) is on screen at any time, and they are all arranged hierarchically, parents should configure their children before pushing them onto the stack. When children need to communicate back to their parents (for example, if you push an editor view controller from a summary view controller, which needs to be updated when the editor view controller makes changes), you can use KVO or notifications, but if the communication is by design of interest only to the parent and child view controllers, just make the parent the delegate of the child. So if the child, say, had a list of favorite URLs for the user to select, it could call something like [delegate didSelectFavorite:url] which would cause the parent to be updated (and change appearance when the child is popped off the stack). (Sent from my iPad.) -- Conrad Shultz www.synthetiqsolutions.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
Application Design
Hi all, I have been writing iPhone applications for a while now, with not too many problems but I feel like I haven't fully grasped how an application should be structured in terms of storing application objects. e.g. up to now, I've created a header file, declared all the main objects e.g. app delegate, view controllers, utilities and initialised them in the app delegate. For each class, I then just include the header file, which gives me access to all the objects, should I need to send them messages on certain UI events. Another option I have considered is storing them all in the app delegate instead and creating utility methods in the app delegate that delegate out to the objects from one place. E.g. a VC would then call the app delegate each time it needs to interact with another VC. If neither of these options is valid, which I suspect is the case (certainly global pointers is considered to be bad practise), then how do you store these pointers to that they are accessible in some way by all the VCs. Sending in the required pointers on initialisation of each VC (and storing a copy in each class) is the only other option I can think of but this seems annoyingly unelegant. Thoughts and suggestions much appreciated. Dan ___ 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: Application Design
A view controller controls a specific view hierarchy so it shouldn't be reaching explicitly out to other view controllers to tell them to do something. Depending on your specific situation, interested objects could register for notifications when certain things change in the world, then one object could just broadcast that something changed and not worry about what other objects care. Or you could synch a controller's state (and possibly its view(s)) in its -viewWillAppear: method since in many cases only a single controller's view hierarchy is visible at any one time. On May 27, 2011, at 11:13 AM, Dan Hopwood wrote: I have been writing iPhone applications for a while now, with not too many problems but I feel like I haven't fully grasped how an application should be structured in terms of storing application objects. e.g. up to now, I've created a header file, declared all the main objects e.g. app delegate, view controllers, utilities and initialised them in the app delegate. For each class, I then just include the header file, which gives me access to all the objects, should I need to send them messages on certain UI events. Another option I have considered is storing them all in the app delegate instead and creating utility methods in the app delegate that delegate out to the objects from one place. E.g. a VC would then call the app delegate each time it needs to interact with another VC. If neither of these options is valid, which I suspect is the case (certainly global pointers is considered to be bad practise), then how do you store these pointers to that they are accessible in some way by all the VCs. Sending in the required pointers on initialisation of each VC (and storing a copy in each class) is the only other option I can think of but this seems annoyingly unelegant. Thoughts and suggestions much appreciated. ___ 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
Application Design Question
Hello everyone. I have a DVR (digital video recorder) program I wrote in Windows that I want to re-write on the Mac. And I wanted to get some ideas about how best to use Cocoa objects to make this program work as I'm still relatively new to Cocoa programming. The application has 2 modes, one is capturing video from a camera of any sort, a NTSC capture card, usb, ethernet, etc, that isn't a big deal since that'd just be its own thread. However I want to display the incoming video live on screen with the minimum of CPU loading as well as being able to scale the data and do some basic manipulations on it, perhaps including whats in Core Image. The incoming data is often 8-bit monochrome and needs to be scaled to 8-bit grey for screen display. The other mode is playing back a file, either frame by frame or playing back the video at a user settable frame rate. I'd like to be able to have multiple sets of both open at once. Another question related to this is what API set provides the fastest disk IO under Mac OS X? On the windows side I used FILE_FLAG_NO_BUFFERING and FILE_FLAG_WRITE_THROUGH flags with the ReadFile/WriteFile API. My thoughts are perhaps NSDocument with NSView's that use Core Animation for displaying everything assuming there is a way to sequence bitmaps into Core Animation. But perhaps there is a better way? Also I might want to do secondary floating windows that display histograms or camera controls, etc. The file formats are a proprietary format and not related to Quicktime or Windows Media, etc. Thanks -Marek ___ 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: Application Design Question
On Sep 4, 2009, at 4:55 PM, Marek Kozubal wrote: Another question related to this is what API set provides the fastest disk IO under Mac OS X? On the windows side I used FILE_FLAG_NO_BUFFERING and FILE_FLAG_WRITE_THROUGH flags with the ReadFile/WriteFile API. The fastest will be the low-level POSIX I/O calls (open / write / etc.). To disable caching, call fcntl() using the F_NOCACHE operand. Try to read/write as much as you can in one call -- on the write side, the writev() function can be very useful. For details you might want to look into the Big Nerd Ranch Advanced Mac OS X Programming book, or for that matter, any book that covers Unix file I/O in depth. —Jens___ 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: Questions on An NSOpenGL Application Design
Carmen, I don't know anything about reading pixels back from VRAM and this CPU analysis you refer to. Why do you need to do that again? You might want to look into using Core Animation for what you are trying to do. For that matter, you could very easily create a simple Quartz Composition that you can load into a QCCompositionLayer (Core Animation) and then apply filters on top of that. If all you are doing is obtaining filter values set by the user (e.g. input radius for a blur, etc.), then you can do this quite easily. Take a look at this blog post to see using a QCCompositionLayer in action: http://www.cimgf.com/2008/09/24/core-animation-tutorial-core-animation-and-quartz-composer-qccompositionlayer/ In fact, better yet, look into using a QTCaptureLayer (also Core Animation). It's simply a capture view that can also easily be overlayed with any kind of Core Image filter. Asking such a broad design question (i.e. should I stick with this design?) may not be the most efficient way of getting what you need. I suggest you try a few things with your own design, post questions here about what is going wrong, and people will most certainly correct your design decisions should they need correcting. Best regards, -Matt On Sep 29, 2008, at 8:03 PM, Carmen Cerino Jr. wrote: When my application starts up, the user is presented with a settings window. It contains a view that will be attached to a web camera, and some widgets to control various filter settings. Once the settings are tweaked to the user's desire, the window will be closed, but the camera will still be processing images. In addition to standard CIFilters, I will also need to read the pixels back in from VRAM to perform an analysis on the CPU that I have yet to transform into a CIFilter. The way I plan on designing this application is to have an NSOpenGLView subclass to display my camera feed, and another class to control the camera and all of the image processing. Questions: 1. Should I stick with this design path? Some of the sample code I have seen puts what I have broken down into two classes all in the NSOpenGLView subclass, ie CIVideoDemoGL. 2. If I leave the code in two seperate files, do I need two OpenGLContexts, one for the view and one to link to a CIContext for the image filters, or can I just use the one from the NSOpenGLView? 3. When I bring the images back in from the GPU they will already be rendered with the CIFilters, so is it worth it to push them back out to OpenGL for drawing? ___ 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 [EMAIL PROTECTED]
Questions on An NSOpenGL Application Design
When my application starts up, the user is presented with a settings window. It contains a view that will be attached to a web camera, and some widgets to control various filter settings. Once the settings are tweaked to the user's desire, the window will be closed, but the camera will still be processing images. In addition to standard CIFilters, I will also need to read the pixels back in from VRAM to perform an analysis on the CPU that I have yet to transform into a CIFilter. The way I plan on designing this application is to have an NSOpenGLView subclass to display my camera feed, and another class to control the camera and all of the image processing. Questions: 1. Should I stick with this design path? Some of the sample code I have seen puts what I have broken down into two classes all in the NSOpenGLView subclass, ie CIVideoDemoGL. 2. If I leave the code in two seperate files, do I need two OpenGLContexts, one for the view and one to link to a CIContext for the image filters, or can I just use the one from the NSOpenGLView? 3. When I bring the images back in from the GPU they will already be rendered with the CIFilters, so is it worth it to push them back out to OpenGL for drawing? ___ 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 [EMAIL PROTECTED]
