The Amazon Appstore
So a few days ago Amazon opened their own Android Appstore, a direct competitor to Google's Android Market. There are other "app stores" out there, for instance, AppBrain, which has provided a much nicer web experience than the official Market until about two months ago, and SlideME, which is offering more payment method coverage, geographically.
So with Amazon entering the fray, the question is how successful they will be. This isn't just another application distribution channel, run by a small start-up hoping to make their mark. This is Amazon, after all, a company that's streamlined an online market for books and expanded it to cover just about anything these days. Not to mention their cloud services such as EC2 and S3.
For one, Amazon came in with quite a bang, an exclusive release of Angry Bird Rio, the third release in the Angry Birds game series that many "mobile gamers" are so gung-ho about. Not to mention, the Angry Birds Rio release was free, at least for us consumers. I'm speculating that Amazon is absorbing most if not all of the purchase price for each distribution and treats every download as a conversion.
Second, although the game itself is free, one is required to set up payment information (e.g. entering credit card details to be kept on file) before the download is granted. This really is the magic key, as it sets up users to be able to make impulse purchases. After all, it was Amazon who "invented" (or at least patented) the 1-click purchase.
Going forward, it seems that Amazon is offering a "free app of the day" in order to attract new accounts.
But will it work? Are consumers aware that their actual purchases are made against Amazon's Appstore, and that this fosters a dependency on this Appstore instead of the more official (Google) Market? I, for one, think I'll continue to look at the free apps that are being offered, but ultimately, if I wanted to buy an app, I'd want to purchase it through the "more official" Market. Losing access to (in my eyes) a bunch of freebies I've acquired on the Amazon Appstore would be preferable to having to worry about where I bought something and how to get it all back after upgrading to another phone, for instance.
And ultimately, should Amazon decide to enter the Android tablet market, things may become even more interesting. A color version of the Kindle, similar to the Nook Color could run Android, but not include the Google licensed apps (which includes the Market), and in that case, Amazon's devices would solely rely on their own Appstore.
The danger then is the fragmented Android market, and potentially annoying consumers that are trying to get their previously (Google Market) purchased Android phone applications working on their Amazon tablet only running the Appstore.
Purely speculation, of course. But an interesting scenario nonetheless, and not too far fetched as far as I'm concerned.
Print This Post
Quick and dirty sometimes is better
First when I threw together the Metapoly project, I spent some time getting the long-polling AJAX pieces right, followed by quite a bit of Erlang code to get the simulation working. I had lots of io:format() calls dumping out various bits of data. The simulation seemed to work right, but I had to visualize everything in my head, because the missing piece was the client to handle the rendering.
The key component on the server side that lets the browser communicate with the game engine is the client view. Essentially it's a component that represents the client on the server. It keeps track of the client state and marshals messages back and forth.
Communication is done using two types of AJAX calls. One is the listener, and another sends each action performed on the client to the server via a separate call. Keeping them independent was to make each more responsive.
Because I was so eager to get something work and on the screen, the client_view component was just thrown together. There's no hint of OTP anywhere. There's not even really a decent API. Other processes literally just use the bang syntax to send messages, hardcoded in whatever module they originate from.
Right now, though, there's some bug resulting in crash dumps. It takes a while, and lots of traffic, in order for it to occur, but when it does, werl.exe is already using up 900mb+, and the's some kind of heap/stack memory allocation issue in the client_view component. I couldn't find anything obvious in the module, but I thought maybe I screwed up some tail recursion call somewhere. The crash dump mentions something about "old_heap", and googling for more info on it has been fairly fruitless. A few posts mention something vague from folks that write Wings3D plugins. but I couldn't narrow anything down just yet. Either way, I figured I'd rewrite the module. Might as well make it proper, and OTP compliant.
So after a few hours of rigging, and also improving the components behavior, it now doesn't scale anywhere near as well as the previously hacked together one. Fantastic.
Originally, the client_view process, of which there is exactly one per each user "session", would queue up messages from the game world. When a listener (that long-polling AJAX call) finally connected, all the pending messages would get sent. I did want to add in some kind of mechanism to ensure broken connections, however, so that if an AJAX call somehow gets interrupted, the next AJAX call could re-retrieve the same messages again.
I half-implemented this by having the client-side record the timestamp of the most recent message it received, and having it send that timestamp with the next comet request. The idea was to have the client_view use that timestamp to acknowledge the client's receipt and prune all those old messages, and then send any pending new messages. But it turns out that I had never gotten around to adding that logic. Indeed, I was simply sending messages to the listener process, and then no longer tracked the listener as part of the client_view state, knowing that the data would immediately be sent back to the client anyway, and that the listener would go away.
I didn't like that approach, though, because the client_view is making assumptions about the listener. And if the listener was a web socket, the assumption had been incorrect. So instead, I inverted the logic. The client_view keeps sending data to the listener, and the listener itself would notify the client_view that it was going away, and unregistered from the client_view process. This, however, adds overhead. And I also added the ability to have a several listeners registered waiting for messages. This probably also adds overhead, although it shouldn't be that much.
Finally, because I figured that one listener acknowledging receipt of a message doesn't mean another listener (heh, why?!) didn't still need that message. So, I essentially over-engineered this beast a bit. And it's very visible. Although the implementation looks cleaner, the approach isn't as fast. But to some extent it unveils protocol issues that would appear in a somewhat laggy environment. There's no client side interpolation / smoothing of events.
For now the solution is to remove the multiple-listener feature, but ultimately, I think this lays bare some of the client-side tweaks that need to be added before this becomes as smooth as I want it to be in order to work with unknown latencies. Either way, this change is gonna stay in its branch for now.
Print This Post
Proper Twitter Integration with Zend Framework
Twitter is all the rage these days. Every site out there has some kind of "Tweet This" link or "Follow us on Twitter" button. Some sites have even deeper integration and tweet events on your behalf. In most cases, those sites are asking you for your Twitter username and password. What? Even scarier, many people enter their credentials without thinking twice. It's crazy. When has it become acceptable to enter your credentials for your online accounts (that often make you choose six or more character passwords) into some random third party site? Well, the answer, I suppose, is since social networking sites have began asking for email account access to rummage through your contact list. Still, it's a rather unacceptable solution for a self-respecting web site to operate this way, especially since Twitter supports the OAuth protocol which is designed to tackle this exact problem.
If you're familiar with how Flickr allows third-party applications and websites access to your account, then you know how it works. A web site requests access to your account, you are prompted to allow and deny access, and that's it. There are no passwords involved. And if you decide that you don't like what that website is doing with your account, you can revoke access at any time.
I will assume that you're already familiar with the Zend Framework. If that is not the case, and you're a PHP developer, you should really consider starting to use it. It is a very well designed and powerful collection of classes that complement each other and, after the initial ramp up time and learning curve, will pay off in both terms of development speed as well as maintainability. Check out the Quick Start.
In fact, Zend Framework (1.8) ships with a Zend_Service_Twitter class, which provides all the Twitter functionality. The problem is that this class only supports Basic Authentication using your Twitter account username and password. But fear not, we can bend this class to do our bidding.
See, underneath the hood, Zend_Service_Twitter is actually a Zend_Rest_Client, which is powered by Zend_Http_Client. Let's just remember that for now.
Let's take a look at this OAuth thing. Zend Framework has some preliminary support for it in the incubator. The client portion of it is functional, although kind of buggy, still.
The proposal for Zend_Oauth can be found here http://framework.zend.com/wiki/pages/viewpage.action?pageId=37957, complete with a ma.gnolia.com example use case.
Let me summarize how this works real quick:
1. Your configured Zend_Oauth_Consumer fetches a request token, which is used to prompt the user of the service to allow access.
2. Once access is allowed, your application receives an access token.
3. Your can ask the access token object to hand you an http client. It's a Zend_Oauth_Client, which extends Zend_Http_Client, and automagically handles the signing so you can treat it like a regular Zend_Http_Client and perform all the GETS and POSTS you want. Nifty!
Now let's go back to the Zend_Service_Twitter. Remember how it uses a Zend_Http_Client? All we have to do now is remove the basic (username/password) authentication mechanism and replace it with the OAuth-based version. To achieve that, we'll simply extend Zend_Service_Twitter as My_Service_Twitter. and make the following changes:
class My_Service_Twitter extends Zend_Service_Twitter
{
/**
* @var array
*/
protected $_oauthOptions;
/**
* @var Zend_Oauth_Token_Access
*/
protected $_accessToken;
/**
* Initialize Oauth
*/
protected function _init()
{
if (!$this->_authInitialized) {
$client = $this->_accessToken->getHttpClient($this->_oauthOptions);
$client->setHeaders('Accept-Charset', 'ISO-8859-1,utf-8');
self::setHttpClient($client);
$this->_authInitialized = true;
}
$client = self::getHttpClient();
$client->resetParameters();
}
/**
* @param array $oauthOptions
* @return My_Service_Twitter provides fluent interface
*/
public function setOauthOptions(array $oauthOptions)
{
$this->_oauthOptions = $oauthOptions;
return $this;
}
/**
* @return array
*/
public function getOauthOptions()
{
return $this->_oauthOptions;
}
/**
* @param Zend_Oauth_Token_Access $token
* @return My_Service_Twitter provides fluent interface
*/
public function setToken(Zend_Oauth_Token_Access $token)
{
$this->_accessToken = $token;
return $this;
}
/**
* @return Zend_Oauth_Token_Access
*/
public function getToken()
{
return $this->_accessToken;
}
}
And it's ready to be used. Instantiate the class, set the Oauth token via setToken() and then use the class the same way as before.
Print This Post
NBC17 News engages audience with Twitter

Twitter on NBC17
In what may be a TV station's first, NBC17 is using Twitter to gather feedback from the local community in the greater Raleigh, NC area. I was fortunate enough to be included in this experiment, although I was unaware how my tweets were going to be used.
@MyNC, mync.com's twitter presence, asked about pay as you go (PAYG) cellphone plans. Some of @MyNC's Twitter followers responded with their experiences and suggestions. The responses were not just casually included in their report, but specifically called out and highlighted on the air.
All in all, this is a bigger deal than it may seem at first. TV stations are realizing that embracing the near instantaneous interactivity that social media users are enjoying is an important step in preventing their own irrelevancy. By targeting the younger always-online audience and taking advantage of social media tools such as Twitter and Facebook, traditional media is not only proving their ability to adapt to new technologies, but it could very well rekindle interest to watch the evening news in the next generation of viewers wanting to see their own messages featured.
Additional benefits for TV stations to embrace tools such as Twitter, Qik, etc. is the ability to reduce response times to local key events and augmenting their reports in cost effective ways.
Print This Post
Spokeo is kind of Scaryo
Evidently 2008 is the year of the aggregators. They're everywhere. Socialthing, ping.fm, and what have you. But here's one with an immedialy obvious business model. Introducing Spokeo. An aggregator that asks you to provide your AOL, Gmail, Hotmail or Yahoo email credentials (which, in my opinion isn't the safest way to share contacts and I wouldn't divulge that kind of information) to load all your contacts from your address book and then tries to connect all the dots.
Spokeo advertises that individuals who give up their email account credentials can find out "secrets" about their friends. The same information that's available free to individuals (well, subsidized by allowing Spokeo to harvest your contact list) is also sold to anyone who'll pay for it. Specifically, they're targeting HR departments.
Their business model is providing in a way, a social media-based public information "background check" to companies. And that's probably a very appealing thing to Old Economy Mega Bank Corp. which will use this service to see what potential job candidates have been up to on 43 Things, Amazon, Bebo, Blogger, Buzznet, dailymotion, deviantART, Digg, Facebook, Flickr, Flixter, Fotolog, Friendster, Hi5, iLike, imeem, Last.fm, LinkedIn, LiveJournal, Multiply, MySpace, Netlog, Pandora, PhotoBucket, Picasa, PictureTrail, Slide, StumbleUpon, Twitter, Upcoming, Veoh, Vox, Web Results, WebShots, Windows Live Spaces, Wretch, Xanga, Yelp, and YouTube.
So, if work hard and play hard, make sure what happens in Vegas stays in Vegas.
Print This Post
Categories
- Android
- Database
- Development
- Entertainment
- Gaming
- Hardware
- PHP
- Second Life
- Social Web
- Software & Tools
- Uncategorized
- Virtual Worlds
- Zend Framework
Archives
- January 2012
- May 2011
- March 2011
- December 2010
- November 2010
- October 2010
- September 2010
- August 2010
- June 2010
- May 2010
- March 2010
- February 2010
- January 2010
- December 2009
- October 2009
- August 2009
- July 2009
- May 2009
- April 2009
- March 2009
- January 2009
- December 2008
- November 2008
- October 2008
- September 2008
- August 2008
- July 2008
- June 2008
- May 2008
- April 2008
- February 2008
- December 2007
- August 2007
- March 2007
- February 2007
- January 2007
- December 2006
- November 2006
- October 2006
- September 2006
- August 2006
- July 2006
- March 2006
- January 2006
- December 2005
- November 2005
- October 2005
- June 2005
- March 2005
- February 2005
- December 2004
- November 2004
- September 2004
- August 2004
- July 2004
- March 2004