[TIMOB-2933] Android: facebook - java errors when using graph api publish (though publish does succeed)
GitHub Issue | n/a |
---|---|
Type | Bug |
Priority | Medium |
Status | Closed |
Resolution | Invalid |
Resolution Date | 2011-04-15T03:33:14.000+0000 |
Affected Version/s | n/a |
Fix Version/s | Release 1.6.0 M07 |
Components | Android |
Labels | android, defect, facebook, regression, release-1.6.0, reported-1.6.0 |
Reporter | Thomas Huelbert |
Assignee | Bill Dawson |
Created | 2011-04-15T03:33:14.000+0000 |
Updated | 2017-03-23T21:57:06.000+0000 |
Description
[INFO] Titanium SDK version: 1.6.0 (01/24/11 08:14 e1cb22a) all supported platforms
- log in to facebook via >mashups > facebook > log
in
- facebook>publish stream enter some text and tap either of
the GRAPH API buttons
- watch logcat
results:a bunch of exceptions, pastie here: http://pastie.org/1497476">http://pastie.org/1497476
the test seems to succeed though, this bug is about the errors seen in logcat.
Sadly, this is inside Facebook's android SDK and android code itself. It's not an exception that surfaces (it's quelled internally by Android code and displayed just for logging purposes by them, thus the comment "Attempt to cast generated internal exception:").
Technical reason:
FB checks every key inside a
Bundle
to see if it happens to be a byte array. They do that by iterating over each key and callingif Bundle.getByteArray(key) == null ...
. If the value associated with the key is not a byte array, then null is returned, which is fine for FB's purposes. Alas, Android'sBundle
code decides to log the fact that the call -- internally -- also caused them to have aClassCastException
. They don't re-throw that exception -- they just logcat it and return null, which FB programmers are counting on (and rightly so, given that the documentation forgetByteArray
says "Returns the value associated with the given key, or null if no mapping of the desired type exists for the given key or a null value is explicitly associated with the key."In a nutshell: this is not our code and the ugly logging -- in this case -- is not a sign of anything gone wrong. Android internal code has decided to log an exception that they don't throw.
Closing ticket as invalid.