var match = 0 var not = 0 val englishLangData = readJson1() val otherLangData = readJson3() val list = englishLangData.split(";") // Main Local.strings for (item in list) { try { val key1 = item.trim().split("=")[1].replace("\"", "").toString().trim() val value1 = item.trim().split("=")[1].replace("\"", "").toString().trim()
// CODE- language to be replaced val jsonArr = JSONArray(otherLangData) for (item2 in jsonArr) { val s = item2.toString() val j1 = JSONArray(s) val s1 = j1[0].toString().trim() val s2 = j1[1].toString().trim() if (s1.equals(value1, true)) {
val s = "\""+key1+"\" = \""+s2+"\";" val s2 = "\n" + s val fileWriter = FileWriter("C:\\Projects\\Project\\Localizable.strings", true) fileWriter.write(s2) fileWriter.close() match = match + 1 break } } } catch (exc: Exception) { } }
Broadcast Receiver - To listen the system as well as custom intent.
Android OS is firing multiple intents like - SYSTEM_REBOOT, BATTERY_LOW/HIGH, NETWORK STATUS and so on.
Intent - It is a messaging object which is used to pass the message from one component to another.
1. Create BroadcastReceiver Class
public class BReceiver extends BroadcastReceiver
2. Register and Filter Intent - Register Broadcast Receiver class to listen to System intent.
and by using IntentFilter we specify which intent app listens.
final BReceiver bReceiver = new BReceiver();
IntentFilter filter = new IntentFilter();
filter.addAction("divakar");
registerReceiver(bReceiver, filter);
Model–View–ViewModel (MVVM) is a software architectural pattern which facilitates separation of development UI (Activity or Fragment) from the development of the business logic or back-end logic (the data model).
What is Architectural Pattern
An Architectural Pattern is a general, reusable solution to a commonly occurring problem in software architecture. Architectural patterns are similar to Software Design Patterns but have a broader scope. The architectural patterns address various issues such as computer hardware performance limitations, high availability, and minimization of business risk.
An architectural style defines a family of systems in terms of a pattern of structural organization; a vocabulary of components and connectors, with constraints on how they can be combined.
What is MVVM
MVVM stands for Model View ViewModel and it is an architectural pattern for implementing user interfaces.
Why MVVM over MVP
1. Tight Coupling
For each Activity/Fragment (View) we require a Presenter. This is a hardbound rule.
Presenter holds the reference to the Activity and Activity Holds the reference to a presenter 1:1 relationship.
As the complexity of view increases, so does the maintenance and handling of this relationship.
ViewModels are simples classes that interact with the logic/model layer and just exposes states/data and actually has no idea by whom or how that data will be consumed. Only View(Activity) holds the reference to ViewModel and not vice versa, this solves our tight coupling issue. A single view can hold a reference to multiple ViewModels.
Even for complex views we can actually have different ViewModels within same hierarchy.
2. Testability
ViewModels are more Unit Test friendly and there is no dependency of the View as they just expose the state and it can be independently tested without requiring the need for testing how data will be consumed.
3. Relationship with View
In MVP, the role of a Presenter is to drive the View changes and at the same time provide data for completing those operations whereas MVVM, the ViewModel only provides the data, whereas the View is responsible for consuming them and does not hold the reference to the View .The ViewModelcan also hold logic for processing users input, same as the Presenter .
Inshort ,MVVM gives more separation of concerns, less boilerplate and encourage reactive approach. Additionally, we get officially recommended tools straight from Google, so we can worry less about lifecycle, memory leaks and crashes.
Now let’s talk about MVVM components.
MVVM Components
It consists of three moving parts:
Data Model — it abstracts the data source. The ViewModel works with the DataModel to get and save the data. it represents the business objects that encapsulate the data and behavior of the application.
ViewModel — it exposes streams of data relevant to the View and provides the data for a specific UI component, such as a fragment or activity, and contains data-handling business logic to communicate with the model.
View — the UI that users see and view send and receive the data from the view model
The Repository holds all the business logic of the particular app section in the app.
Implementation
Step 1: Add the Gradle dependencies
To add it to your project, open the project level build.gradle file and add the highlighted line as shown below:
2. Open the build.gradle file for your app or module and add dependencies:
Step 2: Create a Data Source
First of all, you will create a data source for your application if you are using RestAPI you might use Retrofit or Volley for parsing the JSON data and if you are using SQL database you will use Room Database or SQLite.
In our case, we are using Room Database to demonstrate how to set up MVVM.
We have already implemented how Room in our project and if you do not know how to use Room then we have also written an article we project code.
//article link and code
Step 3: Create a Repository
A Repository is basically a wrapper class which contains the business logic of our app.
As we are Using Room database we need to have ApplicationContext and we will write all the database operation here so the person who is working on the UI does not have to worry about any database operations.
We have already created the Repository class here:
If you noticed that we have used LiveData above so
LiveData is an observable data holder class. Unlike a regular observable, LiveData is lifecycle-aware, meaning it respects the lifecycle of other app components, such as activities, fragments, or services. This awareness ensures LiveData only updates app component observers that are in an active lifecycle state.
We also have written an article on Using Room with LiveData
The ViewModelclass allows data to survive configuration changes such as screen rotations.
Why use ViewModel?
The purpose of the ViewModel is to acquire and keep the information that is necessary for an Activity or a Fragment. The Activity or the Fragment should be able to observe changes in the ViewModel. ViewModels usually expose this information via LiveData or Android Data Binding. You can also use any observability construct from your favorite framework.
To know more about ViewModel and how to use it with RoomDatabase we also have written an article on “Using ViewModel with RoomDatabase”