Pages

Ads 468x60px

Thursday, May 28, 2009

Testing iPhone Apps on Real Devices

Mobiforge published today an interesting article by Wei-Meng Lee on the key steps required to test and deploy your iPhone app.

If you have successfully published on iPhone before, there will be nothing new for you, but if you haven't, the article gives you a simple guide for deploying your app.

The article kicks off by saying that "a repeated criticism from iPhone app developers comes from the difficulty they find in deploying their application to a real iPhone or iPod Touch. Apple, for better or worse, has designed a process involving many hoops that must be jumped through, and this has prompted developers to grumble, and others to explore alternative, non-official open tool chains, which do not require app signing. In this article, I will walk you through the steps you need to take in order to test your iPhone apps on a real device, be it iPhone, or iPod Touch, the official Apple way."

You can read the full article here.

Wednesday, May 27, 2009

Calling all developers for Android Developer Challenge 2!

I'm excited to announce the second Android Developer Challenge (ADC)! The first challenge was a huge success with over 1,700 entries that resulted in 50 excellent winners. With the recent release of Android 1.5, as well as the availability of devices in multiple markets around the world, I'm pleased to announce the second ADC.

We've expanded ADC 2 to involve a very important part of the Android community—the users who will be running these applications. Users of Android-powered devices with Android Market will be able to download a special Android judging application and use it to download and rank applications submitted to the Challenge. The results from this round will determine the top ranking applications in each of the 10 categories. These top applications will then be ranked by a combination of users and a panel of Google selected judges through a similar process as the first round to determine the final winners.

I've already seen a lot of great apps on Android and I look forward to seeing even more innovative and unexpected cool apps that will come out of this Challenge! For more details on ADC 2, please see the official site. Start your engines and good luck!

Tuesday, May 26, 2009

Android Icon Guidelines

For our second post in our series on Android UI, we're releasing our Icon Design Guidelines and an Android Icon Templates Pack. These should make it a lot easier for you (or your designer) to develop all the icons your applications need, so they fit with the other icons in the Android environment.

The Icon Design Guidelines document describes how to design and export icons that fit within the Android framework. It includes a wealth of detail about icons in the Home screen, menus, the status bar, tabs, dialogs, and lists.

The Android Icon Templates Pack is a collection of template designs, filters, and settings that make it easier for you to create icons that conform to the general specifications given in this Guidelines document. We recommend downloading the template pack archive before you get started with your icon design.

The Templates Pack provides templates in Adobe Photoshop and Adobe Illustrator file formats, which preserves the layers and design treatments we used when creating the standard icons for the Android platform. You can load the template files into any compatible image-editing program, although your ability to work directly with the layers and treatments may vary based on the program you are using.

Monday, May 25, 2009

Mobile 2.0 Europe-Future of Mobile Explored


BARCELONA- Mobile 2.0 lands in Barcelona once again next month courtesy of Rudy and Carles of Dotopen and is set to pack a real punch with the main conference on the 19th June being supplemented by a Developer Day the day before.

The main themes of what is now the 5th Mobile 2.0 event in the series (after the initial event in San Francisco) will be: Openness, Beyond Free, Play, Cloud, Context and Sense. Based on the various events I attended this year and the current phase of the global economic cycle, I anticipate that the whole area of new business models within the Beyond Free track of the event will stimulate the most debate.

The thinking up to last year was 'what is free on the web, cannot be charged for on mobile', but perhaps it is time to update this credo as the quality and performance of the mobile experience improves (and not just on smartphone devices).

The speaker line-up features the larger than life founder of Zyb, Tommy Ahlers and Marco Ahtisaari, CEO of Dopplr. Marco was in Barcelona last week to speak at the SIME Barcelona event, and announced there the future release of a Dopplr app on the iPhone and a re-orientation of their business to more of a 'Social Atlas' (read Social Network). It will be interesting to get his views on the future for mobile social networking..

You can find more info on the event here

Friday, May 22, 2009

Lightning talks at Google I/O

Google I/O is approaching, and with over ten quality talks lined up, we should all strive to be attentive, avid learners. But for the last Android session of the conference, we thought it would be fun to unwind and open up the podium for lightning talks. This is where anyone can take the stage for six minutes and talk about anything. If you've done a cool hack involving Android, if you've devised a clever technique for a common problem, or even if you just want to get up on your soapbox for six minutes to appeal to your fellow developers, this is your time to be heard.

For those planning on attending Google I/O, we need you to submit and judge lightning talk proposals through a Google Moderator series we've set up. Please go ahead and start submitting your proposals. You only have 250 characters to describe the talk, which may be 110 more characters than you've been used to these days.

Voting is open from now until the moment the session starts. We'll take the eight highest rated talks and will call upon each speaker to take the stage. Remember you only have six minutes. Exceed that, and our security force tackles you off the stage. Thanks and see you all at I/O!

Wednesday, May 20, 2009

Location in Mobile Social Networks

London-Location is at the very heart of the next generation of mobile services and the future mobile web. Last year, both Nokia and Google made big announcements highlighting location as one of their key strategic axes. Now Vodafone is keen to position itself in this space and its recent acquisition of Swedish navigation software provider Wayfinder is but the first step in that direction.

I presented the experience of GeoMe in launching a location-enabled mobile social network at the Informa Mobile Location Services 09 Conference in London on the 12th May, describing how to overcome some of the barriers to adoption, especially privacy, and new distribution channels that can be exploited for getting the product to market.

I was also priviliged to be in good company on a speaker panel on the next generation of location services together with o2, TIM, Qualcomm and content provider Spoonfed. The conclusion? To create demand, you need to offer a good product with a clear value proposition. Will 2010 be 'the' year of location based services? The answer: 'probably'.

You can see my presentation on Slidespace below:

Friday, May 8, 2009

Dude, where's my Privacy-The Privacy Conundrum in Social Networks


I will be speaking next week at the Informa Mobile Location Services 09 Conference in London and one of the key subjects I was asked to present on was privacy.

One of the key issues has to do with semantics:what do we mean by privacy exactly? How private is private? My argument is that the privacy sphere, like it or not, is getting smaller and smaller for most people. Over time, the level of intrusion that each person is willing to accept in their 'private' sphere is also increasing.

I like to point to the example of Google Street View, as this is a full on example of a significant intrusion into everyone's private sphere which was accepted and ultimately embraced (I recommend you see also the example of the Japanese mashup of a Virtual Jog using Street View).

The other key issue is that legislation is dictating the approach that mobile social networks that use location should use. This is the key concept of 'opt-in', such that it is always down to consumer choice whether or not anyone has access to the location of a mobile subscriber.

This is fine as a preventive measure to assuage the public's fear of location based services in the interim period during which the key players (like Google) educate and inform about the benefits of location based services.

But ultimately, it is not the way in which 'push' services, somewhat of a marketing mecca in terms of delivering the right marketing message to the right customer in the right place, will be achieved.

Wednesday, May 6, 2009

Painless threading

Whenever you first start an Android application, a thread called "main" is automatically created. The main thread, also called the UI thread, is very important because it is in charge of dispatching the events to the appropriate widgets and this includes the drawing events. It is also the thread you interact with Android widgets on. For instance, if you touch the a button on screen, the UI thread dispatches the touch event to the widget which in turn sets its pressed state and posts an invalidate request to the event queue. The UI thread dequeues the request and notifies the widget to redraw itself.

This single thread model can yield poor performance in Android applications that do not consider the implications. Since everything happens on a single thread performing long operations, like network access or database queries, on this thread will block the whole user interface. No event can be dispatched, including drawing events, while the long operation is underway. From the user's perspective, the application appears hung. Even worse, if the UI thread is blocked for more than a few seconds (about 5 seconds currently) the user is presented with the infamous "application not responding" (ANR) dialog.

If you want to see how bad this can look, write a simple application with a button that invokes Thread.sleep(2000) in its OnClickListener. The button will remain in its pressed state for about 2 seconds before going back to its normal state. When this happens, it is very easy for the user to perceive the application as slow.

Now that you know you must avoid lengthy operations on the UI thread, you will probably use extra threads (background or worker threads) to perform these operations, and rightly so. Let's take the example of a click listener downloading an image over the network and displaying it in an ImageView:

public void onClick(View v) {
new Thread(new Runnable() {
public void run() {
Bitmap b = loadImageFromNetwork();
mImageView.setImageBitmap(b);
}
}).start();
}

At first, this code seems to be a good solution to your problem, as it does not block the UI thread. Unfortunately, it violates the single thread model: the Android UI toolkit is not thread-safe and must always be manipulated on the UI thread. In this piece of code, the ImageView is manipulated on a worker thread, which can cause really weird problems. Tracking down and fixing such bugs can be difficult and time-consuming.

Android offers several ways to access the UI thread from other threads. You may already be familiar with some of them but here is a comprehensive list:

Any of these classes and methods could be used to correct our previous code example:

public void onClick(View v) {
new Thread(new Runnable() {
public void run() {
final Bitmap b = loadImageFromNetwork();
mImageView.post(new Runnable() {
public void run() {
mImageView.setImageBitmap(b);
}
});
}
}).start();
}

Unfortunately, these classes and methods also tend to make your code more complicated and more difficult to read. It becomes even worse when your implement complex operations that require frequent UI updates. To remedy this problem, Android 1.5 offers a new utility class, called AsyncTask, that simplifies the creation of long-running tasks that need to communicate with the user interface.

AsyncTask is also available for Android 1.0 and 1.1 under the name UserTask. It offers the exact same API and all you have to do is copy its source code in your application.

The goal of AsyncTask is to take care of thread management for you. Our previous example can easily be rewritten with AsyncTask:

public void onClick(View v) {
new DownloadImageTask().execute("http://example.com/image.png");
}

private class DownloadImageTask extends AsyncTask {
protected Bitmap doInBackground(String... urls) {
return loadImageFromNetwork(urls[0]);
}

protected void onPostExecute(Bitmap result) {
mImageView.setImageBitmap(result);
}
}

As you can see, AsyncTask must be used by subclassing it. It is also very important to remember that an AsyncTask instance has to be created on the UI thread and can be executed only once. You can read the AsyncTask documentation for a full understanding on how to use this class, but here is a quick overview of how it works:

In addition to the official documentation, you can read several complex examples in the source code of Shelves (ShelvesActivity.java and AddBookActivity.java) and Photostream (LoginActivity.java, PhotostreamActivity.java and ViewPhotoActivity.java). I highly recommend reading the source code of Shelves to see how to persist tasks across configuration changes and how to cancel them properly when the activity is destroyed.

Regardless of whether or not you use AsyncTask, always remember these two rules about the single thread model: do not block the UI thread and make sure the Android UI toolkit is only accessed on the UI thread. AsyncTask just makes it easier to do both of these things.

If you want to learn more cool techniques, come join us at Google I/O. Members of the Android team will be there to give a series of in-depth technical sessions and answer all your questions.

Monday, May 4, 2009

Drawable mutations

Android's drawables are extremely useful to easily build applications. A Drawable is a pluggable drawing container that is usually associated with a View. For instance, a BitmapDrawable is used to display images, a ShapeDrawable to draw shapes and gradients, etc. You can even combine them to create complex renderings.

Drawables allow you to easily customize the rendering of the widgets without subclassing them. As a matter of fact, they are so convenient that most of the default Android apps and widgets are built using drawables; there are about 700 drawables used in the core Android framework. Because drawables are used so extensively throughout the system, Android optimizes them when they are loaded from resources. For instance, every time you create a Button, a new drawable is loaded from the framework resources (android.R.drawable.btn_default). This means all buttons across all the apps use a different drawable instance as their background. However, all these drawables share a common state, called the "constant state." The content of this state varies according to the type of drawable you are using, but it usually contains all the properties that can be defined by a resource. In the case of a button, the constant state contains a bitmap image. This way, all buttons across all applications share the same bitmap, which saves a lot of memory.

The following diagram shows what entities are created when you assign the same image resource as the background of two different views. As you can see, two drawables are created but they both share the same constant state, hence the same bitmap:

This state sharing feature is great to avoid wasting memory but it can cause problems when you try to modify the properties of a drawable. Imagine an application with a list of books. Each book has a star next to its name, totally opaque when the user marks the book as a favorite, and translucent when the book is not a favorite. To achieve this effect, you would probably write the following code in your list adapter's getView() method:

Book book = ...;
TextView listItem = ...;

listItem.setText(book.getTitle());

Drawable star = context.getResources().getDrawable(R.drawable.star);
if (book.isFavorite()) {
star.setAlpha(255); // opaque
} else {
star.setAlpha(70); // translucent
}

Unfortunately, this piece of code yields a rather strange result, all the drawables have the same opacity:

This result is explained by the constant state. Even though we are getting a new drawable instance for each list item, the constant state remains the same and, in the case of BitmapDrawable, the opacity is part of the constant state. Thus, changing the opacity of one drawable instance changes the opacity of all the other instances. Even worse, working around this issue was not easy with Android 1.0 and 1.1.

Android 1.5 offers a very way to solve this issue with a the new mutate() method. When you invoke this method on a drawable, the constant state of the drawable is duplicated to allow you to change any property without affecting other drawables. Note that bitmaps are still shared, even after mutating a drawable. The diagram below shows what happens when you invoke mutate() on a drawable:

Let's update our previous piece of code to make use of mutate():

Drawable star = context.getResources().getDrawable(R.drawable.star);
if (book.isFavorite()) {
star.mutate().setAlpha(255); // opaque
} else {
star. mutate().setAlpha(70); // translucent
}

For convenience, mutate() returns the drawable itself, which allows to chain method calls. It does not however create a new drawable instance. With this new piece of code, our application now behaves correctly:

If you want to learn more cool techniques, come join us at Google I/O. Members of the Android team will be there to give a series of in-depth technical sessions and answer all your questions.

Related Posts Plugin for WordPress, Blogger...