Sometimes the most important thing is to tilt your head and look at the problem differently.
I usually end up feeling foolish when this happens. The only thing to do is to own it and move on, lesson learned. I work on a big app in my day job. As delivered, it's currently 45MB. As you can imagine, some size could be sliced off if we could use /this/ technique, or /that/ procedure. Sadly real life doesn't seem to work that way. Apps, like people, seem to be the sum total of all the events (and corresponding scars) made over their lifetimes. There are /reasons/ why we can't use app bundling, or other methods to slim down like some other apps might. So, when I was tasked with creating a carousel effect, though my first thought was to use the 'Android-CoverFlow' library from https://github.com/crosswall/Android-Coverflow, I balked because of the size. I don't have anything against the code or the library, we just needed the lightest implementation possible. So I started trying to build the coverflow effect by hand. I found that the ViewPager is distinctly odd in the Android world. If you luck into the right point of view, it's a no brainer. If you, like me, make invalid assumptions, it's a nightmare of code smells: machine-specific code, hooking into the global layout of the widget, strange unexplained offsets being required, etc. So, instead of being very long winded, I'm going to show you a git repo. One branch, "BadCoverflow", is the original code. It works okay-ish on one size phone (I used the emulator's Nexus s here), but good luck getting it to work across phone sizes (try it on a Nexus 5x for example), or being able to control scrolling, or resizing elements. I couldn't get the scrolling to be reliably 1 page wide on all phones, and strangely the magnification of the transformer wasn't centered and also varied between phones. I had a simple idea that a 'ViewPager' would fit the full width of the diplay, and it would just somehow 'know' to center the current item, etc. I am embarrassed to say I lost 3 days to this mess. To find what was causing the issues for me, I had to completely comment out all the code and uncomment it, bit by bit, to explain to myself what is going on. In the other branch, "BetterCoverflow", is the simplified code. Slightly smaller in size, platform-independent, and with fewer code smells. Note that there's not much difference code-wide between these examples. The biggest change came in my shifting point of view. The viewPager is not expected to go the full width of the display and yet manage only a subset. It's not expected to manage centering etc. That's the job of the enclosing View. Many of the smells have been removed (addOnGlobalLayoutListener? Trying to 'kick' the ViewPager as the transformer wasn't, somehow, being used when first laid out... though I'm sure not all...no tests? I mean really...). As with most libraries we automatically reach for, Android-CoverFlow wasn't actually needed in the end, just a better understanding of how ViewPagers work. I hope this article helps some other poor, lost soul struggling with a ViewPager-based coverflow implementation.
1 Comment
|
AuthorThis is when I'm wearing my IT hat. Archives
February 2024
Categories |