[android-developers] Re: Bug: Google Analytics JAR is generating corrupt data for PageViews and Events
On further investigation, it was found that this bug only manifests when setDryRun(true) is called. The good news is that when it is set to false (or not called), then the LogCat output and any network capture logs (ex: WireShark) show that the correct data is actually uploaded to the servers. Since the real data being sent to the service is not being corrupted, this lowers the severity of this bug. Without seeing the source code, I'm guessing that when setDryRun(true) is called, all tracking calls stop going to the SQLite DB and instead go to an alternative in-memory data structure and that this data structure either has some bugs or is not fully thread-safe. On Monday, March 19, 2012 10:05:45 AM UTC-7, Lathe26 wrote: I should add that a Issue 200 has been filed in the analytics-issueshttp://code.google.com/p/analytics-issues/bug database at this link location: http://code.google.com/p/analytics-issues/issues/detail?can=2start=0num=100q=eventcolspec=ID%20Component%20Type%20Status%20Priority%20Stars%20Summarygroupby=sort=id=200 -- 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
[android-developers] Re: Bug: Google Analytics JAR is generating corrupt data for PageViews and Events
On Monday, March 19, 2012 10:01:55 AM UTC-7, Lathe26 wrote: I'm wondering if anyone else is seeing this severe data corruption bug. I've confirmed this behavior in the Android simulator and on my own phone using the libGoogleAnalytics.jar version 1.4.2 If I use the Google Analytics JAR for Android to track several page views or events and then dispatch them, the data being sent to the server does not match what I'm tracking (LogCat output shows this too). Example: if I track 8 different events and then dispatch, then 8 event packets are sent but only the 1st and 8th packets are correct while the packets between are random repeats or skips of the events in between. If I call the following: tracker = GoogleAnalyticsTracker.getInstance(); tracker.setDebug( true ); tracker.setDryRun( true ); tracker.setAnonymizeIp( true ); tracker.setProductVersion(myProductVersion, 1.0); tracker.startNewSession(UA-24601666-42, this); tracker.trackEvent( Clicks, Button, down1, 1 ); tracker.trackEvent( Clicks, Button, up2, 2 ); tracker.trackEvent( Clicks, Button, down3, 3 ); tracker.trackEvent( Clicks, Button, up4, 4 ); tracker.trackEvent( Clicks, Button, down5, 5 ); tracker.trackEvent( Clicks, Button, up6, 6 ); tracker.trackEvent( Clicks, Button, down7, 7 ); tracker.trackEvent( Clicks, Button, up8, 8 ); tracker.dispatch(); then in LogCat I'll see the debug put for the following events in this order: down1, down3, down5, down7, down5, down7, down7, up8 For anyone that wants to see a demo, see the attached source code. On further investigation, it was found that this bug only manifests when setDryRun(true) is called. The good news is that when it is set to false (or not called), then the LogCat output and any network capture logs (ex: WireShark) show that the correct data is actually uploaded to the servers. Since the real data being sent to the service is not being corrupted, this lowers the severity of this bug. Without seeing the source code, I'm guessing that when setDryRun(true) is called, all tracking calls stop going to the SQLite DB and instead go to an alternative in-memory data structure and that this data structure either has some bugs or is not fully thread-safe. -- 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
[android-developers] Re: Bug: Google Analytics JAR is generating corrupt data for PageViews and Events
On further investigation, it was found that this bug only manifests when setDryRun(true) is called. The good news is that when it is set to false (or not called), then the LogCat output and any network capture logs (ex: WireShark) show that the correct data is actually uploaded to the servers. Since the real data being sent to the service is not being corrupted, this lowers the severity of this bug. Without seeing the source code, I'm guessing that when setDryRun(true) is called, all tracking calls stop going to the SQLite DB and instead go to an alternative in-memory data structure and that this data structure either has some bugs or is not fully thread-safe. -- 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
[android-developers] Re: Bug: Google Analytics JAR is generating corrupt data for PageViews and Events
I should add that a Issue 200 has been filed in the analytics-issueshttp://code.google.com/p/analytics-issues/bug database at this link location: http://code.google.com/p/analytics-issues/issues/detail?can=2start=0num=100q=eventcolspec=ID%20Component%20Type%20Status%20Priority%20Stars%20Summarygroupby=sort=id=200 -- 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
[android-developers] Jerky UI due to too many calls to adapter getViews
I have a GridView and when someone scrolls down the screen and selects
an item, I update the GridView with new contents and set the selection
to 0 so that the first item in the updated view is being shown. For
example: show the contents of a directory, scroll down, select a
directory, update the UI with the new directory's contents and show
the first file.
The problem is that the UI is jerky during this process. What I see
when the GridView is updated is that first the new contents are loaded
into the UI at the old scrolled down position and then the UI jerks to
the first position.
What the problem appears to be is that UI gets updated when the
contents are updated and then there is a 2nd round of updating when
the selection is set to 0.
Is there a way to avoid the 1st round up UI updating? Alternatively,
is there a way to set the selection to 0 before the contents get
updated? I've tried a variety of solutions but either the set
selection gets broken or I have jerking UI.
Pseudo code:
// This is called when the user clicks on an item in the GridView
void updateUI()
{
myAdapter.setNotificationOnChange( false ); // Try to turn of
updating the UI
myAdapter.clear();
myAdapter.addAll( theNewData );
myAdapter.notifyDataSetChanged()
myGridView.clearFocus(); // Someone recommended this online,
doesn't help
myGridView.post( new Runnable() {
@Override
public void run() { myGridView.setSelection( 0 ) }
} );
};
Here, I have my own adapter class (myAdapter is an instance of that
class). For performance reasons, the getView implementation already
has implemented the holder pattern (so findViewById is not excessively
called). This reduced the time of the UI jerkiness but didn't
eliminate it.
Importantly, if I Log.d statements in the updateUI, the Runnable.run,
and in the MyAdapter.getView, I see the followinging:
getView position 12// These are from the user scrolling down
in the old contents
getView position 13
getView position 14
getView position 15
updateUI start// User clicked on an item, new contents
loaded in
updateUI end
getView position 12// UI updates with new contents at WRONG
position/selection
getView position 13
getView position 14
getView position 15
Runnable.run, selection set to 0
getView position 0// UI finally updates to correct position/
selection
getView position 1
getView position 2
getView position 3
I've attempted variations on the updateUI code such as doing a
myGridView.post() of the myAdapter.notifyDataSetChanged() so that it
occurs _after_ the myGridView.setSelection(0), but this only changed
details of how the jerkiness looks and does not make it go away.
Other variations of what is posted, when things are posted, and the
order the methods are called either don't help the jerkiness or
setSelection simply fails to work.
--
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
[android-developers] International / UTF-8 bug in java.util.zip
I have found the following bug in Android. Where do I report it? There is a bug in java.util.zip (likely in the ZipEntry class) where the name of the ZipEntry is not properly encoded in the ZIP file. This bug affects any UTF-8 characters that are not in the ASCII range. An example character is the '©' character, which is Unicode codepoint 0x00A9 or in UTF-8 is 0xC2 0xA9. The effect of this bug is that file names that contain non-ASCII are read back with corrupt file names by other ZIP file reading programs (ex: PKWare's PKZip or WinRar). Thus, file names that contain international characters or special symbols are being corrupted. What is happening is as follows: 1. By default, ZIP files contain file names that use the IBM 437 character set for historical reasons. To use the modern UTF-8 encoding of the Unicode character set, a flag needs to be set in the zip file. This flag has been supported since ZIP file format version 6.3.2 which was released in September 2007. 2. Android writes file names in UTF-8 format but does NOT set this flag. 3. What appears to be happening is that the flag field is a 16-bit field that is stored in little-endian format. The flag to be set for UTF-8 support is bit 11. Instead, bit 3 is being set. Bit 3 is documented by PKWare to mean ...fields crc-32, compressed size and uncompressed size are set to zero However, since the crc-32 and size fields are not 0, I am guessing that the Android code is _trying_ to set bit 11 but is doing it in incorrect big-endian format and thus accidentally setting bit 3. For debugging / testing purposes, I used a hex editor to properly set bit 11 in the zip file. This enables other ZIP file reader programs to properly decode the file names. I have 2 example ZIP files, before and after this hex edit, that demonstrate this bug that I can make available. Note: do not rely on Microsoft Windows 7 built-in zip reader program for testing purposes to properly decode the file names since Microsoft's implementation is known to have several zip-related bugs. -- 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
