Develop Reference

Android - Static class method calls to server

Background -
I have an app that currently has a lot of methods in MainActivity to pull and upload data to firebase. It's quite a mess with the other app logic in there..
Problem -
I would like a separate class filled with server (firebase) access methods that can be called from any activity or fragment and run asynchronously. The class also needs access to context and be able to initialise and store variables.
PS. I'm using kotlin if that helps at all
Edit:
Have done more researching to find terms like "utility" and "static" classes which seems like an accurate way to go... If I create a static utility class with Async methods, will that achieve what I'm after? Also, can you initialise and hold variables in a static class?
Thanks :)
Solved
After more research and testing, I created an object that holds my methods and variables and just need to pass context into the relevant methods. Then just simply call objectname.methodname()

Java class filter to load same class of different versions when class referred in custom loader?

To illustrate the scenario, I have a class called com.test.A and the same class would be modified by different users (eg: DEV1 & DEV2) but they modify their respective classes, eg: com.test.DEV1.A , com.test.DEV2.A
If I use custom loader and load class A, is there any possibility that i can filter the reference of A to DEV1.A or DEV2.A based on some condition?

Without further knowledge of the problem I would say you are trying to solve this problem in the wrong place.
This looks more like a branching problem, that should be solved in the configuration management level, using the features that your SCM gives you. Please have a look at this article on how to handle properly different parallel developments https://thedailywtf.com/articles/Source-Control-Done-Right
The tone is quite accessible and I have used it with success in order to introduce branching to teams, I hope you enjoy it

Class A {
methodForUser1(params);
methodForUser2(params);
....
wrapperMethod(params) {
if (context.user.equals(user1))
methodForUser1(params);
else if (context.user.equals(user2))
methodForUser2(params)
....
}
}
Now every user only have to call wrapperMethod and it will in turn delegate to the right method you have for the user in context.
This is brute way of doing it. Additionally, you can load the method using reflection.
Another approach could be what #Jorge_B is suggesting in another answer (maintaining different CI pipelines)

alternative to findViewById() in classes other than activities (Android Studios)

I'm working on an android game that will have several levels and since each level will have the same code, I thought it would be good idea to create that code in a separate class and then using object of that class to use the code. However, all of my current code inside the main activity uses findViewById() to refer to different view in my app but I'm unfortunately unable to use this function outside of an activity inside just a normal class file. Are there any alternative ways of referring to views that I may be able to use in other classes?
Thanks

You have several options to do so, maybe you can pass the view itself as parameter but be careful to check if this view is in the correct context and if the view exists in the current screen to avoid some null pointer exceptions.
It's difficult to decide if this solution can even work without seeing your code

Background methods always as private class?

I'm starting with Android and wonder if background Task like DB reading and saving are always encapsulated in private classes?
I mean, at the moment I have:
private class SaveToDB extends AsyncTask..
private class ReadFromDB extends AsyncTask..
public void onButtonClick(View v) {
new SaveToDB().execute();
}
And so on. This way, I always have to create a new object if I want to execute background tasks. Is that the correct way?
What I wonder is that all my private classes are "actions" itself, not really objects. As they are named eg save or read which naming normally applies to methods by convention, not to classes.
Moreover, in case I'm doing it right: is it good practice to neast the private classes inside MyApplication Activity? Or should I refacter them out into own separate classes?

You could write a service to handle all the background content management. So, when you want to save, you just message the service and tell it to write data. This is much more complicated. For simple things, you can do it exactly as you are currently.
EDIT:
Also, as Ian pointed out, take a look at the new database interfacing classes post 3.0.

If you are firing of async tasks to interact with a sqlite database, then its not the best way to do things these days, you should check out cursor loaders instead.
http://developer.android.com/guide/topics/fundamentals/loaders.html
http://developer.android.com/reference/android/content/CursorLoader.html
Once you got your head around them they are much easier than firing off async tasks, infact they build on top of async tasks to address some of the issues you describe and are tolerant to configuration changes.
I highly recommend to move away from AsyncTask (for db access) and use the Loader API instead.
Its backported in the compatibility package so you can use them in older versions prior to Honeycomb.

Not always.
For example, if you've got a task that is to be used by different activities (I'm not talking about sharing the same instance), you will want a public class so you don't write it several times.
If you only use that (class of) task in one place, private class might help keeping your code cleaner.

It is a correct way for using AsyncTask, which isntance you can execute once.
Class Name can be DbSaver isntead of SaveToDb for instance which is more readable.
If that class is used only one Activity you can nest them, why not. But if you have task which is executed within different Activities, it is a good idea to create his own file.

It is good design to loosely couple your database access from your UI code. One way to avoid having to create a new object every time would be to make the database access classes a singleton and just return the instance of the class whenever you need to make a transaction.
To your last question it is a better idea to move the database management to its own class so that it can be accessed across several activities. If you do it all in a private class then what happens when you have a new activity that need s database access?

How to send status to other class in JAVA

I have three classes serviceManager,serviceMasterHandler and WokerThread.serviceManager instantiate ServiceMasterHandler,ServiceMasterHandler instantiate and start workerThread.
I want to implements that each class started successfully it's send status to calling upper classes.
All ideas on how to implement is welcome.
Thanks

Have you already heard about PropertyChangeEvent and associated classes (like PropertyChangeListener and PropertyChangeSupport) ? If not, go take a look at them .. And read the chapter in Java tutorial about ProperttyChangeListener. Notice that, although it's defined in a Swing context, elements from java.beans can perfectly be used anywhere else, as they are not Swing-dependant.

Simple way is to have a status flag at each upperclasses and update it to started in the child classess in child's constructor or any init method if you have.