Tag Archives: android

Comparing Titanium and PhoneGap

A common question I get asked at developer events and conferences is how Titanium compares to PhoneGap. I thought I would take some time to explain how each technology works at a high level, and assess how the two technologies compare to one another.

From 10,000 feet, PhoneGap and Titanium appear to be similar. They both provide tools for cross-platform mobile development. Both also require the use of JavaScript and web technologies in some capacity. Both Titanium and PhoneGap are open source software with permissive licenses (the Titanium Mobile SDK is released under the Apache 2.0 license – PhoneGap, which might also be called a “distro” of the Apache Software Foundation-governed project “Cordova”, is similarly licensed).

But that’s really where the similarities end. While both technologies exist to enable cross-platform mobile development, the philosophies and approaches to solving this problem have very little in common. Also, the business goals driving each project from the perspective of the sponsoring companies (Adobe for PhoneGap and Appcelerator for Titanium) are very different. I will attempt, from my perspective, to describe these technical, philosophical, and business model differences in some detail in the text to follow.

Also, if you weren’t already aware, I am a long time Appcelerator contributor and employee. That said, I have worked hard to keep my technical and philosophical assessments based in technical fact and the explicitly expressed goals of the teams involved. If you feel I have made any points that are factually incorrect or misleading in some way, please let me know in the comments and I will update this post as appropriate.

I will first describe at a high level how both technologies work. I will also describe how both technologies are extended with additional native functionality. For each technology, I will also summarize the key strengths and weaknesses with their chosen approach to cross-platform. The technical differences will quickly become obvious, but after these overviews and comparisons, I will also describe what I feel are the philosophical and strategic differences between the platforms and where they are going.

Let’s start by exploring PhoneGap and how it works.

What is PhoneGap Trying To Accomplish?

The purpose of PhoneGap is to allow HTML-based web applications to be deployed and installed as native applications. PhoneGap web applications are wrapped in a native application shell, and can be installed via the native app stores for multiple platforms. Additionally, PhoneGap strives to provide a common native API set which is typically unavailable to web applications, such as basic camera access, device contacts, and sensors not already exposed in the browser.

At a higher level, PhoneGap might be considered the vanguard of the emerging W3C Device API standards, as they attempt to bring that future to web developers in the present. Today, no platform makes web applications first class citizens, though Mozilla’s promising Boot To Gecko platform has a chance to change that. Microsoft is also making interesting strides for Windows 8 with regard to first-class API access to web applications. But the goal of PhoneGap is to seize a subset of these rights for web applications today.

End User Workflow, Tooling and Interface for PhoneGap

To develop PhoneGap applications, developers will create HTML, CSS, and JavaScript files in a local directory, much like developing a static website. In fact, some PhoneGap developers cite as a bonus of the tool that they can develop in a desktop web browser most of the time, without needing the native toolchain at all.

To run a PhoneGap application on a native emulator/simulator, developers will generate a project for each of the native platforms they wish to support, configure that project’s “web root” directory in Xcode, Eclipse, or whatever native toolchain is needed, and then run the project using that tool. The precise steps are outlined in their getting started guides, per platform. Often, symbolic links are used to route the “www” folder across multiple native projects to a common directory location.

Installing a native-wrapped PhoneGap application to a device requires a similar workflow. However, to augment that process and alleviate the need to have native SDKs installed locally, Nitobi (recently acquired by Adobe) had created a service called PhoneGap Build, which will generate installable applications in the cloud. Functionality to support PhoneGap build deployment has recently been integrated into Adobe’s Dreamweaver tool.

The tools used with PhoneGap are the standard tools of web development, such as Firebug, Web Inspector, and your text editor of choice. There is also an emerging tool for remote debugging known as Weinre that is becoming more commonly used. Overall, the fact that you are developing a native application at all is mostly abstract during the development process.

How PhoneGap Works

As we mentioned previously, a PhoneGap application is a “native-wrapped” web application. Let’s explore how the web application is “wrapped”.

Many native mobile development SDKs provide a web browser widget (a “web view”) as a part of their UI framework (iOS and Android, for example). In purely native applications, web view controls are used to display HTML content either from a remote server, or local HTML packaged along with the native application in some way. The native “wrapper” application generated by PhoneGap loads the end developer’s HTML pages into one of these web view controls, and displays the resulting HTML as the UI when the application is launched.

If JavaScript files are included in a page loaded by a web view, this code is evaluated on the page as normal. However, the native application which creates the web view is able to (in different ways, depending on the platform) asynchronously communicate with JavaScript code running inside of the web view. This technology is usually referred to as “the bridge” in the context of PhoneGap architecture – the “bridge” means something slightly different in Titanium, as we will see later.

PhoneGap takes advantage of this to create a JavaScript API inside a web view which is able to send messages to and receive messages from native code in the wrapper application asynchronously. The way the bridge layer is implemented is different per platform, but on iOS, when you call for a list of contacts, your native method invocation goes into a queue of requests to be sent over the bridge. PhoneGap will then create an iframe which loads a URI scheme (“gap://”) that the native app is configured to handle, at which point all the queued commands will be executed. Communication back into the web view is done by evaluating a string of JavaScript in the context of the web view from native code.

There is much more to PhoneGap than that, but the messaging from web view to native code via the bridge implementation is the key piece of technology which allows local web applications to call native code.

Extending PhoneGap

Writing native extensions for PhoneGap requires that you:

  1. Write a JavaScript interface for your extension which will use PhoneGap’s API to queue up messages to be sent to native code.
  2. Register your extension with the native project in some way – on iOS this is done in the Cordova.plist file.
  3. Write native code that PhoneGap will route requests to from the web view, and implement any native code needed

Basically, developers can participate in the same asynchronous messaging system which powers the core PhoneGap native APIs.

Strengths of the PhoneGap Approach

In my estimation, PhoneGap’s primary architectural strength is that it is so small and simple. It does what it does, and it does that well. The PhoneGap team has intentionally implemented only the lowest common denominator of native APIs for the web browser-based app. Because the native API set is so small, it has been relatively easy to port PhoneGap to many different environments. Basically any native platform that supports a web view or web runtime can be a PhoneGap platform.

Non-visual native extensions in PhoneGap are also very simple. The requirements for registering native code to receive messages from the web view are very modest. Simple native extensions can be developed rapidly. This plug-in architecture was also well executed in my opinion.

There is also strength in the fact that native APIs and native app development are almost completely abstract to the end developer. Anyone who can write HTML, CSS, and even a small bit of JavaScript can wrap up a web page in a native app and distribute it as such. The barrier to entry in using PhoneGap to package web pages as native apps is extremely low.

Weaknesses of the PhoneGap Approach

The quality of the user interface in a PhoneGap application will vary based on the quality of the web view and rendering engine on the platform. The Webkit-based rendering engine on iOS is strong, and provides the best performance. The Android web view is functional, but has some notable limitations. On other platforms, the web view performance can be suspect depending on the OS version.

There are also the standard cross-browser issues web developers have always had to deal with. UIs will need to employ progressive enhancement, media queries, and that entire bag of tricks to remain usable on multiple platforms. It helps that many mobile platforms are adopting Webkit, but there are still significant differences even in Webkit based environments.

Mobile browsers are getting better all the time, which will help mitigate those problems. But approaching native-quality UI performance in the browser is a non-trivial task – Sencha employs a large team of web programming experts dedicated full-time to solving this problem. Even so, on most platforms, in most browsers today, reaching native-quality UI performance and responsiveness is simply not possible, even with a framework as advanced as Sencha Touch. Is the browser already “good enough” though? It depends on your requirements and sensibilities, but it is unquestionably less good than native UI. Sometimes much worse, depending on the browser.

PhoneGap also cannot be extended with native user interface. The end developer’s application its self lives inside a web view, and user interface is rendered in HTML. One can message to native code and create native UI that goes on, over, above, or adjacent to the web view, but it’s difficult or impossible to integrate a dynamic, HTML DOM-based UI with native UI components. Appcelerator would know – we tried to associate native UI with DOM elements early on, and needed to scrap that effort as the results were unpredictable and of insufficient quality.

There is also the other edge of the “lowest common denominator” sword. Very few native APIs are exposed to PhoneGap applications by default, which makes platform integration limited. There are a variety of plug-ins that exist to plug some of these holes, but in my personal experience they have varied in quality and maintenance. This could very well continue to improve over time though – there is a strong community around PhoneGap.

We’ll dive more into the philosophical aspects of PhoneGap soon, but let’s explore these same technical areas for Titanium first.

What is Titanium Trying to Accomplish?

The goal of Titanium Mobile is to provide a high level, cross-platform JavaScript runtime and API for mobile development (today we support iOS, Android, and the browser, with BlackBerry 10 and Windows Phone coming soon and eventually, respectively). Titanium actually has more in common with MacRuby/Hot Cocoa, PHP, or node.js than it does with PhoneGap, Adobe AIR, Corona, or Rhomobile. Titanium is built on two assertions about mobile development:

  • There is a core of mobile development APIs which can be normalized across platforms. These areas should be targeted for code reuse.
  • There are platform-specific APIs, UI conventions, and features which developers should incorporate when developing for that platform. Platform-specific code should exist for these use cases to provide the best possible experience.

So for those reasons, Titanium is not an attempt at “write once, run everywhere”. We think there are great, user-experience enhancing features across multiple platforms that developers should be using. We think that native apps should, where appropriate, take advantage of familiar, high-performance native UI widgets. However, we think it is unnecessary that native developers need to learn platform-specific APIs to draw a rectangle, or make an HTTP request.

Titanium is an attempt to achieve code reuse with a unified JavaScript API, with platform-specific features and native performance to meet user expectations. When you write a Titanium application, you are writing a native application in JavaScript. Titanium should be considered a framework for writing native apps, versus an abstraction from the actual platform you are targeting.

End User Workflow, Tooling, and Interface for Titanium

To develop native applications with Titanium, the developer is required to install the native tool chains for iOS and Android. After those tools are installed, however, the developer usually only interacts with the Titanium SDK’s scripting interface (today Python based). This is done either directly through the command line or (more commonly) through Titanium Studio, our Eclipse-based IDE.

Using the Titanium tool set, you will generate an application project directory which contains a configuration file, localization files, and a directory to contain the images, assets, and JavaScript source you will be writing to power your application. You will not, by default, be editing HTML and CSS files, unless you intend to create a hybrid-type application which contains both native and HTML-based UI. Titanium applications can and often do employ a “hybrid” (native and web) UI, like Facebook’s native application for instance. In this way, one could actually implement PhoneGap with Titanium, but that’s out of scope for this discussion.

Using this toolchain, your application is run using the actual em/simulators for the platforms you’re targeting. Titanium Studio also provides step-through debugging, code completion, and other IDE-level features.

Installing to a device for testing is also typically done using our build system. In Studio we provide a wizard interface to configure any code-signing dependencies, and then handle the deployment of your application to a connected device. You can also use the native toolchains to deploy or package your applications, if that is your preference.

When it comes time to ship your application to the stores, our build system will handle the creation of the final application packages for you. This is done locally on the developer’s machine using the native toolchains. The upload process will be the same as it is for native-only developers.

While developing a Titanium application, the underlying tool chains are mostly abstract. They must be present for development, but the end developer is rarely required to use them directly. The fact that native apps are being developed, however, is not abstract. User interfaces are created with cross-platform AND platform-specific components, and your applications should be dealing with things like background services, local notifications, app badges, configuration, activities/intents (on Android)… all things that are exposed via the Titanium JavaScript API.

How Titanium Works

There’s quite a bit happening behind the scenes in a Titanium application. But basically, at runtime, your application consists of three major components – your JavaScript source code (inlined into a Java or Objective-C file and compiled as an encoded string), the platform-specific implementation of the Titanium API in the native programming language, and a JavaScript interpreter that will be used to evaluate your code at runtime (V8 (default) or Rhino for Android, or JavaScriptCore for iOS). Except in the browser, of course, where the built-in JavaScript engine will be used.

When your application is launched, a JavaScript execution environment is created in native code, and your application source code is evaluated. Injected into the JavaScript runtime environment of your application is what we call “proxy” objects – basically, a JavaScript object which has a paired object in native code. Colloquially we will often refer to “JavaScript land” and “native land” in a Titanium application, as they are kind of parallel universes to one another. The proxy object exists both in JavaScript land and native land, and serves as the “bridge” between the two.

In your JavaScript code, when you call a function on the global Titanium or Ti object, such as var b = Ti.UI.createButton({title:'Poke Me'});, that will invoke a native method that will create a native UI object, and create a “proxy” object (b) which exposes properties and methods on the underlying native UI object to JavaScript.

UI components (view proxies) can be arranged hierarchically to create complex user interfaces. Proxy objects which represent an interface to non-visual APIs (like filesystem I/O or database access) execute in native code, and synchronously (or asynchronously for APIs like network access) return a result to JavaScript.

Hopefully this helps directly address two common misconceptions about Titanium – at no point does Titanium require the use of a web view component. The developer can create a web view as a native UI widget, but the web view is not used to evaluate Titanium source code. Nor is JavaScript code cross-compiled to Objective-C or Java in Titanium. Your JavaScript source is evaluated at runtime.

Extending Titanium

Titanium is extensible with both non-visual and UI capabilities in native code. By implementing a Proxy and/or View Proxy interface in native code, developers can create new native functionality for Titanium applications exposed in JavaScript. We expose the same interface we use to create Titanium’s own internal interface to module developers both on iOS and Android.

Strengths of the Titanium Approach

Since the goal of Titanium is to provide a higher level API for native mobile development across platforms, you will get access to a wide array of native features and functionality out of the box, from user interface components to socket interfaces to notification system integration. The goal of Titanium is to reduce the functionality gap between Titanium and pure native apps to something approaching zero. We’re likely to never support an entire platform’s API out of the box, but we want to cover 90% of the most common use cases and provide a platform where the other 10% can be added by people that need it.

Since Titanium can be extended with visual components that plug into the same view hierarchy as the rest of the application, you’re able to (ultimately) implement any user interface that is possible on the underlying native platform. Need a TableView to scroll at 60fps with special native code? You can do that. Want to seamlessly integrate an OpenGL drawing surface for a game, and keep the logic for the run loop in JavaScript? You can do that. You can integrate these UI extensions directly into the rest of your application built with the core Titanium APIs.

The look and feel of a Titanium application, when using common UI widgets, is also a strength of the platform. There is no visual emulation going on (either through the application of CSS, or rendering of UI widgets using OpenGL or Flash). When you create a NavigationGroup, it is backed by an actual UINavigationController on iOS. The animations and behavior match what a native app user will expect, because you’re using the same UI control.

Since Titanium provides a high level native programming API in JavaScript, the barrier to entry for native programming is significantly reduced for anyone who has used an ECMAScript based language (which is a lot of developers). Atwood’s Law is alive and well through Titanium.

Weaknesses of the Titanium Approach

The scope of the Titanium API makes the addition of new platforms difficult – implementing the Titanium API on a new native platform is a massive undertaking. For that reason, the Titanium platform is only available on what have been deemed the most critical mobile platforms at present: iOS, Android, and the web.

Our mobile web browser support is not yet of GA quality – we are continuing to work on the performance and feel of our UI widget set, as well as rounding out the implementation of our core Titanium APIs.

Because the layer of abstraction provided by Titanium is large, sub-optimal API implementations remain in our own internal framework. Some user interface components do not yet perform as well as their native counterparts under some circumstances, such as very large table views with highly customized layouts. Optimizing our core user interface components remains the primary engineering task for our team. As we fix bugs and hardware improves, we are seeing this become less of an issue. We also find that information architecture, especially for large data sets, needs to be applied in many cases.

Also owing to the ambitiousness of the Titanium platform, extending Titanium is non-trivial. A good working knowledge of Titanium’s architecture and the environment is necessary to effectively integrate a new native control or API. The developer experience, API docs, and high level guides for module developers were improved a lot with our latest 2.0 release, but remain an area of focus for us.

Philosophical Differences

By now, I would hope that the technical differences between PhoneGap and Titanium are pretty clear. But beyond those differences, the goals and direction of each project are different as well. The stated goal of the PhoneGap project is to, eventually, cease to exist. As stated earlier, PhoneGap is intended to be the leading implementation of emerging browser standards around device APIs. In theory, once browser vendors implement the features of PhoneGap, the platform will no longer be necessary. PhoneGap its self isn’t intended to be a platform – it’s a shim to add native app-like functionality to web applications. The web is intended to be the platform.

PhoneGap’s new sponsoring organization, Adobe, is also very much interested in the advancement of the web as a platform. In recent months, Adobe has been aggressively building out tools to enable the development of HTML 5/CSS 3 web applications. It seems obvious to me (and many others) that Adobe sees a diminishing role for Flash as standard web technologies evolve.

At it’s core, Adobe is a tools business. Platforms are a channel through which Adobe can sell tools. Once, that platform was Flash. Now, that platform is the web browser (in addition to Flash). I don’t know precisely how PhoneGap factors into Adobe’s product roadmap, but in a lot of ways it serves a similar purpose as Flash. PhoneGap is an attempt to create an abstract runtime environment to enable cross-platform deployment.

If Adobe can sell tools to develop for the web, and the web can be used to develop more types of applications, then that’s a clear win for Adobe. Which is fine, by the way – nothing wrong with selling tools.

It’s worth noting, however, that Adobe is not the governing body of the Cordova project, on which PhoneGap is now based. That project is owned and governed by the Apache Software Foundation. It remains to be seen what the interplay is going to be between the two projects, but my gut instinct is that they won’t diverge much. I think their goals will remain philosophically aligned.

Appcelerator is also interested in and supportive of the advancement of the web as a platform. Everyone wins when the web gets stronger as an application platform. The difference is that we view the web as one great platform among others, with a unique character and set of strengths and weaknesses. We don’t expect the web to become the only mobile application platform. We think that platforms like iOS, Android, BlackBerry, Windows Phone, and the like will continue to be influential, and will provide great experiences for users. That choice and competition will be a good thing for consumers, but will remain a problem for developers.

What we expect to provide for developers through Titanium is a way to target the web and native platforms from a single codebase, while retaining the features, performance, and tight platform integration that the users of that platform expect. We expect to build an enduring platform for mobile client development, with services and tools to speed up that process. We are not a tools company – we are a platform company, and our success will be linked to the success of developers on top of our platform. Over time, we hope to build an open source platform company in the spirit of Red Hat and other giants in that space.

Which tool or approach is right for you? Like all things in software development, it depends. There are no silver bullets. But hopefully this description and comparison will help you make the right choice for your situation.

Leave a comment

Posted by on July 2, 2012 in Tips


Tags: , , , , , ,

Google Officially Announced Nexus 7 – Challenge to iPad and Kindle


Google has finally revealed its own Android Tablet Nexus 7. There has been a lot of rumors regarding Google’s own tablet with the partnership of ASUS. The tablet will cost just $199.  As previously reported, the device was built by Asus and comes with a 7-inch 1,280 x 800 HD display. According to Google, it’s running the Tegra 3 processor, and has a front-facing camera for video chatting. Wi-Fi connectivity, as well as Bluetooth and near-field communication support are also included in the device.

Nexus 7

In making the announcement, Google made its claim for a piece of a hard-fought market where its entry will compete against’s Kindle Fire – which it approximates in size and price – as well as Apple’s iPad.

The Nexus 7 comes in the customer’s choice of an 8GB or 16GB model. The 8GB option retails for $199, while the 16GB version will go on sale at $249. The device will start shipping in two to three weeks. However, interested customers can start preordering the tablet today.

Rounding out the specs is a Micro-USB port, 1GB of RAM, a 1.2-megapixel front camera (no back camera included), a gyroscope, GPS, accelerometer, microphone, and 802.11a/b/g/n Wi-Fi.

The device measures 10.45mm thick, weighs 0.7 pound, and, from the looks of the first pictures released, has a textured, grippy backside and looks to be about the same size as the Kindle Fire.

The Nexus 7 will be the first device to run the latest version of the Android 4.1 OS, also known as Jelly Bean. Google says to expect 9 hours of 720p HD video battery life.


Leave a comment

Posted by on June 28, 2012 in Tech-News


Tags: , , , ,

Ex-Googlers Launch MightyText, An iMessage For Android Users

During their lengthy careers at Google in both senior technical and product management roles, Maneesh Arora and Amit Sangani were able to geek out on products like AdSense, AdWords, and the now-defunct Google Health. Arora tells us that, while his time at Google was defined by smart people and ambitious ideas like these, in development there was often a tendency to “over engineer” without thinking about “the average user.” He said that, while Google employees always had Gchat open and used Google Voice (or Wave while it was still alive), none of these products were able to effectively address the true value prop of communication tools for a mainstream audience: Syncing. Especially when it comes to texting.

Arora says simply, “To me, it makes no sense that I have to have my phone in front of me to communicate … If I leave it in another room, or in the car, or at home, I essentially have to retrieve it to see who’s calling or to receive incoming texts.” So, Arora and Sangani set out on a mission to give Android users the ability to view and reply to text messages no matter what device they happened to be using. After several months of beta testing, the pair are today officially launching MightyText — an app that aims to give Android users their own version of Apple’s iMessage.

After launching as Texty in March 2011, the startup rebranded as MightyText in June. Since then, it’s been more or less in beta and available solely as a Chrome extension. However, the Chrome extension has found some very solid early adoption, attracting over 250K users, who were sending more than 2 million messages every day. What’s more, Arora says that at the current run rate they are on target to hit one billion messages.

The co-founders used this early validation to raise $650K in seed funding last fall from a bunch of notable names, including First Round Capital, Charles River Ventures, 500 Startups, AngelList’s Naval Ravikant, Scott and Cyan Banister, ex-Google PM Director Rich Chen, Guitar Hero creator Kai Huang, Chegg founder Aayush Phumbra, and several others.

But, as a Chrome extension, MightyText had a fairly limited use case, so today, the co-founders are launching their new web app, which lets any Android user send and receive SMSes from virtually any device. While the co-founders have been describing their apps as “Gmail meets iMessage,” Arora thinks that MightyText has the potential to be more “open” and powerful than iMessage, which really only works between Apple users. Instead, MightyText lets Android users sent text to anyone they would normally text, whether they be on Android, iPhone, Blackberry, or even a feature phone.

So, in allowing users to SMS, MMS and make calls anytime, and from anywhere, it’s not hard to see the initial value prop for MightyText. But what’s important to note is that the app syncs with your existing Android number, which means you don’t have to get a new one — unlike Google Voice. (Huzzah!) And since MightyText lives in the cloud (and in your browser), it organizes all your texts, picture messages and calls, allowing you to search and store them securely for as long as needed. Much in the same way that Gmail (et al) organizes (using the term loosely), categorizes, and allows you to search through you email.

Because it hooks into your cell number and is essentially allowing you remote access to your phone from any device, the upside for MightyText is that it doesn’t have to take on any of the costs of SMS itself, which can be a big burden for SMS apps.

The other side of this, Arora says, is a benefit for the umpteen different carriers using Android. If users send text messages in third-party apps, by way of data or WiFi, carriers don’t get to make money on your SMSes, but, because MightyText keeps messaging confined to their network, these companies are likely going to be more inclined to partner with the startup down the road. (Especially if an API shows up down the road, hint, hint.)

The other thing to consider, Arora tells us, is that there are about 300 million Android devices in use today, which are collectively sending over seven trillion SMSes per year. While people are increasingly spending time on their computers and tablets at home and at work, they still can’t send or receive SMS on those devices.

But, with MightyText, users don’t have to change their behavior or get their friends to install the app to get value. They can just text from their phone as they normally would, with the added benefit of being able to push those messages to any computer, tablet, or phone — in the U.S. or international.

The other use case here that one might not pick out initially both shows the value of MightyText’s app and is just hilarious. Employers and teachers, to name a few, may not be excited to hear this, but Arora says that they’ve received scores of emails and messages from students and employees thanking them for finally building an app that allows them to text from their computer. Why? Well, generally speaking, it’s not a good idea to be found — while in class or in a meeting at the office — hovered over your phone, texting away like you don’t have a care in the world.

But, because MightyText allows you to use your own Android number to text from your laptop or iPad (and how many Android users do you know who also own an iPad?), your subterfuge is much more likely to go unnoticed. In fact, Arora even showed me a message to the team from a lawyer, who said that, thanks to MightyText, he was able to sit in court(!) and text plea negotiations back and forth with the prosecutor without taking out his phone or drawing the ire of the judge. Now that’s utility! (If it turns out that an unintended consequence of MightyText is the acceleration of the legal process, it’s going to be difficult to attach a price tag to MightyText that doesn’t involve the word “billions.” Not to mention that the startup will also be hearing from my lawyers. But in a good way.)

So, when Apple brings iMessage — and this same kind of functionality — to Macs this summer, Android users might otherwise have had to suffer silently as their friends gloated over cross-Apple-device messaging and gleefully asked Siri how to tie their shoes from their iPads. But, thankfully, MightyText gives Android users a come-back, which we all know they’ve been trying out in the TechCrunch comment section for months.

For more, find MightyText at home here.

Leave a comment

Posted by on June 20, 2012 in Tech-News


Tags: ,

Android ported to C#

Android ported to C#

Oracle and Google are currently in a $1 billion wrestling match over Google’s use of Java in Android.

But Java is not the only way to build native apps on Android. In fact, it’s not even the best way: we have been offering C# to Android developers as a high-performance, low-battery consuming alternative to Java. Our platform, Mono, is an open source implementation of the .NET framework that allows developers to write their code using C# while running on top of the Java-powered operating system, and then share that same code with iOS and Windows Phone.

Unlike Sun with Java, Microsoft submitted C# and the .NET VM for standardization to ECMA and saw those standards graduated all the way to ISO strong patent commitments. The .NET framework is also covered by Microsoft’s legally binding community promise.

Last July when Xamarin was getting started, we got our team together in Boston to plan the evolution of Mono on iOS and Android. After a day of kayaking in the Charles River, we sat down to dinner and turned our attention to how we could improve the performance and battery life of applications on Android, and make our own Mono for Android even better.

Over and over we came back to the basics: Dalvik is a young virtual machine, it is not as performant or tuned as Mono and suffers from many of Java’s performance limitations without the benefit of the high-end optimizations from Oracle’s HotSpot. One crazy idea that the team had at that dinner was to translate Android’s source code to C#. Android would benefit from C# performance features like structures, P/Invoke, real generics and our more mature runtime.

Although nothing happened back in July, this idea stuck in the back of our minds.

Fast forward a few months: Mono for Android is doing great, and we are starting to think again about improving our own product’s performance on Android. What if we could swap out Java with faster C# and get rid of various Dalvik limitations in the process? Could we create an Android phone completely free of Java, and free of the limitations of the Dalvik VM?

We decided it was crazy enough to try. So we started a small skunkworks project with the goal of doing a machine translation of Android from Java to C#. We called this project XobotOS.

Source and full article: Xamarin blog

Leave a comment

Posted by on May 2, 2012 in Tech-News


Tags: ,

How to Install Android on PC / Laptop

Mobile phones under the android platform always deserve a best place in market. So if you got messed with android OS and want to try it in your netbook or laptop here is the procedure to experiment it. You can install in your memory cards or flash drives to test android OS on your system.
Download android from Android-x86 and copy it in your flash drive or memory card. Scroll down and download it from the stable release section of the site. This will download an ISO file from the website. Also Make sure your memory device having memory more than 256MB and make your memory drive clean before copying android into it.

You also need UNetbootin (Universal Netboot Installer) to run android on your system. So download it from UNetbootin site. It is available for all the leading operating systems. So choose your OS to download UNetbootin from the site.

Now I have downloaded UNetbootin for my windows platform. All you need to do is insert your drive which you going to install your android OS. UNetbootin extracts the ISO file of android OS which you downloaded and install it in the target disk. The first step of your installation is shown in the screen shot below.

After selecting the target disk, android will start extracting from ISO file and installed in your disk. Now your flash drive will get installed with android OS. This may take few minutes depending on the speed of your flash drive.
 Once you get done with the process you will asked to reboot your system. If you wish you can reboot system immediately or else you just exit and run android when you want. Now your system is ready to run android OS. All you need to do is reboot your system with the flash drive. Change the boot setup to boot from removable disk.

In default it will be available to boot from your hard drive. So press F2 on reboot of your system. Go to Boot menu in the BIOS setup and change the boot setup to boot from removable disc. Then press F10 to save your changes and exit from BIOS setup. Now your system will restart and boot from your removable disc. This will bring a menu infront of you with the following options.

Select Live CD- Run Android-x86 without installation. Then your android OS will start booting and you need to wait for few minutes until it gets loaded. After a couple of minutes you will straightly get into your personal desktop. The default applications will be available on the home screen and for more applications go to menu and select the applications you need.
How to Use Android as PC

By default android give access to webcam and Wi-Fi. So that after entering into the menu you can install the apps you need. You can carry your memory card or flash drive to anywhere and use your own android OS. But your apps installed will be gone when you reboot your system or when you put your removable device in another system. This provides a better interface for the persons who are all using the public systems.

Follow these steps, try installing android in your system. share your comments and doubts in the comment box below.

Just download LiveAndroid

Live Android  Part 1
Live Android  Part 2

Leave a comment

Posted by on March 31, 2012 in Tips


Tags: , , , ,

Android falls flat in front of malware coming from Facebook

Google’s Android operating system has had its fair share of concerns as of late, with people growing concerned over flaws that have been unearthed at different times, and malware for the OS appearing on the Android Market. While the scale is still small enough to avoid, more crafty people are looking into ways to get their questionable apps on the OS so that they can cause havoc and potentially harvest details.

Google have tried to prevent this happening in the form of ‘Bouncer’, an automated scanner of the Android Market which picks up on malware and removes it. Bouncer came into use early in February, but it does not protect individual phones, nor does it prevent other sites from holding malware infested files. TechCrunch confirms that Sophos anti-virus have picked up on the flaw. The newest example is an application entitled “any_name.apk”; and it’s spreading via the Facebook for Android application.

When downloaded, the application installs without any permissions granted by the user, and the identity of what is being downloaded is also not made clear. This may not be the case assuming a phone maintains its default settings, since Android comes with a toggle against downloads from alternative sources. Many users do disable this though, so that they can download applications from locations such as the XDA Developers forum.

It seems that this APK is intended to call premium rate phone numbers or send them text messages, incurring large charges which can then be picked up by the fraudsters and con-men who operate the numbers, as well as likely having created the app. The app is also evolving quickly: the researcher who found it downloaded it from a different site a few days later, where it was called “allnew.apk”. The newer version worked in the same manner though was coded differently, which would imply that it is being constantly updated.

The malware associates itself with the Opera web browser for Android, including an encrypted configuration file with the dialling numbers for premium rate lines. Google have responded to the news, claiming that an install could not have happened in the manner depicted. According to Google a user would have to permit that the phone installed the application even if it was downloaded without their consent or knowledge. Sophos have not yet commented on this claim. Regardless, it may be worth unchecking the ability to download from other sources when not downloading an app, to help better maintain security.

Leave a comment

Posted by on February 27, 2012 in Tech-News


Tags: , , ,

%d bloggers like this: