Back in the v3 days, I used to have this idiot discussion about handling passwords every other week. Some weisenheimer would notice that Raccoon only prompts for a password during setup. Then, dug through the config file, just to find the password stored there in plain text. Five minutes later, an angry email would hit my inbox, explaining to me that passwords are sensitive information and therefore must be encrypted before storing them on disk. Read more ›
I’m torn on implementing this feature. Raccoon v3 had it, it was pretty popular with power users. It was suppose to be reintroduced in Raccoon v4.1 (Google’s latest protocol changes forced an early release), but I don’t really want to do it.
The problem with the commandline is it being a quick and dirty way to implement features for power users: fairly isolated code and almost no UI bloat. Takes a fraction of the time you’d have to spend on creating a dialog window and you always end up regret doing it afterwards because eventually regular users will want to use the feature, too and then you have to explain to them how to use the commandline. You initially save time on coding, then waste it all again on email support.
The next problem with adding a commandline mode is that Raccoon v3 kept everything in the filesystem, so running multiple instances of the software wasn’t an issue. With v4, however, it is, since all meta data is now kept in an embedded SQL database, which can only be opened by one process at a time.
The choice here is either running the database as a background daemon for multiplexing access or risking that GUI and a CLI instances will block each other. Neither is particularly appealing! Both will be a cause of later regret.
The solution I currently fancy is to temporarily implement a command line switch for updating apps that will be deprecated from the beginning and have “here be dragons” as its sole description. Then eventually have Raccoon run as a servlet as well as a desktop application (see TradeTrax for an example).
Just had a rather long email exchange concerning a particularly elusive app and it ended with a facepalm moment (as in: why didn’t I think of that?). Read more ›
Dratz! I wanted to release Raccoon v4.1 this week. But unfortunately it looks like Google changed the data format, used to communicate search results between server and client (again). In consequence, Raccoon will, for some queries, get confused and not show a list of apps, but only four buttons that seem to still be loading data. I’m afraid, that’s a showstopper.
What happened? As far as I can tell so far, Play got “smarter”. In the past, a search request would simply return a single list of apps that matched the search term(s). This is still the case for “general” queries, but when Play determines that you are looking for a specific app, you get four lists instead (hence Raccoon shows four buttons). The first one consists of just one entry: the app you were (likely) looking for. The second list contains apps, Google would like you to try as well, the third contains apps similar to the one you were looking for and the fourth is just “everything else that seems to match”.
As far as usability goes, this is a major improvement. Play is overflowing with apps from developers trying to get discovered by riding the backwash of popular apps. And it certainly looks like Google is now finally making an effort to bring down the hammer on the knock-offs. The downside, of course, is that third party APK downloaders and older versions of the official Play app will stop working properly. As far as Raccoon goes, this is only a temporary issue. I look into these things, I fix them. And just so there’s no confusion: this is why you actually want to pay for premium features, even if you don’t need them. Your money allows me to keep the software, you are using, functional.
Oh yes, workaround for the issue (till v4.1 arrives): you have to generalize your search queries. If, for example, you are looking for “Firefox”, Play will (rightfully) assume that you want to download Mozilla’s web browser. Try searching for “web browser” instead and you’ll get a list of all available browsers, including “Firefox”.
With Android O, we are well into the second half of the alphabet (no pun intended) and the Android packagemanager still requires apps to be signed. Why exactly?! Read more ›
There are tons of reasons, why Raccoon might not find an app (or produce any search results to begin with). Today, I learned of a new one: user tried to mimic a Gingerbread device (I’m not happy with little “details” like this one being kept back till the 10. email!).
I’m not quite sure what to say here, except the following:
- Raccoon allows you to experiment. That’s the whole premise. However, if you choose to do something outlandish and it doesn’t work, don’t come running to me. At least not without telling me precisely what you did! You are not the only one sending me support mails and I simply don’t have the time (or the nerve) to drag it out of you in hour long email conversations!
- Google changed the wire protocol somewhere between Android 2.x and 4.x. Given that Gingerbread is a dying breed, Raccoon only supports the newer format. If you use DummyDroid to obtain a GSF ID for an ancient phone, you simply won’t see any search results. Play then switches to compatibility mode and sends data, Raccoon can’t make heads or tail out of.
- An Android app can specify the minimum and the maximum OS version, it will run on. Only the first one is required, though and since Android tries to stay backwards compatible at all costs (usually the cost of all sanity), most app developers keep it open ended. That is, if an app was written in the Gingerbread days, it can very likely be downloaded with a Nougat profile as well.
Considering the last two points, I won’t add Android v2.x support to Raccoon. That train has left!
Just had this crazy idea. It is probably unworkable and legally questionable, but here it goes: icon packs. If you want a consistent look on your homescreen, you need to install a custom launcher and download a pack that likely contains a lot of icons for apps, you do not have. In other words, it’s a giant waste of valuable storage space and you are forced to use a different launcher. Read more ›
Most people probably think that Google Play determines app popularity by how often the APK file gets requested (one download = one installation). Intuitive, but wrong: Read more ›
Looks like v4.1 will be a lot big bigger (in terms of code changes) than anticipated. The things I wanted to be in there:
- More user friendly import feature: instead of manually selecting APKs in a file chooser, select a directory (tree) to scan for Android apps.
- Add commandline support for updating apps again.
- Add Paypal alternatives for paying for premium features.
The things I have actually been working on so far: untangling code. It’s marvelous how you always end up asking yourself what the hell you were thinking a couple months ago when you wrote the original code. Anyways, I’m mostly done with cleanup, so I can focus on features now.
UPDATE: Just got an email asking for clarifications. Raccoon v4.1 is planned to be a service release and won’t introduce new premium features. Premium features that are already unlocked will automatically carry over. There is no reason to wait for v4.1 if you want to unlock.
I just had this magnificent idea: why not put an app on Play that serves as a license key for Raccoon? Once you download that app via Raccoon, it automatically unlocks the premium features. No need to manually mess around with keys, no need to deal with Paypal. In fact, you could even stay entirely anonymous by using Play gift cards! Read more ›