As it turns out, I was using the wrong names for my values. Go me. > Same for MultipartEntity, you have to override the generateContentType > method and provide your own contentType. The problem here is that you > can't seem to override the setter so you have to hard code the content > type in the getter. I guess you have to override multiple times if you > need multiple content types. I'm told that all this will be fixed in > furure releases of httpmime.
Fixed in that you won't need to override multiple time, or fixed in that the Body will have settable types? Any word on that whole getContentLength() being fixed? I'm working around it with searching for the appropriate response header at the moment, but it seems silly to have to do so. > I'm not sure what you mean by this. There's three levels of > communication - actually, there's many more. At the low level, things > are handled by httpClient. You handle httpClient. Then the content of > what httpClient gets you is - or rather can be - xml, which you handle > by DOM or other xml tools. > If you want to know what's happening between your program and the > server, I recommend using wireshark or a similar tool. I mean in a general sense. My undergrad experience with XML was focused on opening a port, and waiting for a pure XML stream to be parsed by (at the time) SAX. A POST request, to me, would be a simple webform, some binary files to be uploaded, etc. What I'm sending is a multipart form where one of the content bodies is actually parsable XML. It just seems... kinda weird to me, you know? :) Semi-related note: I ended up having to use tcpdump to figure out what I was sending to the server in the first place, because there doesn't seem to be an easy way to get the plaintext of what I'm sending via httpmime, only what I receive. On Nov 9, 7:37 am, Christine <[EMAIL PROTECTED]> wrote: > In a StringBody or FileBody, you can't set the mime type (content > type). You have to extend the class and override mime type setters and > getters. > Same for MultipartEntity, you have to override the generateContentType > method and provide your own contentType. The problem here is that you > can't seem to override the setter so you have to hard code the content > type in the getter. I guess you have to override multiple times if you > need multiple content types. I'm told that all this will be fixed in > furure releases of httpmime. > > > On a more abstract level, is this a normal method of information > > transport? I'm fairly novice to client-server apps, but I was under > > the impression you either go fully XML or fully HTTP for client-server > > communication, but not a mixture of both. > > I'm not sure what you mean by this. There's three levels of > communication - actually, there's many more. At the low level, things > are handled by httpClient. You handle httpClient. Then the content of > what httpClient gets you is - or rather can be - xml, which you handle > by DOM or other xml tools. > If you want to know what's happening between your program and the > server, I recommend using wireshark or a similar tool. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---

