Develop Reference

MVVM in android,accessing assetManager without breaking the pattern

I have a JSON file in the assets folder and DataManager(repository) class needs it so assetManager(and context) should have access to the assets.
The problem is that based on Best practice, Android context or android specific code should not be passed into the data layer(ViewModel-Repo-Model) because of writing unit tests or etc easily and also view should not interact with the data layer directly.
I ended up providing the list using and injecting it to the repository.
Is this the right thing to do?
-Thanks
P.S: my Module class which provides the list
#Module
public class UtilModule {
#Provides
#JsonScope
JsonUtil provideJsonUtil(AssetManager assetManager){
return new JsonUtil(assetManager);
}
#Provides
#JsonScope
String provideJson(JsonUtil util){
return util.getJson();
}
#Provides
#JsonScope
Type provideType(){
return new TypeToken<List<Data>>() {}.getType();
}
#Provides
#JsonScope
DataManager provideDataManager (Gson gson, Type type,String json) {
return new DataManager (gson.fromJson(json, type));
}
}

It's not a violation of MVVM for a ViewModel and/or Repository to access the Application context directly, which is all you need to access the AssetsManager. Calling Application.getAssets() is OK because the ViewModel doesn't use any particular Activity's context.
For example, you can use the Google-provided AndroidViewModel subclass instead of the superclass ViewModel. AndroidViewModel takes an Application in its constructor (ViewModelProviders will inject it for you). You could pass your Application to your Repository in its constructor.
Alternately, you could use Dagger dependency injection to inject an Application directly into your Repository. (Injecting the Application context is a bit tricky. See Dagger 2 injecting Android Context and this issue filed on the Danger github repo.) If you want to make it really slick, you could configure a provider for AssetManager and inject it directly into your Repository.
Finally, if you are using Room, and all you want is to pre-populate your Room database with a pre-configured database stored in assets, you can follow instructions here: How to use Room Persistence Library with pre-populated database?

Since you are using MVVM for the first time, we can try to keep things simple.
[ View Component C] ---- (observes) [ ViewModel Component B ] ---- [ Repository ]
According to the Separation of Concerns rule, the ViewModel should expose LiveData. LiveData uses Observers to observe data changes. The purpose of the ViewModel is to separate the data layer from UI. ViewModel should not know about Android framework classes.
In MVVM Architecture, the ViewModel's role is to fetch data from a Repository. You can consider either storing your json file as a local data source using Room, or keeping the Json API as a remote data source. Either way, the general implementation is as follows:
Component A - Entity (implements your getters & setters)
Method 1: Using Room
#Entity(tableName = "file")
public class FileEntry{
#PrimaryKey(autoGenerate = true)
private int id;
private String content; // member variables
public FileEntry(String content){ // constructor
this.id = id;
this.content = content;
}
public int getId(){ // getter methods
return id;
}
public void setId(int id){ // setter methods
this.id = id;
}
public String getContent(){
return content;
}
public void setContent(String content){
this.content = content;
}
}
Method 2: Using Remote Data Source
public class FileEntry implements Serializable{
public String getContent(){
return content;
}
private String content;
}
Component B - ViewModel (Presentation Layer)
Method 1: Using Room
As you asked about how android context can be passed, you can do so by extending AndroidViewModel like below to include an application reference. This is if your database requires an application context, but the general rule is that Activity & Fragments should not be stored in the ViewModel.
Supposing you have "files" as a member variable defined for your list of objects, say in this case, "FileEntry" objects:
public class FileViewModel extends AndroidViewModel{
// Wrap your list of FileEntry objects in LiveData to observe data changes
private LiveData<List<FileEntry>> files;
public FileViewModel(Application application){
super(application);
FilesDatabase db = FilesDatabase.getInstance(this.getApplication());
Method 2: Using Remote Data Source
public class FileViewModel extends ViewModel{
public FileViewModel(){}
public LiveData<List<FileEntry>> getFileEntries(String content){
Repository repository = new Repository();
return repository.getFileEntries(content);
}
}
In this case, getFileEntries method contains MutableLiveData:
final MutableLiveData<List<FileEntry>> mutableLiveData = new MutableLiveData<>();
If you are implementing using Retrofit client, you can do something similar to below code using asynchronous callbacks. The code was taken from Retrofit 2 Guide at Future Studio with some modifications for this discussion example.
// asynchronous
call.enqueue(new Callback<ApiData>() {
#Override
public void onResponse(Call<ApiData> call, Response<ApiData> response) {
if (response.isSuccessful()) {
mutableLiveData.setValue(response.body().getContent());
} else {
int statusCode = response.code();
// handle request errors yourself
ResponseBody errorBody = response.errorBody();
}
}
#Override
public void onFailure(Call<ApiData> call, Throwable t) {
// handle execution failures like no internet connectivity
}
return mutableLiveData;
Component C - View (UI Controller)
Whether you are using Method 1 or 2, you can do:
FileViewModel fileViewModel = ViewModelProviders.of(this).get(FileViewModel.class);
fileViewModel.getFileEntries(content).observe(this, fileObserver);
Hope this is helpful.
Impacts on Performance
In my opinion, deciding whether to use which method may hinge on how many data calls you are implementing. If multiple, Retrofit may be a better idea to simplify the API calls. If you implement it using Retrofit client, you may have something similar to below code taken as provided from this reference article on Android Guide to app architecture:
public LiveData<User> getUser(int userId) {
LiveData<User> cached = userCache.get(userId);
if (cached != null) {
return cached;
}
final MutableLiveData<User> data = new MutableLiveData<>();
userCache.put(userId, data);
webservice.getUser(userId).enqueue(new Callback<User>() {
#Override
public void onResponse(Call<User> call, Response<User> response) {
data.setValue(response.body());
}
});
return data;
}
The above implementation may have threading performance benefits, as Retrofit allows you to make asynchronous network calls using enqueue & return the onResponse method on a background thread. By using method 2, you can leverage Retrofit's callback pattern for network calls on concurrent background threads, without interfering with the main UI thread.
Another benefit of the implementation above is that if you are making multiple api data calls, you can cleanly get the response through an interface webservice above, for your LiveData. This allows us to mediate responses between different data sources. Then, calling data.setValue sets the MutableLiveData value & then dispatches it to active observers on the main thread, as per Android documentation.
If you are already familiar with SQL & only implementing 1 database, opting for the Room Persistence Library may be a good option. It also uses the ViewModel, which brings performance benefits since chances of memory leaks are reduced, as ViewModel maintains fewer strong references between your UI & data classes.
One point of concern may be, is your db repository (example, FilesDatabase implemented as a singleton, to provide a single global point of access, using a public static method to create the class instance so that only 1 same instance of the db is opened at any one time? If yes, the singleton might be scoped to the application scope, & if the user is still running the app, the ViewModel might be leaked. Thus make sure your ViewModel is using LiveData to reference to Views. Also, it might be helpful to use lazy initialization so that a new instance of the FilesDatabase singleton class is created using getInstance method if there are no previous instances created yet:
private static FilesDatabase dbInstance;
// Synchronized may be an expensive operation but ensures only 1 thread runs at a time
public static synchronized FilesDatabase getInstance(Context context) {
if (dbInstance == null) {
// Creates the Room persistent database
dbInstance = Room.databaseBuilder(context.getApplicationContext(), FilesDatabase.class, FilesDatabase.DATABASE_NAME)
Another thing is, no matter your choice of Activity or Fragment for your UI, you will be using ViewModelProviders.of to retain your ViewModel while a scope of your Activity or Fragment is alive. If you are implementing different Activities/Fragments, you will have different instances of ViewModel in your application.
If for example, you are implementing your database using Room & you want to allow your user to update your database while using your application, your application may now need the same instance of the ViewModel across your main activity and the updating activity. Though an anti-pattern, ViewModel provides a simple factory with an empty constructor. You can implement it in Room using public class UpdateFileViewModelFactory extends ViewModelProvider.NewInstanceFactory{:
#Override
public <T extends ViewModel> T create(#NotNull Class<T> modelClass) {
return (T) new UpdateFileViewModel(sDb, sFileId);
Above, T is a type parameter of create. In the factory method above, the class T extends ViewModel. The member variable sDb is for FilesDatabase, and sFileId is for the int id that represents each FileEntry.
This article on Persist Data section by Android may be more useful than my comments if you would like to find out more, on performance costs.

Android: What is the best way to register callbacks in multiple instances item and return onEvents to instance callback?

Background:
Nothing special, I'm using Java for Android.
Problem:
I want to allow my users to create multiple instances of an object and register a callback Interface into each instance (think of an error callback).
The object has several children/sub-children/etc... Each child can return this event.
I expect 1-10 instances in entire lifetime of app.
I'm trying to avoid using a singleton/static events listener.
Possible solutions (and reasons not to use them):
1) Register a BroadcastReceiver in each parent-object instance and allow each grand child notify the event on Intent level. This should allow the main object to notify my user about the event.
The problem is the multiple instances would require multiple BroadcastReceivers which I expect to be heavy or just less than optimal.
2) Register one BroadcastReceiver and find a way to let it decide which instance of the object should be notified of an event, and actually send it to it. The problem is that I'm not sure how to notify the objects themselves.
3) Let the callback interface pass as an argument from parent to each of the children/grandchilren/etc... But this would be messy.
4) Use something like EventBus library (which I understand would be the same thing as BroadcastReceiver, only Reflection based, thus slower).
5) Anything else?

I don't know if this is the best solution for you but I think it would work if I understand your requirements correctly.
public class Listener extends Observable implements Observer {
private List<Observer> clients = new ArrayList<>();
public void addClient(Observer client){
clients.add(client);
}
#Override
public void update(Observable o, Object arg) {
for(Observer client : clients){
client.update(o, arg); // Or whatever you need to do
}
}
public class DataSource extends Observable {
private Observer observer;
public DataSource(Observer o){
observer = o;
}
// Notify observer of changes at appropriate time
}
public class Consumer implements Observer {
public Consumer(){
Listener listener = ...;
listener.addClient(this);
}
#Override
public void update(Observable o, Object arg) {
// Handle appropriately
}
}
}
DataSource is your "sub-objects", Consumer is the end client of the events, and Listener is the class in the middle. I don't know why the clients can't directly register for events with the "sub-objects" but that is what you said! This is modeled as inner classes here for simplicity but I assume you would not do that.

Android service causes a singleton's instance variable to be null

I have class called ClientManager where i load the dictionary from the server. Once the dictionary is loaded a Service is started (which runs in its own process) that will use the data from this dictionary. However, when i access the dictionary through the class singleton it is null. Dictionary object resides in class DataManager. Please see the code below:
ClientManager.java
DataManager mDataManager = DataManager.getInstance();
public void apiCompleted(ApiResult apiResult){
....
DataDictionary dataDict = (DataDictionary) apiResult.valueObject;
//dictionary loads OK from server since i can see the contents by iterating through it
mDataManager.addDictionary(dataDict);
if (!serviceRunning(MyService.class)){
Intent intent = new Intent(mContext, MyService.class);
mContext.startService(intent);
}
MyService.java
public class MyService extends Service {
...
DataManager mDataManager;
#Override
public void onCreate(){
mDataManager = DataManager.getInstance();
if(!mDataManager.containsDataDictionary()){
//toast dictionary is null
}
}
DataManager.java
public class DataManager {
private static DataManager instance = null;
private DataDictionary mDataDictionary = null;
public static DataManager getInstance(){
if (instance == null){
instance = new DataManager();
}
return instance;
}
public boolean containsDataDictionary() {
if ( m_dataDictionary == null ){
return false;
}
return true;
}
public DataDictionary getDataDictionary() {
return mDataDictionary;
}
public void addDataDictionary(DataDictionary p_dataDictionary) {
mDataDictionary = p_dataDictionary;
}
}

You said it yourself: "which runs in its own process"
Each process has its own VM. You cannot access variables etc from one process to another.
The obvious question to follow up this would be, do you absolutely need to run the service in its own process?

Data sharing between processes are done through Intents or ContentProviders.
If the data is only shared within your application package you may also use SQLite or SharedPreferences but both these uses non-volatile memory and are significantly slower than data sharing through IPC.

The Singleton Pattern is allowed to share data within the application not between applications. Any instances of an app its lifespan is restricted within scope of the app life. It seems that you are trying to extend the scope of singleton object outside the app, which is not possible at all..
Note : Each process runs in own VM, so target processes doesn't have singleton instance of source processes.
There are two ways of communication for an app...
1) Active Communication (IPC) : When both source and target app is running (i.e.. processes) you need source/sender should act as a server and target/receiver should act as a client and both should communicate with Remote Object which both side has same remote object signature.Example : AIDL implementation....
2) Passive Communication (Accessing Source's Resource) : When Source is not alive and target is trying to access the data of source which is stored in any kind of storage can be accessed via Intents/Content Provider.
If you want to share data between process then you go with AIDL implementation only...

Pass large string-arrays to another Activity

I am trying to pass a large string-array of maybe 2 or 3 MB to another activity. The chunk is not passed and the only thing I can see in the logcat about what happend is ...
!!! FAILED BINDER TRANSACTION !!!
I tried to create my own class which implements Serializable, put a mutator there in which I put my String, then pass the Object reference to intent.putExtra(key, Serializable obj)
the code:
MyClass mc = new MyClass();
Intent intent = new Intent(MainActivity.this, CalculationsActivity.class);
intent.putExtra("mc", mc);
Is there an easy solution to this issue - that is to pass a large string-array to another activity?
class MyClass implements Serializable {
private String[] str;
public void setString(String[] str) {
this.str = str;
}
public String[] getString() {
return this.str;
}
}
I thought that passing just a reference wouldnt cause this. Reference is not more than a memoryaddress

As others have stated, using Local files (in your sandboxed directory) or database entries will probably be the way to go. However, if you want to do remote (e.g. ftp) hosting of the file and still load them when the application loads you should use a Service. (see the Docs).
I have two previous answers explaining services in more depth that you should look at.
How to use threads and services. Android
and
Android Service with multiple Threads
Essentially though there are two types, a bound thread (which lives with either an activity or the application) and intent services (which can always be active, or only active when the app is open). What you would want is probably the former which would look something like what is in the first link.
here is a snippet
public class BoundService extends Service {
private final BackgroundBinder _binder = new BackgroundBinder();
//Binding to the Application context means that it will be destroyed (unbound) with the app
public IBinder onBind(Intent intent) {
return _binder;
}
//TODO: create your methods that you need here (or link actTwo)
// Making sure to call it on a separate thread with AsyncTask or Thread
public class BackgroundBinder extends Binder {
public BoundService getService() {
return BoundService.this;
}
}
}

How to make interface to be used by Clients : Android

I want to create an Android framework service and publish a listener interface to update clients on updates. I don't want to make register_XX() & unregister_XX() methods for applications to provide listener reference .What i want is , applications simply implement that listener interface and without calling any register/ unregister method gets notified of changes.
How can i implement that ?

is there any good reason against register/unregister? if you call an interface *Listener, i would expect to register/unregister it (from a dev point of view).
i think you can achieve your goal with some abstract class AbstractListener, that registers itself in the constructor - but that's not nice from an architectural point of view and doesn't work around the unregistering.
e.g.
public abstract class AbstractUpdateReceiver {
public AbstractUpdateReceiver() {
register();
}
public abstract void onReceive(Update anUpdate);
// optional, only the user should react on registering
public abstract void onRegistered();
// optional, only the user should react on unregistering
public abstract void onUnregistered();
private void register() {
//...do register
onRegistered();
}
public void unregister() {
//do unregister
onUnregistered();
}
}
the on(Un)Registered calls and implementation are not necessary, if the whole registration process should be hidden from the implementing application. but for the unregistering, the user still has to call unregister(), as long as your framework doesn't provide anything like clearReceivers() or clearReceiver(AbstractUpdateReceiver receiver)
another (much) nicer solution without anything like registering/unregistering the implementation into the framework from the implementing application would be a factory doing the whole job instead of an abstract class. in that case, you have to split the abstract class into a normal class and an interface, the normal class provides and handles the registration, while the interface provides a method for onUpdateReceived. then you'll have the factory, that creates and returns the class from the framework.
public UpdateReceiver createUpdateReceiver(IUpdateReceiver wrapped) {
UpdateReceiver receiver = new UpdateReceiver(wrapped);
receiver.register(); //or register directly into a non-static factory
return receiver;
}