Develop Reference

Use of static member in Android Application bad?

I've stumpled upon an Android Application Class which implements the Singleton pattern and bind a static object to it.
public class App extends Application
{
public static BigObject myObj;
private static App instance;
public static App getInstance()
{
return instance;
}
#Override
public void onCreate() {
super.onCreate();
instance = this;
myObj = new BigObject(this);
}
}
Are there any problems with this implementation, regarding performance, memory leaks or maybe Exceptions, when getInstance().myObj.something() is called form BroadcastReceiver or Service?

The only drawback I see is somewhat ugly code, using dependency injection would be better. I don't know, but if OS guarantees that all other components will be launched after Application::onCreate than there is no issues. Even non-main threads will not cache value of bigObject. But if you want set value of bigObject after onCreate, or it's creation takes long time you can face issues with data racing or slow startup.

I don't see any problems with this implementation. The Application object is basically a singleton.

best practice to share global variables between activities

I'm a bit confusing on how to share global variables between activities in an android project that considered safe.
What is the best practice to do that? Extends Application class or make a custom singleton class?
An help is apprecciate, thanks in advance.

The problem with storing something in the application class is you cannot count on an activity being resumed from the same instance of the application object. For example an activity can be paused, the application killed (due to memory) along with any changes you made to object in the instance, and then the activity resumed with a new application instance.
Here is a very good BLOG post explaining how data stored in the application class can be lost:
http://www.developerphil.com/dont-store-data-in-the-application-object
I am not sure this is the very "Best" practice, but I think this is a good solution
I have a PersistData class holds application wide "globals". I use Dagger to inject instances of this singleton into any class that requires these variables.
The basic process it this:
When I save a value in this object via something like:
mPersistData.saveEmailId("me#example.com");
I first write it to an entry in SharedPreferences
I then save it to a member variable
In the constructor for the class, I initialize the member variables by reading them from SharedPreferences.
This way reads for the variable are "cached", ie they don't need to be read from SharedPreferences, and if the application is ever killed and restarted the member variables have the correct values. If you just hold the values in the application class, when the application is restarted the member variables will be invalid (not what you expect or even null).
Here is an example:
public class PersistData {
private String email;
public PersistData(MyApp app) {
mApp = app;
email = readEmailId();
}
public void saveEmailId(String emailToSave) {
writeEmailId(emailToSave);
email = emailToSave;
}
private void writeEmailId(String emailId) {
generalSettingsFileEditor.putString("USER_ID", emailId);
generalSettingsFileEditor.commit();
}
public String readEmailId() {
String emaiId = generalSettingsFile.getString("USER_ID","");
return(emaiId);
}
public String getEmail() {
return email;
}
}
In my application Dagger module I have this:
#Provides #Singleton
public PersistData providePersistData () {
System.out.println(String.format("mApp = %s", mApp));
return new PersistData(mApp);
}
Then whenever I need to access any of these variables I inject the singleton as so:
public class HomePresenter {
#Inject
PersistData mPersistData;
...
mPersistData.saveEmailId("me#example.com");
myEmail = mPersistData.getEmailId();
...
}

What is the best practice to do that? Extends Application class or
make a custom singleton class?
Think twice whether those variables are really global and they have to be shared between activities.
If the answer to first question is 'yes', then the best place would be to store them in Application.
You can implement a singleton too, but 1) it's slightly more difficult to test and b) if your global variables require Context, then again Application instance would fit the best.

Tracking user idle time within the app in Android

As far as I know, there is no system API for me to get user idle time. When I say user idle time, I mean user have some interaction on the touch screen within my app. Therefore, I want to track it by my self. The way come up to my mind is to extends Activity and override onuserinteraction method to save the last user active time.
But the challenge is that my app have multiple processes. I am not sure the following way is the correct and efficient way.
I want to use SharedPreference with MODE_WORLD_WRITEABLE flag to store the user last active time. To avoid the performance issue, I also cache the last active time within the activity in each activity. And I only save the new time to SharedPrefernces if the diff time > 1 second.
Is this way efficient compared to using aidl? Actually, is aidl also share variable using file? If yes, I think the two ways should have similar performance, right? Thanks.

Instead writing it down every time, from everywhere, make this a global function in your App:
public class MyApp extends Application {
private static SharedPreferences sPreference;
private static final long MIN_SAVE_TIME = 1000;
private static final String PREF_KEY_LAST_ACTIVE = "last_active";
private static final String PREF_ID_TIME_TRACK = "time_track";
public static void saveTimeStamp(){
if(getElapsedTime() > MIN_SAVE_TIME){
sPreference.edit().putLong(PREF_KEY_LAST_ACTIVE, timeNow()).commit();
}
}
public static long getElapsedTime(){
return timeNow() - sPreference.getLong(PREF_KEY_LAST_ACTIVE,0);
}
private static long timeNow(){
return Calendar.getInstance().getTimeInMillis();
}
#Override
public void onCreate() {
super.onCreate();
sPreference = getSharedPreferences(PREF_ID_TIME_TRACK,MODE_PRIVATE);
}
}
Add Application class to manifest: <application android:name="com.example.MyApp"
Place saving functionality in an abstract Activity class:
public abstract class TimedActivity extends Activity {
#Override
public void onUserInteraction() {
super.onUserInteraction();
MyApp.saveTimeStamp();
}
public long getElapsed(){
return MyApp.getElapsedTime();
}
}
Now, extend all your activities from this class, all of them will be auto-save time, and will be able to use getElapsed().

Solution to access global data from everywhere - efficiently

I need to find a solution that holds and accesses large chunks of complex global data and methods. It has to be accessible from within activities and normal instance variables of various data classes.
This is how I have done it. I would just like to know if there is anything wrong with it or if there is a better/cleaner way.
First I extend Application like recommended many times...
public class MainDataManager extends Application{
public ... large chunks of data in arrays, lists, sets,....
//static variable for singleton access from within instance variables of other classes
public static MainDataManager mainDataManager;
//create and init the global data, and store it in the static variable of the class
#Override
public void onCreate() {
super.onCreate();
//in case it should get called more than once for any reason
if (mainDataManager == null) {
init();
mainDataManager = this;
}
}
Now accessing it from within activities like everywhere recommended...
MainDataManager mainDataManager = (MainDataManager)getApplicationContext();
And since I need to access it from normal instances of data classes ...
public class MyDataClass {
public MainDataManager mainDataManager;
public String name;
public MyDataClass(String namex) {
this.name = namex;
//this is why I defined the static variable within MainDataManager, so
//one has access to it from within the instance of MyDataClass
this.mainDataManager = MainDataManager.mainDataManager;
}
public void examplesForAccessing() {
//some examples on how to access the global data structure and associated methods
mainDataManager.someMethodAccess();
xyz = mainDataManager.someDataAccess;
mainDataManager.someIndirectMethodAccess.clear();
mainDataManager.someOtherData = false;
}
}
Since I have not done this so far, I would like to know if there is anything wrong with this. Memory, efficiency, ...
Thanks very much!
May I add a little sidenote?
I could also have just used a class MainDataClass and access by MainDataClass.var or MainDataClass.method(). Is there any REAL disadvantage?
Is the data in both cases held in heap/stack?

You haven't given much detail about your "large chunks of data" but keep in mind that the onCreate method is the first things that runs when your application is starting and it runs on the main/UI thread. This means that if you do long tasks in your init() method your UX will be poor, not to mention that you are risking an ANR exception.
The solution for that is simple:
Keep your onCreate short
Create a BG thread and use it to run all initialization code
Show a "Splash"/"Welcome" screen with the a proper progressbar while the BG thread is running.

Is there any convention for a helper class in Android?

For every Activity I add to my app I'm noticing a lot of similar code being used in the initialization of the Activity. A helper class with a static method to wrap this similar code seems the way to go.
I first thought of a singleton class. I could add static methods/variables and use them across the application. I haven't really tried to see how would this work in an Android application. Searching a little bit more I saw something about creating a class extending Application. For this I did a simple test:
public class MyApp extends Application {
public static String DEMOTEXT = "WORKING!";
public static void ShowToast(Context context, String text) {
Toast.makeText(context, text, Toast.LENGTH_SHORT).show();
}
}
MyApp.ShowToast(this, MyApp.DEMOTEXT); // Placed on onCreate of some Activity
This works exactly as I expected. Is this the way to go on Android or is there a better convention? Anything else I should consider when doing this?
By the way, should I use the final keyword on the string? What about the method?
EDIT: I just read this:
There is normally no need to subclass Application. In most situation,
static singletons can provide the same functionality in a more modular
way. If your singleton needs a global context (for example to register
broadcast receivers), the function to retrieve it can be given a
Context which internally uses Context.getApplicationContext() when
first constructing the singleton.
http://developer.android.com/reference/android/app/Application.html
Should I use a singleton then?

Application is primarily used for a global application initialization. You would create your own class, override Application.onCreate() and initialize your static application data there.
Dont forget to declare it in the AndroidMainfest.xml:
<application
android:icon="#drawable/icon"
android:label="#string/app_name"
android:name="your.package.path.to.MyApp">
A static helper class is made the way you did.
The convention is to use lower case letter at first position, so MyApp.showToast(...).
You would use final for the String if you would want to avoid madifications on other places (since it should be a contant).
// this would allow ...
public static String DEMOTEXT = "WORKING!";
// ... to do this somewhere else
MyApp.DEMOTEXT = "NOT WORKING!"

I haven't tried this but I think you should be able to do something like this as well.
public class MyActivity extends Activity {
private static final String DEMOTEXT = "WORKING!";
#Override
public void onCreate(Bundle bundle)
{
super.onCreate(bundle);
Toast.makeText(this, DEMOTEXT, Toast.LENGTH_SHORT).show();
}
}
Now for all activities that need to use that initialization could just extend your base activity class.
public class SomeActivity extends MyActivity {
...
// Should display the toast on create
...
}

Yes just use a singleton. Well in this case if your methods are static, you don't even need a singleton. Just a class with static methods.