Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I am trying to build an Android application. I've about 31 URLs. Currently I am storing the URL Strings as Constants in a class named UrlRes so that I can call UrlRes.SIGN_UP_URL or UrlRes.PRODUCT_ADD_URL. Is this a right approach? Should I store each URL on specific models ? example PRODUCT_ADD_URL in Product model. I think it'll be more meaningful when I call Product.PRODUCT_ADD_URL.
In android's implementation each ContentProvider provides some contract classes with the uris and fields of each entity. Each contract contains static inner classes or interfaces for the different parts of the ContentProvider it belongs to.
For instance the UserDictionary contains Words and the Contacts contract contains Settings, Groups and some helper methods.
I would prefer using the Product.PRODUCT_ADD_URL strategy because if more links will be added in the future it's much clearer for you or other developers working on your app to understand this approach.
String resources are used primarily for layouts and views so storing URLs in strings.xml is not considered best practice. You may instead want to store it in a class and making URL as public final static.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I need a very lightweight and persistent key/value-store in Java.
The amount of data is very very low and it should be very simple (getter and setter and all can operate on strings).
So I think of using some small NoSQL-DB or even giving some integrated collection a serializer/deserializer to the filesystem.
But I think NoSQL is a overkill and I hope a persister also exists for such a simple requirement.
Whats the best approach here? Any ideas?
You can either implement your own thing if it is a simple key-value string. (Have a look at Java's Properties class too in case it suits your requirements).
If your requirements are slightly more complex have a look at the embedded lightweight databases you can use. Maybe BerkleyDB might work for you. There are quite a number of others if you do a bit of search.
Also think about what you actually need to do with the data. Do you need to query it (so it needs to be indexed?) or do you just want to load it back all into memory? (in which case using a simple JSON or YAML text format would also suffice.)
Most Map<String,String> can be serialized. So for example look into https://docs.oracle.com/javase/8/docs/api/java/util/HashMap.html
there you find Serializable. Under that point information to help yourself solve the Problem.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Say I have a method that is used for opening application with an android app from a sidebar
openApplication(Sidebar s, Context c ... )
and now I want to use this openApplication to open from a Topbar
openApplication(TopBar t, Context c ... )
The function openApplication is very similiar but needs to do little-changes based on Sidebar or TopBar attributes/ members
I dont what to make two different functions that basically do the same thing but different in 2-3 lines of code. What is good practice for approaches like this
I was considering passing a boolean or enum to the function to tell the difference but then I would have lots of if statements in the function for little things. Was also condering making private members _topbar, _sidebar but then if statements again ?
Is there a good practice to generalize functions ? or design pattern out there?
Look at the common interface or superclass that both Topbar and Sidebar share, and use that as the type.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I know that for methods, a explanation is provided and the #param, #return, and #throw. But for classes, are there any particular things that need to be included besides the explanation of the class?
At the class level, the documentation should explain:
Why/when would I want to use this class?
How do I use this class (examples)
How does this class play with other classes?
What is unexpected/special about this class? (thread safety, global variables, ...)
All in all, the class documentation should give a broader view, showing how the class fits into the rest of the code.
The tendency is to not include these comments or keep them very brief and let naming conventions drive our understanding of what the class should do. For example, a plain-old Java object (POJO) named "Address" might need very little in the way of documentation, other than what makes it truly unique. Take a look through recent Java projects on GitHub and you'll see this to be the case. Annotations and package names also help describe the class inherently.
If you focus more on naming, you shouldn't need to document much - other than what makes the class unique or limitations it may have.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Should the conversion methods be stored in the DTO ? ( like in the tutorial for hibernate+gwt on gwtproject.com) Or should i make a a static class with converter methods? When i send a DTO over the wire using asynccallback then is the method code sent?
The idea of the DTO is to separate the model from the data transported on the wire. If you have the conversion methods in the DTO you couple these 2 together.
When would it be problematic? Let's say for example you have a jar that contains dto classes that both server and client use. In this case you can use the same jar in your build process for both sides. But if you couple the model to the DTO you'll have to add jars to your model classes in the client tier.
I recommend a decoupled class for converting. It can be either with static calls or instance-calls if you have specific data for different conversion (for example - different injected services).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'm looking to create an application that will be used to help find a suitable University for prospective students to attend (which is based on various criteria about themselves). The application will be used by prospective students to enter details about themselves and a list of Universities will be displayed based on their profile.
I'm on the design stage (class diagram and etc) and i'm currently thinking of some Java classes I need to produce to do this. So far I've only thought of two...
University class (to hold information about Universities)
Interface class (this the GUI display)
Can someone help suggest what other class that I will need to create this application? You can suggest as many as you like.
Take every noun in your application description. Make it into a class. See if you can write a more detailed description of your app. Use those nouns as classes as well.