What’s new?

• Added Issue Sorting on Issues List (Press Menu to Sort).
• Displays helpful Toasts
• Fixes duplicate label bug
• Adds an option to enable/disable anonymous usage sharing (Press Menu-> Settings on the Main Screen)
• Adds an option to enable/disable automatic data refreshing (Currently inactive)
• Adds option to reset all settings to default. Use if you’re having issues.
• Displays GoogleCode SVN Commits.

You can find it in the market, as usual.

What’s been keeping me busy?

Starcraft 2. Spent many nights playing that game. Nights that could’ve been used to advance Abugadro development. Take this as a confession of a Starcraft-aholic, but I promise to cut back on Starcraft 2, and work more on Abugadro.

Finally, I’m aware the app is currently incompatible with Android 1.5 (Cupcake). I’m starting to test the code on Cupcake, and see what I have to disable to make it work properly. I created an Issue on the Google Code Page. Go ahead and star the issue to be notified of news and changes.
No E.T.A. for Cupcake-compatibility. Sorry.

And a bit of good news: I’m setting up a way to easily translate this app, as I want this available in as many languages as possible. News coming soon.

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.

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.

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.

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.

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.

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.

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.