SEService.isConnected() returns false after SEService.shutdown()

[GoogleCodeExporter]

Here is the sample code to re-produce the error:

SEService se = new SEService(this, this);

.......

if (!se.isConnected())
{
    m_errorDesc = "SEService should be connected.";
    return m_errorDesc;
}

try
{
    se.shutdown();
}
catch(Exception e)
{
}

if (se.isConnected())    // ERROR here !
{
    m_errorDesc = "SEService should not be connected.";
    return m_errorDesc;
}

The se.isConnected() returns true after SEService was shut down.

Thanks,
Danny

Original issue reported on code.google.com by danny.w....@gmail.com on 10 Feb 2012 at 11:42

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

According to SIMalliance OMAPI, the isConnected returns true if the Service is 
connected. This is equal to the SEService instance is valid from now on. SCAPI 
returns false as soon as the connection to the service gets interrupted, e.g.
$ kill org.simalliance.openmobileapi.service:remote

The shutdown() function just releases all resources but still allows the client 
to re-open them later on because the SEService instance is still valid.

I agree that shutdown() normally indicates a complete shutdown of the service 
so the name might be misleading.

Original comment by Daniel.A...@gi-de.com on 10 May 2012 at 4:29

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

not sure why this issue has been marked as invalid.
i checkout the latest code from SVN trunk just now (May 11th, 2012 10:00 CDT), 
and the problem still seems to be there.
as

public boolean isConnected() {
    if (mSmartcardService == null) {
        return false;
    }
    return true;
}

which the state is gated on whether mSmartCardService == null or not,
but in shutdown(), the variable is never reset to null.

public void shutdown() {
        synchronized (mConnection) {
            if (mSmartcardService != null) {
                synchronized (mReaders) {

                    for (Reader reader : mReaders) {
                        try {
                            reader.closeSessions();
                        } catch (Exception ignore) {
                        }
                    }
                }
            }
            try {
                mContext.unbindService(mConnection);
            } catch (IllegalArgumentException e) {
                // Do nothing and fail silently since an error here indicates
                // that binding never succeeded in the first place.
            }
        }
        mSmartcardService = null;   //  <<< propose solution, missing logic to make isconnected work correctly
    }

Original comment by tommypo...@gmail.com on 11 May 2012 at 2:53

[GoogleCodeExporter]

I have no problem including the change in the next release but in my 
understanding of the SIMalliance OpenMobileAPI the current behavior is correct:
6.4.4. is stating "Releases all Secure Elements resources allocated by this 
SEService." but it does not say that the SEService binding becomes invalid. 

6.4.3 states that isConnected refers to the service connection, not the 
allocated SE resources (channels, sessions, readers)

Currently you can call shutdown() and still initiate a new Reader[] list 
because the SEService binding is still valid. With your proposed change you 
would need to create a new SEService object.

INVALID or ACCEPTED?

Original comment by Daniel.A...@gi-de.com on 11 May 2012 at 3:01

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

agree with Daneil's input.
but if that's the case, 2 thing would need to be fixed, because the only real 
use case for isConnected() is to be used on the situation of new SEService() 
with a null callback listener

1) Issue 20 is fixed
2) API Documentation to update to explicitly mention shutdown does not change 
isConnected()'s state.

Original comment by tommypo...@gmail.com on 11 May 2012 at 10:49

[GoogleCodeExporter]

there was a discussion last week with Frank at Gi-de.  he mentioned SEEK 
internal discussion agree that the API naming and current implemention is not 
matching, and updating the API would be difficult so the error would need to be 
fixed as recommanded.  they would reopen the error asap and provide the fix.

Original comment by tommypo...@gmail.com on 19 Jun 2012 at 4:25

[GoogleCodeExporter]

Fixed in next release.

Original comment by Daniel.A...@gi-de.com on 19 Jun 2012 at 12:24

• Changed state: Fixed

Attachments:

• issue11.patch

[GoogleCodeExporter]

setting old issues from fixed to done

Original comment by Daniel.A...@gi-de.com on 5 Jul 2013 at 2:33

• Changed state: Done