First some background (I always like when people asking questions give that): I am writing a library project. It is a simple OpenGL 'graphics distortions' library. Users are supposed to be able to create certain objects called 'Regions' with a simple call to
myRegion = new DistortedRegion(w,h);
then define various distortions on them and draw them:
myRegion.addTwistDistortion(...)
myRegion.draw(x,y);
That's all there is to it. The library uses OpenGL to draw the Region (a rectangular bitmap really) distorted in various user-defined ways.
Now, the problem: the library needs to access its vertex and fragment shaders, which are .glsl files stored with its resources, in the 'raw' folder. In order to do that, we have to access the Resources object, and in order to do that we AFAIK have to have the Context object. So currently as it stands the library has to first be initialized with a call
Distorted.init(Context)
This is a giant problem for me, because this IMHO makes the whole API clumsy. If not for this damn Context, there would be no need to initialize anything, and the user would simply be able to create new objects straight away whenever he wants, which is elegant and simple to explain in the docs. A separate init() call , which is only really needed to pass the Context object to the library, which is only needed to retrieve the Resources object, which is only needed to open up two files containing shader code, makes all of that very clumsy.
I was thinking to simply move the shader code into statically initialized Strings inside my library instead, but this is cumbersome for development (the shaders are several hundred lines long of quite complicated code, and if I keep them in a separate .glsl files, I can have syntax highliting among other things)
Any advice?
So yes, I hopefully figured it out. Here's a function that returns the Context of the current Application by directly calling the underlying Android code by reflection. It can be called from anywhere, not only from classes which extend Application or Activity:
import android.content.Context;
import android.app.Application;
import java.lang.reflect.Method;
private Context getCurrentContext()
{
Class<?> cl =null;
Method method =null;
Application app =null;
try
{
cl = Class.forName("android.app.AppGlobals");
}
catch(ClassNotFoundException ex)
{
Log.e(TAG_DISTORTED_REGION, "Failure to retrieve the AppGlobals class: "+ex.toString() );
return null;
}
try
{
method = cl.getMethod("getInitialApplication", (Class [])(null) );
}
catch(NoSuchMethodException nm)
{
Log.e(TAG_DISTORTED_REGION, "No such method: "+nm.toString() );
return null;
}
try
{
app = (Application)method.invoke(null, (Object [])(null) );
}
catch(Exception e)
{
Log.e(TAG_DISTORTED_REGION, "failure calling method getInitialApplication: "+e.toString() );
return null;
}
return app.getApplicationContext();
}
Related
I'm in the process of completely redesigning my Android app. Before, EVERYTHING was in the same class.
So I tried to redraw everything so that the code is clearer apart Admob than the doc advice to put in the Main thread, I separate the different part of my code in class. So I used two technique: I created a songleton that contains variables that I want to have access to constantly,and I call my classes via weak reference.
Here is what it looks like:
For example, the UIManager class that needs to update the game's IU have a weak reference looks like this:
private static SoftReference<UIManager> ManageUI;
static{ManageUI= new SoftReference<>(null);}
static UIManager get()
{
if(ManageUI.get()==null)
{
ManageUI= new SoftReference<>(new UIManager());
}
return ManageUI.get();
}
GameManager Manager=GameManager.getInstance();
to be able to use the findviewbyid for example I place in method argument the main class that is the mainthread
the singleton that contains all my variables that I want to have permanent access to looks like this:
private GameManager()
{}
/** Holder */
private static class Manager
{
/** Instance unique non préinitialisée */
private final static GameManager instance = new GameManager();
}
/** Point d'accès pour l'instance unique du singleton */
public static GameManager getInstance()
{
return Manager.instance;
}
To separate all in different class, I pass argument to my method so I can call au stuff belong to Activity like that:
(My main class is called GamePlay)
void OpenGlobalScene(GamePlay activity)
{
Manager.OnTitle=false;
if (!checkLayout(activity,R.id.globalscene)) {
LayoutInflater(activity,9, true);
LinearLayout GamePlan = (LinearLayout) activity.findViewById(R.id.globalscene);
GamePlan.setAlpha(Manager.AlphaBord);
}
}
For now, I have not noticed any problems except a few slownesses on old android phone 4.4.2.
Also compared to my old code were EVERYTHING was in the same class, it's much easier to change pieces of code (going to the inapp billing V3 was simpler since everything was in one class that I call like the others with weak referencre)
My questions are:
-What are the problems that such a structure might pose?
I had also chosen that structure to not load or leave in memory things that are not useful
-How are chance that Android will erase from memory an action in progress called with weak reference?
-As you can see I pass the activity has argument to the method, sometimes I pass it from a method to another. Is that fact can cause some trouble?
Thank you for your help.
Check Dagger2 is better than the clasic singleton https://developer.android.com/training/dependency-injection/dagger-android?hl=es-419
thanks for your answer and your tips. I'am gonna check this out.
Anyone else know something about consequences on memory when using weak references ?
I have several classes in my application that uses the Context object to access SharedPreferences and serialize files. Simply put, I want to know how to "design away" the Context.
The background to why I want to do this is because:
The classes should be created in the onCreate() method of a Fragment (and the Context is not decided at this point)
It's just plain ugly to pass around the Context all the time. Especially since I use Singleton-reminding instantiation of these classes (Don't judge, please)
The specific context isn't really needed here, so it should be possible to design away... (What I mean is that I only need the Application Context)
An example of why this is ugly is my Cache object. It holds cached values downloaded from 1-5 different sources decided at runtime.
public static Cache getInstance(Context context) {
if(instance == null) {
instance = new Cache(context);
}
return instance;
}
When later using this object, it needs to read a SharedPreference which needs the Context, so it has to be passed around every single time I want to get an instance of the Cache.
So how can I get rid of these ridiculous contexts? Using the Application Context should be just fine... I guess that the problem can be boiled down to something like "How do I get a SharedPreferences object" in an object without a specific Context?"
I guess that the problem can be boiled down to something like "How do
I get a SharedPreferences object" in an object without a specific
Context?"
Using the Application Context. For this purpose you can subclass Application, registering it in your AndroidManifest file, and have a method to retrieve it from every where, like a singleton
I have seen the static getContext() method on the Application object before and I think it's slightly ugly and I wasn't sure that it was "Risk free" and correct. I was just about to implement it when I found this: https://androidcookbook.com/Recipe.seam?recipeId=1218 which basically says that the Application object in Android can be treated as a Singleton and that I should place my own Singletons inside that object.
It's essentially the same as #Blackbelt 's solution, but gives a slightly nicer vibe!
I have a JNI library that I've written to capture sensor (mostly accelerometer and gyro) data and do some feature detection algorithms on said data. The features detected are configurable via a few configuration files. When the features are detected, the JNI uses a callback to notify the java side of the application. All this works great.
Now I want to be able to have multiple instances of the same JNI library running simultaneously (so I can recognize features from multiple configuration files at once). To do this, I wrote a 'wrapper' class that implements the callbacks for the JNI library and takes care of all the initialization of the library as well. I was planning on simply instantiating this class and using each instance separately. What I've found is that while each wrapper instance is distinct, the library is reused across instances almost like it was statically declared. When I try to initialize the library from the second instance of the Wrapper class, I find it has already been initialized.
Here is a wrapper class similar to the code I've written:
public class JNIWrapper {
public native int initializeJNI(String configPath);
public native void endProcessing();
public native int getInstanceIdFromJNI();
public JNIWrapper(){
try {
System.loadLibrary("libjnicode.so");
}
catch (Exception e) {
Log.e("JNI", "WARNING: Could not load libjnicode.so: " + e.getMessage());
}
}
public int initialize(String configPath){
return initializeJNI(configPath);
}
public void stop(){
endProcessing();
}
public void callbackFromJNI(int output, int instanceId){
//notify the subscribed application(s) of the feature detection
//via message passing.
}
}
Does anyone know how I can instantiate multiple copies of a JNI library?
Thanks!
You can't do that. The dynamic linker will only load a given .so file into a process once.
Ideally you would modify the library to give it a light object-oriented style, allowing you to create instances and initialize those (rather than process-level static state) from your configuration files or calls. This isn't necessarily as complicated as it seems - basically put all your state in a struct and pass the pointer to it through all your calls. You'll have one marathon editor session resulting in a tired "paste" finger, and then some mistake cleanup. Fortunately once you remove the static variables you'll get compile errors on all remaining attempts to use them.
A very hacky alternative might be to declare some remote-process services in your AndroidManifest.xml and load the library into each of those. Or, really breaking the android model (and at theoretical risk of random killing), load the library into multiple created-on-demand native executables.
I am looking for how to share functions and data across multiple activities within a single application. I researched the daylights out of it and find some ideology war between overriding the extend for the application and doing a singleton, neither of which I can find examples sufficient to make me understand. Basically I want to share data and share functions. All activities need the same functions and data so this is not one activity sharing data with another activity. It is all activities needing to have access to the same functions and data.
What I want to know is what is the way to go and how do I do it. I need to see what I need to do in my 34 activities, what the class that is going to be common looks like, and what the Manifest entry needs to be. I also need to be sure the common data area will not be closed by the OS.
This is my first Android - Java program and now find my 15,000 line, 34 activity application needs some structure. I know, should have done things differently but the app works really well with two exceptions. One is that it is structurally a mess. Two is that the fact it is a mess is making it hard to fix one behavior I would like to fix.
This is a GPS based application for racing sailboats. It is timing critical and every activity basically runs a once a second loop inside the location manager onLocationChanged function. That part is fine and I do not want to put the GPS code in one place. The problem is that most activities need to filter the data so a lot of code is copied and pasted to the activities. The filter needs history so it needs to remember a state. There are other functions that are used by several activities so these have been copied as well. Think of a function that averages the last three GPS speed readings. It needs to save some history, do its thing, and give a result. All activities need to do the exact same thing. All this works but the problem is that the averaging starts over every time I switch activities because every activity has its own filter. That gives a glitch in the data that I need to get rid of. I need common place to save the data and hopefully a common place to run the filtering and other functions that are common. If every activity can call the filter function that is using common state data, there will be no glitch across activity changes.
I would appreciate some guidance.
Why you don't just make a Class with only static functions, passing needed Parameters? An example if you want to show an ErrorDialog
public class SharedHelper{
public static Dialog showErrorDialog(Context ctx, String message, String title, DialogInterface.OnClickListener okListener, DialogInterface.OnClickListener cancelListener){
AlertDialog.Builder builder = new AlertDialog.Builder(ctx);
builder.setMessage(message).setTitle(tilte);
if (okListener != null){
builder.setPositiveButton(R.string.button_positive, okListener);
}
if (cancelListener != null){
builder.setNegativeButton(R.string.button_negative, cancelListener);
}
return builder.show();
}
}
Singletons are (from my point of view) one of the uglyest design pattern and will bite you sooner or later. Putting anything in Application requires you to cast it everytime to the Special Application class you designed. A class with only statics however is very flexible in its usage and doesn't need an instance to work.
For the storage-issue:
lookup "SharedPreferences" & "SQLite" and decide afterwards which storage-type suits your needs more.
For the methods-issue:
This question is a bit more complex and there are different ways to do it. For example you could write a parent-class that implements all your globally needed questions and you let all your activity-classes inherit from it.
public class MyParentActivity extends Activity {
public void myMethod() {
}
}
and:
public class Activity1of34 extends MyParentActivity {
myMethod();
}
I think what this comes down to is not an Android problem but an Object-Oriented Programming problem. If I understand the situation correctly, I'm betting the best solution would be to take your shared filter and create a new Filter class that is instantiated within each Activity (this is likely more manageable than a singleton, but not having seen your use case, it's hard to say for sure). If you need to centrally track the averaging, you can simply create a static variable within the Filter class that maintains the same value during the life of the application. If you really want to maintain that average (even past the application's current lifecycle), you can persist it in a database or other local data options. However, I don't see any reason to put everything in a singleton just to maintain that average. Singletons (and all static data structures) can be potentially troublesome if used incorrectly.
I, for one, do not mind the singleton pattern. Of course as everything else it should not be abused.
This is the construction I use for my shared objects. My app is divided into modules this way but can just as well be used in your case.
public class SharedDataObject {
private Context context;
private static SharedDataObject instance;
public static SharedDataObject getInstance() {
if (instance == null) throw new RuntimeException("Reference to SharedDataObject was null");
return instance;
}
public static SharedDataObject createInstance(Context context) {
if (instance != null) {
return instance;
}
return instance = new SharedDataObject(context.getApplicationContext());
}
// notice the constructor is private
private SharedDataObject(Context context) {
this.context = context;
}
...
public void myMethod() {
// do stuff
}
}
Notice that it uses the application context, that means among other things, means that the context owned by SharedDataObject cannot be used for GUI operations. But, the context will live for the entire lifetime of the application, which is nice.
Furthermore I hate having to pass a context everytime I wish to call methods on my SharedDataObject, thus I have a splashscreen calling SharedDataObject.createInstance() on all my modules.
Once an instance is create, I can call:
SharedDataObject.getInstance().myMethod();
Anywhere in my code, regardless of a context being present or not (from the place calling this code that is).
R class on android has it's limitations. You can't use the resources dynamically for loading audio, pictures or whatever. If you wan't for example, load a set of audio files for a choosen object you can't do something like:
R.raw."string-upon-choosen-object"
I'm new to android and at least I didn't find how you could do that, depending on what objects are choosen or something more dynamic than that. So, I thought about making it dynamic with a little of memory overhead. But, I'm in doubt if it's worth it or just working different with external resources.
The idea is this:
Modify the ant build xml to execute my own task. This task, is a java program that parses the R.java file building a set of HashMaps with it's pair (key, value). I have done this manually and It's working good. So I need some experts voice about it.
This is how I will manage the whole thing:
Generate a base Application class, e.g. MainApplicationResources that builds up all the require methods and attributes. Then, you can access those methods invoking getApplication() and then the desired method.
Something like this:
package [packageName]
import android.app.Application;
import java.util.HashMap;
public class MainActivityResources extends Application {
private HashMap<String,Integer> [resNameObj1];
private HashMap<String,Integer> [resNameObj2];
...
private HashMap<String,Integer> [resNameObjN];
public MainActivityResources() {
super();
[resNameObj1] = new HashMap<String,Integer>();
[resNameObj1].put("[resNameObj1_Key1]", new Integer([resNameObj1_Value1]));
[resNameObj1].put("[resNameObj1_Key2]", new Integer([resNameObj1_Value2]));
[resNameObj2] = new HashMap<String,Integer>();
[resNameObj2].put("[resNameObj2_Key1]", new Integer([resNameObj2_Value1]));
[resNameObj2].put("[resNameObj2_Key2]", new Integer([resNameObj2_Value2]));
...
[resNameObjN] = new HashMap<String,Integer>();
[resNameObjN].put("[resNameObjN_Key1]", new Integer([resNameObjN_Value1]));
[resNameObjN].put("[resNameObjN_Key2]", new Integer([resNameObjN_Value2]));
}
public int get[ResNameObj1](String resourceName) {
return [resNameObj1].get(resourceName).intValue();
}
public int get[ResNameObj2](String resourceName) {
return [resNameObj2].get(resourceName).intValue();
}
...
public int get[ResNameObjN](String resourceName) {
return [resNameObjN].get(resourceName).intValue();
}
}
The question is:
Will I add too much memory use of the device? Is it worth it?
Regards,
I'm new to android and at least I
didn't find how you could do that,
depending on what objects are choosen
or something more dynamic than that.
The Resources class has a getIdentifier() method that will give you the resource ID given the name as a string. This uses reflection, so you would want to cache the results, perhaps using a LinkedHashMap as an LRU cache.
Is it worth it?
IMHO, not really. I would just use getIdentifer() or directly use reflection myself. In fact, I have directly used reflection myself (with the LRU cache) to address this issue.