K3RNEL

The K3RNEL Hub

There’s been a lot of changes that have kept me busy with this release, and yet it’s not the mythical “0.1.0″ I’ve been promising.

What’s been keeping me busy?

  • Restructured the database to add support for GCode-Wiki, Gcode-SVN, Gcode-HG, Redmine/Bugzilla/etc (Though they’re not in it yet)
  • Automatically parses latest issues when creating a new project
  • Automatically parses latest issues when browsing a project
  • Displays issue’s comment’s changes, such as label adding or removing.
  • Moves database from /sdcard/data/net.k3rnel.abugadro to /sdcard/Android/data/net.k3rnel.abugadro.
  • Display helpful Toasts
  • Added a “Sync Timer” that automatically starts syncing when you open a project or issue, if it hasn’t synced in the last 30 minutes.
  • Allows installing on SDCard if on Froyo.
  • Hiding the unused/unfinished buttons. No need to display them yet.
  • Added Flurry, a library that allows me to keep track of app usage, although currently it only tracks app launches. (This is totally optional!)

This one took quite a while, as the db changes where exhausting. I hope that the next releases will be done a lot more frequent, as I start stabilizing the application and its database.

I’ve been overhauling the database and a lot of the core functions of the app. I’m not ready to release it, but it’s getting there.

You can read the Changelog on the brand new Changelog page, and check out the Download page while at it.  I’m working on the About page to add more detail to the app.

The version after this one (0.1.1), codename unknown yet, will include a dark theme, since according to some, black pixels actually save energy on the Android. The theme will be a setting option, so relax, you’ll still stay with the white theme if you’d rather use that.

I hope to get Abugadro out between right now and tomorrow afternoon. The hurricane is hitting my house pretty hard right now though, and I’m not sure if I’ll have electricity/internet in the morning.

I’ve been overhauling the database and a lot of the core functions of the app. I’m not ready to release it, but it’s getting there.

You can read the Changelog on the brand new Changelog page, and check out the Download page while at it.  I’m working on the About page to add more detail to the app.

The version after this one (0.1.1), codename unknown yet, will include a dark theme, since according to some, black pixels actually save energy on the Android. The theme will be a setting option, so relax, you’ll still stay with the white theme if you’d rather use that.

I hope to get Abugadro out between right now and tomorrow afternoon. The hurricane is hitting my house pretty hard right now though, and I’m not sure if I’ll have electricity/internet in the morning.

Abugadro stores the database on the SDCard. Since all (current) Android devices have limited internal memory, storing “megabytes upon megabytes” of data for each application is unreasonable.

The problem with storing stuff on the SDCard is that there isn’t a single defined directory where developers can store stuff, and the user can easily back up.

Since I’m releasing 0.1.0 soon, and need to nuke the current database, I might as well use the nuke option to regenerate the db in a different place, but where?

I currently store stuff on /sdcard/data/net.k3rnel.abugadro/ (Unless there’s no SDCard, which means it’ll use the Internal Storage instead).

I noticed Google Scoreboard stores its db on the root of the sdcard, creating /sdcard/com.google.android.apps.scoreboard. I find that hard to organize and backup. Kindle creates its own “kindle” directory, as does Android Comic Viewer and Aldiko.

The Weather Widget included in CyanogenMod (And probably Android 2.x) creates a folder called Android, then data, then the path, with the result as: /sdcard/Android/data/com.google.android.apps.genie.geniewidget.news-content-cache

I think that as developers, we should come up with one shared path to store our files, so as to not ‘pollute’ the user’s sdcards with dozens of weirdly named directories. If the user knows that he can back up and restore the contents of Android safely, he’ll probably do so.

So, using what little powers I have, I’m asking devs to please use /sdcard/Android/data/your.package.name/ to store your files in there. I know I will, and based on some other Android users, so does CoolIris, Google Earth and other apps.

Thanks for your time.

Note: I mention /sdcard as a path, but actually use Environment.getExternalStorageDirectory()+”/Android/data/”. You should too.

Now that Abugadro’s on the Market, I’ve found the lack of Android Market features disturbing. And I’m not alone at that.

Five Issues have stood out above them all, and I’d like to point them out today, in hopes that it’ll get someone at Google to pay attention and finally solve them.

  • Issue 2851. Tag comments with the version they refer to.
  • Issue 4738. Replying to user comments.
  • Issue 2148. Add a ‘Changelog’ field to allow devs. to explain the contents of the update.
  • Issue 4376. Share application statistics with developers.
  • Issue 4851. Allow multiple APKs of the same Application.

The first problem, Tagging comments can be overlooked. It’d be nice, but I wouldn’t want to waste a wish on that.

The second one, Replying to user comments, would be nice. Sometimes the comments are from confused users that don’t know how to use our app. It’s our fault, sure. But sometimes, the comment is aggresive over a bug or a missing feature. If we could get an “eBay-like” reply system that let us say “Fixed in x.y.z”, the end users could give our app a second chance.

A new Changelog field, separate from description, would mean it would only work with Android 2.3 and above, and you know what? It doesn’t matter. It’s a very welcome change.
Currently, devs have to implement a Nag-screen, like on Google Maps. On launch? It displays an annoying “here’s what’s new” message. Completely unneeded. A standard way to check the changelog would be welcome, and failing that, extending beyond the twitter-like “325 characters” for description is a welcome change.

The fourth issue is self-explanatory. You guys made Google Analytics. Extend that for Android Apps. There’s currently libraries like Flurry that give us all that information, but “Phoning Home” is NOT cool. If the user is already downloading from the market, he’s not really “phoning home”, and if uninstalling, you already ask for the reason, but it isn’t fed back to the developer. While at it, the download stats refresh about once a day. Would it kill you to have them update more often? Share them stats, Google!

Finally, multiple APKs is something that’d be appreciated. You talk about Fragmentation as if its something mythical and non existant, and yet your own Platform Versions link says otherwise. To use the newest apis I have to sacrifice a huge part of the user base, and the current solution? Release an App called “Abugadro for Donut”, “Abugadro for Eclair”, “Abugadro for Froyo”? Horrible idea. What if it was a paid app? They wouldn’t be able to get the Eclair/Froyo version once the update was made available, because it would be marked as a separate app.

Finally, if you’d like to help out, Star those issues. Clicking the star icon gives it an ‘up vote’, and would help raise awareness/priority to the features we want. Developers are people too. We need these tools.

Update: It’s been pointed out to me by a lot of people that it is possible to include newer APIs while keeping compatibility. Google even released a video about it during the Google IO. For that reason, I’m eliminating the 5th point on the wishlist.

It’s a quick-fix release.

The changes are:

  • If you have no Internet access, it will display an Alert icon, that, when pressed, will explain that you have no Internet access. This is better than displaying a horrible Exception screen.
  • When ‘refreshing’ the issues list, it should only bring back the issues for the current project. Sorry for the mixup.
  • When viewing a particular issue, it should now load a lot faster.

That’s it. For now. Get the App from the Market.

If you liked the app, I’d appreciate a donation.

I’m trying to get $580 USD to buy a Nexus One, so I can test on the Nexus One (I currently have a TMobile G1), so donations are appreciated.

I’m extremely pleased to announce that the first public release of Abugadro, v0.0.7 “Adorable Ant” has just landed on the Android Market at the low, low price of Free.

If visiting this page from your Android device, just click on the QR Code to open it, or search for “Abugadro” on the Market.

This release is extremely bare-bones, there’s a lot of features I intend to add in the upcoming weeks, however I feel confident in what I just released, and wanted to share it as early as possible.

I intend to have ~weekly releases, at least at first, and until the app matures.

Features:

  • Track your favorite Google Code projects from your phone
  • Browse through Open Issues, and Closed Issues.
  • View all comments of the Issues.
  • All information is stored locally, on the sdcard, so you can browse for offline use

What’s missing:

  • There’s a very accessible Search button that’s currently disabled. I intend to make this work by next week, tops.
  • Filters, Searches, Sorting. I know, I promise to get this done by next week.
  • Wiki and SVN/HG Commit access. I can’t promise to get both by next week, but I’ll certainly try ;)
  • Creating Issues, adding comments, modding issues. I can’t put a date on this yet, but it’s on my mind.
  • Notification / Automatic Sync / Some sort of a ‘push support’ every time critical bugs or something is displayed
  • Other bugtrackers like Launchpad, Bugzilla, Redmine or Trac. Again, no ETA, but it’s on the TODO list.

Finally, if really feel the need to pay for such a great app, I set up a paypal account for these very purposes.

I’m trying to get $580 USD from donations to buy a Nexus One, so I can test on the Nexus One (I currently have a TMobile G1), so donations are appreciated.

Long story short? SAX is faster. There, you don’t have to read the article.

Since it’s no secret that fetching Issues from Launchpad, Google Code and Bugzilla involves parsing RSS/ATOM feeds, I decided to poke around and investigate which parser to use and the advantages each carried.

After a few seconds of Googling, I found this article, over at Developer.com. Their math seems solid. I’m sticking to SAX.

I really like blogging. Almost as much as coding itself. But today, I decided to stop typing and start showing some images of what’s up.

The URLs they’re at are kinda static, and I’ll be updating them from time to time, so look around and enjoy!

Please note that the app is still in heavy development, but these are *not* mockups. The code’s available at the Abugadro Code Site.

Did you mean... Avogadro?

In case it wasn’t fairly obvious, the name ‘Abugadro’ is a mix between “Avogadro” and “Bugs”. You can call it “Abuga” if you want, since I hear “Abugadro” is kinda hard to pronounce for Portuguese-speakers (Or so my buddy Matruskan tells me).

This project is intended to make browsing Launchpad, Google Codes and Bugzilla projects a bit easier for Android devices.

The code’s starting to flow on the Google Code Project but its nowhere near ready for an early alpha test.