Before diving right into coding, you can greatly enhance the development experience for your project by mapping out the various services and features your app needs. Doing so will help reduce code duplication, frame your data flow, and lead the way for rapid feature development in the future.
A service is a class that typically handles processing and/or provides data to your app. Your usage of these services does not need to know the specifics of where the data came from, just that it can ask the service for its purpose and it will happen.
A good exercise for this is to sketch out a rough idea of one of your app views. You may not know what it will look like yet and that's okay; this is purely an exercise to think about the user expectations as a first step to guiding your thought process into the various sections or modules you need to construct to meet those expectations. It will also help you think about the various states the app needs to manage.
Take, for example, the app we are going to build, TNSStudio (Telerik NativeScript (TNS)). We will dive into more detail of what our app is and what exactly it will do inChapter 2, Feature Modules.
Starting from top to bottom, we can see a header with a menu button, a logo, and a record button. Then, we have a listing of user recorded tracks, each with a (re)record button and a solo or mute button.
From this one sketch, we may think about several services the app may need to provide:
- A Player Service
- A Recorder Service
- A Persistent Store service to remember which volume level settings the user sets for each track in the recording mix and/or if the user is authenticated
We can also gain some insight into the various states the app may need to manage:
- A listing of user recordings/tracks
- Whether the app is playing audio or not
- Whether the app is in the recording mode or not
It's also advantageous to provide some low-level services that provide a convenient API to access things, such as HTTP remote requests and/or logging. Doing so will allow you to create unique characteristics that you or your team like to work with when interacting with low-level APIs. For instance, maybe your backend API requires a unique header to be set in addition to a special authentication header for each request. Creating a low-level wrapper around an HTTP service will allow you to isolate those unique characteristics and provide a consistent API for your app to interact with, to guarantee all the API calls are enhanced with what they need in one place.
Additionally, your team may desire an ability to funnel all the logging code to a third-party log analyzer (for debugging or other performance-related metrics). Creating low-level wrappers with the lean code around some framework services will allow your app to adapt to these potential needs quickly.
We can then think about breaking these services up into organizational units or modules.
Angular provides us with the @NgModule decorator, which will help us define what these modules look like and what they provide to our app. In an effort to keep our app's bootstrap/launch time as fast as possible, we can organize our modules in such a way to allow some service/features to be lazily loaded after our app has launched. Bootstrapping one module with a small subset of required code that our app needs to launch will help keep this launch phase to a minimum.
Here's how we will break down our app organization by module:
CoreModule: Low-level services, components, and utilities that provide a nice foundation layer. Things such as interacting with logging, dialogs, HTTP, and other various commonly used services.AnalyticsModule**: Potentially, you could have a module that provides various services to handle analytics for your app.
PlayerModule*: Provides everything our app needs to play audio.RecorderModule*: Provides everything our app needs to record audio.