I have created a Builder class which initializes the Picasso library object in variety of ways, properties like gravity, resize(x,y) etc.
In one particular case, if isCenterCropGravity(int gravity) is called. The gravity is operational if the resize method is also called while creating the object.
In order to achieve so, I want to create a custom lint check, within which, if the centerCropGravity() method is called before resize() method, a lint error message warning should be displayed, now I've never written custom lint check and any available resource on the internet is not remotely related to the solution i want to achieve.
Related
I am working on print custom document in Android, in PrintDocumentAdapter I need to override the function onLayout, I should call onLayoutFinished, I always set the second parameter as true, but the website says
Note: The boolean parameter of the onLayoutFinished() method indicates whether or not the layout content has actually changed since the last request. Setting this parameter properly allows the print framework to avoid unnecessarily calling the onWrite() method, essentially caching the previously written print document and improving performance.
So how can I know whether the layout has been changed from last request, and if it false does it mean it is the same layout with the former layout so why onLayout is called? Which action triggers? I am new to android, so any help is appreciated.
Since you're using custom printing, your app determines how the content is laid out and can determine if the file needs to be re-written hence setting it to true. If the content of the file hasn't changed based on the new 'PrintDocumentInfo' then you can set it to false.
I have a method that darkens a given hex color and percent. Currently, the only place I use this method is within one of my Activity classes (I may or may not end up using it in other classes later on).
public static int darkenColor(int color, int percent) { ... }
However, where should I put this method? Should I create a new class called Helpers that contains all of these methods that I may use only once throughout the entire app?
This is just a matter of choice. You can have Set of utility classes and have these helper methods to be in those classes. But, This method is for not used in one of your activity, and If you do not see that it will get reused in the near future in some other point, Put it as a private method inside your Activity. I say this because you do not want to over complicate the code and also By this way another developer can easily follow the flow of execution.
But after sometimes if you feel, that this code is getting reused, put that into a logically meaningful Utility class. When the code base is huge, you do not have any choice to follow a solid standardization of there to put your code, That is why there are things like Layered architectures etc.
We here (two small teams) are writing an Android library (OpenGL ES 3.1 based graphics effects library, but that's irrelevant to the question). One team writes the Core part (this code ends up in the (*.library.core package) , while another writes the individual effects (each effect is a single .java file in *.library.effects package + some shader code).
Currently the development works like this: each time a new effect gets written (lets say the class that implements it is called EffectBlahBlah), the Core team has to go over their code and, in one place, add a call to a static method EffectBlahBlah.init(), in another place - a call to another static method EffectBlahBlah.getUniforms(), etc etc. There are AFAIK 7 different places where we have to add 7 different calls to certain (static and non-static) methods from the new effect.
Now - having to add 7 lines of code is not the end of the world; however (especially in light of the fact that we are hoping to open the development of the effect part to outside programmers) we are hoping to automatize this in the following way:
have the Core scan the *.library.effect package and come up with a
list of all Effect classes that are there (we know how to do this)
in each of those 7 places in our code, automatically call the
appropriate method for each discovered class.
Now, if not for the static methods (which have to be there) I'd know how to do this: have all Effects extend an abstract class (lets say 'BaseEffect') which declares the 7 methods abstract, in each of the 7 places instantiate each effect in a loop using Class.forName(), cast it to a BaseEffect and call the appropriate method.
However Java does not allow abstract methods to be static. What do you recommend then?
You can use reflection for this. A possible sequence of calls is roughly:
Use Class.forName(name) to get the Class instance describing your class.
Call getMethods() on the Class instance to get the list of methods (or getMethod() to directly get a method, if you can figure out how to use it).
For the entries in the returned list of Method instances, use getModifiers() to check if it's static, and getName() to identify a specific method.
Once you found the desired Method instance, call the invoke() method on it to call the method. For static methods, you can use null for the receiver (first argument).
OOTB, Robolectric does not support Locales that well. Therefore, if your app is dependent on locales (which a lot of apps are if they are i18n'nd properly) this can be a royal pain. Long story short, I created my own ShadowFooGeocoder and ShadowFooAddress that allow me to simulate the locale I want. They're basically re-implementations of the existing shadows.
However, when I bind my class as such: bindShadowClass(ShadowFooGeocoder.class), this works great. At runtime, the correct shadow is returned. The problem is that I want to set up the simulations on this object and I'm not sure how. shadowOf(instance) where instance is an injected GeoCoder returns ShadowGeoCoder. I've tried working directly with the ShadowWrangler, but that also returns a ShadowGeocoder.
How can I get at my shadowed class that I've bound through the bindShadowClass(...) call so I can set my expectations (simulations)?
Note: This is a repost of the same question on the Robolectric group here. I posted here because my success rate of getting anyone to answer questions on the group is fairly low. I'm hoping for a better result here.
What I've basically done here is extend ShadowGeocoder like this:
#SuppressWarnings({"UnusedDeclaration"})
#Implements(Geocoder.class)
public class ShadowFooBarGeocoder extends ShadowGeocoder {
// implementation stuff
}
Then I would bind it using the bindShadowClasss(...) and when I retreive the shadow via the static shadowOf(...) call I get back a "ShadowGeocoder" which is an instance of ShadowFooBarGeocoder. I then cast it to that type and perform whatever work I need to.
In the source code of Activity.java, I see some methods bellow :
public View findViewById(int id) {
return getWindow().findViewById(id);
}
and the definition of getWindow method:
public Window getWindow() {
return mWindow;
}
But as the following rules:
Avoid Internal Getters/Setters
In native languages like C++ it's
common practice to use getters (e.g. i
= getCount()) instead of accessing the field directly (i = mCount). This is
an excellent habit for C++, because
the compiler can usually inline the
access, and if you need to restrict or
debug field access you can add the
code at any time.
On Android, this is a bad idea.
Virtual method calls are expensive,
much more so than instance field
lookups. It's reasonable to follow
common object-oriented programming
practices and have getters and setters
in the public interface, but within a
class you should always access fields
directly.
Without a JIT, direct field access is
about 3x faster than invoking a
trivial getter. With the JIT (where
direct field access is as cheap as
accessing a local), direct field
access is about 7x faster than
invoking a trivial getter. This is
true in Froyo, but will improve in the
future when the JIT inlines getter
methods.
so I want to know why android developers not access this mWindow object directly? If the JIT of the current android versions cannot inline the access, getWindow().findViewById(id) will costs more time than mWindow.findViewById(id), and findViewById is a rather frequently used method.
First: you can't access it because it's private.
Why is it private?
As you said, accessing members directly is faster. On the other hand, you are invoking a method that isn't very fast as it will lookup for some view in the view hierarchy. So using a method instead of a direct access will incur in a small overhead in terms of percentage of the total time that it would take to perform that task.
Anyway, I believe that the reason for this is encapsulation.
You are invoking something you don't own (that is the Android SDK). So, you shouldn't make any assumptions of whats happening "in the other side". Simply use this method and expect that it will return the view you want (or null if it doesn't exists).
Maybe the next version of android will use a different method to lookup a view, not calling getWindow(). If you use this method, they (Google/Android) can simply mark the method as deprecated and "forward" your invocation to the newest implementation. If you were calling directly getWindow(), maybe you would be looking for something that is no longer placed in there.
You can't access the mWindow property directly - it's private.
And I wouldn't care about the speed of findViewById, since you only need to call it once for every view in your layout in your onCreate() method and store the views in members of your activity. You do call findViewById only once per view, don't you? ;-)
However, if you really care about these things, you could call getWindow() for yourself, store it into a local variable and call findViewById on it directly. I wouldn't recommend this because all your performance increasements here are not worth the time and anyway will be obsolete with future versions of the JIT.
If you do this I would be very interested in the amount of microseconds you saved. :-)
We have a reason to smile now...
The android documentation which says to avoid internal getters and setters will change soon, supposedly progruard was added to Gingerbread platform which does a fine job of inlining accessor's, please refer to "Avoid Internal Getters/Setters" is bad advice and these two SO posts.
https://stackoverflow.com/a/6716573/892055
https://stackoverflow.com/a/4930538/892055