There is a big problem in the App Ecosystem

Hola, Namaste, Hello! Mobile Apps

Previously there were different Operating Systems, then came different browsers and now we different application development ecosystems, and just looking at the mobile ecosystem, we can see that there is so much difference among the different service providers, OEM manufacturers and merely the smartphone itself.  In the mobile space, there is the iOS platform, the Android platform and the recently released and hopefully catching up Windows Phone OS. Take a look at the difference in the foursquare application on the different platforms.
The Foursquare Mobile application on the iOS platform
The Android Platform running the Foursquare application (notice the tabs on the top as compared to the iOS's at the bottom)

The Windows Phone Ecosystem presents a completely different application ecosystem.

What it means

Now each platform promises a different approach to building applications, the iOS has tabs, navigation bars etc. while the windows phone os has panorama and pivot based applications. These are not just different looking but completely different in the way of the functionality as well. Since of course the user only cares about the application experience, the underlying layer of functionality might not be visible to him/her. This is because once you get too acquainted to a system of doing things on your smart phone or mobile device, you just get it. It's about learning a new language, you don't have to figure out the syntax and semantics of the language when you become fluent in it. Thus, any significant deviation from a particular convention of  display on a particular device will cause issues with the set of users on that particular device, they would either need to get familiar to the application design or completely settle for another similar cloned app because it just looks good.

For developers this means writing apps in multiple platforms and multiple languages. There are various frameworks available to speed up the process and of course regular debates about whether HTML5 is the new standard or whether one should switch to a native way of writing code for a platform application. Although I am not really interested in the debate part, I am definitely interested in the different mergers and fusions this is bringing about. One of them is Parse which is trying to change the face of mobile development by taking care of the backend for the apps. The biggest challenge to adopting such a development strategy is that it is very good for small apps, apps like instagrm where the functionality is less and all the app does is data transfer to and fro, very few relationship management on the server side among the data objects. For bigger applications and more complicated ones, I am not sure if Parse can be put to test. Another is Titanium, which uses HTML5, CSS and Javascript to structure the application. However with Titanium you get a CSS feel and the application feels like a mobile clone of a website and deviates miles away from any of the platform guides on user experience like Apple's or Microsoft's. Same is the case with Phonegap or Apache Cordova (As it is called now) or Jquery Mobile or Adobe's new Flex technology. 

The problem remains the same, one cannot get a native feel with using technologies like CSS, HTML and javascript.

What should be done

I think before thinking about what should be done, one needs to realize that there is a problem. We can agree that maintaining multiple application platforms is a pain, while people (Mac users and Windows users) love the Office 13 preview released recently they cannot help blame Microsoft for not updating the Mac application at the same time as the Windows application. And the mobile application ecosystem is exploding as we speak. Android is pushing interface changes regularly while Apple is staying the same with more features and shortcuts being added with each version of iOS. Microsoft is the new player with it's new Metro design philosophy. We can agree that not one of these players is going to completely dominate the market. 

In my my opinion there needs to be evolution in the form of an abstraction, which separates the templating engine from the logic code. This would mean that the logic code consisting of core libraries, networks, login support, offline processing, notification management etc. can be shared between the different platforms, while another set of code and libraries do the rendering based on the different type of device platforms they encounter. It can look radically different, but at least since the core libraries are shared, the functionality can be made available to different platforms. It just needs to be written, accessed anywhere. Much akin to Java byte code philosophy. Let's say you come up with a new feature of tagging comments and putting them into a stack organized by good, bad tags etc. So you can abstract out that feature and put it in a core library. That way, a Windows Phone OS developer does not need to worry about that feature having bugs. All he needs to do is make sure the view code calls the library with the appropriate parameters.

Where does this leads to?

Ideally I would like to see a mixture of Adobe Flex and Parse. Flex allows developers to share code between different device platforms and that is something that really cuts the work of developers try to hunt for a bug which might be caused by the platform itself. Parse can do the shared code part very effectively although I am a bit skeptical the limit to which Parse can be stretched. Still the common code part (Network Management, Login Support etc.) is pretty cool and cuts down the boiler plate code a person needs to write for different devices.

Write Once, Access Anywhere. Any takers?





Software philosophy is important than the Software itself

Today was a very special day. We had Kosuke Kawaguchi coming to our office in Akasaka, Tokyo and telling us about how to develop plug-ins for the Jenkins continuous integration system. At first I thought it would be a challenge because I did not know Jenkins from before and I thought that maybe I can't develop the plug. 2 hours later I had understood the philosophy behind Jenkins. It followed a plugin-architecture much like that of eclipse and had a couple of hundreds of Abstract classes that were fairly easy to implement and thus allowed the code to extend the functionalities. More importantly, the thing to "get" was how Jenkins was structured in a fairly straight forward interface-defined manner. In about 3-4 hours I had covered the gap from being a "n00b" to a person with a fair bit of understanding of the underlying core technologies in place. That said, I am very much impressed with the ease one can implement the plugins. No wonder there are so many plugins already on the jenkins hosted server.

Anyways, this episode taught me something. That software philosophy is much greater than the software itself. If you can connect a lot of people using using the philosophy then maybe you have a better job of reaching out to them and telling them hey this can be done this way because of something. I think philosophy has a much greater role in determining the future of software because software is not just stagnant it evolves over time and thus it needs to be backed up by philosophy. When we have that kind of a philosophy, I am sure that people will understand how to use it. That is what I am saying now this is because some of the software just pops up and then it vanishes we do not even know why they manage to live such a short life. I think it is because they do not have a philosophy associated with them and philosophies are closely related to architecture of the platform or the software in question. It may be motivated by the architecture and not completely denote the functionality of the architecture itself. And I guess plugin-based architectures are so much overlooked but they offer the most sophisticated features and customizations. People like to extend these softwares because they come with bare minimum functionality built within them but plenty of extension points to start from and start forking/pulling/merging.

This is what in my opinion moves things forward: a software philosophy more than anything else.





Sample usage of uploader.js

In my previous post you saw how I wrote an uploader.js library for managing uploads to imgur.

Now the question is how to use it.

Here is a sample source code from a phonegap+jquery page.

The uploading happens in 2 steps. First, we choose the photo from the photolibrary. uploader.js sets up a callback_func to be invoked whenever the photo gets selected, it returns a 64 bit encoded string of the image. The function on the html side then sets up another function that take cares of the uploading process, setting up a second callback which takes care of any errors that might be raised. Thus it sort of sets up a nested callback.

Sample source code:


Phonegap + Imgur Uploader

One of the stuffs I recently did was to use the Phonegap API and Imgur API to do image uploading.

Source Code


Java Web App development using Spring Roo

Enough has been said about Java and how the Java EE 6 specification has caused the process of making web applications in Java slow and painful. True with Java the problem is of comprehensibility and integration of the different components. On top of that you have a number of things such as patterns, JPA and the web front end files. All of this come with different kind of frameworks to ease up development, for example the JPA object relational mapping can be solved by using Hibernate. However there was no meta framework, something unheard of in the Java web application development world. A framework to manage the frameworks ? Hmm, very strange indeed.

Spring Roo solves all of that by providing a nifty overlaying architecture that just does one thing - integrating the different patterns and best practices and different providers/frameworks to do that. It keeps you focused on the logic and thats what is more important.


Not being able to change

One of the things I seriously hate while doing work is to be able to look back and say that things could have been different but I did not put the required effort to get the job done. Completion of software projects is as much about planning as it is about being able to put the required amount of effort into it. The thing is that anyone can do anything technically, but it is the things that we actually do, matter the most and are the ones seen by the world. So yeah, while the world is harping on being agile and doings things fast, one step at a time, I think that doing them and not leaving them for later is a bigger game changer. No matter how agile we can be, there are things which should be done at an early stage of the project and cant be left for later. There is no guide which can tell which decisions fall under these categories, it's an individual's job and an individual regret that lives on with him/her later for the rest of the project cycle. We all wish for things to happen, but we can't just hope for them to happen, we have to satisfy the necessary preconditions in order to get the job done.


Restkit + iOS (#1)

I commenced on making an iPad at the start of the semester and by and large towards the end I have learnt so many concepts. I am going to detail out solutions, some common ones, found out from the web or forums or just pure ingenuity.
I am not a big iOS coder, I am more familiar with javascript, java, python and C. But then again its the same MVC principle all over again. Although, the standard way of doing some things in XCode would be to use protocols, I don’t usually find myself very familiar with these constructs. So here are my solutions/tips.
Troll No 1:

Problem
You have 2 view controllers, master and detail, you want to load something (a GET request) to your detail panel (which is a hierarchy of navigation controllers). You can do it via a GET request in the root view controller of the navigation controller in the detail panel but you want to do it via the master view controller since it is at a higher level.
Solution
here’s how I did it.
NavigationController has a property called viewControllers which stores the stack of view controllers. The first one is the controller you wish to invoke as delegate. All you need to do is this:

UINavigationController* v1 = [self.splitViewController.viewControllers objectAtIndex:1];
[[RKClient sharedClient] get:@"/hello" delegate:[v1.viewControllers objectAtIndex:0]];

All you need to is make a get request via the RKClient and pass the delegate to be the first view controller in the navigation stack.
Its not clean, but does the job :-)