This release brings with it the new r7 support library. Due to the previous version depending on a now-removed Dalvik bug, we have to update to this version of ABS to ensure it functions with future versions of Android and Dalvik. https://plus.google.com/108284392618554783657/posts/5adND7hSey8
Like the version code, the android-maven-plugin takes care of updating this manifest field for us. Having the app debuggable is useful because it allows us to profile performance & mem usage using DDMS: http://developer.android.com/guide/developing/debugging/ddms.html
Both RoboGuice and ActionBarSherlock require the use of base activities, so we're using copies of the RoboGuice classes that extend the *ABS* base classes, rather than the normal Android classes. https://github.com/rtyley/roboguice-sherlock
I used 'mvn release:prepare' to do the tagging this time, which is much faster than me doing it, but doesn't commit the automatic version-code updates - so I'm doing that now.
Three changes: * Remove use of ABS 'plugin-support-lib' as this is back in the ABS lib itself * Adapt our activities to use RoboGuice-supporting subclasses of the ActionBarSherlock activity and fragment classes. * ProGuard rule to ensure that the constructor of the ActionBarSherlock implementation classes aren't over-aggressivly removed (the 'native' one is invoked via reflection).
There's some fractional improvements in reduced array allocation etc, but mostly this change is just to remove the duplication of the graph-generating code that was in TrafficListFragment & GaugeViewHolder.
Unfortunately, due to some rendering issues, this isn't quite ready to go out yet: expectedbehavior#13 (comment) We're putting it on a branch and hopefully it'll be sorted soon and we can re-merge it. Reverts commit e606ff2. Conflicts: app/src/main/java/com/github/mobile/gauges/ui/ListLoadingFragment.java
Uses setList() instead of setAdapter() - it's not a method available on ListAdapter, so we have to ensure we have a ViewHoldingListAdapter. This is a redo of commit 73689dc - which was broken because it left the 'Content' and 'Referrers' fragments blank. This was because a private reference to the ListAdapter was being held in the ListLoadingFragment- a bad idea because list fragments can actually have their ListAdapters replaced when on coming back on screen, leaving the LLF holding an old ref. Now, instead of holding our own ref to the ViewHoldingListAdapter, we call getListAdapter() and cast it, ensuring we have the correct ListAdapter. fix the jump fix
This commit introduced a bug, the 'Content' and 'Referrers' fragments went blank - quite surprised, sure I had checked them... oh well, investigating This reverts commit 73689dc.