Developing for Android and Windows Phone 7
I spent a few (no more than 2) hours on developing for Android, and the better half of a day building for Windows Phone 7 / Silverlight, mostly because I wanted to learn enough to understand the development model of both platforms, and compare said models to iOS's.
I went through Android source code when it was released ( spending most time on the 'Skia' 2d drawing component ) and figured out through the basic concepts. Its been a long time since then.
I was drawn to Windows Phone 7 because I really like the UI. Its clean, simple and elegant. Its also fresh and unlike iPhone's UI(everyone is copying Apple, left and right, as it has always been the case). When Silverlight was announced, I looked into it but was put off by the use of XAML files and some weird naming decisions in the classes tree. Other than building a trivial 'lets see what this is all about' application, I didn't spend more time on it.
As expected, Android and WP7/Silverlight also adopt the familiar views/controls paradigm. On Android, you got tasks (processes) and each holds a stack of Activities; an activity is more or less a page, that holds a content view. That content view is usually a container view that contains other views. Activities do not need to come from the task that owns the activities stack. They are popped out in a LIFO fashion, and its alls simple and nice. You also get services ( really, tasks with no front-facing UI, which are cool ), intents ( effectively, messages with action and payloads ) and other niceties.
It all more or less make sense - the one thing I don't like about Android is the UI of the controls. Everything is ugly. The emulator is also slow and, well, ugly, which makes things even worse than they probably are. Google is no Apple, sure, but they should have done something about it. It all reminds me of those Java Swing components (or even worse, AWT components used in Java Applets when applets were cool - which is a long, long time ago ). You get to use Java to build the applications. I am not fond of Java, but I don't really mind it ( a bit too high level for my taste, among other things). You also get to use Eclipse ( which makes it really easy to build stuff, with intellisense, on-the-fly compilation and all those nice things people expect nowadays from IDEs ), or use any other IDE or just use the tools on the terminal , if you don't like IDEs or for whatever other reason. That's what I did. The tools are easy to use and it takes very little amount of time to feel comfortable enough with the environment.
I spent an hour or so trying to find my way around Windows Phone 7 Silverlight concepts and paradigms. Those XAML files, that I hated on SL back in the day, were still here and I just didn't want to deal with them. It turns out, that unlike what the documentation may make you believe, you don't need to use them. You can delete them and do everything programmatically ( though its not straight forward, but it make sense once you do it once or twice ).
You need to decide if you want to build a Silverlight application, or an XNA application. If you want to build 'high performance' games, you need to build an XNA app. Otherwise you will want to build a Silverlight app. They are concepts and classes that are unique to each approach and it just doesn't feel right, having to restrict yourself to either of those as opposed to building an application that can access all facilities offered by the device. You are going to use C# to build Windows Phone 7 applications. C# is nice. Java on steroids. Visual Studio 2010 Express for Windows Phone is a free download from Microsoft, providing everything you need to build your applications.
So, you got your Application instance ( every WP7 application needs a class that derive from System.Windows.Application ). Every application instance has a RootVisual property. Its the main application UI ( a System.Windows.UIElement derived class instance ). The convention/requirement on Windows Phone is to have a special class instance set to RootView(PhoneApplicationFrame) and that should hold a PhoneApplicationPage derived class instance ). That page in turn holds a Content - which is the content view, etc. Similar concept to Android's activities and their content view, and iOS's Windows, Navigation controllers and their views. Again, simple stuff - just make sure you stay away from XAML documents.
By the way, there is no support for multitasking on Windows Phone 7, unlike Android and iOS. There is no supports for sockets, either, which is weird and rather sad ( Access over HTTP and 'web services' is not good enough ). Hopefully, this will change soon.
I am going to build a 'real' application for Windows Phone 7 in whatever spare time I have this week and submit it on their Market Place. It should be fun; if nothing else I will should learn enough to help our Mobile Unit folks at work with upcoming Windows Phone 7 projects.
Sunday, 17 October 2010 1:10 am
mySQL, noSQL, and Key Value datastores
Monolithic RDBMs are losing ground to key-value data stores, particularly persistent distributed in nature. mySQL mounting problems was perhaps the key reason (pun intended) people looked elsewhere. Google's brilliant engineers realized that a key/value data model can satisfy the needs of almost every class of application that needs a datastore backend.
Key/value datastores are simple to build, easy to understand, easy to optimize, easy to scale. The, now famous, CAP theorem states that it is not practically possible to guarantee consistency, availability and partitioning resilience/tolerance all at the same time; one of those traits has to be sacrificed. Again, most applications really do not require all three to function. The CAP theorem is most likely derived from the Project Triangle mode.
Most web-based applications are built on simple data models. Most web-applications eventually suffer from service capacity and availability issues(i.e scalability woes). It is trivial to scale out(vertically) application logic processing(application servers), HTTP requests processing(web servers, load balancers).
It is not easy to scale out an RDBMS. Some expensive systems(Oracle, etc) provide ways to address those issues (e.g Oracle RAC) but its expensive to deploy them, and most of them rely on a shared everything setup which just doesn't work in the long run. (Shared nothing is really the way to go).
Google released a bunch of papers ( actually, a bazillion of papers ), many of them defining and shaping the development of future related technologies. Namely, the papers describing GFS, BigTable, MapReduce (and of course, the paper the changed everything, "The Anatomy of a Large-Scale Hypertextual Web Search Engine" ) steered everyone to the right direction.
In the datastores domain, Hadoop/HBase, Radix, Cassandra and others, based on BigTable and Amazon's Dynamo papers, all relying on the simple key/value datastore model, are gaining market share - rightly so. Coupled with Memmache and similar services(in-memory key/value stores) they are solving the problems of service capacity and availability. This is a paradigm shift. Its a downhill for heavy-footprint, complex and inflexible datastore systems. They wont go away but will not be such a valuable(pun intended) component in tomorrow's technology landscape.
We are going to gradually migrate from RDBMs - though, we are not relying that much on them nowadays - to a key/value datastore (we are currently building one, also based on BigTable and Dynamo ). If nothing else, those simple systems are both simple and beautiful (for the most part).
Saturday, 13 March 2010 8:14 pm
New Theme, iPhone, Google AppEngine
My brother provided me with a theme for my blog. Its pretty clean and simple - yet not a simple or clean as I would have wanted it to be, but that's entirely my fault. Its a matter of modifying the structure of the various elements and using font families and colors that make sense.
I purchased two iPhones from Las Vegas ( Thank you for the invitation Patrick ). I used to dislike cell phones with a passion. Especially those engineered by Nokia. Complicated for no reason, cumbersome to use, fancy for the sake of being fancy and loaded with a gazillion crappy applications and 'services'. The only cell phone I actually liked was the original Nokia phone ( short-lived moment of glory for them ) used in the Matrix 1 movie. So, naturally, my expectations were rather low when it came to putting the iPhone to the test.
"The iPhone is a revolutionary mobile phone". It actually is. Everything just works, supported by an ultra sleek UI, robust facilities and solid design decisions. It is by far the best mobile device I ever used, far surpassing any expectations I may have had.
Amazon kick-started the cloud computing era by introducing an ever expanding array of facilities and services, from S3 to EC2, to SimpleDB. Microsoft is entering the game with SSDS. Google made available a dozen APIs and WebService as a means to interfacing with their core services but everyone knew Google would come after Amazon and co, big time. It did. What is perhaps the most important benefit and side-effect of the availability of such a platform is that the everyone can build any web application without having to shelling out for the kind of resources that would have made this application possible. The AppEngine service is going to provide everyone with free access to resources and documentation - all one would need to do is signup with them, build the application on his computer using the provided SDK and then push it back to the cloud. Once the application gets successful (say, 4-5 million page views / month ) that said developer would pay Google for access to more resources. Everyone wins.
I am looking forward to similar offerings from IBM and Sun. For those who are into buzzwords, Web3.0 is here.
Tuesday, 8 April 2008 10:08 pm
