In my app, every time a user switches to a new view a sound will be played. Also, every time a button is tapped, a sound will be played.
The sounds to be played are the same for each case, so for example, sound.caf will be used many times and will be the same for every view.
My problem is that I cant think of a clever place to alloc these sounds, thats visible to all views. Is this possible? I dont want to alloc the sound everytime a view is created because I think it's a waste of time.
Is there someplace where I can alloc these sounds, and play them from any view in my program? Thanks!
The simplest solution would probably be to use the app delegate for that purpose because it's a singleton class (there is only one instance of it per application) and it can be accessed by any class easily: [UIApplication sharedApplication].delegate
You could set up the sound(s) in the applicationDidFinishLaunching: method so they're ready to go when your app is.
Related
Background:
I currently have a NSTimer running in my AppDel class (I also have a method to calculate the amount of time my app spends in the background and adds it to the total, in case anyone brings this up).
The timer is checked at different intervals to see if it has reached 12 hours, at 12 hours the app needs to refresh its data from the server.
When this occurs, I need to display a UIAlert which when its button is pressed:
• Pops off view controllers to the first view controller.
This “refresh” should only be able to occur on 3 (specific)view controllers out of 7 within my app.
The Question(s):
Is NSNotifcationCenter sufficient for my requirements?
Where I would add an observer only to the view controllers I want this to occur on?
Is there a better approach I should be taking?
ya you can implement the NSNotifcationCenter approach but best alternative is to use custom delegate approach .By this way your app will work according to apple guidelines and memory utilisation of app is also less.
Using NSNotificationCenter is a good approach when you need to send information about some event (for example need of refreshing app) and you want to make as few changes as possible, without redesign all app architecture. I recommend you https://github.com/AllinMobile/AIMObservers because is created to facilitate the work with NSNotificationCenter and NSNotification.
Lately I have been playing around with the bluetooth framework and grew a strong enough knowledge to start building an application. The only problem is that all the examples I found and all the practice I have made consist in putting the core bluetooth core code inside the same file as the UIView with which the user is interacting.
I would like my future application to have multiple views in which the BLE scan occurs on the background. I initially thought about creating an object with a name similar to bleDeviceFinder and pass this object through each view. However, after thinking about it I realised that if I want something to happen in the current view I need the function didDiscoverPeripheral to have direct access to the UIView objects which it is supposed to affect.
I know it is probably a stupid question, what would be the best way to do so? I was thinking maybe to set and alert and subscribe every view to that alert; is this a good solution?
A quasi singleton BTLEManager that you pass around in the app. It sends NSNotifications for events like discovery, and your ViewControllers observe these notifications. The truth (i.e. list of discovered devices) stays in BTLEManager. Once a viewController has received such a notification it asks the BTLEManager for the list of current devices and then the viewController changes your views accordingly. The Views should never talk to the BTLEManager directly.
That's how I would do it.
Lets say I have multiple View controller classes using the same UIAlertView *alertView. *alertView's delegate is set to a centralized delegate.
I do this because would like to use the .tag to do different things based on it.
The question is every time I invoke an alert view or dismiss it, what do i have to do to prevent a memory leak?
Should I not release every time? Or is this a very bad idea?
Thanks.
A UIAlertView may be "shown" from anywhere in your app. I have an app that the main UIViewController has a timer that every so often brings up a UIAlertView. When that timer goes off, even if my main view being shown is from a completely different UIViewController (and thus view) the Alert will come to front.
If you really want to "actively" bring up the UIAlertView from any of your UIViewControllers (lets say based upon a user action), then I would do one of two things.
1) setup my Application Delegate Object with the UIAlertView implemented there, with accessor methods for invoking (showing) the Alert view, and thus freeing it from there also, or
2) Generate a singleton like object with the AlertView implemented there!!!
In either case then you can simply dealloc your UIAlertView once within the dealloc routine you write for either of those placements, and alloc it only once when the object is initialized.
Just treat it like you would any other object. If you want to keep it around, assign it to a retained property like: self.myAlert. You still need to release it like you normally would when creating it. The retained property will take care of keeping it around for you.
Always keep your retains(alloc's, copy's, etc...) and releases balanced.
I want to make sure that all my initializations for my views and stuff are handled every time my application starts, even when it is called back after being sent to the background, such as with multitasking.
What's the best way to do this? should i use applicationDidBecomeActive to call viewDidLoad on my viewcontroller directly? I'm guessing this is not wise. I just want to make sure that stuff gets done on load every time the user calls up the app, no matter what state it is in at the time.
I have several apps published that do just that - call viewDidLoad on one or several UIViewControllers from applicationDidBecomeActive.
It works just fine. Apple doesn't object to it either.
However, be aware that if you have allocations in your viewDidLoad you need to either check for already allocated instances or release the instances you allocate in viewDidLoad when your app suspends. The same goes for DB connections that need to be closed, notification listeners, and so on.
As long as you watch for these elements and handle them correctly, the approach is valid and very usable.
How would I play songs or make a splash screen for my cocoa app? I know it's a simple question but I am a complete noob when it comes to cocoa.
You want to create an application delegate class and implement the -applicationWillFinishLaunching and -applicationDidFinishLaunching methods to display/hide your splash screen or start/stop your audio. You can connect an instance of this class as the application's delegate in Interface Builder in the project's MainMenu.xib.
Keep in mind that it's generally considered bad form to have to display a splash/load screen in Mac apps. If your app can start instantly and lazily load resources or load them in a background thread, it provides a much nicer experience for your users.
Barry is right, you have to get rid of this idea to use splash screens.. it's mainly a M$ Windows concept and it is kind of frustrating for the user to wait for the app to load itself, and I bet you won't load a thing and you just want to show a splash screen so you can feel important, but I'm telling you: apps with "marketing-only" splash screens are trash right from the beginning, because the user waits for absolutely nothing to load, and he/she will immediatelly get sick of seeing it every single time the app starts..
Now, about the songs.. I'll help you on this one, but I'm telling you again: it's useless, can't see the usefullness in having a sound play on every startup... so putting sound and a splash screen to your app startup will scare most users away, and your app won't made it!
So, to load a song you use the NSSound class like this:
NSSound *s = [[NSSound alloc] initWithContentsOfFile:songPath byReference:YES];
and then you can control it with the following methods:
[s play]
[s pause]
[s resume]
[s stop]