I want to store debug variables while using a breakpoint and restore them regardless of the application. I probably need some plugin to let me serialize variables and restore them anytime.
To be more specific I want:
breakpoint
see variables, store them
let the flow go further
restore variables and view them in a convenient way (maybe in debug, but not while debugging) and compare variables with my application's view tier
ps. I was trying to find some plugin, but without results.
thanks
I completetly agree with stacker, to answer for your next question about expand all it's very hard to implement for eclipse guys - regarding to this
One risk is the difficulty of dealing
with self-referencing structures,
because application have to expand
them only one time. There may be
variable A which has a reference to B;
and there may be a variable B which
has a reference to A. This kind of
problems -seem- can easily solve by a
set, however this isn't the best
approach. Another risk may be the
quantity of the features I proposed. I
think it would be better to withdraw
some of these. I published them here,
because I couldn't determine which.
The only thing you can do (using the standard debugger) is, to copy the textual information from the variables view into the clipboard (Ctrl-C) and store (Ctrl-V) it in a texteditor for later reference. Please note that only expanded nodes, from the variables view, will be copied.
Related
There can be potentially up to 1000 strings in total. Should these be hardcoded or stored in database? These are frequently accessed because everytime user wants to register or checkout an item, they are going to need to see list of area/suburb/province/countries.
If i have bunch of Enums, i think the performance should be fast because there is a max number of strings ~1-2k max.
On the other hand, if i store them in database, there's going to be latency accessing the database as well as cpu/memory consumption.
Which option do you choose?
1000 isn't a huge amount, and I would put this information into a text file and read them into the program on start-up.
Regardless, this is data, not code, and so should not be an enum (code). Why not enum? It's a lot easier and more flexible to update/change data than it is to change code, should this need to be changed in the future.
If you will definitely be updating and changing this information with time, especially if through multiple sources, then a database is surely the way to go.
It all depends on you. There is no proper convention. Below are 3 ways along with their pros and cons.
Create a class with static final string variables.
Pros:
a. Very easy to use.
b. Developers can do look ups from within IDEs.
Cons:
a. Every time you need to add/delete something, code will have to be recompiled. However, this will not be much problem if you have ci-cd in place.
Add everything in properties file and load at runtime.
Pros:
a. Modifying things will be a breeze. No code recompilation required.
Cons:
a. This would still need re-deployment and server restart.
b. Developers will be unhappy as they will have to refer the txt file every now and then. Also this could lead to mistake if developers use wrong codes which are not present in properties file.
Use database
Pros:
a. Highly configurable.
b. No need of re-deployment.
Cons:
a. Service restart will be required.
As you can see, service restart will be required for all of them as you will definitely going to use caching in case 2 and 3. My suggestion would be to use first option if they are literally never going to change as it is quite developer friendly.
I have read many blogs about how singleton are vulnerable in android.so my question is how to maintain such global objects or list in application.i know shared preference is one way but is there any way to maintain such objects or list efficiently.any help will be more helpful.
You can use a file or SQLite database to save data in android app. You can check below links to learn more about saving data in a file or SQLite database:
Saving data to a file is ideal to store long sequences of data that are generally read in order
https://developer.android.com/training/basics/data-storage/files.html
Saving data to a database is ideal for repeating or structured data:
https://developer.android.com/training/basics/data-storage/databases.html
use sharedPreferences, Sqlite database to manage your objects, singletons are not very good, but static variables are more hard to maintain and will make testing the cide more tough, you can use Shared preferences to maintain a global state if the data is not very large, if there is large amount of data then use of sqlite is recommended.
Shared preferences are extremely easy to use, if you have problem using sqlite though you can use orm libraries for android
here's a link to one: http://greenrobot.org/greendao/
If you just want to keep a list as Global until your app is running, then create a new class let's say "Helper" and Initialize a Static List in that class. Now you can access that list anywhere within the app by "Helper.yourStaticListName" and you can also add/remove or get data from the list anywhere within the app.
But if you want to keep that list even when app has been closed, then there are two solutions for that.
First Create a local database "SQLite file" in your app and add/remove or get data from it.
Check this tutorial: http://www.androidhive.info/2011/11/android-sqlite-database-tutorial/
Second solution is to convert your data into a JSON and convert that JSON into String and save it in Shared Preferences. And whenever you need it just get the string from Shared Preferences and convert it into JSON and parse to get the data.
One last thing when you are talking about parsing a JSON, then "GSON library" is a good thing to work with.
Here is the link: http://guides.codepath.com/android/leveraging-the-gson-library
Hope this answer will help you.
How about using Android Service?
You can initialize / start it when your application started (and also stop them when your application stopped) and then bind them whenever you need (put and get your object / list).
I believe it will be an efficient way.
From conceptual point having a static variables or service-locators is very similar to having Singletons. Hence, having them as alternatives may not be be correct, if the intention is to avoid the Global state and consequences.
We can change Singleton-classes into instances, which are instantiated only once and injected into the components and methods as needed. We can use a IoC-framework to handle the injection part or do it manually with a factory pattern to construct (we can restrict only one instance creation as well) instances of the classes. This discussion thread gives lot of insights on the problem and various options.
So if I understand your question right, you need to store some global variables all over your application if that's so please take a look at this question
basically you create a class that extends application which would store anything you would like on start of your app and all of them can be accessed trough out the app.
hope this helps.
If you are trying to create a globally accessible object, the first thing you should ask yourself is: Why? Why do you need a globally accessible object? Most of the time you don't, and you can get away with creating an object with a limited scope which is passed around the app.
There are times when you do want globally accessible resources and using a singleton is just one way to accomplish that. According to the Android Docs your data storage options are:
Shared Preferences
Store private primitive data in key-value pairs.
Internal Storage
Store private data on the device memory.
External Storage
Store public data on the shared external storage.
SQLite Databases
Store structured data in a private database.
Network Connection
Store data on the web with your own network server.
Singletons are great, but the do have their own risks based on how they are implemented. Typically developers use this pattern when you are attempting to share a resource within the application, things like Loggers, Print spoolers, etc. There are multiple ways that you can create Singletons in Java, you can use a Lazy Initialization or Static initialization, each has their own pro/cons. In terms of "vulnerabilities", there are issues with whether or not the singleton is thread-safe, who/what can access it, and so on. This is why it makes sense to try and understand the problem you are trying to solve. Personally, I'm not clear on what exactly you are trying to solve, so I can't really elaborate on how this might help or hurt you. All I can say is that the biggest vulnerability is also it's greatest asset, which is that like most global variables, it can be accessed from anywhere at anytime. There can also be an issue whether or not the singleton is thread-safe.
Personally, I think you need to assess what it is you are trying to solve and the pick the appropriate solution. Maybe using a singleton is the correct solution, maybe it isn't. But understanding all your options and the strength/weakness of each one is going to be the best way to solve this issue. Unfortunately, you haven't provided enough context to your problem for me, or anyone for that matter, to give you a solid recommendation.
The best way to manage global objects is not having them at all. Based on my experience, in a lot of cases there are alternative options instead using singletons. There is so good explained in this post
shared preference is good but some time you will feel problem when do some modification make static constant variable in one pojo java class and use this variable anywhere.because shared preference will not change value after use or unless you dint modify .shared preference retrieving and storing is not very unfriendly. if you use constant you can modify easily .only one class you have to hit
For example new object allocated, after then it throw to different place, where it is used by a lot of methods. So I want to track all read operations on it to understand in which places this object is used. Something like "go to breakpoint" but "go to next read operation with this object".
There does not seem to be such a shortcut available with IDEA. I am not aware of such shortcuts in any other IDE either.
Below is a resource with list of all available shortcuts and no such facility is listed.
https://resources.jetbrains.com/storage/products/idea/docs/IntelliJIDEA_ReferenceCard.pdf
Communities grow with contribution. You're always welcome to submit a request with below link so that it can be considered if feasible.
https://intellij-support.jetbrains.com/hc/en-us/requests/new?ticket_form_id=66731
If you're talking about seeing where the variable is used (which is what I make from your question), you can just Ctrl-Click on the variable name.
Alternatively, you can right-click on the variable name and click on "Find Usages".
If you want to observe the variable's state and how it changes throughout a debugging session, you can attach a variable "watch" to it.
See https://www.jetbrains.com/help/idea/2016.3/debug-tool-window-variables.html for more information on that.
In my application I use some icons. Where should I store the path of the directory containing those icons ?
The icons are used in different classes so it doesn't really make sense to store them in one of those classes in particular.
I read that global variables are evil, but is it acceptable to use a class (eg Commons) containing only public static final fields to store this king of data ? What solution is used in professional applications ?
Global Constants
As others state, global constants don't have the same negative connotation as global variables. Global variables make a program difficult to debug and maintain because of uncontrolled modifications. Global constants (public static final) don't create the same problem
Nevertheless, object-orientation is about binding code close to its data to enhance understandability and maintainability. You still have to find the right balance between storing global configuration values in a global class vs keeping data close to the code that will use it.
It is probably also worth reminding here that, because the compiler may inline some constants, if you change a constant value, you may have to recompile and redeploy more than just the class that contains the constants.
Externalizing Values
You also asked about what professional apps do. Its not uncommon for those apps to make these types of values, like files paths, externally configurable. It depends on how likely the value is to change (i.e. how likely your app will move or your code will be used in another app) and how convenient or easy it is to recompile and redeploy the code with new values. If you do choose to make some values externally configurable, you still may want to encode default values for those items in the code.
Here are some ways to externalize those values and some links to get you started. This is of course not an exhaustive list:
System properties so you can specify them on the command line
Property files [See StackOverflow Q - How to use java property files?]
Resource Bundles [See StackOverflow Q - How to load a resource bundle from a file resource?]
Global variables are evil (since they make it nearly impossible to figure out who modifies what), but constants aren't evil. public static final String fields are fine, since they can't be modified.
I would recommend to include them (the icons) with your class files in a jar, say a folder called resources and only the icon loader needs to know the resources folders name within your jar.
You are referring to constants, not global variables, so don't worry about them being evil - they are not, because they don't change.
if they are used by one class - place them in that class
if they are used by multiple classes in one package - place them in a special class
if they are used by multiple classes and they logically belong somewhere, place them there.
Have in mind that in case these "constants" are actually configurable, you'd better pass a Configuration object to methods that need it. Well, you may have the static somewhere, but from testability point of view it is a must to inject them / pass them.
Global variables are not the same as global constants. The reason global variables are bad is because they can be changed anywhere in the code and it is very hard to track down errors that result from a global variable not being in the expected state. Global constants will always be in their expected state because they can never be changed inadvertently.
In general I would suggest that this particular case be a packaging problem and to not reference the items as files on the file system, but rather as elements in the classpath, and load them via a classloader. This requires setting their location in the classpath of your application.
Then there should only be one class that knows how to retrieve these icons, and all other code asks that class for the icons it needs.
I just had an idea that I wonder whether is possible in java. Let's say when doing debugging using eclipse or netbeans, you could record an object and save it. Then when going through the second round of debugging, save the object again. Now you could compare the first object recorded with the second object for all properties and find out any differences. Is this possible?
You can do this in plain Java code (assuming your objects are Serializable), but I don't think any debuggers have this feature built-in.
It would simply be a case of serialising the first object during the debugging run (which if you had a static method to do so, you could generally call from the debugger) and saving it somewhere. Then, during the second run, call another method to reconstitute the object from it's serialised form - and then compare the objects (either with their equals() methods, or some more bespoke comparison method).
In practice though I find that whenever I want to do this I just scribble down the relevant properties on a piece of paper and compare them manually. Rarely am I looking at thousands and thousands of properties that might change between a run; if you think about the symptoms you're seeing and the behaviour of your object, you can normally have a very good idea of what might be changing before you even fire up the debugger, and then use the latter to confirm your hypothesis and backtrack to see where the value "went wrong".
Give your object a useful toString() method and then use unit tests to compare the result with what you expect.
But I agree: The wire protocol for remote debugging can serialize any object, so it should be possible to write a program that does this automatically.
OTOH, objects which aren't meant to be serialized can be dangerous. If you accidentally use this on a classloader, you'll get all objects and classes and everything back as one big lump. So you need a way to stop the serialization to make sure it can't run havoc in a deep object tree.
On top of that, I'd like a feature to save the current state of the app and be able to go back in time.
I don't think any debugger can save object to compare them later. What you can do though is to create a watch variable on the variable, but wrap it with the ToStringBuilder() of the apache commons and dump it in the console, like so:
System.out.println(ToStringBuilder.reflectionToString(object));
Each time the breakpoint is reached, the content of the object will be shown in the console. You can even see the private data.
Therefore, you do not need to modify the toString() method of the object directly (this is useful for library object for example). You can then compare the output of your two passes.