This is a screenshot of the project I’ve been working on since the Android port of Prescriber’s Letter:
The name Retro Radio isn’t set in stone yet, but describes the app well. Retro Radio will simulate the behaviour of a real antique radio. The user will be able to tune the channel dial and will hear the normal sounds of a radio as you move between channels. There will be two kinds of stations placed throughout the dial, music stations that play music from the 1920s and story channels that play old radio shows. The dials are tuned just like a real radio, the user uses two fingers and “pinches” the dial and turns it, this moves the needles and of course changes what the radio plays.
The user will be able to configure how they want the radio to work. They can set it so that shows air at a regularly scheduled time in order to experience the real feeling of being back in time eagerly awaiting the next episode of your favourite show, or they can configure it so that when they tune into a particular show’s channel they’re played the next show they haven’t listened to yet.
I love open source software. I love that there are people out there with such a love of programming that they’re willing to spend countless hours of their own time to build cool things that people find extremely useful on a day to day basis. For iPhone development one of the best open source things around is Cocos2D. Here was a package originally made for Python that riq went and converted to Objective-C and now is used in all kinds of iPhone games, and by me for my current project. When you read the forums you see all kinds of cool stuff happening. The community works together to support each other’s efforts, to further develop the library and quickly fix bugs that come up.
Every now and then you even get to see financial success based around the open source project, whether it’s by supporting users of the software, or building addons to the software. In the case of Cocos2D for iPhone check out Particle Designer by 71 Squared. This thing is amazing. I’ve developed games for 10 years and every game I’ve worked on used particles in one way or another and none of them ever had a programmer with the time to build as nice of a particle design tool as this, and here’s one you can buy for $8 that works with an open source engine. That’s so awesome it blows my mind. I’ll be buying it straight away and putting it to good use.
After checking it out, and messing around some more with an updated ASIHTTPRequest library I’ve decided to use Amazon’s S3 storage service to host the media my new app will stream. This means I need to figure out how to incorporate the costs of bandwidth into the price of the app, as well as ensure that ongoing use of the app doesn’t bankrupt me.
Right now the plan is to charge an upfront fee to the user (the price of the app) which entitles the user to X hours of use. Once the hours run out the user won’t be able to stream anymore media from the S3 service. Then I’ll incorporate in-app purchase which will allow the user to purchase more listening time. I’m worried about the nature of this, I’m scared about the extra barrier this puts on the purchase decision.
Other options would be just to increase the overall price of the app, and then assume that some users will use the app a lot, and some will use it very little. This is a dangerous move I think, users could decide they love the app so much and use it constantly which would kill my profits of course. I also thought about adding ads to the app, but I don’t think that would generate much revenue due to the nature of the app. People will turn it on, tune into a stream and then lock the screen and put their iPhone in their pocket. They’re not going to stare at it and tap ads.
Even if I go with the purchased time approach, I’ve still got the pirates to worry about. Lots to think about with this issue that’s for sure.
Well after lots of trouble with a nasty bunch of issues on one device (the HTC Incredible, which should be called the HTC Incredibly Crappy) Prescriber’s Letter is now up on Android Marketplace.
The HTC Incredible had all kinds of weird issues. When we enabled zoom on all the WebViews that caused the WebView to crash on that device only. We had to check the device model and disable zoom for the Incredible. Then we had all sorts of strange issues with respect to leaving the app (either by the back button or the home button) and then coming back into the app. On every device but the incredible we would get one pattern of resume calls for activities, but on the HTC Incredible it seemed to want to recreate the default activity every time, which sort of left the existing stack of activities orphaned. I had to do a bunch of custom work for the Incredible to work around this.
So, if you’re doing any Android work try to get yourself an HTC Incredible to test with.
My next project will require streaming media which I need to host somewhere. I have a website (stormtapstudios.com) which I’ve paid for unlimited storage/bandwidth, but I’m positive for the amount I pay that bandwidth pipe can’t be all that wide. So I’m currently checking into things like Amazon’s S3 storage service to determine whether I can make it work economics-wise. Essentially what I need to do is estimate the amount of user my app will get by the average user, and then incorporate the bandwidth/storage costs of that use into the price of my app. This will be pretty tricky to do, if I guess wrong then I’ve got an app on the store that costs me money rather than makes me money! Not exactly my goal as a successful entrepreneur. 
Well after completing the Android port for Prescriber’s Letter I’m now pursuing other opportunities for contract work. I’ve been chasing leads here and there, some more promising than others, but the good news is that there does seem to be work out there. It’s interesting, so far every time I’ve finished or come close to finishing a project something has popped up to pursue. The ones I’m after right now are long shots, but that’s ok. It gives me time to focus on my own apps again.
As for which of my numerous ideas that all seem like gold mines to pursue, that’s the tough part isn’t it. Time to do research, figure out which one I can do in the least amount of time with the best guess at chance for reward. I need to approach the next app I make differently, I need to bake in all the tricks for attracting attention to it right from the start (Facebook, Twitter, etc…) and also just take the app development in steps. I’ll build something simple first and get it on the store to test the waters. Then I’ll look into expanding features and beefing it up when I see whether it’s a potential seller. I can’t just put my head in the sand like with Photo Resize and pop up after 3 months only to sell a few copies a week.
I thought I would follow up my post mortem of the iPhone version of Prescriber’s Letter with a discussion about the complexities involved in porting the app to the Android OS. This will be a long blog post, so continue reading only if interested in the technical details involved with Android development.
I’m going to try to make an effort to work outside of the house, just to get out and see other people and environments and prevent the hermit syndrome from sinking in. Luckily Vancouver has a great library downtown with free WiFi and nice seats/tables to work from. Sometimes I’ll go to my wife’s University which also has Internet access and good places to work.
I still prefer working at home, but I think it’s good to get out. For example every time I come downtown lately I see a new skyscraper that wasn’t there before. Vancouver has nowhere to build but up, so that’s understandable, I just thought I came downtown more often than the speed of skyscraper building.
It appears the Tweetable plugin I was using to push notices to my Twitter followers of new blog posts died on its own over the weekend and made it so every page on the blog was coming up blank. Not cool!
Besides putting out blog fires I’ve just finished Milestone 2 for the Android project and I’m moving on to Milestone 3. Milestone 2 taught lots of GUI creation lessons for Android. The lesson being that it takes a LONG time to make GUIs on the Android compared to the iPhone. The one thing I like better on the Android though is that since you’re coding the GUI by hand with XML you’re already thinking of screen “scalability”, i.e. you’re already factoring in different resolutions and orientations. I’ve had rotating the app working since day one. So far on my iPhone projects multiple orientations have been afterthoughts (even though they shouldn’t be).
I found this handy post to the Android developer’s group, which explained how to get the equivalent behaviour to Apple’s flexible spacer views on toolbars.
The implementation in a layout XML file looks like this:
<LinearLayout android:id="@+id/ToolBar" android:orientation="horizontal" android:layout_width="fill_parent" android:layout_height="wrap_content"> <View android:layout_width="0px" android:layout_weight="1" android:visibility="invisible"/> <Button android:layout_height="wrap_content" android:layout_width="wrap_content" android:background="@drawable/homebuttonselector" android:id="@+id/HomeButton"/> <View android:layout_width="0px" android:layout_weight="1" android:visibility="invisible"/> <Button android:layout_height="wrap_content" android:layout_width="wrap_content" android:background="@drawable/nextbuttonselector" android:id="@+id/NextButton"/> <View android:layout_width="0px" android:layout_weight="1" android:visibility="invisible"/> </LinearLayout>
Note the use of the layout_weight property for the hidden views. This tells the layout code to take whatever space is leftover from the non-weighted views (the two buttons) and divide it evenly amongst all the other views set to a weight of 1. You could play with this to do other goofy layouts as well. This is much handier than using padding, or even relative layouts to achieve the same effect because it allows you to leave the calculations up to the layout code rather than you figuring out at runtime what the padding should be. Especially if you’re adding/removing views depending on context.
UPDATE:
After playing with this a little more I actually went with this solution, which makes it even easier to programmatically show/hide the buttons.
<LinearLayout android:id="@+id/ToolBar" android:orientation="horizontal" android:layout_width="fill_parent" android:layout_height="wrap_content"> <RelativeLayout android:id="@+id/Button1Layout" android:layout_height="wrap_content" android:layout_width="wrap_content" android:layout_weight="1"> <Button android:layout_height="wrap_content" android:layout_width="wrap_content" android:background="@drawable/button1selector" android:id="@+id/Button1" android:layout_centerHorizontal="true"/> </RelativeLayout> <RelativeLayout android:id="@+id/Button2Layout" android:layout_height="wrap_content" android:layout_width="wrap_content" android:layout_weight="1"> <Button android:layout_height="wrap_content" android:layout_width="wrap_content" android:background="@drawable/button2selector" android:id="@+id/Button2" android:layout_centerHorizontal="true"/> </RelativeLayout> </LinearLayout>
With this version to show/hide buttons all you have to do is set the visibility for the layout group the button resides in to Visibility.GONE or Visibility.VISIBLE. You don’t have to worry about having the proper arrangement of empty views to the left and right of the button.
