Good Morning, I recently got stuck playing around with xmpp and stream compression (essentially a zlib initialization). There is an alternate implementation, jzlib, which most apps use for this purpose. XMPP recommends a flush after each package. This is especially needed during feature negotiation and login.
Results so far: - jzlib / ZOutputStream / send + flush: works - jzlib / ZInputStream / receive: works - DeflaterOutputStream / send + jdk7 flush: works - InfalterInputStream / receive: hangs You may wonder how to overcome the 5+ year old gzip problems of the JDK: Android 2.2 ships with some JDK7 features, including a *working* flush implementation. You should just use reflection to check the availability.... Anyway, the receive path seems to be broken. I was unable to receive complete xml fragments with the DeflateInputStream. It always blocked before receiving the last few hundred(!) bytes. JZlib/ZInputStream works like a charm. I tried to feed the inflater with single byte reads but still no receive of the last few bytes. I would guess that the lookahead got messed up somewhere and that android is waiting for a never-coming extra byte. I'm not sure if the native code is broken as well, but I would highly appreciate ideas for a workaround. Pulling jzlib for zlib reading looks wired.... Thanks in advance, René Treffer -- 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
