I still need to get back to improving SudoTape.  I have some things I want to improve, the top two things:

1. reorganize some of the strings so that I can get localized versions
2. improve the performance of drawing the markers when zooming

for issue #1 I noticed that there are a number of users in Latin America using SudoTape.  To be honest the majority of comments about the app directly have been in Spanish so I think there is likely some value in getting the app ported to Spanish, by reorganizing the strings.xml that will be much easier to do.  It helps that I work with people who are natively Spanish so perhaps I can persuade them to convert the app to Spanish if the content is laid out easy in my source.

For issue #2 it bugs me that zooming in is sluggish in SudoTape if you have a few markers defined.  I have an idea where the slowdowns are but I haven’t spent much time optimizing it.  There will be some value in optimizing it as personally I have a few project images that I defined 2-3 markers on and the app seriously slows down when zooming.

I also bought a tablet this past week.  woot.com had a sale on a Viewsonic gTablet which on paper is very similar to the highly touted Motorola Xoom, except it was less than 1/2 the price.  Sadly Woot wouldn’t ship to Canada but my parents are snowbirds and live in Arizona during the winters so I had the device shipped to them.

I’m pretty excited (being your token male gadget lover) but I won’t receive the device until Easter at the earliest.  I guess it will give me time to do some reading and think of writing an app for the thing.  Luckily XDA has a great following for the device so there will be a lot of fun had modifying it as well.

I’ve been out for a while, I haven’t done any real software development outside of work for a while.. just taking a break.

I bought Mafia 2 on Steam the other week which was on sale, I hadn’t finished or played a game for a while so it was nice to take a break.

The other day a friend from work had me look at his cheap Android tablet.  It was a cheap iPad ripoff from China but being a geek I like gadgets so I took the device home to play with it.  My friend wanted to get Honeycomb on the thing but 1) Honeycomb isn’t officially released 2) there is NO XDA support for the device 3) the device is pretty slow.  It has a decent clocked CPU (1ghz) but only has 256 MB of memory and that 1ghz processor is the old Arm11 which from what I understand is slow and inefficient.  Nonetheless it was a fun experimentation and gave me a new appreciation for tablet computers.  Now if they would finally come down in price.

It seems to me that all tablet computers are overpriced.  For the amount the cheapest high end device that is being sold you could get a pretty great netbook (or if you shopped around a fully usable Laptop.  Sure you could argue that a tablet is a lot more portable but I can guarantee that the laptop is also a lot better at doing computer type things.  It’s likely the ‘it’ factor that tablets have that is driving their perceived value up.

With the release of Honeycomb there will be a lot of competition though so with luck we’ll able to pay a lot less for even more powerful device before the end of 2011.  Then it will become a matter of “is there enough tablet specific software to make the purchase a lot more attractive”.

When submitting your app to Google marketplace you’re given a nice screen that shows where people who ran your app encountered bugs.  You can use this screen to help point out problems in your code that perhaps you missed or overlooked.

SudoTape v1.2 and v1.3 now available on the market addresses a few of these issues.  Some bugs make sense and it’s pretty easy to see how the problem occurs but some bugs you can see how it would crash but it’s really difficult to envision how the code would have crashed there.  Sadly not many users actually write in the report how they encountered the crash to give you input on how to fix the bug.

I adjusted the camera media manager of SudoTape and updated CameraTest accordingly.  It seems to work even better on my device, hopefully others will agree.

I always ignored the ‘share’ option when taking a picture with the built in camera on my phone but after using it a few times with Facebook I realized how nice it worked.  I plugged this functionality into SudoTape so it’s now able to accept and use the share option as well.  Seems to work better for my Galaxy S than the camera capture that exists in SudoTape.  I think there are still timing issues in the capture process even with all the work I did regarding capturing images and the CameraTest prototype.

At any rate, go to the market and get v1.1

I finally released SudoTape to the market.  The last stretch was around testing and getting some of the final artwork done.

I initially listed it in the photography section of the market but this morning I revised it and put it in the tools section.  You don’t really need to have a camera on your device in order to use it so it makes more sense to put it in the tools section.  I don’t know if the market automatically filters stuff out so even if you don’t have a camera and the app doesn’t really need a camera I’m not sure if you’d see it as available to download or not.  Not that it matters though, I presume most devices come with at least one camera now anyway.

I had problems creating a signed APK, I never really read anything about it and Google’s information online is sketchy at best, at whatever documentation I found was related to Eclipse so it wasn’t much help since I use IntelliJ.  Luckily IntelliJ’s created signed APK wizard wasn’t too tricky so I uploaded the app and some art/screenshots last night.

Going to see if anyone downloads it to see how much I want to support it.  I’d like to add some other features like saving the files to DropBox, perhaps unit conversions on the define markers options dialog, etc.  If there is little interest I’ll hold off adding more features and think of a new project.

You can find SudoTape on the market here:  https://market.android.com/details?id=net.pixelsystems.sudotape

You can read SudoTape’s basic documentation here: http://pixelsystems.net/?page_id=66

I finally figured out how to use GitHub.  It didn’t work well at all with IntelliJ, mostly because the learning curve is pretty vertical regarding to setting up permissions and connecting github with your machine (pgp keys, etc).

You can read about my first github project here and all the trouble I had getting camera images from the camera functionality on your Android phone into my Android app.

My app is functionally complete.  I need to do more testing and I have a bug related to importing a photo taking by the device’s camera that I can’t reproduce but the graphic designer reproduces on his HTC Evo.  I need to get a logcat from him to try and troubleshoot where the problem might be.  I’ve sent out feelers to some of my other contacts on Android to see if they can reproduce the problem.

I need to get the final artwork from the designer as well as design an about screen as well.  There are a number of ideas I have related to improving the app but I want to see how it does on the market before adding many more features.  Probably one of the nice things about releasing a free app, if no one uses it I feel less compelled to update and improve it.

I like what it does though and I can see myself using it regularly so at any rate it does what I set out to have it do.

I spent some time looking at GreenDroid . I like the idea of a unified library to help aid in developing apps but I couldn’t get it to work very well, not in IntelliJ and not outside of his sample application.  Either way there wasn’t going to be easy way to integrate it into all the work I had done already.  I really liked his QuickActions work which is what lead me to GreenDroid but in the end I had to abandon using it.

I stumbled on some work that Lorenz did around QuickActions and the code was free to use, easy to understand and easy to modify which was pretty exciting.  He had a bunch of samples that were easy to build and play with which was always nice.

I started looking into new projects but find myself intimidated by all the dp dpi px and other screen resolution type issues that people regularly complain about.  It’s probably just a matter of doing some reading and experimenting.

My project is coming along nicely.  I learned the hard way that the Android emulator is quite different than an actual device so when I got my phone back running my project on it pointed out a number of issues that I hadn’t thought of because they weren’t exposed with the emulator.

Here are some issues I tackled with recently:

• If you have multiple <intent-filter sections in yourAndroidManifest.xml defining:

<action android:name=”android.intent.action.MAIN” />

<category android:name=”android.intent.category.LAUNCHER” />

then each of those sections will create icons for your application with no other identification saying which is which.. Can be a bit confusing on which icon to press to run what main mechanism

• If you are launching an custom intent/activity from preferences DO NOT specify data= in your preferences.xml unless you are set to handle it, otherwise you will get a “cannot find activity” exception.  This took me several hours to discover, a lot of head scratching and swearing because I got lazy and never deleted the data= part that I copied from Google’s example code.
• The bundle as the argument to onCreate() for your activity is actually very useful and tied to onSaveInstanceState(), this I supposed is common sense but no example I read actually showed them being used together so some digging exposed to me how to use it, very handy.
• PreferenceManager.getDefaultSharedPreferences() is super easy to use, beats property file loading/saving which I use at work a lot.
• My app is targeting Android 2.1 so I couldn’t use Camera.getNumberOfCameras().  I was using Camera.open() to find out if the device has a camera but not calling Camera.release() which caused some really strange exceptions later on in my code
• this information on screens proved very important to several UI problems I was having (multi-touch), should be fundamental reading for anyone learning Android programming.

I started writing code a long time ago, so I went through the days where you had to worry about how much memory you had available to you and how you could get your data into your application without causing out of memory issues.  With all the windowing environments and new object oriented languages it’s easy to forget “the good ole days”.

I was reminded this week when I was working on an app I’m writing for Android.  The software I want to write deals with images saved from the device’s camera (or hopefully other images on the device that the user may have imported,etc).  Android has a lot of great functionality around reading and importing bitmaps but I underestimated how well those bitmaps are kept in memory.  I was running out of memory when I wanted to save my manipulated bitmap based off it’s full original size.  I wasn’t sure how I was going to solve the problem until I found this post on the Google forums:

Yes, the images from the camera are 2048px by 1536px.  If you convert

to a bitmap, thats 2048 x 1536 x 2 = 6291456, or 6MB.  This is right

at the allotted space an Activity gets.  If you can live with smaller

images, I would suggest using a sampleSize of > 1 when decoding the

image.  This will result in a smaller image size, thus less memory

used.  I have used the following code in the past to keep my images

under a set byte count.  Alternatively, you could forget about

calculating the sample size and just set it to 2.  This would use

1.5MB instead of 6MB on a standard image.

6MB, that’s not that much, but for a mobile device, yeah I suppose I can see how that is overkill.  I was unaware that the ‘allotted space an Activity gets’ was around 6MB so that is why my app is running out of memory (basically I was trying to allocated 2 uncompressed images in memory.

The posting on Google gives a solution which I’ve tried.  I haven’t spent any time playing with the calculation but I plan on it as the default sizing loses a lot of the image detail.  I have some wiggle room in there because at any one time I’ll only be using 2 images so I can probably bump up the quality/sizing a bit.

I use Jetbrains IntelliJ Idea at work.  I have for quite a while now.  In the early days they didn’t really exist but since starting college and TurboC I’ve used an IDE.  Since I’m spending my free time learning Android development and I know that Jetbrains have an Android plugin for Idea I figured it would be natural to use IntelliJ.  Unfortunately the plugin for Android is pretty simplistic.  It’s not bad (the recent community beta for Idea is pretty flakey) but it leaves a lot to be desired as filling out the XML files for configuration can be a pain without examples.

I know Google recommends Eclipse so I downloaded it instead and while it’s integration with Android is awesome I find the IDE too cluttered, it does TOO many things.  I never though that I’d say it, but sometimes you can have too much functionality and the user can get confused.  Regularly at work I’ve got into arguments with product managers with my statement  “If the user doesn’t want to use the functionality they’ll just ignore it” but in the case of Eclipse you’re so surrounded by all these features that you can’t really escape it.

I don’t really like how projects are laid out either in Eclipse.  It seems like they try to hide the directory structure/layout of your build process with their “projects” mentality but likely it’s because I’m so used to having my code laid out a different way that it’s just foreign to me.

Either way, learning new stuff is fun but can be frustrating when you just learning to walk and you want to run.