Win a copy of Machine Learning Systems: Designs that scale this week in the Scala forum
or Xamarin in Action: Creating native cross-platform mobile apps in the Android forum!

Tony Docherty

+ Follow
since Aug 07, 2007
Forum Moderator
Tony Docherty currently moderates these forums:
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Rancher Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Tony Docherty

Leonardo Nash wrote:
- Is it bad idea to read data from same InputStream using multiple wrapper Streams (BufferedInputStream, DataInputStream, and another subclass of FilteredInputStream) ? If it is, why ?

If you mean chain wrappers together (ie wrap a FileInputStream in a BufferedInputStream which is wrapped in a DataInputStream) then this is fine but if you mean to wrap one InputStream in 2 or more different wrappers then this is not a good idea. The reason is if you read from one wrapper it will consume and return values from the underlying stream then when you read from another wrapper it will consume and return the next available values from the underlying stream and so the second read will be missing the values already read in via the first stream. Unless you are extremely careful you will have no idea what the data being read in actually means as it will be be starting from some unknown point in the stream.

Leonardo Nash wrote:
- Is it bad idea to call reset, mark methods from base InputStream that passed to wrapper InputStream (BufferedInputStream, ...) ? I think, we should call these methods from only wrapper InputStream.

The reset, mark methods from InputStream don't do anything (they are null implementations) so there is no point in calling them. As to the general principal of calling methods in base classes of wrapped classes I would say it is a dangerous policy if the methods change the state of the object. For example if you called an InputStream subclass that implemented reset() and then called the wrapping classes reset() method, if the wrapping class provides it's own implementation of reset and mark, then the result is unlikely to be resetting of the file position back to the marked point.
3 weeks ago
The problem with not calling flush() in the client code (assuming the android stuff works the same as standard Java) is the client is unlikely to send the string until the connection is being closed (or the buffer fills up) so the server will just sit there waiting for the message from the client.
3 weeks ago
Sorry I've never programmed for android so I can't give you a definitive answer to that but I would have thought you would have needed to call flush().
3 weeks ago
Can you show the client code as well please and does it use flush() as well.
3 weeks ago
Your problem is on line 42

When will this not evaluate to true?
3 weeks ago

Dave Tolls wrote:Sequence does not hav a no-args constructor, so cannot be serialized at all.

You can serialize it using the alternate approach I described in my earlier post provided there are getters and setters for the fields you need to serialize (or you are willing to use reflection).
1 month ago
Not sure why you are saving the state of the object but if you are trying to provide persistent storage then I would advise against using Serializable. if, on the other hand, you are implementing transient storage then Serializable is an acceptable approach, you do need a no args constructor though to deserialise an object.
An alternative approach to extending the Sequence class would be to create a wrapper class which implements the readObject and writeObject methods as stated in the API docs for Serializable. The wrapper class could then handle serialization and deserialization of the Sequence object's state through these methods.
1 month ago
Are you asking how to run the given class from the command line or are you asking how to call the given code from another class?
1 month ago
Glad to hear the advice was useful.
1 month ago
Your index into the array is with a variable of type byte. The maximum size of a byte is 127. If you add 1 onto a byte whose value is 127 the value wraps around to the minimum byte value of -128 hence you get an ArrayIndexOutOfBoundsException giving a value of -128.

The solution is to change the type of data to an int.
2 months ago
No it's not a valid solution.

available() returns the number of bytes that can be read without blocking. If it returns 0 it does not mean the end of the stream has been reached it just means there are currently no more bytes available to read. This could be due to i/o delays, network delays etc.

Using available() in this way may appear to work every time when the file is stored locally but there are no guarantees. In short it's extremely bad practice to do this.
4 months ago
All classes have an equals() method but the String class also has an equalsIgnoreCase() method which is useful when you want to compare strings for equality ignoring the case of the letters.
4 months ago
Is there a specific reason you need to know this?
One of the good things about Java is all memory allocations are handled for you and for 99.999% of cases you don't need to worry (or even know) where variables are stored. And no there are no special instructions relating to their storage.
4 months ago

Caiz Austin wrote:
At the moment I would create a Briefcase class and initialise 26 Briefcases as an array setting each individual briefcase a value e.g. briefcase[0] = 0.50; briefcase[1] = 1.

That's not implementing a Briefcase class, that's having a float (or double) array called briefcase.
If you do implement a Briefcase class it can have properties such as value, opened etc. You could then have an array of type Briefcase which you filled with Briefcase instances ie briefcase[0] = new Briefcase(0.5, false);
4 months ago