Using a HPC on a Daily Basis

Recently I’ve started using my Jornada 720 as a replacement for my iPad as a lab computer since it’s extremely tiny (space is very important in the bench) and can do practically everything I need my iPad for, of course I still have my main computer in the lab to program microcontrollers and do everything, but the Jornada is great to have near my working area so I can quickly check datasheets, schematics, and parts list while soldering or prototyping.

Lab view

Usually when I’m prototyping or testing a board I have to check datasheets for pinouts, common voltages, etc. and Adobe Reader is great for this task:

Datasheet open

In my main computer I keep a very well organized folder (and database, but I’m still researching the best way to get the DB into my j720 and keep them both synced) with datasheets for practically every electronic component I have in stock. So whenever I update the folder with more stuff I just rsync everything to my Jornada, and since it’s a nice Linux machine I’ve already wrote a nice script to automate things.

Datasheets

Folders

Last, but certainly not least, I’ve built a small command line application a while ago called build-bom which gets a schematic file from my CAD program (EAGLE) and can output the parts list into HTML, CSV, or JSON. So whenever I’m populating a board I export the parts list to HTML and open it in my Jornada so I can know which part to place where in the board:

Parts list

The New Wave of Vaporware

Last week I got a new development device, a Galaxy Nexus, mainly for Android development since I bricked my old Galaxy S. Sooner or later I would try to install my favorite alpha mobile OS: Firefox OS. I really wanted to try Firefox OS because of how they want HTML5 to be the primary (and unique) way to build applications, but since I NEVER run anything on emulators, I was waiting until I had a device that was compatible.

So I went to their docs to get started on how to flash their OS into my Galaxy Nexus. The first thing that I see is that they don’t provide binaries, that’s not good, but I can compile it myself, no big deal. So I started following their Building/Installation entries, installed all the prerequisites, pulled the code from their repo and ran the configure command to prepare the repo. Then I realized it was downloading the Android source code, which is fucking huge and takes an eternity to download, at this point I realized things weren’t going to be good.

For some reason they weren’t using Google’s servers to get Android’s code, but instead the shitty Linaro ones, I was getting a extremely unreliable, 60kb/s download, it was a hell. After 4 hours trying to get all the code it started failing bad and then it wouldn’t download the rest anymore, so I went to their IRC channel hoping to get some help, but couldn’t get much of it, but what was interesting from the conversation in the IRC is that their primary development target isn’t phones, but the shitty emulator.

I can rant about emulator and all that crap for days here, but I prefer not to. So, dear Mozilla, if you want developers to really care about the awesome product that you’re building, you should first give us a fast and easy way to install it on our devices.

If you look closer at all these 5th place mobile OSes (Ubuntu Touch, Firefox OS, and Tizen) you’ll realize one major thing: It looks like they’ll never ship (yeah Tizen, you’re the worst at the time), they just appear to be a bunch of vaporware.

I really love to see all these emerging technologies and have fun with development stuff, but if I can’t install it, I’ll just loose my interest and never look back. I think I’ll never try Firefox OS again, it was a great experiment, but if you focus on crap emulators I won’t support your platform.

Getting Rid Of Physical Buttons: The Right Way

Three days ago a friend, which is a regular user, asked me about my opinion on the “new button-less phone that was just released”, he was talking about the Sony Xperia Z. First I explained him that those kinds of phones (button-less) existed for a long time before the Sony one, then I gave him a long explanation why I think the Android way of getting rid of buttons was just wrong.

If you really want to get rid of the physical buttons you shouldn’t replace them with virtual ones, since I still loose part of my screen to that piece of the past, so don’t get rid of them, I prefer to have something more “natural” than just an abstraction of it.

To get rid of the physical buttons in the right way you should first of all replace their place with pixels (shocking!), so I can see more content. After that you replace the button actions to be triggered by something that won’t take more screen space, for example gestures.

A clear example where a company made the transition perfectly is RIM, they came from a OS that was completely driven by physical buttons (BBOS) and went to a fully gesture driven OS (PlayBook OS and BB10). Another great example of how to use gestures is the awesome Ubuntu Phone which in my opinion is one of the best implementations I ever seen.

So, if you want to replace the buttons you shouldn’t just virtualize them, but really replace them with something different.

Apple, What Are You Doing?

This is my thoughts about the new iPhone that Apple just introduced today. I’m writing this as I watch the keynote. (it was written yesterday at night so I decided to publish it today. I haven’t reviewed or modified it.)

iPhone 5

The name

Seriously Apple? I really loved that you called the iPad 3 the new iPad, which is a lot better for you and for the people since now most of what you’re going to do is just do some iterations like you did from the iPhone 4 to the iPhone 4S. Calling it the iPhone 5 makes no sense.

The bigger screen

That looked like a nice addition in the beginning, but it will become a hell. A lot of apps are going to have those crappy bars, could you guys do what Android does and just re-align the pixels? Most of the apps really have no reason to “take advantage” of that bigger screen. Also that aspect ratio is just the worst one ever. It will also start a little more fragmentation to the platform.

That back

Seriously that back looks like a generic chinese phone back. It is just so ugly. I would prefer if it was made all of the same color/material which would make a lot more sense.


Stock Apps

Shared Photo Stream

Haha, I had to laugh when I saw this. That’s really the worst thing ever. They forgot that today our friends have different devices, usually they are half iOS users and half Android users, also Instagram does this a lot better and in a lot better and more social way.

Siri

Nice new additions to Siri (I’m talking about the sports stuff). I hope that’s international because if that’s only for the USA you just made a stupid decision.

iTunes

The new additions to iTunes were really awesome. The new Mac app UI is really great. I loved the clean interface.


iPod

The nano

The new iPod nano is really awesome and a lot better than the current generation. If I didn’t used my phone as my music player I would buy it for sure. By the way I still can’t understand why someone would use the iPod nano to watch a movie or look at photos.

The touch

The back really looks like crap. It’s really thin and light, but the only market for that is kind of device is for children that their parents doesn’t want to give them a smartphone. Also I had a “WTF?!” moment when they showed that wrist wrap they are calling iPod touch Loop.


Conclusion

Sadly Apple haven’t got me back. I’ll continue to develop for BlackBerry, I think they are doing a better work to innovate with BlackBerry 10.

RIM is Doing it Right

Finally someone got it right! RIM is the first company that understood that there is no way you can be successful without having 4 things (and implemented all of those):

  • A good, stable and professional OS that fills the needs from teenagers to business people.
  • Beautiful interface that is everywhere and is extremely easy for developers to use on their apps.
  • Developer support/excitement.
  • Carrier support.

Impressions from The BlackBerry 10 Jam

I just got back from the BlackBerry 10 Jam São Paulo and what I saw there was just awesome! I’ve been developing for BlackBerry since I got my Torch 9800 (just for fun) in March of this year and as soon as I started developing for it I saw that RIM was really committed to developers. They provide all the tools, SDKs, frameworks and support for you to create the most awesome apps.

They saw that if you don’t have a developer community that is excited about the future they just can’t continue with their business since after Apple introduced the App Store consumers got addicted to apps and if a platform doesn’t have the apps the need/want they just go to another one. Everyone at The Jam was extremely excited about BlackBerry 10 and how innovative it will be.

I talked to some people there, from business mans that were there only to see the next step from Rim, to developers from other platforms that were thinking about migrating to BlackBerry. The business people were really excited about the new UI/UX of BB10 and how great it will be for multitasking. The developers were really excited too about the UI/UX, but a lot more about how easy it was to develop gorgeous apps for it.

One interesting quote that I got there was from a awesome Android/iOS developer that said: “I submitted a FREE app to Google Play. It made a good success there, but in about a month there was a exact clone of my app being sold on Google Play and other app stores for Android.” He was there because he loved how RIM really cared about developers (which is not true for Apple and Google).

The Dev Alpha

Another thing that RIM did right.

I was one of the lucky developers that was able to get a Dev Alpha (What is the Dev Alpha?). The idea behind distributing prototypes for developers is just amazing. I’m the kind of developer that hates emulators and only develop using real hardware. That’s why the Dev Alpha was a must for me, so I could start developing for BB10.

This is really a awesome idea that we don’t see very often: OEMs distributing prototypes for developers so they can start building their apps to make sure that when the platform is really for commercial release there will be a great selection of apps available on day one.

Monetization

One of the most awesome talks from the BlackBerry 10 Jam, in my opinion, was about monetization of apps in the App World and how it’s proven (by those analytics and research companies) that BlackBerry developers make more money than the average Android/iOS developer.

I totally agree with this because everyone knows that the piracy rates on Android are absurd and the fact that for some strange reason the average Android user doesn’t like to spend money on apps (even if it’s just 99 cents). On the iOS side piracy is a bit of a concern too, but less than on Android.

When we compare to BlackBerry piracy isn’t a big concern since RIM is very well-known for having the best security on their products, also as they showed on the conference the average BlackBerry user loves to download apps and think it is ok to pay for apps that are good and fit their needs.

Conclusion

RIM is really making their path into the future and will definitely survive this phase and get the 3rd place on the mobile market, since I really can’t see Windows Phone going forward with all these bad decisions from Microsoft, how they can’t get outside developers into their platform, and how they are having problems with OEMs to get onboard. (poor Nokia, no updates for you…)

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.

There is a Market For The Nokia PureView

Today I remembered about the Nokia PureView because of The Verge’s sample pictures and videos, and I after thinking about the concept of that phone for a while I finally understood the potential market, besides their fan base, that they might be aiming at with that device.

First of all when Nokia unveiled the PureView at this year CES my first impression was really bad, since I’ll never ever understand camera phones. Also it was running Symbian, which for sure was the best choice since Microsoft would never let them customize Windows Phone to their pixel needs and because this was really on development for at least 2 years. Another thing that I noticed was that it was extremely thick, making it really a camera also does phone calls. This happened because of the entire camera mechanics they used, which impressed me a lot because of the way they did it, by inverting the way the lens moves instead of just doing like any point-and-shoot camera, in and out, they made the lens go up and down, removing the need of that popup lenses.

But now I saw that this product was targeted at people like for example journalists (more specifically from the independent media) so they wouldn’t need to carry a camera with them while they are at a conference or just out gathering information for their article. I realised this after I started thinking about how many times I saw journalists using iPhones/point-and-shoot cameras to capture photo, video, or audio for their job.

I hope Nokia can get some attraction to this new device because I really liked it after realizing this.

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:

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):

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:

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.

How To Setup And Use NativeControls In PhoneGap

NativeControls

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:

Xcode

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:

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:

TabBar

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:

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

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:

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.

My Dream Reading Device

My dream device

Today I was reading some of the 109 articles saved on my Pocket account and I thought about something that I would love: A tablet running a fully customized (for stability and lightness) version of Android sporting a awesome e-ink display. As soon as possible I posted it on Google+, since I really wanted to philosophize more on this idea I’ve wrote this article.

Why e-ink?

First of all, if you’re going to read for long periods of time the LCD screen is just going to burn your eyes, that’s why e-ink is the best alternative. Second, if you ever owned a Kindle (I own the DX, and the new non touch screen version), or any other e-ink device, you know that the experience is incredibly great. I know the refresh rate is a con, but seriously there are a lot more pros and also this technology is still evolving.

What about a touch screen?

Maybe, but I would buy the non-touch screen version because on a reading device I prefer to navigate and switch pages using physical buttons, also be able to holding it anyway I want without worrying about touching the screen by accident.

Why not just root a Nook Simple Touch?

Yeah, the Nook Simple Touch can be rooted and turn into a “fully functional” e-ink Android tablet, the problem is fairly simple: The lack of Android e-ink optimized apps. That’s why if a startup start this trend and it gets some attraction of reading addicts I’m sure developers of big reading apps for Android will optimize their applications for this new category. Also the interface isn’t actually optimized, it’s just a lighter version of ADW Launcher with some tweaks, nothing drastically changed from stock Android, and for this kind of screen a UI with more contrast and less mid-tones is a must.

What’s your proposed interface for this device?

This is my sketch of the perfect UI for it, made with Paper (sorry for my terrible drawing skills):

UI Sketch

The interface is pretty clean and extremely usable (also it looks a bit with the Kindle interface). The status bar will only show the name of the user and a clock. Below the status bar is the app drawer, I thought about it as just a simple collection of the application names (scrollable if you have more applications than it can fit on the screen). The last piece is the actual running application itself.

There is market for such product?

That’s a difficult question to answer, but as far as everyone can see the eReader/eBook market is growing exponentially and I think a lot of customers would give it a try if it was presented to them.

What you might end up doing?

As I wait until this dream reading device becomes true I’ll buy a Nook Simple Touch, root it, customize the OS to make everything with high contrast, and start developing that launcher from scratch.

What are your thoughts about this dream device? Any suggestions about it? Leave a comment.

We Don’t Need Another SIM Standard

Three days ago I received my first BlackBerry development device, a Torch. As I said, it will be just a development device, so I have to use it for a while to learn how the apps look like and how they feel, so I can start to develop/port applications to the OS. Why I told all this story? Simple, I use a microSIM on my iPhone, so I had to purchase a converter to use it on my BlackBerry, because it’s the SIM my carrier automatically activated the BlackBerry Internet Services. The day I had to buy the converter I remembered the new nanoSIM project and thought: “The problem isn’t SIM design, it’s the SIM itself”.

We don’t need another SIM design, we need to get rid of the SIM. It’s a 1998 that just got little updates over time. We are moving everything to the cloud (I know a lot of people hate this term, but I don’t care, I like it), our contacts, files, photos, our entire lives, why not all the informations the carrier needs to authenticate our plan?

The idea is fairly simple: Just as I have to register a username and password to have BIS (BlackBerry Internet Services) with my carrier, just make this for everyone on the carrier, as soon as you get your first phone/plan you register a username/password and all your information gets stored on the carrier. When you turn your phone ON, it connects to the carrier and ask you for the credentials, if they are valid it will download all the information and get your plan up and running.

What’s your opinion about this idea? Any thoughts about this topic? Leave a comment, I love to read and respond to them.

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.

Follow my blog with Bloglovin

There is Still a Market for Resistive Displays

Since the first iPhone came out, in 2007, the world of touch screens went to capacitive because they were a lot more finger-friendly. Because of this people started to think of resistive screens almost as 90’s technology and forgot that they were good at one key thing: Handwriting and pen recognition.

We, humans, are used to write and draw with pens, not with our fingers. This makes the experience with drawing, sketching, and note taking apps terrible. Some will say that anyone can buy a capacitive stylus that will work on all the modern mobile devices, the problem with those stylus is that they are not precise enough, they help a lot, but humans are precise when they want to draw or take some handwritten notes.Very often I take my HTC Touch Pro2 so I can take notes digitally.

At least this idea, of having a stylus on mobile devices, is still not dead yet. The Samsung Galaxy Note is the proof of this, also I want to mention that their stylus (S-Pen) implementation is very good, they managed to put a fairly precise stylus to work on their capacitive display. If other companies start to see this market and come out with great new ideas to merge the new technologies with the old ones I’m sure they will increase their profit significantly and will make their customers a lot happier.

Apps I Can’t Live a Day Without (Android Edition)

This is the first article of a series I’ll be doing. Here I’m going to list the apps I can’t live a day without, in the various platforms I use on a daily basis.

I decided to start with iOS, which is the one I like most in the phone category, that’s why I always carry my iPhone with me: Apps. But then I choose to start with Android because in my opnion it’s a more productivity OS, also I’m  writing this article on my Eee Pad Slider using Google Docs.

Let me begin by listing the Android devices I own and use every day:

  • ASUS Eee Pad Slider
  • Samsung Galaxy Tab (the original 7” version)
  • Samsung Galaxy S

I also have a Motorola Milestone (aka OG Droid) which I only use to test the apps I develop for Android. So I think it doesn’t count as one of my daily drivers. Now let’s begin with the app list:

Google Music
The best way to listen to my library whenever I go. It syncs my iTunes library with all my devices using the awesome Google cloud and albums that I like most and want to enjoy don’t matter if I have a internet connection, with a single tap and they get downloaded to my device so can be played offline. With a stuning UI and great features it’s by far the best music player for Android in my opinion. If you don’t want the cloud features you can check out DoubleTwist which a great alternative for people that just want their music on the device.

Gaug.es
In my opinion the best analytics service available. It’s simpler than Google Analytics and everything happens in real-time. The app shows all the information you can have on the desktop version and also lets you have the awesome AirTraffic Live feature that shows you in real-time, on a map, the detailed traffic on your site. Since I love to check out every second how my sites are performing I can’t live without it for a day.

Wunderlist
This is just the best task manager app ever invented. With a set of apps for every platform you can imagine from desktops to mobile devices. I use it to manage all the tasks I have to finish regarding my projects and keep them all synced across my devices. Definetly a must-have app for people that must be productive.

Google Docs
The most important app on my Eee Pad Slider. Everyone knows this app, if doesn’t know at least the service you should know. I use it on a daily basis to write my articles and long texts for work or school. I stoped using any office suite, this includes iWork and Microsoft Office, after switching to Docs last year. Don’t matter where I go I can view and edit any document I want.

Read it Later
I choose it instead of Instapaper because of the official support for Android and iOS. I love this app because I can keep all the articles I want to read offline and synced. Really a must-have for people that like to read a lot of articles on a day.


That’s it, if you have any other app you think is awesome please share on the comments.