Re: [protobuf] Re: uni64 data to uint32 unit time

2010-04-19 Thread Kenton Varda
On Mon, Apr 19, 2010 at 7:51 AM, ikalbeniz wrote: > i have used this API to access to android market: > > http://code.google.com/p/android-market-api/ (uses google-protobuff- > api) > Note that the android-market-api project is not from or authorized by Google. It looks like they reverse-engine

Re: [protobuf] Re: uni64 data to uint32 unit time

2010-04-19 Thread Marc Gravell
Now that is amusing (to me, at least); I decode a variant in "calc", and then mess up the field number! It is the field with *binary* 101, i.e. field 5. and note also that I'm treating that as an unsigned variant; a signed (zig/zag) variant would give a different answer. On 19 April 2010 15:57, M

Re: [protobuf] Re: uni64 data to uint32 unit time

2010-04-19 Thread Marc Gravell
and you process the last 2 bytes separately, of course; it is field 101 of type string (or sub-message or bytes), length 14, with the actual data missing. Marc On 19 April 2010 15:53, Marc Gravell wrote: > I know it wasn't the core part of the question, but note that BitConverter > isn't especi

Re: [protobuf] Re: uni64 data to uint32 unit time

2010-04-19 Thread Marc Gravell
I know it wasn't the core part of the question, but note that BitConverter isn't especially helpful for protobuf, unless you happen to be dealing with [s]fixed{32|64} / float / double (it is unclear whether you mean "uint64" as a protobuf type or a language-specific type). Treating it as fixed/uns