Develop Reference

Send XML file to FTP/HTTPS server

I create small tracking app which get coordinates write them to xml file and then send this file with that data to ftp server. I am using function "SendFileGPS" to send that file but apk all the time crashes and it doesn't work. This function is using additional library common net 1.4 and it is quite strange because all the time when I start Android Studio I must download this library from web by Android Studio. And I got some additional questions.
I was thinking that maybe not only this function is a problem, how should look this server I mean how proper this server to get file from this app?
There is a another way to send this file without using additional libs ?
How it should look if I want send this file to another type of server (HTTPS)?
public void SendFileGPS()
{
FTPClient mFTP = new FTPClient();
try {
// Connect to FTP Server
mFTP.connect("here I put adress IP");
mFTP.login("here I put login", "here I put pass");
mFTP.setFileType(FTP.BINARY_FILE_TYPE);
mFTP.enterLocalPassiveMode();
// Prepare file to be uploaded to FTP Server
File file = new File("/path/to/MyXmlFileName.xml");
FileInputStream ifile = new FileInputStream(file);
// Upload file to FTP Server
mFTP.storeFile("filetotranfer",ifile);
mFTP.disconnect();
} catch (SocketException e) {
// TODO Auto-generated catch block
e.printStackTrace();
} catch (IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}

why using DecodeStream(stream) take longer time in a thread than it is in main thread?

I am trying to receive image stream from desktop in the android phone. When I put decodeStream() method in my thread, then put decodestream() into runOnuiThread() to display in the imageView, it takes more than 7 secs. But when I try to directly read image from asset, and convert into inputstream, then decodeStream(), it may take 500ms, I don't know why it happens. The image is 100K.
Thread thread = new Thread(new Runnable() {
#Override
public void run() {
// TODO Auto-generated method stub
SocketConnect = new socketConnect();
SocketConnect.connectsocket("134.129.125.126", 8080);
while (true) {
data = new byte[2048 * 2048];
try {
read = SocketConnect.getInputStream().read(data, 0,
data.length);
input = SocketConnect.getInputStream();
System.out.println("getInputStream()");
bitmap = BitmapFactory.decodeStream(input);
System.out.println("decodestream()");
} catch (Exception e) {
// TODO: handle exception
e.printStackTrace();
System.out.println(e);
}
runOnUiThread(new Runnable() {
public void run() {
image.setImageBitmap(bitmap);
System.out.println("setImage at less than 500");
}
});
}
}
});
thread.start();
client side should sent the image very 5 sec.
If I try to read same image from asset, Image display immedately.
try {
inputasset=getAssets().open("good1.jpg");
Bitmap bit = BitmapFactory.decodeStream(inputasset);
image.setImageBitmap(bit);
} catch (IOException e) {
TODO Auto-generated catch block
e.printStackTrace();
}
socketConnect class
public class socketConnect {
private Socket clientSocket;
private InputStream input;
private Bitmap bMap;
public InputStream getInputStream() {
return input;
}
public void connectsocket(String ipString, int port)
{
System.out.println("starts");
try {
// clientSocket = new Socket("134.129.125.172",8080);
System.out.println("starts");
clientSocket = new Socket(ipString, port);
System.out.println("AsyncTask: Connect to 134.129.125.126");
input = clientSocket.getInputStream();
System.out.println("AsyncTask: get the inputStream");
} catch (IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
}

read = SocketConnect.getInputStream().read(data, 0,
data.length);
input = SocketConnect.getInputStream();
System.out.println("getInputStream()");
bitmap = BitmapFactory.decodeStream(input);
System.out.println("decodestream()");
You read the data from the input stream, then you ask the BitmapFactory to read the data from the input stream. But you already read it! Remove the call to read -- you're stealing data from the BitmapFactory.

My guess would be that the server side is not properly signaling that the end of the file has been reached. I've encountered this previously because the web server implementation might not tell you the length of the file it is sending. If it doesn't set the content length then the input stream keeps trying to read forever. My guess is that it takes a number of minutes because this is the default socket timeout value.
So, the input stream from the socket reads as much as it can and keeps waiting for more data. After waiting several minutes (although usually 5 minutes is the default timeout) the socket closes and you get your image.
I'm not entirely sure that a content length will help, another option might be that the server closes the connection after all the data is sent.
Clearly, if you're trying to stream new images though, you need to do something different than you are. Perhaps have your server send a file header that the reader interprets. This header might include the length of the data being sent and then the client you write stops reading after reaching this length. In this case you'll need to read the image data into a buffer and then have the BitmapFactory read the buffer instead of the stream.
An alternate approach would have the server close the connection after sending the data for each image and then the client would reconnect to get the next one.
Bottom line, not all InputStreams are created equal and a SocketInputStream doesn't know when to close without a content length or the socket being closed.

Android app doesn't work on Android 4

I created an Android project on 2.3.3 and tried it on mobile 2.3.3, everything works OK. It didn't work on mobile 4, so I re-built for Android 4, but I have the same problem.
This is the code:
public void FTP_Download(){
String server = "192.168.1.135";
int port = 21;
String user = "pc1";
String pass = "1551";
FTPClient ftpClient = new FTPClient();
try {
ftpClient.connect(server, port);
ftpClient.login(user, pass);
ftpClient.enterLocalPassiveMode();
ftpClient.setFileType(FTP.BINARY_FILE_TYPE);
Toast.makeText(getBaseContext(), "download starting.",Toast.LENGTH_LONG).show();
// APPROACH #1: using retrieveFile(String, OutputStream)
String remoteFile1 = "i.xml";
File downloadFile1 = new File("sdcard/i.xml");
OutputStream outputStream1 = new BufferedOutputStream(new FileOutputStream(downloadFile1));
boolean success = ftpClient.retrieveFile(remoteFile1, outputStream1);
outputStream1.close();
if (success) {
Toast.makeText(getBaseContext(), "File #1 has been downloaded successfully.",Toast.LENGTH_LONG).show();
}
} catch (IOException ex) {
System.out.println("Error: " + ex.getMessage());
ex.printStackTrace();
} finally {
try {
if (ftpClient.isConnected()) {
ftpClient.logout();
ftpClient.disconnect();
}
} catch (IOException ex) {
ex.printStackTrace();
}
}
}
Note:
I use commons-net-3.1 to connect.

In android version 2.3 above you can not start internet connection from main UI thread. Instead you should use AsyncTask. I assumed you are not using AsyncTask. If you are, then post the code and log cat also. Some examples of other operations that ICS and HoneyComb won't allow you to perform on the UI thread are:( from link posted in comment below ) -
Opening a Socket connection (i.e. new Socket()).
HTTP requests (i.e. HTTPClient and HTTPUrlConnection).
Attempting to connect to a remote MySQL database.
Downloading a file (i.e. Downloader.downloadFile()).

You should not use the main UI Thread to start a network connection or read/write data from it as #phazorRise explained it. But I strongly disagree with using an AsyncTask to perform your download. AsyncTask have been designed for short living operations and downloading a file doesn't belong to that category.
The most relevant way to achieve your goal, if your files are big (and I assume it depends on users, so we can say they are big) is to use a service to download the files.
I invite you to have a look at RoboSpice, it will give your app robustness for networking and it's really the most interesting library for network requests on Android.
Here is an inforgraphics to get familiarized with alternatives and understand why using a service is better than any other technology.

When I use "internet conections" programming for andoid 4, I do an Async Task as follows:
You can put this Class code into the same file as principal file to intercatue with global variables or functions.
public class MyAsyncTask extends AsyncTask<String, Void, String> {
#Override
protected String doInBackground(String... urls) {
String url = urls[0]
try {
//Connection request code, in your case ftp
} catch (Exception e) {
//Catch code
}
}
#Override
protected void onPostExecute(String result) {
//Code to de After the connection is done
}
}
Then, in the Activity I call the Asyn Task
String url = "http://...";
new MyAsyncTask().execute(url);
Edit
Here it's explained how to use Async Task, with an example
http://developer.android.com/reference/android/os/AsyncTask.html

I added this code, and all thing OK
StrictMode.ThreadPolicy policy = new StrictMode.ThreadPolicy.Builder().permitAll().build();
StrictMode.setThreadPolicy(policy);
Note: I taked the code from #user1169115 comment in another post.
This isn't the best soluation, but I don't know why asynctask isn't work, so I don't have another choice.

android not running on my phone, but on my emulator does

i wrote this ftp upload method...it works great on the emulator but doesnt on my phone...
can someone tell me why not?
FTPClient client = new FTPClient();
FileInputStream fis = null;
try {
client.connect("ftp.atw.hu");
client.login("festivale", "festivale12");
Log.d("TravellerLog :: ", "Csatlakozva: ftp.atw.hu");
//
// Create an InputStream of the file to be uploaded
//
client.setFileType(FTP.BINARY_FILE_TYPE);
client.enterLocalPassiveMode();
String substr = globalconstant.path.substring(4, globalconstant.path.length());
String filename = substr + "/Festivale.db";
Log.e("TravellerLog :: ", substr + "/Festivale.db");
fis = new FileInputStream(filename);
//
// Store file to server
//
client.storeFile("Festivale.db", fis);
Log.d("TravellerLog :: ", "Feltöltve");
client.logout();
} catch (IOException e) {
e.printStackTrace();
} finally {
try {
if (fis != null) {
fis.close();
}
client.disconnect();
} catch (IOException e) {
e.printStackTrace();
}
}
pls help i'm trying to do this ftp almost 3hours ago :S

On devices, you need to use a separate thread to handle the ftp connection.
"By using a separate thread, you will reduce the risk of Application Not Responding (ANR) errors and the application's main thread can remain dedicated to user interaction with your activities."[android.developer.com/guide/components/services.html]

getSocketAddress() method causes delay which leads to communication lag in Android

I'm developing a UDP responder to handle basic SSDP commands. The purpose of this piece of code is to do auto discovery, so when the server sends a multicast to a specific group all other subscribed devices should send back a UDP packet announcing its presence to the host and port of who sent the multicast. My android device receives and sends the packet just fine but because it takes too long to get back the SocketAddress object from getSocketAddress() method the server times out, closes the listening port and never gets a packet back from the android device.
Here's my code:
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
MulticastSocket ms = null;
byte[] packBuf = new byte[128];
try {
ms = new MulticastSocket(32410);
ms.joinGroup(InetAddress.getByName("239.255.255.250"));
} catch (IOException e3) {
// TODO Auto-generated catch block
e3.printStackTrace();
}
while (true)
{
DatagramPacket receivedPack = new DatagramPacket(packBuf, packBuf.length);
try {
ms.receive(receivedPack);
Log.d(TAG, "Received data");
} catch (IOException e3) {
// TODO Auto-generated catch block
e3.printStackTrace();
}
String responseStr = "HTTP/1.0 200 OK\n" +
"Content-Type: app\n" +
"Resource-Identifier: 945e7dd5913ab45f1db4f271a1620b9471fb7d4d\n" +
"Name: Test App\n" +
"Port: 8888\n" +
"Updated-At: 1319511680\n" +
"Version: 0.9.3.4-29679ad\n" +
"Content-Length: 23\n\n" +
"<message>test</message>";
byte[] response = responseStr.getBytes();
DatagramSocket sendSocket = null;
try {
sendSocket = new DatagramSocket();
} catch (IOException e2) {
// TODO Auto-generated catch block
Log.e(TAG,"Erro",e2);
}
DatagramPacket outPack;
try {
outPack = new DatagramPacket(response, responseStr.length(), receivedPack.getSocketAddress());
sendSocket.send(outPack);
} catch (UnknownHostException e1) {
Log.e(TAG,"Erro",e1);
}
catch (IOException e) {
Log.e(TAG,"Erro",e);
}
catch (Exception e)
{
Log.e(TAG,"Erro",e);
}
}
}
Any ideas?
thanks in advance,
fbr

The most likely problem is that getSocketAddress() is trying to resolve the DNS name of the IP address, which is timing out either due to it being a multicast address or just general DNS lag.
The InetSocketAddress class has a constructor option needResolved which can control this behavior. Unfortunately, it does not appear that DatagramPacket.getSocketAddress() allows you to specify that you want that set to false.
This is apparently a known issue, with some recent discussion of it here:
Issue 12328: DatagramChannel - cannot receive without a hostname lookup
The thread suggests that this has been fixed in Android 3.0, and offers a couple of workarounds for Android 2.0 which may or may not work.
In your case, you could try creating an InetSocketAddress set to INADDR_ANY and port 0 with needsResolved set to 0, and then pass that in when you create receivedPack. Hopefully receive() will reuse that and remember the setting.

2 things come to mind...
1) What happens when you change:
outPack = new DatagramPacket(response, responseStr.length(), receivedPack.getSocketAddress());
to
outPack = new DatagramPacket(response, responseStr.length(), receivedPack.getAddress(), receivedPack.getPort());
2) I remember having this sort of problem with an embedded Java on a Home Automation system. Our short term solution was to put most of the machine and multicast addresses in the hosts file. Long term we ended up with a local DNS server.
There is a parameter somewhere in the Java Network stack that tells it how long to cache DNS failures in memory. We cranked that number up to, I think, 5 minutes instead of 10 seconds.