My question is regarding in creating a method to be used in my android app. This method is a blackbox that accepts string as a parameter then converts the string object into something.
I want to call this method everytime a certain button is clicked (from a fragment and activity) and I'm wondering if static is the better approach for this since i dont need to instantiate.
I read the answer in Difference between Static methods and Instance methods and says that static is better but i found a blog that one should avoid static as possible.
So what's better approach to implement for my blackbox method?
If you place your method in activity class which contains button with onClickListener calls this method, there is no need to make it static, because the instance of activity created anyway.
If you use a separate class with utils methods, then it may be a good idea to use a static method.
This article is simple explanation of rules to make a method static in Java
Related
Background -
I have an app that currently has a lot of methods in MainActivity to pull and upload data to firebase. It's quite a mess with the other app logic in there..
Problem -
I would like a separate class filled with server (firebase) access methods that can be called from any activity or fragment and run asynchronously. The class also needs access to context and be able to initialise and store variables.
PS. I'm using kotlin if that helps at all
Edit:
Have done more researching to find terms like "utility" and "static" classes which seems like an accurate way to go... If I create a static utility class with Async methods, will that achieve what I'm after? Also, can you initialise and hold variables in a static class?
Thanks :)
Solved
After more research and testing, I created an object that holds my methods and variables and just need to pass context into the relevant methods. Then just simply call objectname.methodname()
I don't know if it has been answered or not, I found some similar questions but the answers are not making any sense to me. So, I am asking it again.
How can we test a method which is inside an activity.
public class MyActivity extends AppCompatActivity {
#Override
protected void onCreate(Bundle savedInstanceState) {
//inflate layout
}
public int someMethod() {
//perform some logic and return an integer
}
}
I want to unit test the method someMethod but how can I do this as I cannot create an instance of the activity and directly call that method. The method under test does not use any android component so I dont want to use Roboelectric or any other such libraries or tools. It is a plain java method.
One way I know is to move the method to another class and have that class unit tested and I am perfectly fine with it, but I wanted to know if that is the right way, (create a separate class just for this purpose), or is there any other way to do it?
Thank you for any feedback.
To go a bit into theory, you do not want to test a single method in another class.
Following S.O.L.I.D. and D.R.Y. principles, your classes shall have a single responsibility.
So if you think that you want to test only one single method, this method clearly has another responsibility than the rest of the class. Which leads us to: It should not be in that particular class.
Unit Tests are only as good (and as valuable) as the plan behind the testing.
To answer your question: Yes you can call a new myActivitiy() and the unit test might run it (at least I think so). But if the method uses runtime values / context or any other thing from that activity, you can't without running Espresso or similar frameworks.
I recommend to create a proper object model that is testable.
Unit tests can only test code that is written testable
cheers, Gris
I have an application with 100+ static variables and methods in its Application class will it affect the performance of the app? if so how to handle it?
As I see, your only question is if using static methods and variables inside your application class is wrong or not. As far as I know, it will not affect your application performance or anything else, but putting them inside application class is a wrong design. It's like you put all your code inside one single method and it will not be good.
So, I suggest you to put your static methods inside a Helper class and since they don't need to be instantiated, they need to be static, not a singleton. Also for your variables, for example for your Strings, I suggest to create another class and put them into it so your application maintenance be possible.
Im trying to change the method of just one instance from another class. Is this possible, and if so how can I do it?
Im trying to rewrite the entire method durring runtime. I only want the method to be changed for one instance of the class, and all the other instance's methods should stay the same. I hope that clears up some confusion
No this is not possible.
Method definitions are stored by class, not instance (and are immutable anyway). One thing you can do is to store a callable object per instance and call that.
I think you need to provide more details and perhaps some sample code to get a sufficient answer. That being said, if class Foo extends class Bar, class Foo can override a method of class Bar. Is that what you're trying to do?
Okay, I'm NOT a Java noob, it just so happens that I've forgotten a tad bit about core Java while I was learning more fun stuff like MySQL, Servlets, Java EE, JDBC etc etc; so don't frame your answers as if I were a beginner. Now the question.....
I'm writing a class (lets say ThisIsAJFrameExtendingClass) which extends JFrame, and to minimize confusion with my overall project, I also want to park some other utility methods in ThisIsAJFrameExtendingClass. I intend this class (ThisIsAJFrameExtendingClass) to seek certain inputs from the user following which; commit suicide (ie dispose()). So, my question is, how can I independently use the utility methods inside the class without any JFrame popping up on the user screen.
I'ld like a solution with the help of multiple constructors inside the ThisIsAJFrameExtendingClass class, where, invoking the argument-less constructor return JFrame and the second constructor with a boolean argument gives access to the utility methods.
[UPDATE]
Ohh.... I just had a thought, the utility method has a return type of ArrayList so, assuming the utility method is called utilMethod() then:
ArrayList<String> pring = new ThisIsAJFrameExtendingClass().utilMethod();
will the above code output any JFrame?
You could make the utility methods static, in which case they can be invoked using ThisIsAJFrameExtendingClass.<method name> without creating an instance.
The stuff about constructors doesn't really make sense to me. A class's constructor always returns an instance of that class. It can't return "something else" because of a parameter you pass in.
[Edited to respond to the question's Update]:
new ThisIsAJFrameExtendingClass() will create an instance of your class, running its constructor (and the default constructor of all superclasses). This may allocate other resources (such as other Swing components or whatever) that each constructor in the inheritance tree requires. So a JFrame is created, but if you only call utilMethod() and never hang on to the reference to the frame, it will be garbage collected and its resources freed at some point in the future.
Creating a JFrame instance to call a single utility method on it isn't a particularly efficient way to go about things, but it won't cause any problems. (As Chad says, by default a JFrame isn't visible, so users won't see anything if you're using it in "util" mode).
As to returning an ArrayList, as a general rule when using collections, you should return the highest level interface that makes sense rather than a concrete class. So in this case, consider returning List<String> or even Collection<String>.
I have a lot of trouble getting behind your concept, which sounds a bit confused to me. At the very least, it sounds like horrible design. But I do have some suggestions:
You can make those utility methods static, then you won't need to instantiate your class at all to use them. This would be the simplest case.
You could pack your utility methods inside a static inner class of your frame, which essentially gets you around the requirement to only have one class per file.
Finally, do you just want the JFrame to disappear once the user is done with it, or do you want to terminate the application? dispose() will do only the former, your app will continue to run as a kind of headless zombie process.
Okay let's assume the methods you need aren't static.
In that case, remember the JFrame won't show up unless you call setVisible(true); So just make sure you never show the frame, and you can use whatever functions you want without it annoying the user.
Or you could design it properly and break out the utility methods into a separate class...