I am creating a library project for a number of android apps.
The apps all have some common functionality that I wish to include in the library project but the library project functions require use of application specific constants
So I am looking for a way to provide the library functions with the names of the constants and allow each app to define them
An example of a specific app constant and how it is used within the library project
public class AppConstants {
public static final long APP_ID = 6;//Needs to be set for each app
}
public static long getCurrentAppId(Context context) {
return getLongPreference(context, CURRENT_APP_ID_KEY, AppConstants.APP_ID);
}
This is just one example of approximately 60 constants that need to be defined for each app for a large number of library functions
Obviously I would normally just import/include the project specific app_constants.java file but this is not possible in the library project files as it hasn't got a clue about the specific applications (rightly so)
So what is the best way to have each specific app override the constants?
Update
I took a long time deciding on which of the superb answers I have been provided with best suited my needs (Thanks everyone) In the end I chose the xml solution. I don't particularly like it because it clutters up my apps resources and I did seriously consider using the interface solution but the xml solution does work nicely
Option #1
Extend your AppConstants class in each project
Better Option#2
Use XML resources to define the constants
<?xml version="1.0" encoding="utf-8"?>
<resources>
<item type="integer" name="app_id" format="integer">6</item>
</resources>
then you can retrieve them by
Context.getResources().getInteger(R.integer.app_id);
add the xml file to your resources in each project with only the values you need different
I don't know of a great schema to do that but it would certainly work this way:
define some base class in your library
// class, enum or whatever you want it to be.
class BaseConstants {
// use some real singleton instead
public static final BaseConstants instance = new BaseConstants();
// define those values - sadly static inheritance does not work
private static final int APP_ID = 0;
private static final int CURRENT_APP_ID_KEY = 24;
// so we have to do that via methods
protected int getAppId() {
return APP_ID;
}
protected int getAppIdKey() {
return CURRENT_APP_ID_KEY;
}
}
let each Activity that wants something custom implement that
class App1Constants extends BaseConstants {
public static final App1Constants instance = new App1Constants();
private final static int APP_ID = 1;
// want a different APP_ID here.
protected int getAppId() {
return APP_ID;
}
// getAppIdKey not implemented here, uses default
}
Use that class as context to the constants for your library
class Library {
public static long getCurrentAppId(Context context, BaseConstants settings) {
return getLongPreference(context, settings.getAppIdKey(), settings.getAppId());
}
}
Activities would be like so
class myActivity extends Activity {
// each Activity can implement it's own constants class and overwrite only some values
private static final BaseConstants CONSTANTS = App1Constants.instance;
private void whatever() {
long appId = Library.getCurrentAppId(this, CONSTANTS);
}
}
class myActivity2 extends Activity {
// or could just use the default ones
private static final BaseConstants CONSTANTS = BaseConstants.instance;
private void whatever() {
long appId = Library.getCurrentAppId(this, CONSTANTS);
}
}
That schema is kind of ugly but it would work at least
Define them as enum's in your library project, like
public enum Planet { MERCURY, VENUS, MARS }
Android proper takes another approach, the dreaded constant interface, like,
interface Planets {
static final int MERCURY = 1;
static final int VENUS = 2;
...
}
However, this is a well-known Java anti-pattern (constant interface, and is covered in detail in Effective Java, I quote,
The constant interface pattern is a poor use of interfaces. That a
class uses some constants internally is an implementation detail.
Implementing a constant interface causes this implementation detail to
leak into the class’s exported API. It is of no consequence to the
users of a class that the class implements a constant interface. In
fact, it may even confuse them. Worse, it represents a commitment: if
in a future release the class is modified so that it no longer needs
to use the constants, it still must implement the interface to ensure
binary compatibility. If a nonfinal class implements a constant
interface, all of its subclasses will have their namespaces polluted
by the constants in the interface.
If you need the constants to have int values for some reason, and calling toString() on the enum isn't sufficient, you can give the enum's a extra information like,
public enum ZipCode {
LYNNWOOD(98036), SAN_JOSE(95112), ...;
private int zipCode;
private ZipCode(int zipCode) { this.zipCode = zipCode; }
public int getZipCode() { return zipCode; }
}
Note that enum's are slightly less performing than integer constants, but from a code organization and clarity perspective they are far superior.
Related
I have a bunch of small support methods in Android Studio I use as shortcuts in my development process, whether it's logging or popping up a toast. Where should I put these 'misc' methods? What is best practice?
At the moment they are seperate classes e.g
public class Message {
public static void message(Context context, String message) {
Toast.makeText(context, message, Toast.LENGTH_LONG).show();
}}
Is it good to have a public 'SupportClass' filled with these methods or is this whole approach bad practice?
What I do is Create multiple helpers in a package called helpers
Something like LogHelper , StringHelper , DateHelper...
you should declare those classes final and add a private Constructor, like this
public final class StringHelper {
private StringHelper () {
//Private constructor for avoiding this class to be construct
}
//... ( your public static methods goes here )
}
Most of the developers place such methods in a class named Utils but there is neither a rule nor a convention for this.
This is not a bad practice. But if your helper class contains a lot methods, you can split up the class into other multiple classes for better maintainability.
Here is my scenario.
I have an android activity in which I want to abstract my I/O dependencies. The dependencies are represented by this interface (edited for brevity and simplicity):
public interface ITimeDataServer {
TimeRecord[] get(int userID);
void save(TimeRecord record);
}
What I want is for my activity to be able to call these interface methods, and leave the implementation to be supplied by the calling code. (Pretty standard, I think).
ITimeDataServer myServer;
int myUserID;
void loadRecords() {
TimeRecord[] records = myServer.get(myUserID);
// etc...
}
My difficulty is, how can I ensure that myServer gets set?
This seems like a common problem, but I can't find a clean solution.
My first thought would be that myServer would be passed in through the constructor, but Android activities aren't really instantiated with constructors.
I've come up with several solutions, but they're all icky in some way:
Icky Solution 1
Create a static method to launch the activity class which takes an ITimeDataServer parameter and stores it in a static variable from which the activity can access it:
private static ITimeDataSource theDataSource;
public static void launch(Activity currentActivity, ITimeDataSource dataSource) {
theDataSource = dataSource;
Intent intent = new Intent(currentActivity, MainActivity.class);
currentActivity.startActivity(intent);
}
This is icky because (a) the data source is static and not actually associated with the instance, and (b) a consumer could initiate the activity by the standard activity API rather than this static method, which will cause NullPointerException.
Icky Solution 2
I can create a Provider class which provides a singleton instance of ITimeDataSource, which needs to be initialized by the calling library before use:
public class TimeDataSourceProvider {
private static ITimeDataSource myDataSource = null;
public void initialize(ITimeDataSource dataSource) {
myDataSource = dataSource;
}
public ITimeDataSource get() {
if (myDataSource == null)
throw new NullPointerException("TimeDataSourceProvider.initialize() must be called before .get() can be used.");
else
return myDataSource;
}
}
This seems a little less icky, but it's still a little icky because the activity's dependency is not obvious, and since there may be many paths to launch it, it's highly possible that some of them would forget to call TimeDataSourceProvider.initialize().
Icky solution 3
As a variation on #2, create a static IODependencyProvider class which must be initialized with ALL dependencies on app startup.
public class IODependencyProvider {
static ITimeDataSource myTimeData;
static IScheduleDataSource myScheduleData; // etc
public static void initialize(ITimeDataSource timeData, IScheduleDataSource scheduleData /* etc */) {
myTimeData = timeData;
myScheduleData = scheduleData;
//etc
}
public static ITimeDataSource getTimeData() {
if (myTimeData == null)
throw new NullPointerException("IODependencyProvider.initialize() must be called before the getX() methods can be used.");
else
return myTimeData;
}
// getScheduleData(), etc
}
This seems superior to #1 and #2 since a failure to initialize would be much harder to sneak by, but it also creates interdependencies among the data types that otherwise need not exist.
...and other icky variations on that theme.
The common themes that make these solutions crappy:
the need to use static fields to pass non-serializable information to an activity
the lack of ability to enforce initialization of those static fields (and subsequent haphazardness)
inability to clearly identify an activity's dependencies (due to reliance on statics)
What's a nooby Android developer to do?
As long as these dependencies implement Parcelable correctly, you should be able to add them to your intent, then unparcel them as ITimeDataServer and get the correct class.
I found a nice solution here, in the least-loved answer.
I define the library activity as abstract and with no default constructor, but a constructor that takes an interface, like so:
public abstract class TimeActivity extends AppCompatActivity {
private ITimeDataSource myTimeDataSource;
public TimeActivity(#NonNull ITimeDataSource dataSource) {
myTimeDataSource = dataSource;
}
#Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_time);
// do stuff with myTimeDataSource!
}
}
Then, the calling code can create a concrete subclass with its chosen implementation that does have a parameterless constructor. No static members, easy-peasy!
This allows you to abstract and inject all sorts of crazy behaviours! Woooo!
(Note that the concrete subclass activity needs to be manually added to AndroidManifest.xml, like all activities, or the app will crash when it tries to launch.)
In a persistent Android Service, what's the best place to declare static strings to reference SharedPreferences, for eventual use in BroadcastReceivers?
public final static String KEY_ENABLE_LOCKSCREEN = "key_enable_lockscreen";
Declare them in the:
Service?
Activity?
A singleton?
A singleton!
It is way more clean that way.
Usually I declare mine in package names utils.
mycustom.package.com.utils
Here a example.
public class MyUtility{
public final static String KEY_ENABLE_LOCKSCREEN = "key_enable_lockscreen";
}
And when you use it , just refer to it everywhere as follows:
SharedPreferences prefs = getSharedPreferences( MyUtility.KEY_ENABLE_LOCKSCREEN, Context.MODE_PRIVATE);
Its better approach & practice to create a separate classes like
/**
*
*/
package com.comapnyname.projectname.utility;
/**
* #author Rakesh.Jha
* All static member variable will be listed here
*/
public class MyPreferences {
/*
* #Declare all static variables here
*/
public final static String KEY_ENABLE_CODE = "0001";
}
When ever you want to use preferences you can use like -
MyPreferences.KEY_ENABLE_CODE
So, it will give you managed code to make speedness in your code.
You can extend Application class to create your own and declare it there.
You can create a helper class and just declare it in there. Your constant doesn't require a Context so it can safely live in there. This class doesn't have to be a singleton to hold your static final variable as it doesn't have to have an instance.
From Android Developer Reference on Application class:
Base class for those who need to maintain global application state. You can provide your own implementation by specifying its name in your AndroidManifest.xml's tag, which will cause that class to be instantiated for you when the process for your application/package is created.
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.
Please note that this question is a bit opinion based and there's no one good answer.
I see no reason to declare them in anything other than a static class. They're constants, really. You're not going to change them (as demonstrated in the example). Why bother instantiating them in a singleton? A static class just acts like a header file in C. An even better trick is to put them in an interface definition. That way, you can mix and match constants by implementing multiple interfaces in a class. When you implement an interface that doesn't have any methods, you inherit the constants.
I think it's best to put such constants in the service as final static strings, with the minimum required scope (e.g. package private, or public, as required).
The singleton is completely unnecessary (there is no need for an instance).
A separate utils class is unnecessary. This may be a matter of preference, but there is very little to gain from having your constant definitions separated from the class they're related to. They can be accessed just as easily from the service as they can from some other arbitrary class, and in the long run I feel it will be easier to remember where the constants for MyService are, if they are in MyService, than if they are in some other utils class which you must now also remember the name of.
A separate utils class complicates naming. Putting all of your constants in a single separate class will also require you to decorate the names, assuming you have multiple services/broadcasts. In other words, you won't be able to unambiguously use the same name for your constants in multiple services.
For example, I feel this:
public class PlaylistManager extends IntentService {
public static final String BROADCAST_ERROR = "#package.name#.PlaylistManager.broadcast.ERROR";
// can be referenced within this class as BROADCAST_ERROR
private void broadcastError() {
Intent broadcastIntent = new Intent();
if(broadcastIntent != null) {
broadcastIntent.setAction(BROADCAST_ERROR);
// etc.
sendBroadcast(broadcastIntent);
}
}
}
public class AudioCacheLoader extends IntentService {
public static final String BROADCAST_ERROR = "#package.name#.AudioCacheLoader.broadcast.ERROR";
// can also be referenced within this class as BROADCAST_ERROR
private void broadcastError() {
Intent broadcastIntent = new Intent();
if(broadcastIntent != null) {
broadcastIntent.setAction(BROADCAST_ERROR);
// etc.
sendBroadcast(broadcastIntent);
}
}
}
// naming pattern:
// PlaylistManager.BROADCAST_ERROR
// AudioCacheLoader.BROADCAST_ERROR
// etc.
...is more desirable than this:
public class MyUtils {
public static final String PLAYLIST_MANAGER_BROADCAST_ERROR = "#package.name#.PlaylistManager.broadcast.ERROR";
public static final String AUDIO_CACHE_LOADER_BROADCAST_ERROR = "#package.name#.AudioCacheLoader.broadcast.ERROR";
}
public class PlaylistManager extends IntentService {
private void broadcastError() {
Intent broadcastIntent = new Intent();
if(broadcastIntent != null) {
broadcastIntent.setAction(MyUtils.PLAYLIST_MANAGER_BROADCAST_ERROR);
// etc.
sendBroadcast(broadcastIntent);
}
}
}
public class AudioCacheLoader extends IntentService {
private void broadcastError() {
Intent broadcastIntent = new Intent();
if(broadcastIntent != null) {
broadcastIntent.setAction(MyUtils.AUDIO_CACHE_LOADER_BROADCAST_ERROR);
// etc.
sendBroadcast(broadcastIntent);
}
}
}
// naming pattern:
// MyUtils.PLAYLIST_MANAGER_BROADCAST_ERROR
// MyUtils.AUDIO_CACHE_LOADER_BROADCAST_ERROR
// etc.
Note that the first example makes it easier to copy and paste code between service classes.
Also, keep in mind that you should use unique strings for BroadcastReceivers, unless you're using LocalBroadcastManager.
The Intent namespace is global. Make sure that Intent action names and other strings are written in a namespace you own, or else you may inadvertently conflict with other applications.
(See: http://developer.android.com/reference/android/content/BroadcastReceiver.html)
I can see this is common practice among Android developers.
public final class TasksSample extends ListActivity {
private static final String TAG = "TasksSample";
private void method() {
Log.i(TAG, "message");
}
}
Will it be easier, if I do it this way? I need not to declare TAG for every new class.
public final class TasksSample extends ListActivity {
private void method() {
Log.i(getClass().getName(), "message");
}
}
Rather than writing getClass().getName() at each place where a log is placed in a particular activity, it is always preferred to have a TAG that would represent the name of the activity class.
Why use TAG?
When you are running your application there might be more than one Activity class in it. To distinguish which activity class has logged the information in logcat we use a TAG which of course represents the name of the class.
And the proper way (I am not saying what you have written is wrong) of writing the TAG is:
private static final String TAG = TasksSample.class.getSimpleName(); // and not "TasksSample"
Every previous answer is right, but I just wanna add a little comment.
private static final String TAG = TasksSample.class.getSimpleName();
or
private static final String TAG = "TasksSample"
The latter is used when you use proguard. As you know, proguard obfuscates class names and it affects logs too.
calling a function every time has it's toll and getClass().getName() is calling 2 functions every time you log something into the system (an already long process).
Therefor, it's better to save the tag is a final static String instead of calling the same function over and over again.
Yes its a common practice, and is supported by Google for logging & debugging. If you use getClass().getName() then you have to call getClass().getName() every time, so its a better approach use TAG.
Actually getClass().getName() returns the class name, where TAG represents easy understandable name/identification of your class.
I am not sure I did the right thing. The main reason for my doubts is that I cannot find, in this or other forums, someone who has done a similar thing.
I created an abstract java class in my project. Named it lib. I put there several structures and methods used by all other classes in the project.
It works for me, but I want to know if there is a more accepted method of gathering all common methods and structures.
Note: All methods of course are declared as public static.
Note II: I did not know how to get the context within the abstract class, so if needed I had to pass it as argument to the method.
Is this wat you are looking for?
public abstract class AbstractActivity extends Activity{
public static synchronized boolean showAlertBox(Context ctx,final String title,final String message,final String okBtnTxt,final OnClickListener clickListener){
AlertDialog.Builder alertbox; alertbox = new AlertDialog.Builder(ctx);
this.runOnUiThread(new Runnable() {
#Override
public void run() {
alertbox.setTitle(title);
alertbox.setMessage(message);
if(okBtnTxt!=null || clickListener!=null)
alertbox.setNeutralButton(okBtnTxt,clickListener);
alertbox.show();
.....
}
});
return true;
}
}
In the class extending this abstract class you can just call it by using showAlertBox(this);
Other wise use AbstractActivity.showAlertBox(Context);
Well, thanks to #Matt Wolfe's comment I came to know that what I did is called "Utility class" and it is widely used to share common code in a project.
The general template is:
public abstract class lib {
public static final int ZERO = 0;
public static final int ONE = 1;
public static final int TWO = 2;
public static void func1(int i) {
}
public static void func2(int i, String s) {
}
}
and you can use it like this from any other code:
...;
lib.func1( lib.ZERO );
lib func2( lib.TWO, "sandwich" );
...;
Knowing that makes me confident that what I did is OK.
It would be perfect to find a way to avoid the prefix lib. and just have ECLIPSE, and the compiler, find the right import and recognize the function with just its name, like they do for global libraries.