I too am encountering the same issue.
I'm using MOTODEV to develop an Android app using the Google Calendar
API. I downloaded gdata-src.java-1.40.3 and unzipped it. In Project -
> Properties I pull up the Java Build Path tab, Libraries subtab and
click "Add External Jars". I navigate down to gdata-src.java-1.40.3/
gdata/java/lib, and inside there are like 50 jar files. I'm a noob
but I admit this seems odd straight away - why so many? So I pick
gdata-calendar-2.0.jar and click through and I'm happy to see that my
compile now reads clean, plus there is a new "Referenced Libraries"
entry (peer to src, assets, etc.) and that it is populated with 5 jar
files: calendar, calendar-meta, client, client-meta, and core. Sweet,
looks like dependencies are handled too. (Noob here, and if my method
sucks I invite instruction).
Upon run (in the Emulator) I get a force close and the logcat shows a
stack traceback for a java.lang.NoClassDefFoundError:
com.google.gdata.client.calendar.CalendarService at this line:
CalendarService myCalendar = new
CalendarService("dcd-Timeline-1");
I've looked round lots and don't see where I can tell the runtime how
to find this... I would have thought it would be statically compiled
into my .apk??
thanks,
DJC
On Mar 15, 11:52 am, Brion Emde <brione2...@gmail.com> wrote:
> Hi Tom,
>
> I went down the same path as you with the gdata library and I was
> going to take a look at this library, which the developer claims does
> work on Android:
>
> http://code.google.com/p/simply-gdata/
>
> I'd be interested in if this works for you, as I haven't gotten around
> to looking at it and if it solves my medium-term needs.
>
> On Mar 15, 10:00 am, Tom <orei...@mbari.org> wrote:
>
>
>
> > Thanks everyone for all of your suggestions. I haven't been able to
> > get the com.google.gdata classes to load properly in the emulator or
> > my N1 phone.
>
> > The stack trace indicates that the DVM cannot load classes in the
> > com.google.gdata.client packages, despite the jars being included in
> > the Eclipse project. My test app generates the following messages when
> > trying to instantiate a
> > com.google.gdata.client.calendar.CalendarService object:
>
> > W/dalvikvm( 220): Unable to resolve superclass of Lcom/google/gdata/
> > client/ca
> > lendar/CalendarService; (6)
> > W/dalvikvm( 220): Link of class 'Lcom/google/gdata/client/calendar/
> > CalendarSe
> > rvice;' failed
> > E/dalvikvm( 220): Could not find class
> > 'com.google.gdata.client.calendar.Cale
> > ndarService', referenced from method
> > com.tomoreilly.CalendarTest.onCreate
> > W/dalvikvm( 220): VFY: unable to resolve new-instance 15 (Lcom/google/
> > gdata/c
> > lient/calendar/CalendarService;) in Lcom/tomoreilly/CalendarTest;
> > D/dalvikvm( 220): VFY: replacing opcode 0x22 at 0x0012
> > D/dalvikvm( 220): Making a copy of Lcom/tomoreilly/
> > CalendarTest;.onCreate cod
> > e (608 bytes)
> > W/dalvikvm( 220): Unable to resolve superclass of Lcom/google/gdata/
> > client/ca
> > lendar/CalendarService; (6)
> > W/dalvikvm( 220): Link of class 'Lcom/google/gdata/client/calendar/
> > CalendarSe
> > rvice;' failed
> > I/dalvikvm( 220): Could not find method
> > com.google.gdata.client.calendar.Cale
> > ndarService.setUserCredentials, referenced from method
> > com.tomoreilly.Calendar
> > Test.onCreate
> > W/dalvikvm( 220): VFY: unable to resolve virtual method 46: Lcom/
> > google/gdata
> > /client/calendar/CalendarService;.setUserCredentials (Ljava/lang/
> > String;Ljava/
> > lang/String;)V
> > D/dalvikvm( 220): VFY: replacing opcode 0x6e at 0x0025
> > W/dalvikvm( 220): Unable to resolve superclass of Lcom/google/gdata/
> > data/cale
> > ndar/CalendarFeed; (20)
> > W/dalvikvm( 220): Link of class 'Lcom/google/gdata/data/calendar/
> > CalendarFeed
> > ;' failed
>
> > I haven't been able to solve this specific problem, but instead have
> > decided to take the alternate approach suggested by Jim Blackler
> > athttp://jimblackler.net/blog/?p=151. His approach does not rely on
> > com.google.gdata classes, but instead uses an Intents mechanism that
> > is not documented by Google.
>
> > Regards,
> > Tom
>
> > On Mar 14, 12:37 am, Bob Kerns <r...@acm.org> wrote:
>
> > > Yes. The reason I do copy them (and recommend copying them) to a lib/
> > > directory is twofold:
>
> > > 1) It makes them an explicit part of your project for versioning. If
> > > you use Subversion you can make these be a copy from a directory of
> > > third-party components. You could copy the third-party directory for
> > > tagging as well as your project, but this makes the dependency more
> > > apparent.
>
> > > 2) It's compatible with how the ant build scripts are set up out-of-
> > > the-box, so it makes it easier to transition to an ant-based
> > > production build.
>
> > > But as you note, Eclipse doesn't really care.
>
> > > On Mar 13, 9:14 pm, Kumar Bibek <coomar....@gmail.com> wrote:
>
> > > > It doesn't really matter if you create a lib folder and put the jars
> > > > and link them. It just works if you have added the jars the the build
> > > > path. Though I am not able to figure out why you are getting this
> > > > error.
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
