I have an Android Studio project that is using an MVP architecture.
What is the advised packages structure for a project this style
we can do:
app:
screen_name
activityA
presenterA
interfaceA
or:
activities
activityA
activityB
preentors
presentorA
presentorB
etc
Your problem is just only UI part of MVP architectural pattern. Which is View classes along with their corresponding Presenters. And the better solution is the first approach.
App should have package according to features, NOT by the common functionality. We should group together the classes which are getting changed/modify together.
Some developers group source code by layer - like the second approach - because they want to keep the same package structure for ALL the projects they work on. But that is bad decision because it's always HARD to find classes when they are grouped only because they share same parent classes!
Ex: For activities, some developers put them in activity package because all activities extends Activity class. It makes sense because this is activity-ONLY package, BUT it is hard to go through those packages.
For more information, see: android-mvp-architecture and this S.O answer
In addition to the other answers i would recommend to look at android architecture blueprints, which may give you ideas of how to organize and implement your application.
MVP is good choice. You can follow following pattern:
app:
1. activities:
+ interface to represent view (i.e activity)
+ actual activity java class
2. Presenter:
+ interface to represents presenter
+ java class to represent presenter implementation
3. Model:
+ interface to represents model
+ java class to represent model implementation (do network calls here, pass callback to presenter which then gives data to activity)
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.
Suppose I have a Android Application which can have different navigational capabilities based on the concrete class attached to the application. How to specify the concrete class. Android Resources (R.java) doesnt talk anything about Objects. I do agree that I can have classname as a String attribute and then instantiate through Reflection.. but I am not in favor of that solution.
Which other way I can attach a concrete implementation to the Android Application so that depending on this object, the application can behave differently in different builds.
Consider declaring an interface and have all of the concrete classes implement the interface as plug ins. Then you can either hand code a single line of code such as
Model model= new Model(new MyConcreteClassSpec());
where MyConcreteClassSpec implements IMyModelSpec
Or you can pass an integer value and return a concrete class using a class factory as in:
Model getInstanceModel(int i);
Using an int instead of a enum makes the class factory extensible in the future.