Android 服务——为共享首选项声明静态字符串的最佳位置

在一个持久的Android服务中，什么是声明引用SharedReference的静态字符串的最佳位置，以便最终在BroadcastReceivers中使用

public final static String KEY_ENABLE_LOCKSCREEN = "key_enable_lockscreen";

在下列文件中声明：

服务

活动

单身汉

您可以扩展

应用程序

类来创建自己的类并在其中声明它

您可以创建一个helper类并在其中声明它。您的常量不需要

上下文

，因此它可以安全地存在其中。这个类不必是一个单例来保存静态final变量，因为它不必有一个实例

从应用程序开始类：

用于需要维护全局应用程序状态的基类。您可以通过在AndroidManifest.xml的标记中指定其名称来提供自己的实现，这将导致在创建应用程序/包的流程时为您实例化该类

通常不需要对应用程序进行子类化。在大多数情况下，静态单例可以以更模块化的方式提供相同的功能。如果您的单例需要全局上下文（例如注册广播接收器），则可以为检索该上下文的函数提供一个上下文，该上下文在首次构造单例时在内部使用context.getApplicationContext（）

请注意，这个问题有点基于观点，没有一个好的答案。

一个单身汉
那样更干净。
通常我在包名utils中声明我的

mycustom.package.com.utils

这里有一个例子

public class MyUtility{
    public final static String KEY_ENABLE_LOCKSCREEN = "key_enable_lockscreen";
}

当您使用它时，只需在任何地方引用它，如下所示：

SharedPreferences prefs = getSharedPreferences( MyUtility.KEY_ENABLE_LOCKSCREEN, Context.MODE_PRIVATE);

---

除了静态类之外，我看不出有任何理由声明它们。它们是常数，真的。您不会更改它们（如示例中所示）。为什么要费心在单例中实例化它们呢？静态类的作用就像C中的头文件。更好的技巧是将它们放在接口定义中。这样，您可以通过在一个类中实现多个接口来混合和匹配常量。当您实现一个没有任何方法的接口时，您将继承这些常量。

我认为最好将这些常量作为最终静态字符串放入服务中，并具有所需的最小范围（例如，根据需要，包私有或公共）

• 单例是完全不必要的（不需要实例）

• 不需要单独的utils类。这可能是一个偏好问题，但是将常量定义与它们相关的类分离并没有什么好处。它们可以从服务访问，就像从其他任意类访问一样容易。从长远来看，我觉得如果它们在MyService中，那么记住MyService的常量的位置将比记住其他utils类中的常量更容易，现在您还必须记住它的名称

• 一个单独的utils类使命名复杂化。假设有多个服务/广播，将所有常量放在一个单独的类中还需要修饰名称。换句话说，您将无法在多个服务中明确地为常量使用相同的名称

例如，我觉得：

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.

…比这更可取：

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.

注意，第一个示例使在服务类之间复制和粘贴代码变得更容易

另外，请记住，除非您使用的是

LocalBroadcastManager

，否则您应该为BroadcastReceivers使用唯一的字符串

意图名称空间是全局的。确保意向操作名称和其他字符串写在您拥有的名称空间中，否则您可能会无意中与其他应用程序发生冲突

---

（请参阅：）

更好的方法和实践是创建一个单独的类，如

/**
 * 
 */
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";

}

当您想要使用首选项时，您可以使用以下选项-

MyPreferences.KEY_ENABLE_CODE 

---

因此，它将为您提供托管代码，以加快代码的速度。

对于#2，是否有理由创建帮助器类而不是仅在服务本身中声明它们？是的，真的只是为了清晰和代码组织。

静态final

几乎可以在任何地方声明。您可以在服务构造函数或onCreate（）中实例化Singleton？通常，Singleton会在第一次使用时实例化自身。这如何帮助提供xml访问，例如：？我想你最后会再次输入常量值（“诸如此类”）。