Thought I’d share this. I’m using the CopyPixels ActionScript method to blit images to the screen for animation. In this sample, notice how the CopyPixels method doesn’t update the sprite when the app is pushed into the background. This is unlike some of the device demos where we see movie footage continuing to run when the movie player is pushed into the background. Perhaps the video or media API uses some other method to modify image pixels, or maybe the beta version of the PlayBook simulator doesn’t have that snazzy ability like we’ve seen in the videos of others (Jim B) playing with the PlayBook.
PlayBook Dev – Blitting with Copy Pixels Does Not Draw When App is in Background
November 21st, 2010
View Comments
Quote from H. G. Wells, The Discovery of the Future
November 20th, 2010
View Comments
The following is one of my favorite passages. I first read it in the Help file of a software program by John Walker called Home Planet maybe 15 years ago. John includes it at the end of an incredibly well written article about the Fermi paradox.
And finally there is the reasonable certainty that this sun of ours must some day radiate itself toward extinction; that at least must happen, until some day this earth of ours, tideless and slow moving, will be dead and frozen, and all that has lived upon it will be frozen out and done with. There surely man must end. That of all such nightmares is the most insistently convincing. And yet one doesn’t believe it. At least I do not. And I do not believe in these things because I have come to believe in certain other things—in the coherencey and purpose in the world and in the greatness of human destiny. Worlds may freeze and suns may perish, but there stirs something within us now that can never die again.
We are in the beginning of the greatest change that humanity has ever undergone. There is no shock, no epoch-making incident, but then there is no shock at a cloudy daybreak. At no point can we say, here it commences, now, last minute was night and this is morning. But insensibly we are in the day. What we can see and imagine gives us a measure and gives us faith for what surpasses the imagination.
— H. G. Wells, “The Discovery of the Future,” Nature, 65: 326-331 (1902).
10 Tips for Developing for the BlackBerry PlayBook
November 15th, 2010
View Comments
So it’s been a couple of weeks now since RIM unleashed the PlayBook development SDK and simulator. I thought I’d share some of the things that I’ve experienced – issues, tips, etc in a quick blog post.
- Flex Builder 4.0 isn’t going to cut it. You need to download the 4.1 update in order to avoid a very vague error when trying to deploy to the PlayBook simulator.
- FlexBuilder is absolutely not required to build a PlayBook application. I haven’t been using it. Instead, I’ve turned to trusty Notepad++ on Windows. If you plan on doing the same, make sure to remove the .as extension from the langs.xml file for the haskell language type. Actionscript is already defined as a language with the .as extension, but by default, Notepad++ sets the language type to haskell when the .as extension is used.
- You need the 32bit java runtime installed. If using Windows 7 or Vista, you might have the 64bit version installed. You can have both on your machine at the same time. I downloaded the 32 bit JDK and unzipped it into c:\Java. I then created a shortcut to the command line that also sets the JAVA_HOME path and adds the Playbook SDK bin folder to my PATH environment variable.
- If you’re using the command line tools to build and deploy, you will find that packaging a number of large assets into a bar file will cause an error when deploying the bar file to the PlayBook when using the blackberry-airpackager batch file for install and launch. Instead, break the packaging and deployment into two separate steps. Step 1, package with blackberry-airpackager. Step 2: Use blackberry-deploy to deploy the app to the PlayBook simulator.
- If you’re building and deploying with the command line tools, use Ant. It will make your life a billion times easier by allowing you to bundle your command line arguments into build targets using the exec command. For example:
<target name="build-debug">
<exec executable="amxmlc.bat">
<arg value="-compiler.debug"/>
<arg value="HelloWorld.as"/>
</exec>
</target> - MXML isn’t optimized for the PlayBook yet. Write it all out in action script. ActionScript is a great language anyway (best implementation of ECMAScript in my opinion) and the more you have to write in it, the better programmer you become.
- Many of the PlayBook functions don’t have anything written for them in the QNX API yet. So don’t search too hard online for geolocation methods. I suspect that these hooks will be available in an upcoming SDK package. By the way – RIM is hoping to release an updated SDK at least once per month (according to the first developer webinar).
- I wasn’t able to get the debugger working with an app if it was deployed with the blackberry-deploy tool. This is unfortunate, given point 4 above. However, adl seems to work fine so in theory, you probably don’t even need to test in the PlayBook simulator for the majority of the time. Just use adl and run as if it were a regular Air app.
- Blitting BitmapData objects with CopyPixels is wicked fast for Bitmap based animation.
- There is no way currently to change the opening BlackBerry splash for an app. Ask RIM to change this via the developer forum or via email to pressure them to make this change.
So it’s been a couple of weeks now since RIM unleashed the PlayBook development SDK and simulator. I thought I’d
share some of the things that I’ve experienced – issues, tips, etc in a quick blog post.
1) Flex Builder 4.0 isn’t going to cut it. You need to download the 4.1 update in order to avoid a very vague
error when trying to deploy to the PlayBook simulator.
2) FlexBuilder is absolutely not required to build a PlayBook application. I haven’t been using it. Instead,
I’ve turned to trusty Notepad++ on Windows. If you plan on doing the same, make sure to remove the .as extension
from the langs.xml file for the haskell language type. Actionscript is already defined as a language with the
.as extension, but by default, Notepad++ sets the language type to haskell when the .as extension is used.
3) You need the 32bit java runtime installed. If using Windows 7 or Vista, you might have the 64bit version
installed. You can have both on your machine at the same time. I downloaded the 32 bit JDK and unzipped it into
c:\Java. I then created a shortcut to the command line that also sets the JAVA_HOME path and adds the Playbook
SDK bin folder to my PATH environment variable.
4) If you’re using the command line tools to build and deploy, you will find that packaging a number of large
assets into a bar file will cause an error when deploying the bar file to the PlayBook when using the
blackberry-airpackager batch file for install and launch. Instead, break the packaging and deployment into two
separate steps. Step 1, package with blackberry-airpackager. Step 2: Use blackberry-deploy to deploy the app to
the PlayBook simulator.
5) If you’re building and deploying with the command line tools, use Ant. It will make your life a billion times
easier by allowing you to bundle your command line arguments into build targets using the exec command. For
example:
<target name=”build-debug”>
<exec executable=”amxmlc.bat”>
<arg value=”-compiler.debug”/>
<arg value=”HelloWorld.as”/>
</exec>
</target>
5) MXML isn’t optimized for the PlayBook yet. Write it all out in action script. ActionScript is a great
language anyway (best implementation of ECMAScript in my opinion) and the more you have to write in it, the
better programmer you become.
6) Many of the PlayBook functions don’t have anything written for them in the QNX API yet. So don’t search too
hard online for geolocation methods. I suspect that these hooks will be available in an upcoming SDK package.
By the way – RIM is hoping to release an updated SDK at least once per month (according to the first developer
webinar).
7) I wasn’t able to get the debugger working with an app if it was deployed with the blackberry-deploy tool.
This is unfortunate, given point 4 above. However, adl seems to work fine so in theory, you probably don’t even
need to test in the PlayBook simulator for the majority of the time. Just use adl and run as if it were a
regular Air app.
Blitting BitmapData objects with CopyPixels is wicked fast for Bitmap based animation.
9) There is no way currently to change the opening BlackBerry splash for an app. Ask RIM to change this via the
developer forum or via email to pressure them to make this change.
Free Public Domain Emoticon Set
October 31st, 2010
View Comments
I’m working on a new project that requires a whole bunch of emoticons. I’ve been attempting to create my own set with Inkscape (a fantastic open source Adobe Illustrator alternative). I’ve also decided to release the following emoticon set free to the public domain.
Enjoy!
How to Install the HelloWorld app into the BlackBerry PlayBook Simulator
October 26th, 2010
View Comments
Just a couple of weeks ago, it seemed like the BlackBerry PlayBook was borderline vaporware – with all its glass enclosure protection at press conferences and such. But yesterday RIM unleashed the BlackBerry PlayBook SDK and OS simulator to the public, showing that the PlayBook indeed is not just an mp4 on repeat.
As soon as I got home from the office yesterday, I downloaded the files offered at the BlackBerry developer site and got straight to playing around.
iPhone and Android developers might be a little miffed at first with the PlayBook simulator. It’s not an atomic program like what you have the the iPhone or Android simulators, but comes in the form of an ISO OS install image. Getting the ISO to install on Virtual Box, my first choice, proved difficult. I checked the PlayBook dev forum threads and saw that I wasn’t the only one who ran into issues with Virtual Box. With VMWare, on the other hand, it was simple a simple process of mounting the ISO on a Linux based (Ubuntu) VM with an IDE hard drive (note that it did not install to a SCSI drive – the default hard disk type).
After initially getting it installed, I found that I had to restart the VM a couple of times before it began responding properly. Perhaps it was because I was also running Camtasia in the background, but eventually I was able to click on the various buttons without the OS freezing on me.
I then took a stab at installing the HelloWorld app (that comes with the PlayBook SDK) onto the simulator. I first tried to use the Flash Builder 4 approach to install the app, but ran into some errors doing so. In fact the Flash Builder 4 IDE integration with the SDK seems hit and miss. I then turned to the command line (in Windows) and ran the BlackBerry AIR packager program, pointing to the ip address of the simulator VM as the target device. I rarely get things right the first time, so I was somewhat stunned to find the HelloWorld app install and run without much difficulty.
I captured the whole thing to share the process. This is my first tutorial video in a while, but I expect to make some more for the PlayBook and Adobe AIR. Enjoy.
Google TV in a Family Room Near You
October 15th, 2010
View Comments
Google may have pwned the Search engine market and may be poised to do the same with the mobile OS with Android, but those successes may end up dwarfed by what may come in the form of Google TV. Yes, Google has unwrapped their plans to dominate family rooms across the World. In the near future, the impact may be limited to select countries (certainly the US), but comparing the prevalence and usage rates of television to computers and smartphones, it’s like comparing pumpkins to peanuts.
Statistics show that adults (18 years or older) watch an average of 319 minutes of television per day, according to the Media Comparisons Study 2010 commissioned by the Television Bureau of Advertising [http://bit.ly/bDr5B6]. In comparison, adults spend only 156 minutes on the Internet and far less on mobile devices averaging only 19 minutes of daily use. Despite everything that has been happening since the dawn of the CRT, TV still owns the average human life’s leisure activity. In fact, the television reaches nearly 90% of adults and 80% of the general population around the World every day!
That level of consumer penetration is incredible in its own right, but take into account the fact that 23% of online time is spent simply on Social Networking platforms, dominated by Facebook (at a whopping 85%) [http://bit.ly/9gEiCv]. If certain parts of Facebook were available on Google TV, no doubt that number would drop somewhat. Besides Social Networking, gaming and email contribute the the majority of the rest of the average person’s Internet usage. If Google TV is successful and can pull in players to provide gaming content as well, I think we may see a fairly significant shift away from computer screens, back to the living room and the TV.
Google TV is certainly going to be huge for developers – by being capable to run apps from the Android App Store. Of course, most of the existing apps are geared to mobile handsets and won’t necessarily look pretty in TV format. But consider that developers now have the ability to leverage Google TV and the potential exposure that it will bring. Think outside of the proverbial box. NTN at home anyone? Yule Log screensaver? Twitter TV? Bananas!
If Google is able to get other vendors on board and make Google TV available on televisions and blue ray players like they’ve done with Sony, simply think about what the future holds for Android App Store developers. To any developers who have yet to check out the Android and Chrome platforms, I’d suggest that now would be a good time.
Apple iAd Blows
October 4th, 2010
View Comments
So it’s been a few days since my latest app release that employs iAds. And in short, the earnings on it are absolutely abysmal. Since the release on Thursday, I’ve only seen about 50 cents. I’m fairly disappointed, to say the least.
During the first couple of weeks that Apple’s iAd network was running, there were discussions around how certain individuals were racking up the cash on their iAd apps. I’m becoming more and more convinced that this was only due to the novelty that the iAds were and that as time goes on, those dollar signs will decrease (as I have seen first hand).
I took a look at my analytic reports closely and cannot see how iAds would be at all lucrative. The number of ad impressions that an app shows is a fraction of the number of times that the app sends a request for an ad. In my case it works out to a single ad impression every 5 times someone opens the app. Apple is referring to this as fill rate and I think it is so low only because at the current time only the US and UK are displaying ads. So take this low fill rate (something well under 25%) and then multiply that by an even lower click through rate (something around 10% probably) and that is the probability that someone will click through an ad in your app. And that sucks.
To determine how many ad requests my app would need in order to see earnings of $1 (yes – a buck), I worked out the forumula
Fortunately eCPM is pretty good for the most part. Suppose an eCPM of $25, which is 4 to 5 times higher than my daily average, but is a number that I’ve seen. That means that for every 1000 ad impressions, Apple is estimating that based on the current click through rate and per click bid amount from advertisers, I should get roughly $25.
Using the formula, in order to see a single dollar in iAd revenue, 222 requests would be required! To see $10 then, 2220 people would need to run the app. And so on. To make $10 with a 99 cent app you’d only need roughly 15 people to download it.
Now let’s fast forward a couple of years and assume that Apple has a much larger advertiser base and more countries showing ads, resulting in nearly a 100% fill rate. How many requests would be necessary to see $1 from iAds? Well, with that high $25 eCPM, that would equate to 1000/25 = 40. It still sucks. It would take 40 requests for me to see just a dollar. Assuming that the eCPM will remain high and that you had a 100% fill rate and you were able to get 5000 people to open your app on a daily basis, you could see a daily earnings of $125.
And in a nutshell, I think for the most part, that blows.
