GeoMe and IRL announce Partnership

AMSTERDAM, THE NETHERLANDS and BARCELONA, SPAIN--(Marketwire - January 27, 2009) - In Real Life (IRL), the only presence-based social networking company that adds presence to social networks and social media, and GeoMe, a mobile phone service that allows users to explore, share and connect via messages on a map, announced today the creation of a central platform for location-based social networking services on both mobile phones and the Web. This is the first time a Web-based social network has partnered with a mobile, location-based social network, providing full access privileges across the two communities of users.

The partnership extends the services of the IRL Connect Web-based social networking platform (www.irlconnect.com) to the mobile, as well as brings GeoMe's (www.geo-me.com) expertise in delivering location-based solutions on mobile to the Web. The combined platform features a social network toggle that allows members to seamlessly cross between communities. Both services bring the best of the mobile and Web worlds to users for an optimal social networking experience where they can access and exchange information and find friends online with the least effort, rather than a walled garden format of many of today's mobile social networking services.

"Many competitors focus on mobile and then try to extend their service to the Web by themselves, creating a half-baked Web solution," said Frank Schuil, founder and CEO of IRL. "By allowing aggregation with external parties, such as GeoMe, it is easier to grow our user base and give IRL Connect users the opportunity to explore mobile social networking using the GeoMe platform."

"Both IRL and GeoMe are focused on developing fresh concepts within the context of social networks. By partnering together, we combine resources to reach out to a wider public than would have otherwise been possible," said Ric Ferraro, managing director, GeoMe. "Instead of just aggregating different networks, GeoMe and IRL are sharing our communities openly in order to provide a richer experience for members."

GeoMe is launching its public beta in February 2009. IRL Connect members will be able to access the GeoMe service on mobile and on the Web in Q2 2009.

Vringo Update-Announces Global Partnership with Sony Ericsson

NEW YORK–Jan. 22, 2009—Vringo^TM, the next-generation ringtone pioneer, announced today that its free video ringtone application is being pre-linked on global shipments of Sony Ericsson’s Walkman™ phones and promoted via the manufacturer’s Fun & Downloads portal, introducing Vringo to millions of new users. New Sony Ericsson owners join a thriving community of Symbian, Java and Windows Mobile users who are already experiencing Vringo’s high-quality video ringtones and VringForward™ technology, which lets users send ringtones to friends just by calling.

This partnership with Sony Ericsson, which was established when Vringo took home a prize at last year’s Sony Ericsson Content Awards, is the latest step in Vringo’s continuing push toward global availability and monetization of video ringtones. Recently, Vringo announced partnership deals with mobile carriers in Turkey and France that enable users to download the Vringo application and access content, in some cases on a paid-subscription basis.

“Our partnership with Sony Ericsson is unprecedented,” said Vringo CEO Jon Medved. “In addition to being the first social video ringtone application to be downloadable directly from Sony Ericsson phones, we’re reaching millions of Walkman users—one of the most innovative, media-hungry audiences in the world.”

Vringo’s application, which is also available for a wide variety of Symbian, Java and Windows Mobile devices via www.vringo.com, lets users create or take video, images and slideshows from virtually anywhere, including Vringo’s 4,000-clips-and-counting video ringtone library or the Web, and make them into their personal call signatures.

To access Vringo, Walkman users can find the link prominently displayed in their phone’s Web browser. By clicking the link, users will download the Vringo application to their phones and can immediately begin sharing video ringtones with their phone contacts.

Avoiding memory leaks

Android applications are, at least on the T-Mobile G1, limited to 16 MB of heap. It's both a lot of memory for a phone and yet very little for what some developers want to achieve. Even if you do not plan on using all of this memory, you should use as little as possible to let other applications run without getting them killed. The more applications Android can keep in memory, the faster it will be for the user to switch between his apps. As part of my job, I ran into memory leaks issues in Android applications and they are most of the time due to the same mistake: keeping a long-lived reference to a Context.

On Android, a Context is used for many operations but mostly to load and access resources. This is why all the widgets receive a Context parameter in their constructor. In a regular Android application, you usually have two kinds of Context, Activity and Application. It's usually the first one that the developer passes to classes and methods that need a Context:

@Override
protected void onCreate(Bundle state) {
  super.onCreate(state);
  
  TextView label = new TextView(this);
  label.setText("Leaks are bad");
  
  setContentView(label);
}

This means that views have a reference to the entire activity and therefore to anything your activity is holding onto; usually the entire View hierarchy and all its resources. Therefore, if you leak the Context ("leak" meaning you keep a reference to it thus preventing the GC from collecting it), you leak a lot of memory. Leaking an entire activity can be really easy if you're not careful.

When the screen orientation changes the system will, by default, destroy the current activity and create a new one while preserving its state. In doing so, Android will reload the application's UI from the resources. Now imagine you wrote an application with a large bitmap that you don't want to load on every rotation. The easiest way to keep it around and not having to reload it on every rotation is to keep in a static field:

private static Drawable sBackground;

@Override
protected void onCreate(Bundle state) {
  super.onCreate(state);
  
  TextView label = new TextView(this);
  label.setText("Leaks are bad");
  
  if (sBackground == null) {
    sBackground = getDrawable(R.drawable.large_bitmap);
  }
  label.setBackgroundDrawable(sBackground);
  
  setContentView(label);
}

This code is very fast and also very wrong; it leaks the first activity created upon the first screen orientation change. When a Drawable is attached to a view, the view is set as a callback on the drawable. In the code snippet above, this means the drawable has a reference to the TextView which itself has a reference to the activity (the Context) which in turns has references to pretty much anything (depending on your code.)

This example is one of the simplest cases of leaking the Context and you can see how we worked around it in the Home screen's source code (look for the unbindDrawables() method) by setting the stored drawables' callbacks to null when the activity is destroyed. Interestingly enough, there are cases where you can create a chain of leaked contexts, and they are bad. They make you run out of memory rather quickly.

There are two easy ways to avoid context-related memory leaks. The most obvious one is to avoid escaping the context outside of its own scope. The example above showed the case of a static reference but inner classes and their implicit reference to the outer class can be equally dangerous. The second solution is to use the Application context. This context will live as long as your application is alive and does not depend on the activities life cycle. If you plan on keeping long-lived objects that need a context, remember the application object. You can obtain it easily by calling Context.getApplicationContext() or Activity.getApplication().

In summary, to avoid context-related memory leaks, remember the following:

• Do not keep long-lived references to a context-activity (a reference to an activity should have the same life cycle as the activity itself)


• Try using the context-application instead of a context-activity


• Avoid non-static inner classes in an activity if you don't control their life cycle, use a static inner class and make a weak reference to the activity inside. The solution to this issue is to use a static inner class with a WeakReference to the outer class, as done in ViewRoot and its W inner class for instance


• A garbage collector is not an insurance against memory leaks

Note: This article was originally posted on my personal blog.

GeoMe in the Press-Mobile LBS Feature Article

BARCELONA- GeoMe was featured in the Economic Section of Sunday 11th January's edition of Avui newspaper, with an article by Jordi Garriga.

The article gives a quick tour of the GeoMe story up to today, from the first prototype developed for the Mobile World Congress in 2008, to the imminent release of the public beta version.

An important differentiating factor of GeoMe from the multitude of me-too applications out there, is the fact that GeoMe does not display people on the map but displays messages instead. That way, privacy of the user is safeguarded.

While GPS on high end phones is set to become a ubiquitous technology, incoporating alternative technologies like CellID will extend the reach of GeoMe to the wider public, especially in the target group of 15-24 year olds.

The full article (in Catalan) is available by clicking here

Why is my list black? An Android optimization

ListView is one of Android's most widely used widgets. It is rather easy to use, very flexible and incredibly powerful. ListView can also be difficult to understand at times.

One of the most common issues with ListView happens when you try to use a custom background. By default, like many Android widgets, ListView has a transparent background which means yo can see through the default window's background, a very dark gray (#FF191919 with the current dark theme.) Additionally, ListView enables the fading edges by default, as you can see at the top of the following screenshot; the first text item gradually fades to black. This technique is used throughout the system to indicate that the container can be scrolled.

The fade effect is implemented using a combination of Canvas.saveLayerAlpha() and the Porter-Duff Destination Out blending mode. This technique is similar to the one explained in Filthy Rich Clients and various presentations. Unfortunately, things start to get ugly when you try to use a custom background on the ListView or when you change the window's background. The following two screenshots show what happens in an application when you change the window's background. The left image shows what the list looks like by default and the right image shows what the list looks like during a scroll initiated with a touch gesture:

This rendering issue is caused by an optimization of the Android framework enabled by default on all instances of ListView (for some reason, I forgot to enable it by default on GridView.) I mentioned earlier that the fade effect is implemented using a Porter-Duff blending mode. This implementation works really well but is unfortunately very costly and can bring down drawing performance by quite a bit as it requires to capture a portion of the rendering in an offscreen bitmap and then requires extra blending (which implies readbacks from memory.)

Since ListView is most of the time displayed on a solid background, there is no reason to go down that expensive route. That's why we introduced an optimization called the "cache color hint." The cache color hint is an RGB color set by default to the window's background color, that is #191919 in Android's dark theme. When this hint is set, ListView (actually, its base class View) knows it will draw on a solid background and therefore replaces th expensive saveLayerAlpha()/Porter-Duff rendering with a simple gradient. This gradient goes from fully transparent to the cache color hint value and this is exactly what you see on the image above, with the dark gradient at the bottom of the list. However, this still does not explain why the entire list turns black during a scroll.

As I said before, ListView has a transparent/translucent background by default, and so all default Android widgets. This implies that when ListView redraws its children, it has to blend the children with the window's background. Once again, this requires costly readbacks from memory that are particularly painful during a scroll or a fling when drawing happens dozen of times per second. To improve drawing performance during scrolling operations, the Android framework reuses the cache color hint. When this hint is set, the framework copies each child of the list in a Bitmap filled with the hint value (this assumes that another optimization, called scrolling cache, is not turned off.) ListView then blits these bitmaps directly on screen and because these bitmaps are known to be opaque, no blending is required. And since the default cache color hint is #191919, you get a dark background behind each item during a scroll.

To fix this issue, all you have to do is either disable the cache color hint optimization, if you use a non-solid color background, or set the hint to the appropriate solid color value. This can be dome from code or preferably from XML, by using the android:cacheColorHint attribute. To disable the optimization, simply use the transparent color #00000000. The following screenshot shows a list with android:cacheColorHint="#00000000" set in the XML layout file:

As you can see, the fade works perfectly against the custom wooden background. I find the cache color hint feature interesting because it shows how optimizations can make developers' life more difficult in some situations. In this particular case, however, the benefit of the default behavior outweighs the added complexity for the developer.

Note: this article was originally posted on my personal blog.

Vringo-can video ringtones crack the subscription model?

I met Haim Cohen-Mintz from Vringo at the Mobile Web Europe conference in London in September and he exuded a quiet confidence about both the prospects of the Vringo content proposition and its (nicely executed) business model.

True to form, the company has been progressively announcing a number of recent deals in both France and Turkey to provide their video content on deck with various operators.

What is interesting about their deal with Avea in Turkey is that Vringo will break new ground by launching a carrier led video ringtone subscription model. It is interesting because in many ways we are at an inflection point in the traditional models of mobile revenue generation, particularly when it comes to mobile content.

Pure advertising-supported business models are beginning to creak as the need for a balanced revenue mix imposes itself on content providers to both smooth revenues and cashflow as well as to increase the sustainability of revenue generation.

What we also see is increased divergence between the 'mature' mobile markets and the nascent or 'emerging' ones that are characterised by heavy mobile internet penetration. The consumers of the latter market have not 'evolved' from PC web to mobile web, thus do not suffer from the same degree of eyeball saturation.

Traditional revenue models (such as those entirely dependent on advertising) may well work in the emerging markets (at least for a while) but there is little doubting that a new market imperative is beginning to emerge in mature markets. Mass mobile consumers here will develop greater resistance to mobile advertising and since most large players will be slow to adapt, my belief is that nimble startups focused on niche content or niche market segments will have at their grasp interesting revenue opportunities.

Where does this leave Vringo? Vringo innovates in a mature (premium ringtone) market, so should be able to do well for a while. However, the market in mature countries appears to be shrinking, so the focus on emerging markets will be critical in sustaining future revenue growth ceteris paribus.

Can I use this Intent?

Android offers a very powerful and yet easy to use tool called intents. An intent can be use to turn applications into high-level libraries and make code re-use something even better than before. The Android Home screen and AnyCut use intents extensively to create shortcuts for instance. While it is nice to be able to make use of a loosely coupled API, there is no guarantee that the intent you send will be received by another application. This happens in particular with 3rd party apps, like Panoramio and its RADAR intent.

While working on a new application, I came up with a very simple way to find out whether the system contains any application capable of responding to the intent you want to use. I implemented this technique in my application to gray out the menu item that the user would normally click to trigger the intent. The code is pretty simple and easy to follow:

/**
 * Indicates whether the specified action can be used as an intent. This
 * method queries the package manager for installed packages that can
 * respond to an intent with the specified action. If no suitable package is
 * found, this method returns false.
 *
 * @param context The application's environment.
 * @param action The Intent action to check for availability.
 *
 * @return True if an Intent with the specified action can be sent and
 *         responded to, false otherwise.
 */
public static boolean isIntentAvailable(Context context, String action) {
    final PackageManager packageManager = context.getPackageManager();
    final Intent intent = new Intent(action);
    List<ResolveInfo> list =
            packageManager.queryIntentActivities(intent,
                    PackageManager.MATCH_DEFAULT_ONLY);
    return list.size() > 0;
}

Here is how I use it:

@Override
public boolean onPrepareOptionsMenu(Menu menu) {
    final boolean scanAvailable = isIntentAvailable(this,
        "com.google.zxing.client.android.SCAN");

    MenuItem item;
    item = menu.findItem(R.id.menu_item_add);
    item.setEnabled(scanAvailable);

    return super.onPrepareOptionsMenu(menu);
}

In this example, the menu is grayed out if the Barcode Scanner application is not installed. Another, simpler, way to do this is to catch the ActivityNotFoundException when calling startActivity() but it only lets you react to the problem, you cannot predict it and update the UI accordingly to prevent the user from doing something that won't work. The technique described here can also be used at startup time to ask the user whether he'd like to install the missing package, you can then simply redirect him to the Android Market by using the appropriate URI.

Note: this article was originally posted on my personal blog.

GeoMe at Living Labs Global Summit in Hamburg

HAMBURG-Organised by Living Labs Global and the Barcelona City Council, this initiative to create a Global Market for Mobility and the growing market opportunities in the Mediterranean Market of 485m citizens, with Barcelona as its prime gateway for innovative business.

GeoMe will be showcasing its application at the event on the 16th of January 2009 and extends a warm invitation to all to come along and take part in the event. This will cover amongst other things:

• The summit's plenary session will provide a compact overview of Living Labs Global and highlight the Mediterranean market and growth opportunities.
• Parallel thematic matchmaking panels will be held to connect international partners, customers and peers in the fields of Design, Media & ICT and Healthcare.
• Matchmaking sessions will start with a panel discussion of respected experts, and lead into a well-structured matchmaking process over lunch and coffee. To understand your offerings, needs and interests, we will follow a structured procedure upon registration and build your personal event experience.
• mWatch: Showcase your innovations and win the Living Labs Global Award.
• An exhibition area will be mounted in the summit, offering you the opportunity to showcase your products, services and solutions.
• Upon registration you can choose to take part in this exposition, from which the participants in the Summit will vote for the most innovative solution. An Award will be presented to the winners, in the form of a one-year Associate Membership in Living Labs Global.

More information can be obtained by clicking here