ClassCastException

After looking at the code in SVN, I can't understand what happens, GetDirectionActivity and getdirections.xml have not changed for a long time.

At the moment the Exception is thrown on this line :
<pre>
<code class="Java"> Spinner s = (Spinner) findViewById(R.id.modeoftransport);</code>
</pre>
And this id seems indeed to refer to a Spinner :
<pre>
  <Spinner
        android:id="@+id/modeoftransport"
        android:layout_width="fill_parent"
        android:layout_height="wrap_content"
        android:drawSelectorOnTop="false"
        android:prompt="@+id/mode_of_transport_types"
    />
</pre>

May be related to this issue on Android core :
http://code.google.com/p/android/issues/detail?id=3981
Fixed with Eclair, that means we'll have to find a workaround in the meantime if it's related.

I can't get this to happen when using Eclipse, so it seems like it's something to do with the build script.

Kizza, did you have a look here ?
http://code.google.com/p/android/issues/detail?id=3981

I really think it's related.

Still 2 bug reports with the same stacktrace today. I've enhanced the automatic bug report in last commit (rev #74) to have the revision number in it. That should help us know if it's tied to a specific build.

Sounds like a very good idea. Should help narrow things down.

Thanks,

Chris.

Another case with a ClassCastException on the Spinner cast with a Button (not a TextView) in a morning bug report.

Happened with a rev pre #72

(Android: 1.6 - model: T-Mobile G1)

<pre>
java.lang.RuntimeException: Unable to start activity ComponentInfo{org.opensatnav/org.opensatnav.GetDirectionsActivity}: java.lang.ClassCastException: android.widget.Button
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2401)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2417)
at android.app.ActivityThread.access$2100(ActivityThread.java:116)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1794)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:123)
at android.app.ActivityThread.main(ActivityThread.java:4203)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:521)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:791)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:549)
at dalvik.system.NativeStart.main(Native Method)
Caused by: java.lang.ClassCastException: android.widget.Button
at org.opensatnav.GetDirectionsActivity.onCreate(GetDirectionsActivity.java:72)
at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1123)
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2364)
... 11 more
</pre>

With the more than ten bug reports received on this issue, that seems not to be related only to the GetDirectionActivity, one bug report showed the same issue with ContributeActivity

*Caused by: java.lang.ClassCastException: android.widget.TextView*
*at org.opensatnav.ContributeActivity.onCreate(ContributeActivity.java:57)*
at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1123)
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2364)
... 11 more

The issue seems indeed to come from an id collision in R.id, with <pre>public static final int modeoftransport=0xxxxxx;</pre> conflicting with another id elsewhere (an id for a TextView and later for a Button in another bug report, something that make me think that there were more than one build affected).

Now that the SVN revision is in the bug report, I hope that won't happen anymore (I'm unable to reproduce it), and I hope that that's related to a specific build.

I've finally found a way to reproduce it

I've tested one by one every build, there are ClassCastException when starting either GetDirectionActivity or ContributeActivity on builds :
- 65, 66, 68, 73, 74
The other seem to work
- 58, 60, 61, 63 and the last 77.

That's not very good news, it can happen randomly. The automatic developer build must not be downloaded by anyone, we should have a warning on the files page.

When we will have a build for Android Market, we will need to test it thoroughly.

This issue is not linked to any particular version, and it didn't happen in the last week. Removing target release not to keep the 0.9 release to go live.

ZeroG wrote:

> That's not very good news, it can happen randomly. The automatic developer build must not be downloaded by anyone, we should have a warning on the files page.
>
> When we will have a build for Android Market, we will need to test it thoroughly.

ZeroG,

I'd been downloading the nightly builds, should I stop doing so? SHould we have a warning on the download page?

This is the only open issue that doesn't have a target release. I can sort of see why you removed the target release, but when this happens, things tend to get forgotten. Could I ask you to suggest a new target release? If the error is truly random, will we ever be able to reproduce it and fix it?

Chris.

Before 1.0 release, we must have JUnit or any other tests in place to check if the build is ok. In the meantime we should have a warning on the download page, but I didn't find any way of doing so.

Pushed-back. Needs re-assessing in line with other issues after 0.9 release.

Chris.