Nokia E71 MIDP app closes intermittently

[mattstrain]

Hi,

I have written an app which sends the GPS position of the phone to our server. I use a timer object to do this every 10 minutes whilst the app is running in the background.

I have nearly all the code in the timer task object within try catch blocks, but for some reason the application keeps shuting down by itself. There are no uncaught Exception messages thrown and i have been unable to debug the issue. I have even tried using the redirect system.out and system.err application but that gets closed as well.

This occours on all the 5 * E71's we are trialing at the moment. Is there a known OS issue which shuts down applications or the JVM? Is it something to do with trying to make an SSL connection when phone is in use or in poor / bad signal areas? Has anyone else had issues of thier app running in the background closing unexpectedly.

There is no pattern as to when the app gets closed. Sometimes it runs for days other times it runs for only a few minutes.

Also it apears that the pauseapp and destroyapp methods never get called.

[jitu_goldie]

hi,
are u tried to show alert in notifyDestroyed(). u can try some alert in notifydestroyed function in midlet to show exception. try this and reply.

[mattstrain]

I have tried that, although alerts don't even show up, which is expected. The destroyApp method is not getting called.

[grahamhughes]

Does the application fail if it is in the foreground?

I never trust Timer and TimerTask. Create a Thread, and sleep() for the delay you want.

Cheers,
Graham.

[jitu_goldie]

Hi,
Are u tried the same with other devices. Is same problem arise with those all. Try the same delay with thread.sleep(duration) and run the whole process in thread.
can u tell me that after how much time ur application get killed. try the same for less time and check. Please avoid timers and timertasks. Do the same in thread.

[mattstrain]

I only have E71's to test on. I must admit though i wasn't aware of problems with the Timer / Timer Task, I will rewrite as a thread.

It is hard to keep the app permenantly running in the foreground, as the phones are being used as phones.

Thanks for the advice.

[jitu_goldie]

I only have E71's to test on. I must admit though i wasn't aware of problems with the Timer / Timer Task, I will rewrite as a thread.

It is hard to keep the app permenantly running in the foreground, as the phones are being used as phones.

Thanks for the advice.

this is not necessary to run the application at foreground. I think u r misunderstanding something. no need to run application in foreground. can u tell that whats ur actual need and requirement of ur application?
u can also take use of pushregistry. just invoke ur midlet after every 10 min and send data and so on.

also can use following approach..

boolean bool = true;
new Thread(runnable).start();
run(){
while(bool)
{
senddata();
thread.sleep(1000*10*60);
}
}

senddata()
{
send the data.
}


no need to run it in foreground. why u think so? If ur requirement is quite different then pls explain ur requirement.

[mattstrain]

I have tried using the thread.sleep method instead of the timer but the application still gets closed periodically.

I think i will try the push registry option, however as i am still waiting for a code sigining certificate, would the app still keep asking for permission to using location api and network access?

Basically what the midlet does is the following

1) our employees provide a username and password and clock in.
2) every 5 minutes the app uses the username and password and sends the gps position of the phone.
3) at the end of the day the employee, clocks out and the phone stops sending the gps position of the phone.

If i used the push registry option i guess i would need to use a file to store the username / password and a flag to indicate if the user is at work (i.e. clocked in but not yet clocked out). This would in-turn require more user intervention to approve file access until i get a code signing certifcate.

I guess if i could get the imei or phone number i wouldn't need to use a username / password.

[grahamhughes]

You can use RMS to store information (javax.microedition.rms). This does not need any confirmation or signing.

I'm curious as to why the application quits. Do I understand correctly that you don't have your own device to test on? I think you need one. Perhaps if you can see it fail while it's in the foreground, you might see some diagnostic message.

You don't have much chance of getting the IMEI, and less of getting the phone number.

Cheers,
Graham.

[mattstrain]

I have devices i am testing on. I have 5 devices out in the field being used.

As i say, no uncaught exception message is thrown and if i use MIDPlogger (to view system.err & system.out), other than the expected ex.printStactTrace's when phone has no signal etc (see below) i get nothing else.

Here is the code that is running in the background:

 
public void run() {
        while (!exit) {
            try {
                Coordinates c = GPSWorker.getLocation(30);
                String request = "";
                if (c == null) {
                    request = "109>>" + user + ">>" + password;
                } else {
                    request = "108>>" + user + ">>" + password +
                            ">>" + c.getLongitude() + ">>" + c.getLatitude();
                }

                SecureConnection sc = (SecureConnection) Connector.open(
                        "ssl://our-server-address", Connector.WRITE);
                sc.setSocketOption(SocketConnection.LINGER, 0);
                sc.setSocketOption(SocketConnection.KEEPALIVE, 0);
                OutputStream os = sc.openOutputStream();
                os.write(request.getBytes());
                os.write(0);
                os.flush();
                os.close();
                sc.close();
            } catch (Exception ex) {
                ex.printStackTrace();
            }
            try {
                sleep(5 * ONE_MINUTE);
            } catch (Exception ex) {
                ex.printStackTrace();
            }
        }
    }

public class GPSWorker {

    public static Coordinates getLocation(int timeout) {
        try {
            Criteria cr = new Criteria();
            cr.setPreferredPowerConsumption(Criteria.POWER_USAGE_MEDIUM);
            LocationProvider provider = LocationProvider.getInstance(cr);
            Location location = provider.getLocation(timeout);
            Coordinates c = location.getQualifiedCoordinates();
            return c;
        } catch (Exception ex) {
        }
        return null;
    }
}

[grahamhughes]

OK, I suggest you run it on your test device in the foreground, and monitor what happens. Maybe it's throwing an exception somewhere.

You have a tendancy to catch exceptions and swallow the silently, which may be causing you to miss useful information.

One thing I recommend you change is the connection code. Make sure the connection is closed after you use it.

SecureConnection sc = (SecureConnection) Connector.open("ssl://our-server-address", Connector.WRITE);
try {
    sc.setSocketOption(SocketConnection.LINGER, 0);
    sc.setSocketOption(SocketConnection.KEEPALIVE, 0);
    OutputStream os = sc.openOutputStream();
    try {
        os.write(request.getBytes());
        os.write(0);
        os.flush();
    } finally {
        os.close();
    }
} finally {
    sc.close();
} 

Rather than catching exceptions and ignoring them, I'd suggest you let them propagate up the code, to a point where you can decide whether it's safe to ignore them, where you can handle them (for example, by re-trying an operation), or where you can report them (or log them to RMS, for example). Avoid returning 0, -1, false or null to indicate an error condition; that's what exceptions are for.

public static Coordinates getLocation(int timeout) throws LocationException, InterruptedException {
    Criteria cr = new Criteria();
    cr.setPreferredPowerConsumption(Criteria.POWER_USAGE_MEDIUM);
    LocationProvider provider = LocationProvider.getInstance(cr);
    Location location = provider.getLocation(timeout);
    Coordinates c = location.getQualifiedCoordinates();
    return c;
} 

Avoid catching "Exception", catch the actual type you intend to handle or ignore (except as a "catch all" at the highest level of the program).

Make use of finally{} to release resources like connections, RecordStores and so on. Remember you can have a finally{} without a catch{}.

Cheers,
Graham.

[mattstrain]

Thanks Graham, your suggestions are really useful.

I did have a lot more code in there to catch errors and report them, but i have stripped it all out in an attempt to try to work out what is causing the midlet to keep closing.

With regard to the exceptions from the GPSWorker i completly understand where you are coming from but as i don't care what exception gets called during attempting to get a GPS postion, (the phone just reports it is still active), i decided to catch all and return null for simplictiy. I did print the stack trace in that block and report it but as our employees are indoors most of the time, my error logs were filled with location exceptions.

However you are completly right with regard to the connection block, and i am going to re-write it now.

Again many thanks for your help, lets just hope the app keeps closing due to loads of connections not being closed properly!

Matt

[JMandar8]

Hi there
I am too facing a similar issue on Nokia E71. I keep my GPS application in the background by using setCurrent(null). My application doesn't shut down but hangs the device instead. This may happen at anytime after the app is kept in background. I didn't get any solution for this and even debugging was in vain.