So long APK Manager

Just a quick post, largely to use as a static header for the APK Manager page/category.

In June 2015 I moved from Android to iOS, so I will no longer be updating or supporting my APK Manager for Mac OS X. If anyone out there still uses it, I encourage you to search for a new tool, or if you’re so inclined, you can message me to take over the project.

It’s not you Android, it’s your OEM’s

So given the post history of this blog, it should be pretty clear that I’m both a Max OS X nerd, and an Android nerd. I prefer OS X for my day-to-day productivity, but I’ve been an Android user since the G1 was released. I have followed both mobile OS’s evolution over the years though, and surprisingly (even to me!) I very much expect my next phone to be an iPhone, for the first time since the original model. Specifically, I’m guessing I’ll be buying whatever the next “Plus” model is, e.g. iPhone 6s Plus or whatever name they give it.

Why am I thinking of switching back to iOS? Like everything in life, it’s complicated.

In part, my usage has significantly shifted back to media consumption (e.g. podcasts, twitch, youtube, kindle/ebooks, etc.) and there’s no real advantage to either platform anymore in this regard.

Another┬ápart is battery life; no android phone I’ve ever owned, even my nexus 5, has been able to last through a full day of heavy use. My nexus 5, with stock 5.1, no “rogue apps” etc. will drain 4-10% battery overnight. Every single review I’ve seen for the iPhone 6 Plus praises it for battery life, even under heavy use.

Mostly though, I just want convenience and reliability again; flagship hardware, a killer camera, timely software updates, and no carrier/oem bloatware.

I’m beyond frustrated with OEM skins on top of stock Android, and Nexus devices just don’t “wow” anymore, certainly not at the Nexus 6 price point. And for some inexplicable reason, no Android OEM is willing to make a true flagship quality phone, with a killer camera but otherwise unmolested/stock Android. Motorola the past few years has been by far the best when it comes to maintaining the spirit/cleanliness of Android, but they tend to use older/outdated hardware, and they never really “Wow” with their camera’s.

I’ve also finally grown tired of needing to root (and risk voiding warranties) just to flash custom recoveries, custom roms, etc. just to remove bloatware on Android. And when community ROM’s are finally released for the latest phones, they inevitably sacrifice the advanced camera features and custom/OEM camera interfaces, which were the only desirable OEM changes in the first place.

So Android, I’m sorry, I still love you (especially post 5.1!) but I just don’t love your OEM’s.

Sworkit mockups

So I admit it can come off wrong to criticize an application without offering an alternative, so I’ve taken some time to mockup just how good a native version of Sworkit could look and work on Android.

These are all very rough, and I’m not anywhere near finished creating mockups for every screen. Please note, the screen-captures from my phone are at 1280×720 resolution (with hardware buttons instead of soft-keys) whereas the mockups are made to target a Nexus 4 1280×768 resolution, with soft-keys.

First, a comparison of the existing application (left) and my mockups (right)

Overall, the only major changes are the move to a slide-out navigation drawer for access to settings, and a more holo-centric version of the “Cards” UI style. In addition, There’s plenty of room on-screen for quick access to your most recent workouts to repeat them without any hassle.

The workout selection list is largely unchanged too, simply conforming to the HOLO theme, and removing the “back” and “more” buttons up top in favor of using the “UP carrot” in the top action bar.

And the custom workout screen, compared to a workout “Queue” system. Of course a queue system doesn’t have to replace the custom workout option, but I think it’s a better feature to implement earlier than fully custom workouts, especially with the randomization that Sworkit can already employ.

And of course, the settings menu compared to a Navigation Drawer. You could go even further, and embed a switch/toggle for the “30 Second Break” right into the drawer for super quick access to this setting.

EDIT: 3:50pm, 8 Oct, 2013 – Updated the navigation drawer mockup to show icons in the drawer. All icons used in the mockup are stock Android, available for free from Google in vector format.

And lastly, to expand on some of the drill-down pages in the Settings menu, I would break apart the user profile and goals into separate screens, and incorporate things like TDEE calculation, more accurate calories burned estimation based on fitness profile, etc.

And an idea of what an expanded “Goals” screen might look like, with linked sliders so that adjusting minutes-per-day, minutes-per-week, or days-per-week will all update the other sliders for best-fit goals.

And of course, all of the above could easily translate to the “Holo Dark” system theme with little to no modification really.

Second class Android

It should be no surprise to anyone here that I’m a big fan of Android, though I’m by no means a “fanboy.” I’ve had a smart phone since the days of the original Handspring Treo, and since then I’ve used palm OS, windows mobile, Symbian, iOS, and Android devices. Really the only mobile platforms I missed were WebOS and meego (both died to quickly.)

The number one reason I settled on Android was the extremely tight/core integration of Google services, and the generally “Open” nature of the platform on the whole.

I like to hack and tinker with my electronic devices, and Android affords me the greatest opportunity to do so.

That said, it’s extremely disheartening to see that after 5 years of rapid development, Android is still a second class citizen when it comes to many cross-platform applications.

A recent example of this is a popular exercise app, Sworkit.

The paid/pro version of this app ($1) has an overall rating of 4.6 on the Play store. And the free version has an overall rating of 4.5, and both apps combined have an “install” base of ~105,000-510,000 users according to the ranges indicated on their product pages.

And Sworkit for Android is a borderline unusable iOS port, and an example of a terrible developer pushing crap as quickly as possible to make money, instead of focusing on quality.

Here’s a few or the biggest problems with Sworkit for Android:

  • Sworkit isn’t native, but an extremely poor performing web-wrapper, using Cordova.
  • Sworkit completely ignores every Android UI guideline. This is a huge, HUGE issue. Menu’s don’t work the way they should, There’s no action bar, nav drawer, view control, etc.
  • Sworkit completely ignored the systemwide “Holo” themes, instead using UI elements straight from the iOS app that don’t fit with Android at all.
  • Sworkit largely ignores hardware buttons which either don’t work as they should (back causes endless loops in many screens), crash the application, or don’t do anything at all (e.g. menu button)
  • Sworkit uses built-in, pre-recorded voice files instead of utilizing the Android TTS services, so the only language it supports is English.
  • Sworkit embeds assets (e.g. system fonts like Roboto) instead of calling them from the operating system framework.
  • Sworkit even ignores common APK structure, placing all drawables into the /assets folder instead of the /res folder.

This is by no means an exhaustive list of all the problems with Sworkit for Android, but it’s definitely some of the most glaring issues.

I don’t really know how else to say this, but to anyone developing for mobile platforms, your applications need to show that you actually care about them. Android users by and large want apps that look and feel like they belong on Android, not iOS or web ports. Just like iOS users want apps that look and feel like they belong on iOS.

If you’re going to develop for multiple platforms, take your time. Learn the platform. Use it’s strengths wherever possible, and only develop custom workarounds in the absolute worst/last case scenario.

adb screencap function

So regardless of being a failure at pretty much everything, I still like to tinker and tweak my android phones pretty regularly, and one thing I rather hate is the need to open DDMS/Monitor to take a screenshot.

Well, a few days ago I found a great tip on this site:

And quickly decided to expand on it a bit for my own personal use, and thought I’d share my final implementation here in case anyone might use it.

Just add the following function to your .bashrc or .zshrc file and either re-start your shell, or re-source the file (e.g. source $HOME/.zshrc) to be able to use the “adbss” command.

# setup a simple adb screenshot function
adbss () {
    local file="$(/bin/date +"%d-%b-%Y_%I.%M.%S").png"
    local dir="$HOME/Downloads/adb_screencaps"
    if [[ ! -d $dir ]]; then
        mkdir -p "${dir}"
    adb shell screencap -p | perl -pe 's/\x0D\x0A/\x0A/g' > "$dir/$file"

And of course to change the directory the screencaps are stored in, just edit the “local dir=…” line with the path to the directory of your choosing.

Anyway, I’ve tested this with the default BASH 3.2.48 shipped with OS X 10.8, BASH 4.2.52 (built by homebrew), and ZSH 5.0.2 (also built by homebrew) and it works fine in all three.