I've some simple sounds and I have multiple View Controllers and I wonder how to use sounds in every controller in my app. Should I create an extension, protocol, struct or something else? What would be the best OOP approach? There are plenty of tutorials but none of them shows how to efficiently use sounds in your app.
With your context, I suggest you to write something like SoundService, and declare it as a singleton. So every controller has the access to this service. The parameter for the service is something like sound file names.
This service will be used in the app, anytime the controller wants to play a sound, just call a method in the singleton. That will make your code looks better, and if you find any problem related to Sound, you know where to find the problem.
Related
I'm pretty new in programming in swift. Right now I'm halfway through a course and really loving it. Right now I'm a musician and before I started this course, I already had an idea of what app to make. So I started making this Music Play along app and am pretty happy already with how it's coming together. On to my question :
I've been coding all of my functions, variables and outlets into the main ViewController.swift file. It's becoming a pretty long read and I was thinking if it would be better to separate some functions in different swift files. Now as I understand it, different .swift files come into play if you create classes that aren't directly related to each other, but so far all of my code is related to this single ViewController aka the main screen. Disregarding the efficiency that probably could be better in my coding, should I keep on going in this single file, or should I start differentiating some parts of my code and put them in their own swift files?
Alright thanks in advance and also, thank you SO much for all the invaluable information on this website. This is a pretty amazing community.
-Patrick
First of all, I structure my code like this: the ViewController is divided into 3 files, in the first there is the declaration and also the override methods and obj-C methods, in the second file I put the delegate, on extension for each delegate and in the first there is a unique extension where I put all the helper methods.
If the application contains only one ViewController you can leave all inside the main, but if the app will be a more complicated and structured, it's better you create a second viewController presented by the parent ViewController where you perform all what you need to do.
Say I am switching Views via a segue and I know that most of the data I want to pass to a new VC will get passed to multiple other VCs in later segues. I am pretty new to swift/cocoa development, but as far as I am concerned, the standard way of passing this data would be via the prepareForSegue function. This seems to be pretty repetitive though, as I am passing the same data over and over again. Wouldn't it be easier to have some kind of singleton class to store that data and manipulate it with the current VC? I'm pretty sure Apple has a better solution for this though.
Is it ok to use singletons for this kind of scenario or is there a better way?
Singletons can be accessed directly from anywhere in the app. Singletons introduce coupling in your code and make your objects hard to test.
There are two ways to pass data forward.
Passing data when a segue is performed
Passing data when a transition is performed through code
Both could be boring but I think there is no way except them.
i am very new to ios development, rather i have just started work on my first app. Now my app has a home button on almost every page and behind that button the same code snippet is called to move to the home screen. This is a lot of duplicate code in every controller that has a home button. And it is just an example. There are many other scenarios like this and programmer still learning to code, i think its bad practice as any change will have to be made separately on every controller.
So my question, what are the best practices in scenarios like this when coding for ios??
One easy thing to do in this situation is to make a UIViewController subclass (MyAppMasterVC, for instance) and define your button as so:
- (IBAction)myCommonButtonAction { // code and such }
In all of your view controllers, inherit from this one instead of UIViewController (a la #interface MyNewViewController : MyAppMasterVC).
The first thing to do is to learn more about OO programming and class hierarchy, and understand how you can make a common base class for all of your similar controllers.
Software development for iOS in this sense is no different from any other software development. Simply merge your logic into some common class or function, and use that as it deems appropriate. It often turns out that you don't know what part could be common and reusable until you write multiple pieces of code, and only then you realize that it all could be one function. The process of organising existing code, cleaning it up, making it more readable and reusable is called code refactoring. There are a lot of books on refactoring that explain different design patterns, techniques and processes of making your code better. I recommend you read some of them to get a better picture.
This problem is language/platform agnostic. The term many use is 'DRY', an acronym for 'Do not Repeat Yourself'.
Here is a SO search. This should help you with the typical problems and uses, so you can better determine whether you can, when you should, and how to approach this type of problem.
I am developing an iOS app where I am recording sound from the devices mic, saving it to a wav, then it needs to be accessed and played from a different view controller. As I understand, a FMOD::System object can only be defined in one view controller.
What would be the best way to access FMOD in more than one view controller?
I have tried using a Singleton class, however with objective-c's lack of class (non-instance) variables, I am not sure how declare the FMOD::System variable.
Has anyone successfully implemented what I am trying to do? Any help appreciated!
Thanks
I ended up making a singleton class and got it working.
If anyone would like help doing the same just ask.
I am learning tons on this thing. Reading also, but this is awesome!
Ok.. so long story sort I hope. I'm making a data class to pump out some instances of people that have various attributes. I would like my view controllers to be able to access them (through properties of course.. I think) to manipulate their data.
Where in an iphone app would be the best place to do this, and how would you write the code to message to this object. My current setup would be to have a navigation controller with a firstlevelviewcontroller that created a few secondlevelviewcontroller children instances that would do things like pickers for date of birth, and height, weight, etc.
Could the Navigation Controller make these model objects? Should application delegate? Lets say application delegate does. If so, then how would I put references to these objects from my first and second level view controllers?
Awesome!
**Update for the new millenium. **
I'm reading on core data structures, and though they are awesome, they are above and beyond what I need for this project. what I need is simple, I think..
I want one class that is a data class with a few variables that I can manipulate. I want to manipulate these from two view controllers. I might want more than one data instance, so I don't want a singleton data object. I don't need a persistent store of data.
I would like to know how to step by step have this data class instantiated.. should it be in app delegate? can i do it somewhere else? I dont want it a child of one of the view controllers.. How would I do that? then, how would I reference it from the view controllers and manipulate data (I'm pretty sure through properties but I can't figure out how to reference the instances to make this happen).
CHeers! thanks for the help!
Lots of questions that fringe on conjunction of various best practices.
First, the NSManagedObjectContext (if instantiated in the application delegate) can be shared in any number of ways. You can push it on through as you load your controllers or, something I've been more want to do (and will gladly argue the merits), you can hand it off to a Singleton that any controller has access to.
Depending on the model graph and how your UI maps to the data objects (you didn't say), keep in mind being memory friendly. I defer creating the NSFetchRequests until there is a controller that needs the data (CRUD).
If you want to edit your question or add comments that may provide more clarity... the answer may change
Frank