Programming


UNIX Fragmentation 2.0: Android

First of all, let me introduce you briefly to the UNIX fragmentation: Before Linux was around (1991 Linus released the version 0.01 of the Linux kernel) there was a huge problem on the UNIX-based operating systems, since they were all proprietary and each OEM had their own version of the OS. It was common that some softwares would not be able to run on all the UNIX variations which caused a lot of trouble at the time since if you were a company buying computers you had to know if the computer you were buying was compatible with the software you had to run. You can read more about the history of UNIX if you want. I’ve learned about the history of Linux and the open source movement from two books: Just for Fun and Rebel Code.

Now, if you look carefully and you’ll notice that the same is happening with Android, maybe less intensive since software may run on different “distributions of Android” (aka different Android versions made for a particular device) but it’s happening. In this article I’ll be talking about this new era of UNIX/Linux fragmentation in two main areas: UI fragmentation (skins), version fragmentation (OEMs holding the source code) and how Google doesn’t care about their app developers.

UI Fragmentation

One of the most visible fragmentation issues of Android is the UI fragmentation. OEMs are (still) thinking that Android is just the smartphone version of the old Java ME-based OS they used on their feature phones. They are skinning Android just like they skinned their feature phone OS.

These skins are creating a huge issue among consumers because since they are not geeks, like us, they think that Android is something like a platform that manufactures use to run smartphone apps, most of them don’t even know its built by Google. These customers also get a little confused when they switch to a newer smartphone, from a different OEM, and the skin of the OS is completely different from the one they were previously used to.

Skins are terrible for the Android ecosystem, but most of them added some really great features, for example the “slide to call/text” from TouchWiz. These improvements to Android UX in my opinion shouldn’t be embedded into these crap bloatwares, but instead should be pushed to Android’s tree (remember the Open Handset Alliance?) to be used on all Android-based devices since they’ll improve the end user experience with the OS.

Version Fragmentation

I don’t know which one is worst: UI fragmentation or version fragmentation, but I think it’s more likely to be the version one.

This problem is completely Google’s fault, even Google itself had problems with Android’s version fragmentation: Google Chrome for Android only runs on Android 4.0+.

Time passed and Google hasn’t come with any solution to Android’s biggest issue, and they know that the only way to correct this is by making pressure on OEMs to only announce new devices if they are running the latest version, and impose tight timelines to update all the older devices that are capable of running the stock version of the latest major release if they want to continue having access to Google Play on their phones. Don’t come to me saying that there is also the carrier problem because there isn’t any carrier problem, Apple updates their devices to the latest version from day one. You know why this is possible? Simple: Apple told the carriers to fuck off. They imposed to the carriers that their OS shouldn’t be bloated, so carriers couldn’t include their crapware with it. As I said previously: Pure stock crapwareless Android is always the solution.

Version fragmentation is extremely frustrating since all those awesome features (and UI) that Ice Cream Sandwich and Jelly Bean have are currently available (stock experience) in one single mass-market device: The Galaxy Nexus.

This is a very serious issue on Android because its making app developers stuck with their innovations, which doesn’t happen on the iOS side. Everyday we see awesome iOS apps, with innovations in UI and UX, getting released for iOS, but we don’t see the same happening with Android mostly for one reason: Developers need to make their app compatible with older Android versions.

Developer Relations

Google doesn’t care about app developers. A great example is how we don’t see a lot of official Android developer evangelists around the internet, another example is how there is only one language you can use to develop you apps: Java. HTML5 is the future of mobile, and desktop, applications and Google is just ignoring this. Developing a PhoneGap app for BlackBerry or iOS is great and you don’t have serious problems like CSS properties or drafts that weren’t implemented, but on Android this is completely different, the terrible CSS3/Javascript animation rendering issue that is still open and yet not addressed.

The only company that I see that is doing a great job on this area is RIM. They care about their app developers because they know that users want not just awesome smartphones, but awesome smartphones with a lot of awesome apps they can download. A great example of this is how they support natively Java, Flex/Flash, HTML5 and C/C++. They even created a awesome mobile UI/UX framework for HTML5 apps called bbUI.js.

Conclusion

Everyday Android feels a lot more like vaporware for me. I’ve stopped using my Android phones on a daily basis and I don’t think I’ll ever start using them daily again. I’ve stopped developing for Android and now I’m almost fully committed to the platform I’m loving most, and felling more comfortable, to develop to: BlackBerry.


Using bbUI’s onscreenready and ondomready to Dynamically Change Your HTML

I started playing a bit with BlackBerry development these days and since I’m not the best at Java (also hate how it’s difficult to do simple things with it) I choose their awesome framework for HTML5 native web development called WebWorks. I really loved it because it’s like PhoneGap, but a lot easier to build plugins (extensions on WebWorks) for it to make your native WebApp feel a lot more native.

Another great thing that RIM did to make the life of WebWorks developers easier and create apps that are exactly like native ones is a Javascript framework called bbUI.js, which is like jQuery Mobile, but seriously, it’s a lot more than just a UI framework. It makes it a lot easier to interact with the OS, override the back button for example, and makes your development cycle look a lot with native development by using screens. On this post I’ll teach you how to dynamically manipulate the screen’s HTML before it’s processed by the bbUI library.

One of the first things that you’ll notice after you start working with bbUI is that it’s not just a collection Javascript functions and CSS stylings, it actually reformat and customize your screen’s HTML before it’s shown to the user. As an example, this simple image-list item declaration in your screen HTML source looks like this:

After it’s processed by the library and shown to the user it will look like this:

Hopefully we can easily manipulate our screen elements and other things before and after it’s processed by bbUI. This is done with the bb.init() function (you can always read more at their documentation). This will be called when the application starts and can be used to listen to events like when a screen is loaded. The main ones are onscreenready and ondomready.

onscreenready: This event will be fired before the sources get processed by the library, so here is where you should manipulate, add or remove things from your HTML source using Javascript, so after it’s done the code will be passed to bbUI to be processed.

ondomready: This event will be fired when the screen finished loading and it has been already processed by bbUI and shown to the user. Here you can put things like alerts and other things that will be used to interact with the user, also some little editing to the screen’s source like renaming a field grabbing some information from a field and etc.

Here is a example of a bb.init() call:

bb.init({
  onscreenready: function (element, id) {
    if (id == "main") {
      // code to be executed before the "main" screen is loaded.
    } else if (id == "add") {
      // code to be executed before the "add" screen is loaded.
    }
  },
  ondomready: function (element, id) {
    if (id == "main") {
      // code to be executed after the "main" screen is loaded.
    } else if (id == "add") {
      // code to be executed after the "add" screen is loaded.
    }
  }
});

The code is almost self-explanatory. The id is the name, second argument, you gave to a screen when you call it to be processed, for example bb.pushScreen(“screen/main.html”, “main”). And element is the screen source code, which is used to be manipulated before the screen is loaded.

A little problem that some developers might come across while using bbUI for the first time is that when you want to append or change the HTML of the screen before it’s processed by bbUI you might write your code like if the HTML was already loaded onto the screen, but it’s not. Here is an example of a code that won’t work, used to populate a image-list and then show a button that was hidden (using jQuery):

bb.init({
  onscreenready: function (element, id) {
    if (id == "main") {
      var item = document.createElement('div');
      item.setAttribute('data-bb-type','item');
      item.setAttribute('data-bb-title','my title');
      item.innerHTML = 'my description';
      item.setAttribute('data-bb-img','foo.png');

      document.getElementById('mylist').appendItem(item);

      $("#button").css("display", "block");
    }
  }
});

The main problem here is that it’s using document as the source to be manipulated. Since bbUI still hasn’t appended the screen into the document it will give you an error. In order to correct this you should replace document with element, that is passed by the onscreenready event. If you have any jQuery code, just add element as a context argument as shown below in the corrected code:

bb.init({
  onscreenready: function (element, id) {
    if (id == "main") {
      var item = element.createElement('div');
      item.setAttribute('data-bb-type','item');
      item.setAttribute('data-bb-title','my title');
      item.innerHTML = 'my description';
      item.setAttribute('data-bb-img','foo.png');

      element.getElementById('mylist').appendItem(item);

      $("#button", element).css("display", "block");
    }
  }
});

That’s it! Now you know how to use the onscreenready and ondomready events to dynamically insert or modify your bbUI screen’s. Any questions or suggestions just leave a comment and I’ll reply as soon as possible.


Why You Should Start Dart’ing Right Now

With this article I hope you understand more about the Dart idea and how you can become more productive and happier as a developer of web applications by using it as your main language.

First of all here are some words, from the official site, for you to understand what Dart is:

With the Dart platform, you can write code that runs on servers and in modern web browsers. Dart compiles to JavaScript, so your Dart web apps will work in multiple browsers (not just ours).

The Dart platform includes a language, libraries, an editor, a virtual machine (VM) for both servers and browsers, and a compiler to JavaScript.

The Community is Awesome
One of the biggest advantages of Dart is the vibrating community. Since it’s still under development the developer base is very helpful and shareful too. If you’re on Google+ you’ll know almost every new project that is done using Dart, this way you have more attention on your project.

Libraries are Needed
Because it’s on it’s early stages Dart needs libraries to fulfill developers, this way you have a lot of libraries you can create, from scratch or porting from Javascript. This way you’ll be learning more, helping the community and earning respect from the community.

It’s Incredibly Easy to Create Web Applications
Since it was built by Google for web applications from scratch, it’s the perfect language for web application development. You’re not having to adapt a old language for the web revolution, you’re using a language that was built for the web revolution.

Weekly Updates
The language is under active development. Almost every single week a new build of the language, or the tools (Dart Editor and Dartium), is released. This way you can feel something that any other language can provide you today, the feel that it’s mutable and is evolving. It’s awesome when I open my Google Reader application and there is a new update on the Dart feed. I quickly download and test what’s new.

Organized Syntax
As a node.js developer I know that as you dive deeply into a complex part of your web application the code becomes a hell to understand. With the Dart syntax this is a bit more difficult, your code becomes more readable and a lot more maintainable. Also the Dart team published an awesome style guide to make your code even better for your eyes and brain.

Easy to Learn
Dart is incredibly easy to learn. There are three ways of learning Dart. If you’re already a Javascript you can learn by reading the awesome Translations from Javascript table which will show everything you must know about Dart comparing to Javascript. The second way of learning is by reading their lengthy Language Tour which will give you an in-depth look at every single aspect of the language. The third way is to learn by practicing and looking at the previous links when you don’t know how to do something or the compiler is giving you a strange error.

Those, in my opinion, are some of the key features of the awesome Dart language. I hope you give it a try and have lots of fun with it. Don’t forget to comment about your experience with Dart and your opinion about it.


We Are Living The $0.99 Application Era

I can still remember like it was yesterday, a time where paid applications never would cost less than $10. Today I can get on the App Store or the Play Store and download an fairly powerful app for no more than $3.99, but even at this prices I think twice before buying it. The App Store effect, as I like to call it, made the app consumer not want to pay more than $0.99 for a decent app, even if it’s just $1.99 it might hesitate buying it.

I would comfortably pay more than $3.99 for a extremely well done, powerful and useful app. The problem is that those kind of applications aren’t very common, but they are an expressive number, but I’m not here to talk about the apps that deserve this price tag, this article is about apps that aren’t deserving their price tag.

In my opinion the best way to actually charge for an app is by using the freemium model, that’s why Paper was such a success, you get the app for free and test it, if you like/need more features, in this case tools, you pay for them using in-app purchases, and if you want to unlock all the potential of the app you pay a discounted price for all the tools. This way the user can feel the app before buying it, which makes me hesitate when I need to buy the app without a way of testing it first.

On this model I’ll start with an Android app called Flick Notes, if you’re a heavily SimpleNote user like me you might know this app. It’s an awesome clean and simple app, the problem is that in order to unlock all the (missing) features of the app: Note and notes list widgets, To-Do list style notes, and remove ads, you must pay a extremely expensive CA$4.99 fee. I think this is to much expensive just to get rid of ads, enable to-do lists, and have the widget of the app. I would comfortably pay $1.99 for those features, and I’m sure the developer would earn a lot more money since a lot more people would buy the full version.

Another example of this, now on the desktop side, is a awesome new app for SimpleNote users that have a Mac OS computer, called MetaNota. It’s a free, ad-supported app, but it’s possible to remove it by paying a $9.99 fee, yeah that’s just to remove the ad.

These are just some small examples of what I’m talking about. If you’re a developer that is planing to monetize your app in some way I suggest you to do the freemium way, but don’t forget: We are living the $0.99 era!


The Raspberry Pi Will Bring Fun To Computers Again

I was browsing the Raspberry Pi forums these days and I came across a very interesting thread titled PC’s Are Boring. I read all the posts until that moment and started reflecting about that statement. The thread starter was completely right about this, PC’s (which I understand for computers that run Windows or Linux, excluding Macs) are really boring, that’s why the mobile industry is so amazing these days, because people stopped changing their computers every ½ years and started changing their mobiles.

A lot of the users on the forum were talking about “the old times” of the Commodore and Atari when you felt like you had power over the machine and today you’re just part of a mainstream movement. Also they were talking about how “normal people” are discouraged to program because are afraid they can break the computer (which isn’t true of course, but that’s what the average user thinks) and how the price of the Raspberry Pi could help people to get into Linux or programming. They are completely right, as soon as the Pi comes out a lot of programmers are going to rush to get their hands on one (I am very excited to get my hands on one too) and possibly a lot of people that want to start programming will get it too.

The RPi will make the feeling of having power over the machine come back again. The best example I can give is my own. I’ve never been so excited for a “computer” since the first dual cores came out, I’m thinking about the awesome things that I could do with it like: Making my own Linux-powered tablet (which is completely possible), porting new Linux distros to it, porting other OSes to it and even making my own distro only for the Raspberry Pi.

I’m sure all the geeks are very excited waiting for the release and wondering all they could do as soon as they get their hands on it. Leave a comment below with your opinion or ideas. If you want to keep in touch to the latest news about the board just visit their blog and don’t forget to contribute on the forums.


Microsoft Finally Saw Where The Developers are Going

Today I revived my hope on Microsoft as I received the news that they released their brand new “product” for their fellow developers. The release I am talking about is the official Metro theme for jQuery Mobile. The awesome mobile framework finally got some Microsoft love.

In December of last year I got a new device to develop for, a HTC Titan, running the latest Windows Phone 7.5 Mango build. I loved the OS UI and how the applications were information-centric and not just eye-candy, but there was one problem, the same way C# is a incredible language for a lot of things, it’s parsing functions, for JSON specifically, are very difficult to learn and the articles about it were made for senior C# developers, which makes it difficult for beginners like me to understand them, at least I now can develop using the technology I love most for mobile development: Cordova (aka PhoneGap).

I always wanted to use Cordova for my WP7 projects but the Metro interface was way too complex to build from scratch and since the WP7 build of Cordova was on it’s early stages there were some features still to be implemented, for example there was no way to prevent the app from scrolling and some other things. Now there are plenty of plugins to make the app as native as possible and with the latest help from Microsoft, the Cordova development community has another great platform with almost full support of the native web app framework.

It’s great to see that Microsoft finally realized that the future of development has Javascript, HTML and CSS as the main languages. That’s why I have hopes that Boot to Gecko gets some market attraction and becomes a popular platform.


Interpreted is The Future

Interpreted languages are pretty popular since 2005. Ruby with the Rails framework (or API), Python with Django, Javascript with Node.js. These are just some examples of interpreted languages that became extremely popular, mostly because of frameworks, but the main thing that will make the future be ruled by interpreted languages aren’t frameworks. Instead the best feature of these languages are the fact that you can easily test or debug your code on-the-fly, without having to worry about compiling a test source code to see if it works.

The Node.js console for example: I can run my server script on the test machine, then I type node and I can debug/test the code I just wrote, sending GET/POST requests, doing simple database queries (MongoDB of course) and testing code I might add to the main script. A lot of people complain that they are slow because of the way they “read” your code, but seriously I never had any problem with slowness on my code, so I think this isn’t an issue.

Of course languages like C/C++ (I hope Go can kill them because they are completely outdated and there is no more reason to continue using them) or Java will continue to exist for a long time because there are some things, like bootloaders, security systems, OSes, that can only be written in code that can be compiled.

I hope the future gets even brighter for interpreted languages, that’s why I’m trying to give them all a try before choosing the one I’ll stay. At the time Node.js is the best for me because I really love Javascript, but I might get into Ruby too, I like the syntax and the community is really great too.


How To Setup And Use NativeControls In PhoneGap

As many might know the most used plugins in PhoneGap for iOS are NativeControls and ChildBrowser, but installing plugins is a bit tricky and you can’t easily find this kind of help around the internet, for example in my case I’ve learned by reading about plugins installation in PhoneGap and doing tests, so on this post I’ll cover the entire setup and usage of NativeControls (but you can use this for any other plugin in the iOS repo) in a very simple and informative way that even a PhoneGap beginner can understand. I’ll assume that you’ve already had installed and configured the Xcode environment on your Mac and is familiarized with the latest version of it. The first thing you must do is download the phonegap-plugins repo archive and extract it anywhere you like. Now go to the extracted folder and go to iPhone/NativeControls and copy the NativeControls.h and NativeControls.m to the /Plugins folder on Xcode, then move the NativeControls.js to your desired place in the www folder. After all this copying and pasting you must open your PhoneGap.plist under /Supporting Files and add a new item to the Plugins array with the Key and Value NativeControls and the Type String, at the end your project should look something like this:

Now you’re ready to start diving into the code. The first thing you should do is include the required Javascript files into your index HTML source in this order:

<script src="phonegap-1.0.0.js" type="text/javascript" charset="utf-8"></script>
<script src="NativeControls.js" type="text/javascript" charset="utf-8"></script>

The next thing to do is go to your main Javascript file, which contains the onDeviceReady event set and put the NativeControls initialization code there. On this example we are going to use the TabBar component to output something like this:

As you might have noticed I’m using the Glyphish Pro icon pack there, which you can get for $25, but it’s worth every cent, since it’s such a complete icon pack for your TabBars and more. First of all you should initialize a NativeControls variable and create a assign a TabBar to it using this code:

nativeControls = window.plugins.nativeControls;
nativeControls.createTabBar();

Then you can start creating a icon/button for a tab using this JSON object:

nativeControls.createTabBarItem(
  "books",
  "Books",
  "/www/tabs/book.png",
  {"onSelect": function() {
    // Do something
  }}
);

The first item is the name variable, the second is the icon label, the third is the icon path and the last one is a function that should be called every time icon is clicked. Be aware that you should insert the icon path relative to the project folder! About retina icons I really encourage you to check out this explanation on how to organize them. After you added all the icons you want to the TabBar you should show it in the screen. Then start to place the icons (the order you declare on this function they will get placed) and finally assign a TabBar to be active as the app is fired, just like this:

nativeControls.showTabBar();
nativeControls.showTabBarItems("books", "finished", "about");
nativeControls.selectTabBarItem("books");

If you want you can choose from the pre-defined TabBar icons that Apple include by default on their SDK by using these keywords as the icon item:

  • tabButton:More
  • tabButton:Favorites
  • tabButton:Featured
  • tabButton:TopRated
  • tabButton:Recents
  • tabButton:Contacts
  • tabButton:History
  • tabButton:Bookmarks
  • tabButton:Search
  • tabButton:Downloads
  • tabButton:MostRecent
  • tabButton:MostViewed

Remember that the label will be unusable since these will overwrite it, but you should put something on the label item or it won’t work. I’ve uploaded the full source code to my Gist and you can check it out at Example of NativeControls in PhoneGap. After all this hard work you’re ready to compile your application and test it. If you followed the instructions correctly everything should work. If anything goes wrong please drop us a comment and will be my pleasure to help you. Also leave a comment with your thoughts on this article or suggestions.