There is so much dogma in the iOS community. Enum based protocols with lots of switch/casing considered to be good where, most of the time a more straightforward message sending/delegate would suffice
I guess I'm on the "enum" side for a couple of reasons (some of which may or may not happen eventually):
The callback looks nice for an Event Emitter. Downside is, there are two states now. One internal state of the recorder and then a state you need to track within the consumer of that recorder. Now the app is responsible for correctly tracking all state changes - which absolutely can be done, but requires you to actually do that.
However, once you want to just query the state of the Event Emitter you are screwed (I could imagine some sort of shared resource), as you only get an Event on state change. Just my belly feeling, but this smells less robust to me.
fair enough! in practice though I find that most of the time you end up creating your own controlled state in your own app's business logic such as viewmodel or interactor for this anyway.
It is a matter of preference but when you separate things in your codebase by strict layers where does the audio recorder belong? likely it is a service layer of sorts because it's an external thing that you're using (or you could even put it in the UI layer I guess because it's user input after all). But either way this is probably not the layer where you want your application state and business logic/state to be. Therefor you better off having your own internal state for the recording status such as recording, stopped, failed, etc. instead of relying on that service to query all the time. So having an unambiguous clearly defined even emitter is a better choice.
Both solutions work, in the end engineering often is about finding the best compromise among all the possible solutions.
I might have a different understanding of the term "business logic" though. Anything that merely takes one state as input and outputs the state without change, I wouldn't consider business logic and therefore wouldn't necessarily put it into a (view) model. Once combined states / dependent states or actions are needed, I wouldn't put them inside a view (though not necessarily part of a view model either).
We recently introduced a cache that can be accessed both synchronously and asynchronously from views and (view) models. It does have a few caveats, but it's a compromise that is really easy to use and test - using the cache is now easier than the vintage usage of the network layer - as that cache is working out very well with enum cases, I might be a bit biased :)
I guess I'm on the "enum" side for a couple of reasons (some of which may or may not happen eventually):
The callback looks nice for an Event Emitter. Downside is, there are two states now. One internal state of the recorder and then a state you need to track within the consumer of that recorder. Now the app is responsible for correctly tracking all state changes - which absolutely can be done, but requires you to actually do that.
However, once you want to just query the state of the Event Emitter you are screwed (I could imagine some sort of shared resource), as you only get an Event on state change. Just my belly feeling, but this smells less robust to me.
fair enough! in practice though I find that most of the time you end up creating your own controlled state in your own app's business logic such as viewmodel or interactor for this anyway.
It is a matter of preference but when you separate things in your codebase by strict layers where does the audio recorder belong? likely it is a service layer of sorts because it's an external thing that you're using (or you could even put it in the UI layer I guess because it's user input after all). But either way this is probably not the layer where you want your application state and business logic/state to be. Therefor you better off having your own internal state for the recording status such as recording, stopped, failed, etc. instead of relying on that service to query all the time. So having an unambiguous clearly defined even emitter is a better choice.
Both solutions work, in the end engineering often is about finding the best compromise among all the possible solutions.
I might have a different understanding of the term "business logic" though. Anything that merely takes one state as input and outputs the state without change, I wouldn't consider business logic and therefore wouldn't necessarily put it into a (view) model. Once combined states / dependent states or actions are needed, I wouldn't put them inside a view (though not necessarily part of a view model either).
We recently introduced a cache that can be accessed both synchronously and asynchronously from views and (view) models. It does have a few caveats, but it's a compromise that is really easy to use and test - using the cache is now easier than the vintage usage of the network layer - as that cache is working out very well with enum cases, I might be a bit biased :)