Is there any way to access private variables of other class.Actually I am writing testCases for my library project in order to test all possible critical conditions when the app is going to crash .I shuld write in such a way that my project should pass all test cases.Now what my problem I should check for the variables which are declared as private in my library project.Is there any way to access these variables (which are declared as private).
use getters and setters ..it is the preferred way.. in setters make sure you keep safe values and make sure they will not break your code in any case..
On Android, you wanna make your activities' methods private to prevent other classes from thinking they can access it (fragment can, but that is wrong practice to me, it's better to use an observable-observer pattern). Then you will end up with private fields and methods that would need to be accessed by tests only.
BoundBox does exactly that ! Here below is an example of a test that accesses 2 private fields of an activity to test it :
#UiThreadTest
public void testCompute() {
// given
boundBoxOfMainActivity = new BoundBoxOfMainActivity(getActivity());
// when
boundBoxOfMainActivity.boundBox_getButtonMain().performClick();
// then
assertEquals("42", boundBoxOfMainActivity.boundBox_getTextViewMain().getText());
}
Related
I'm working on an Android app that uses some background tasks (AsyncTasks) and I want to use best practices regarding data persistence across app lifecycle and tasks callbacks.
Up to now, I have a mix of practices regarding this:
1) I have some static fields in classes where AsyncTasks are used in the form of:
private static String str1;
private static String str2;
private static int int1;
...//=>no more than 6 static fields
2) I use a sinleton App instance with many getters/setters in the form of:
package xxx.xxx.xxx
import xxx.xxx.xxx
...
public class AppSettings {
private static AppSettings singleton;
private String _field1;
...//=>many fields
public void setField1(String field1) { _field1 = field1; }
public String getField1() { return _field1; }
...//=>many getters/setters
private AppSettings() {}
public AppSettings getInstance(){
if (instance== null) {
synchronized(AppSettings.class) {
if (instance == null)
instance = new AppSettings();
}
}
return instance;
}
}
I definitely know that abusing of static fields is not good at all, so I decided to replace them all, but I'm not completely sure if my second approach -having an application instance in a singleton with many getters/setters- is considered a good way to go, and in case not, I would like to know about better alternatives.
Thank you very much.
Edit 1: Just to clarify.
In order for you to understand more clearly what I use my AppSettings singleton class for I'll give you two examples:
1) I use it to store app setting/configuration values (that's why the name) to be available anywhere. For example, font color, font size, whatever.
2) I use it to store temporary data/values. For example, my main activity creates a small video in the backgroung using "VideoHelper" class and called through an AsyncTask, and as video generation process needs some parameters from main activity, I use AppSettings getters/setters to send them through.
Edit 2: Better explanation of everything.
Thanks to #a_local_nobody I realized my "case of use" was not so clear so I'll add a few things more.
My AppSettings is not being used to store user settings, I use SharedPreferences for that, but instead app default configuration parameters.
To give an example, I store activities background color (and this is just an example) so if in the future I change my mind and decide to use another background color this setting (and many more) are centralized there. It's like a "container" for many default app settings.
Regarding the use of getters and setters in this app singleton class, I think I'll foloww #a_local_nobody suggestion related to define some static variables in each class and use them as needed instead of having a bunch of unrelated getters/setters globally.
Anyway, all comments are welcome.
Well, you are talking about persisting data across app lifecycle which, in my mind, sounds like you're looking for a ViewModel:
The ViewModel class is designed to store and manage UI-related data in
a lifecycle conscious way. The ViewModel class allows data to survive
configuration changes such as screen rotations.
as well as:
The purpose of the ViewModel is to acquire and keep the information
that is necessary for an Activity or a Fragment. The Activity or the
Fragment should be able to observe changes in the ViewModel.
ViewModels form part of the MVVM design pattern, with loads of examples available online.
For more info, have a look at the documentation
on a side-note, perhaps you can have a look at the google sunflower project for some ideas on how to implement the new architecture components, which includes usages of ViewModels.
Also worth adding, is that what you've created with your AppSettings solution, is a big dependency. Various things will depend on this single object and it will be needed throughout your application, most likely. You might consider, instead of creating it like this, to rather use dependency injection with your options, for android, probably being either Dagger 2 or Koin for kotlin (if you ever swap over to kotlin) or perhaps your own form of dependency injection without having to use these frameworks.
Hope this helps
Edit based on feedback from OP:
I use it to store app setting/configuration values (that's why the
name) to be available anywhere. For example, font color, font size,
whatever.
this sounds like a better use case for Shared preferences, especially if these are settings defined by a user, otherwise you should be savings these into strings.xml etc. and making use of localization
I use it to store temporary data/values. For example, my main activity
creates a small video in the background using "VideoHelper" class and
called through an AsyncTask, and as video generation process needs
some parameters from main activity, I use AppSettings getters/setters
to send them through.
if you have a VideoHelper class, you might be better off either creating a Builder design pattern for this object, or having static variables for this helper to change its functionality as you need to, if these are variables for your VideoHelper, then they should be located with your VideoHelper.
Things which change together should usually stay together.
Your approach doesn't qualify as "best practices" in modern android development.
The recommended way of handling configuration changes is by using the new architecture component: ViewModel
It have the property of surviving the onDestroy triggered when a configuration change occurs.
Basically, you will need to move this AppSettings code to a ViewModel.
I have a class that consists only of static member variables and static methods. Essentially, it is serving as a general-purpose utility class.
Is it bad practice for a class to contain only static member variables and static methods?
No, I don't think so at all. It is worse practice to have a class full of instance methods which don't actually depend on a particular instance. Making them static tells the user exactly how they are intended to be used. Additionally, you avoid unnecessary instantiations this way.
EDIT: As an afterthought, in general I think its nice to avoid using language features "just because", or because you think that that is the "Java way to do it". I recall my first job where I had a class full of static utility methods and one of the senior programmers told me that I wasn't fully harnessing the OO power of Java by making all of my methods "global". She was not on the team 6 months later.
As long as the class has no internal state and is essentially what is known as a leaf class (utility classes fall into this category), in other words it is independent of other classes. It is fine.
The Math class being a prime example.
Sounds reasonable.
Note: Classes that do this often have a private no-arg constructor just so that the compiler yields an error if a programmer tries to create an instance of the static class.
Static methods don't worry me much (except for testing).
In general, static members are a concern. For example, what if your app is clustered? What about start-up time -- what kind of initialization is taking place? For a consideration of these issues and more, check out this article by Gilad Bracha.
It's perfectly reasonable. In fact, in C# you can define a class with the static keyword specifically for this purpose.
Just don't get carried away with it. Notice that the java.lang.Math class is only about math functions. You might also have a StringUtilities class which contains common string-handling functions which aren't in the standard API, for example. But if your class is named Utilities, for example, that's a hint that you might want to split it up.
Note also that Java specifically introduced the static import: (http://en.wikipedia.org/wiki/Static_import)
Static import is a feature introduced
in the Java programming language that
members (fields and methods) defined
in a class as public static to be used
in Java code without specifying the
class in which the field is defined.
This feature was introduced into the
language in version 5.0.
The feature provides a typesafe
mechanism to include constants into
code without having to reference the
class that originally defined the
field. It also helps to deprecate the
practice of creating a constant
interface: an interface that only
defines constants then writing a class
implementing that interface, which is
considered an inappropriate use of
interfaces[1].
The mechanism can be used to reference
individual members of a class:
import static java.lang.Math.PI;
import static java.lang.Math.pow;
or all the static members of a class:
import static java.lang.Math.*;
While I agree with the sentiment that it sounds like a reasonable solution (as others have already stated), one thing you may want to consider is, from a design standpoint, why do you have a class just for "utility" purposes. Are those functionals truly general across the entire system, or are they really related to some specific class of objects within your architecture.
As long as you have thought about that, I see no problem with your solution.
The Collections class in Java SDK has static members only.
So, there you go, as long as you have proper justification -- its not a bad design
Utility methods are often placed in classes with only static methods (like StringUtils.) Global constants are also placed in their own class so that they can be imported by the rest of the code (public final static attributes.)
Both uses are quite common and have private default constructors to prevent them from being instantiated. Declaring the class final prevents the mistake of trying to override static methods.
If by static member variables you did not mean global constants, you might want to place the methods accessing those variables in a class of their own. In that case, could you eleborate on what those variables do in your code?
This is typically how utility classes are designed and there is nothing wrong about it. Famous examples include o.a.c.l.StringUtils, o.a.c.d.DbUtils, o.s.w.b.ServletRequestUtils, etc.
According to a rigid interpretation of Object Oriented Design, a utility class is something to be avoided.
The problem is that if you follow a rigid interpretation then you would need to force your class into some sort object in order to accomplish many things.
Even the Java designers make utility classes (java.lang.Math comes to mind)
Your options are:
double distance = Math.sqrt(x*x + y*y); //using static utility class
vs:
RootCalculator mySquareRooter = new SquareRootCalculator();
mySquareRooter.setValueToRoot(x*x + y*y);
double distance;
try{
distance = mySquareRooter.getRoot();
}
catch InvalidParameterException ......yadda yadda yadda.
Even if we were to avoid the verbose method, we could still end up with:
Mathemetician myMathD00d = new Mathemetician()
double distance = myMathD00d.sqrt(...);
in this instance, .sqrt() is still static, so what would the point be in creating the object in the first place?
The answer is, create utility classes when your other option would be to create some sort of artificial "Worker" class that has no or little use for instance variables.
This link http://java.dzone.com/articles/why-static-bad-and-how-avoid seems to go against most of the answers here. Even if it contains no member variables (i.e. no state), a static class can still be a bad idea because it cannot be mocked or extended (subclassed), so it is defeating some of the principles of OO
I wouldn't be concerned over a utility class containing static methods.
However, static members are essentially global data and should be avoided. They may be acceptable if they are used for caching results of the static methods and such, but if they are used as "real" data that may lead to all kinds of problems, such as hidden dependencies and difficulties to set up tests.
From TSLint’s docs:
Users who come from a Java-style OO language may wrap their utility functions in an extra class, instead of putting them at the top level.
The best way is to use a constant, like this:
export const Util = {
print (data: string): void {
console.log(data)
}
}
Examples of incorrect code for this rule:
class EmptyClass {}
class ConstructorOnly {
constructor() {
foo();
}
}
// Use an object instead:
class StaticOnly {
static version = 42;
static hello() {
console.log('Hello, world!');
}
}
Examples of correct code for this rule:
class EmptyClass extends SuperClass {}
class ParameterProperties {
constructor(public name: string) {}
}
const StaticOnly = {
version: 42,
hello() {
console.log('Hello, world!');
},
};
I'm developing an android app implementing MVP and clean architecture. I have the following scenario:
One core module with presenters and view interfaces,...
One domain module with repositories, data sources,..
App module with the core implementation (so the Fragment/Activities).
Currently the strings.xml file is in the app module, but I'm thinking whether it should be in a commons module or not. The problem is that, sometimes, the presenter must set the text to the view, so the presenter should need to access to the strings.xml. I've thought in two possible solutions:
1) Create a TextHelper interface on core module that will be implemented on the app module and injected to the presenter, so the presenter will use this helper to get the strings it requires. (This is the solution I have implemented).
2) Move the strings.xml file to a common module so the file can be accessed from core module. But this solution would have a problem: the presenter doesn't have a context.
What do you think? What is the best approach?
Thanks in advance
If your view has nested if/elses related to strings, then they should probably be unit-tested. Therefore, that logic should stay in presenters or use-cases, where can be tested more quickly.
Your question is about how to retrieve the actual strings, given that they reside in the "outer layers" of the Clean Architecture scheme, i.e. in the Context object. IMHO your TextHelper is the right approach, as it allows to inject a mock when writing unit tests: you're interested in how the strings are processed, rather than how the strings actually look. I'm trying a very similar approach and calling it StringsRepository.
A point of uncertainty is how the the repository API should look like:
A single method like getString(#StringRes int stringResId, Object... formatArgs) that simply wraps Context.getString(): very simple to implement, but will make the presenters depend on your R.string class, which in turns requires strings.xml to be in the same module as your code under test;
One method per string with optional arguments, each one containing the reference to the appropriate string ID. This solution allows for best abstraction, but may become big (both the interface and the implementation...) and many domain classes may depend upon it. Handle with care.
Like (2), but with several classes, one per each part of your app. Each class may have a base class similar to (1) but with that method with protected visibility.
The best options for your case would be (2) or (3), but your mileage may vary.
You can use Application class to get the context any where from the app.
public class MVPApplication extends Application {
private static Context context;
public static Context getContext() {
return context;
}
#Override
public void onCreate() {
super.onCreate();
context = getApplicationContext();
}
}
Recently I have started development in Java for Android.
My idea is to create one static class which will load ton of stuff on the beginning and store results for a lifetime of application.
I have been reading lot of how to share object between activities and I think the best will be to create one static class. What do you think? Should I use another approach? I am asking because I have read lot of counter opinions over the internet.
Thank you.
I'm assuming that you were referring to static fields of a class, as opposed to static class which, as Wyzard pointed out, is something completely different. As a general rule of thumb, holding information in static fields is not a good idea in Java. The reason for this is that it prevents the ability to instantiate multiple instances of whatever it is you store in the class.
In the specific case of an Android application, the best way to deal with the issue of having data stored associated with the application itself is to subclass the android.app.Application class and use it to handle application-global data:
class FooApplication extends Application
{
private String privData;
public String getPrivData() {
return privData;
}
}
You then need to declare that this class is your main application class (instead of the default Application). In the application entry in AndroidManifest.xml add the following:
<application android:name="com.example.application.FooApplication"
...>
...
</application>
You can then look up the application instance from anywhere inside your application using the method Context.getApplicationContext() which will be an instance of your Application subclass:
FooApplication app = (FooApplication)Context.getApplicationContext();
String privData = app.getPrivData();
Depending on from where you are trying to look for subclass of "Application", you may have to invoke the "getApplicationContext()" without "Context":
FooApplication app = (FooApplication)getApplicationContext();
String privData = app.getPrivData();
The problem with your solution is that you're basically creating a huge stack of globals. It's sometimes unavoidable, but it has the same type of problems globals always have- you quickly end up with hard to read code that doesn't really have a good OO breakdown. You can use this, but use it sparingly- only with important data structures that are really going to be shared between many activities.
Android provides a class called Application, which is will not be gc'ed as long as your Application isn't killed. Use this class for initialization, static classes as containers are somewhat ugly, but i can't pinpoint why that is.
I only use them as containers for constants such as bitmasks which can't be expressed as EnumSets.
As the other posts mention SharedPreferences: I think the preferences exist to store values, but not to load your structures that you need for you application. These structures should be loaded from a construct that represent or make up a model for your data's semantics.
When I'm writing a method or using a member variable, I often find I need to share them across an app. But where should they go?
I can subclass Activity, but that falls over as soon as I use a MapView and am forced to use MapActivity, so not all my activities inherit from my subclass. Is there I way around this?
Where inheritance isn't applicable, I am tending to put generic methods and member variables into a subclass of the Application object, but I'm finding it's creating a mess of code as every class needs to either grab access to the application object through via context, or I have to pass it down.
I suspect I would be better off creating MyApplication.getInstance() and keeping everything in a singleton, instead of passing the application object down through the app classes. but before I wanted to see what you guys had to say.
If you want to access the "Global Singleton" outside of an activity and you don't want to pass the Context through all the involved objects to obtain the singleton, you can just define, as you described, a static attribute in your application class, which holds the reference to itself. Just initialize the attribute in the onCreate() method.
For example:
public class ApplicationController extends Application {
private static ApplicationController _appCtrl;
public static ApplicationController getAppCtrl()
{
return _appCtrl;
}
}
One example with resources: Because subclasses of Application also can obtain the Resources, you could access them simply when you define a static method, which returns them, like:
public static Resources getAppResources()
{
return _appCtrl.getResources();
}
For global methods, use a static Util class with static methods. If you can't use static methods, then the methods shouldn't be global in the first place, and put them in the class that makes sense.
First read this:
How to declare global variables in Android?
Now why you shouldn't use a static singleton. Using a singleton is a the same thing as a global variable. Global variables reduce your maintainability because everywhere you use the global variable you break modularity or introduce global details and assumptions about your overall design. Your program can't have two of these variables because it only looks in one place for it. This means your program can't adapt easily when you have two instances instead of one.
For example, say I have a method called playTurn() and I implement it like so:
public void playTurn() {
globalPlayer.incrementClock();
globalPlayer.doSomething();
globalPlayer.doSomethingElse();
}
Now let's say I want to add a second player to the mix. Uh oh my playTurn() method assumes one player only when it used globalPlayer. If I want to add a second player to the program I have to change that method. Do this a lot and your program is very rigid and inflexible to change. Instead what if I did this:
public void playTurn(Player player) {
player.incrementClock();
player.doSomething();
player.doSomethingElse();
}
Now can do this:
playTurn( player1 );
playTurn( player2 );
I can reuse playTurn() for both player1 and player2 and I didn't have to change it. I just had to change the client of that method.
Most of the time you're being lazy and you want to get a reference to some object, and global variables are fast ways to get references to well known objects. Instead it's better to have one class that resolves the dependencies across your application at start up or the time when it makes sense. Then only that one place understands how your code is put together. For example,
public class Game {
Player player1;
Player player2;
Board board;
public void startGame() {
BlueTooth blueTooth = BlueTooth.getChannel();
player1 = new LocalPlayer();
player2 = new NetworkedPlayer( blueTooth );
board = new Board();
player1.setOpponent( player2 );
player1.setBoard( board );
player2.setOpponent( player1 );
player2.setBoard( board );
}
}
Now everyone has their dependencies, and they don't need to use static variables to find references to things. Also player1 doesn't have to know about details like that player2 is over the network, or that it's apart of a Game. What's important to note is that these objects we're connecting have a long life, possibly the entire program, but if they need to create other things at runtime that's ok for them to do.
Say for example, we need to create multiple players at runtime based on who joins the game. Well we might create a PlayerManager that we can instantiate at startup then create Player objects on the fly. PlayerManager is just a plain old object that we create in Game when we start a new game.
I hope you can start seeing this is a much better way to develop software. You might not understand it right off, but if you think about it will make more sense. It's very subtle change, but very powerful.