ObjectOutputStream

[Ivan452]

Hello, I'm trying to make a client-server app.

Server on computer.
Client - android app.

When I try to send and Object via ObjectOutputStream from Server to Client its not working correctly.
When I send String its working OK.
But when I try to send and object of MyClass its not working.
ObjectOutputStream throws an exception but I cant see which one.

I tried to run the exact same client code on non-android Java app, and its working...

Anyone been dealing with this?
What would other options be?

Thx :)

[alostpacket]

Can you post some code? Hard to know where it could go wrong....

[Ivan452]

ok here is the function that should read the object.

http://codepaste.net/bbq7rq

and i'm sending it with:
oos.writeObject(new Question("1","1","1","1","1","1","1",1,1));

and this is the Question class, same on client and server side.

http://codepaste.net/gcxown

[alostpacket]

What about the code that writes the object to the stream you're sending to the server?

From the code you've show the only thing that strikes me as odd is the call to super in the Question class since you dont extend anything (but I'm not sure if that would matter). Also I'm not sure you need the @Override meta tag for the toString() method.

For my bluetooth connections I have this function for sending serializable objects:



private void sendVO ( Serializable obj )
{

ByteArrayOutputStream bos = new ByteArrayOutputStream() ;
ObjectOutputStream out;

try
{
out = new ObjectOutputStream( bos );
out.writeObject( obj );
out.flush();
out.close();
}
catch ( IOException e )
{
e.printStackTrace();
}

byte[] buf = bos.toByteArray();

write ( buf );

}


// in a separate Thread

public void write(byte[] buffer)
{
try
{
mOutStream.write(buffer);
}
catch (IOException e)
{
Log.e(TAG, "Exception during write", e);

connectionLost();
}
}


Not sure if that code helps you or not but figured it couldnt hurt...

[alostpacket]

Basically I'm wondering if the object is not being written to the stream correctly, or fast enough, on the android side, and then the is not understanding the data it gets....

[Ivan452]

@alostpacket
Thank you for responding.
I have closed all my programs for tonight and I'm off to bed, so ill check the thing you posted tomorrow.
Something similar crossed my mind, I think that writing and reading bytes is impossible to fail, or at least less likely then the way I used it.
And code thats sending from server its just like ObjectOutputStream.writeObject(new Question());
nothing more to it.

I dont think its OutputStream problem, because when sending to Java PC Client its working. It must be something on Android side...I really checked everything multiple times. Ill try tommorow so send a custom class with one element, and see will that work over ObjectOutputStream.

The call of super in that constructor is only because I was getting a message that there is no empty constructor(the one that takes no parameters). So it does the same thing that cant be the problem.
And the @Override its not necessary, but again its makes no difference. I just like to see right away which methods have been overridden.

So, anyway since I see that you have been working a bit with serialization and sending data over network I'll ask you a bit more :)
I sent all my class data with ObjectOutputStream string by string and int by int (7 strings and 2 ints) and recreated the class on the Android side.
Its working instantly and I'm not seeing any delay. I know that its not the 'right' way to do it, but I had to do it like that so I could continue to work further.
So I was wondering what are your thoughts on that, and do you have any other ideas how could this be done.

And if its not too much, can you explatin this line:
Log.e(TAG, "Exception during write", e);
I looked it up online. How I got it its used to easily debug a program because e.printStackTrace() is usable in Android.

P.S
I looked your Thread about your app. It looks very nice.

[alostpacket]

Hi Ivan, sorry it took awhile to get back to you.

I think I was confused about which was sending the stream and which was receiving the stream.

Anyways, I found that when I wanted objects to serialize correctly on Android, I had to indeed make sure they had constructors with no parameters (or no constructor).

So maybe that call to super(); is something worth looking into.

Personally I like my objects to look like this:





import java.io.Serializable;

public class AddressVO implements Serializable
{

public long id;
public String type = "";


public String fullAddress = "";

public String street = "";
public String city = "";
public String regionState = "";
public String country = "";
public String zip = "";


}



I use all public varibles and no getters/setters unless I need the for a specific reason. Although this is mostly a style decision, since there is no right or wrong way to do this.

However, an object like this easily serializes and deserializes, so maybe that will help you I hope.

And thanks much for the kind words about my App :)

Cheers



(note I use the term VO for Value Object because I'm originally a Flash/Flex developer and that's what they are called in ActionScript, however you probably know the object as a DTO/data transfer object or POJO/plain old java object)

[Ivan452]

I haven't tried it yet but I found the possible problem.
It might be the package. Classes on both sides must be in the package with the same name. As soon as I try that ill report here :)

Thanx for responding!

[Scythe]

I use all public varibles and no getters/setters unless I need the for a specific reason. Although this is mostly a style decision, since there is no right or wrong way to do this.

However, an object like this easily serializes and deserializes, so maybe that will help you I hope.

You technically don't have to, but most Java developers will cringe if they see you using a bean object that uses no getters or setters and instead uses public permission to access variables. It's a pretty large Java no-no. The whole point of getters and setters is to remove outside control of variable modifications. Also implementing the serialization interface will handle the serialization portion of the object, and you could use something like Xstream to even convert it to XML.

Anyway, my honest opinion. ;)

[alostpacket]

I haven't tried it yet but I found the possible problem.
It might be the package. Classes on both sides must be in the package with the same name. As soon as I try that ill report here :)

Thanx for responding!


Yes they need the same package name so that could definitely be your problem.

[alostpacket]

You technically don't have to, but most Java developers will cringe if they see you using a bean object that uses no getters or setters and instead uses public permission to access variables. It's a pretty large Java no-no. The whole point of getters and setters is to remove outside control of variable modifications. Also implementing the serialization interface will handle the serialization portion of the object, and you could use something like Xstream to even convert it to XML.

Anyway, my honest opinion. ;)


They can cringe all they want as long as they realize it's a matter of coding style.

There aren't very many technical reasons to have a getter or setter unless you are performing some logic durring the get/set. And for me, logic should be handled in a proxy/adapter. For me, these object's sole purpose is to hold a value (hence why I call them Value Objects, though again that's a holdover from my ActionScript development days* ).

"Access control" is often tossed around as the reason, but what does that matter when you have a public getter and setter?

Years ago, I used to be all gung-ho about using getters and setters but I was eventually convinced they were just verbose bloat in 99% of cases.

Anyways that's my honest opinion -- though I believe most of all, people should code in whatever style works for them.

:)






=====================

*which incidentally has ECMAScript faux getters and setters so you can refer to a property and have it actually call a getter/setter.


obj.prop=3
would function just like the code below:



function set prop (val:int)
{
this.prop=val
}

[Ivan452]

I think the difference between public getter and setter and declaring a public variable is that when you declare a public variable someone has direct access to it and can manipulate it.
And when you declare the public get/set can only get the value not the variable.
I think this became popular when you could use the direct access to variable for overflowing the stack.

Anyway, doing those stuff by the book is the way to go and not think much about it.

[alostpacket]

I'm not going to argue a holy war (I know, too late) but getters and setters are a matter of style, and have appropriate uses in certain situations, but are not something people should think is a requirement. Java beans are not the only way to represent data. Think of public value objects as structured key-value bundles. They should only be accessed by classes that know how to talk to them. in proper OOP it should have been wrapped in an adapter, but at some point there isn't a huge need for all that effort when you wanna get the job done.


Now, let's talk singletons and really get the holy war going! ;) ;) ;)


Couple of interesting articles:
http://typicalprogrammer.com/?p=23

http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html?page=1

[Scythe]

Yeah, I'm going to shy away from this debate. Only because I could rant on for way too long about my stance.

Also I don't mind singletons in moderation. It's a standard design pattern, it just needs to not be abused. For cache's -- creating a framework which makes use of a singleton to handle multiple cache's is ideal (instead of multiple singletons). I use them typically to limit disk IO.

[alostpacket]

Yeah, I'm going to shy away from this debate. Only because I could rant on for way too long about my stance.

Also I don't mind singletons in moderation. It's a standard design pattern, it just needs to not be abused. For cache's -- creating a framework which makes use of a singleton to handle multiple cache's is ideal (instead of multiple singletons). I use them typically to limit disk IO.


Yeah, I agree on singletons -- actually Flex, (specifically the Cairngorm framework), used them a lot.

Everything has a time and place :)

Now, Coke or Pepsi? ;)