Pages

Ads 468x60px

Thursday, February 25, 2010

Mobile Solutions @ the NAB Show in Las Vegas






There have been some rapid changes over the last few years that those in the digital broadcasting community face. The 2010 NAB Show is the place to discover new opportunities for all those in the broadcaster world.

The NAB Show is coming up on April 10-15 in Las Vegas.

For a taste of what the 2010 NAB Show has to offer, check out what Destination Broadband and the Broader casting Conference has to offer in 2010 and discover the latest trends and gadgets in broadband technology.

In particular, Destination Broadband will feature the latest in mobile technologies, including mobile video, networks, and content delivery.A must for anyone in the mobile media distribution space.

Destination Broadband: See site here
Broader-casting Conference: See site here

Oh, and just because you are reading my blog, I’m giving out a code for FREE ACCESS to the exhibit floor at the show. This free Exhibits Only pass includes:

- Access to the Opening Keynote and State of the Industry Address
- Info Sessions
- Content Theater & Destination Broadband Theater

Visit here to redeem or register here with the code A913 (and feel free to pass this along).

You can check out more information and register on the official show website here

Monday, February 22, 2010

Mobile World Congress 2010 (#mwc10) Summary



























BARCELONA-With the MWC maelstrom over, now is a good time for me to reflect on last week's show and share my thoughts about the experience.




This was my fourth Mobile World Congress and while it may not put me in the Veterans Club (and my repeated meetings with mobilists from the 'Cannes days' made me keenly aware of this), it does give me some insight into how the mobile ecosystem is evolving, at least since the dawn of the 'Mobile 2.0' days.



Overall, attendance was probably lower than last year and the fill-rate of the trade floor was below 100%, but this was no surprise. What surprised me was the general positive feeling (especially compared to last year) amongst participants that 'the worst was over'. In fact, the show was buzzier than many people had expected and there was clear evidence that while some incumbents were still in the doldrums (read mobile operators), newcomers were seeing decent growth (read content developers).



The App Planet may have been physically located at the far end of the show but in terms of buzz, it sat squarely in the centre of the show. Ok, there were some companies in Hall 7 that could only loosely be associated with Apps, but it was here that the various developer conferences took place and that the smaller, innovative content companies were to be found.



The WipJam event on the last day of the show tackled many of the challenges facing developers in the increasingly competitive world of apps (kudos to Caroline & the team for a great event):



-how do you get your app to be discovered

- how do you monetize your apps

- how do you create addictive apps

-how do you sell cross-platform



and many more issues.



I took part in two discussion groups on ‘Marketing Apps’ and ‘Features of Addictive Apps’. Both were extremely valuable. From the first one, I took away some interesting points on 'app discoverability' using Pinch/Flurry tools as well as a pointer to the presentation below from Mobile Monday Silicon Valley:













...to be continued...

Thursday, February 11, 2010

Service API changes starting with Android 2.0

Service API changes starting with Android 2.0

Watching developers use the Android platform the last year has shown a number of trouble areas in the Service API as well as growing issues in the ways services operate. As a result, Android 2.0 introduced a number of changes and improvements in this area for both developers and users.

The three main changes to be aware of are:

  • Service.setForeground() is now deprecated and in 2.0 does nothing.
  • There were many edge cases in the service lifecycle that made it very easy to accidentally leave a service running; new APIs in 2.0 make this much easier to deal with.
  • Android 2.0 also introduces a new UI for end users to monitor and manage the running services on their device.

Background on services

Before going into the details of 2.0, it may be useful to go over a quick summary of services. The Service API in Android is one of the key mechanisms for applications to do work in the background. Due to the way Android is designed, once an application is no longer visible to the user it is generally considered expendable and a candidate to be killed by the system if it ever needs memory elsewhere. The main way applications get around this is by starting a Service component, which explicitly tells the system that they are doing some valuable work and would prefer that the system not kill their process if it doesn't truly need to.

This is a very powerful facility but along with that power comes some responsibility: an actively running service is taking resources away from other things that can run (including inactive processes in the background that don't need to be initialized the next time the user visits them). It is thus important that developers take care when designing their services that they only run when truly needed and avoid any bugs where they may accidentally leave the service running for long durations.

Redesigning Service.setForeground()

During the final stabilization period of Android 1.6 we started to see more issues due to an increasing number of applications using the Service.setForeground() API when they shouldn't be. This is an API that we haven't advertised much because it should not be used by most applications and can be very hard on the system: it asks that the service's process be treated as in the foreground, essentially making it unkillable and thus more difficult for the system to recover from low memory situations.

At that point in 1.6 it was too late to make any significant changes to the behavior here, but in 2.0 we have done so: Service.setForeground() now does nothing. The API was always intended to be something a service would do in conjunction with putting up an ongoing notification for the user; by saying you are in the foreground, the user should be "aware" that the service is running in some way and know how to stop it. Thus in place of the old API Andriod 2.0 introduces two new APIs that require a notification go along with being in the foreground:


public final void startForeground(int id, Notification notification);
public final void stopForeground(boolean removeNotification);

This also not coincidentally makes it much easier to manage the notification state along with the service, since the system can now guarantee that there is always a notification while the service is in the foreground, and that the notification goes away whenever the service does.

Many developers will want to write a service that works on older platforms as well as 2.0 and later; this can be accomplished by using something like the following code to selectively call the new APIs when they are available.


private static final Class[] mStartForegroundSignature = new Class[] {
int.class, Notification.class};
private static final Class[] mStopForegroundSignature = new Class[] {
boolean.class};

private NotificationManager mNM;
private Method mStartForeground;
private Method mStopForeground;
private Object[] mStartForegroundArgs = new Object[2];
private Object[] mStopForegroundArgs = new Object[1];

@Override
public void onCreate() {
mNM = (NotificationManager)getSystemService(NOTIFICATION_SERVICE);
try {
mStartForeground = getClass().getMethod("startForeground",
mStartForegroundSignature);
mStopForeground = getClass().getMethod("stopForeground",
mStopForegroundSignature);
} catch (NoSuchMethodException e) {
// Running on an older platform.
mStartForeground = mStopForeground = null;
}
}

/**
* This is a wrapper around the new startForeground method, using the older
* APIs if it is not available.
*/
void startForegroundCompat(int id, Notification notification) {
// If we have the new startForeground API, then use it.
if (mStartForeground != null) {
mStartForegroundArgs[0] = Integer.valueOf(id);
mStartForegroundArgs[1] = notification;
try {
mStartForeground.invoke(this, mStartForegroundArgs);
} catch (InvocationTargetException e) {
// Should not happen.
Log.w("MyApp", "Unable to invoke startForeground", e);
} catch (IllegalAccessException e) {
// Should not happen.
Log.w("MyApp", "Unable to invoke startForeground", e);
}
return;
}

// Fall back on the old API.
setForeground(true);
mNM.notify(id, notification);
}

/**
* This is a wrapper around the new stopForeground method, using the older
* APIs if it is not available.
*/
void stopForegroundCompat(int id) {
// If we have the new stopForeground API, then use it.
if (mStopForeground != null) {
mStopForegroundArgs[0] = Boolean.TRUE;
try {
mStopForeground.invoke(this, mStopForegroundArgs);
} catch (InvocationTargetException e) {
// Should not happen.
Log.w("MyApp", "Unable to invoke stopForeground", e);
} catch (IllegalAccessException e) {
// Should not happen.
Log.w("MyApp", "Unable to invoke stopForeground", e);
}
return;
}

// Fall back on the old API. Note to cancel BEFORE changing the
// foreground state, since we could be killed at that point.
mNM.cancel(id);
setForeground(false);
}

Service lifecycle changes

Another situation we were increasingly seeing in 1.6 was that, even ignoring the services that inappropriately make themselves foreground, we had a growing number of devices with a large number of services running in the background all fighting each other over the available memory.

Part of this problem is services that are running more than they should or there simply being too much stuff trying to be done on the device. However, we also found many issues in the interaction between services and the platform that made it easy for an application to leave a service running even when it is trying to do the right thing. Consider this typical scenario:

  1. An application calls startService().
  2. That service gets onCreate(), onStart(), and then spawns a background thread to do some work.
  3. The system is tight on memory, so has to kill the currently running service.
  4. Later when memory is free, the service is restarted, and gets onCreate() called but not onStart() because there has not been another call to startService() with a new Intent command to send it.

Now the service will sit there created, not realizing it used to be doing some work, and so not knowing it should stop itself at some point.

To address this, in Android 2.0 Service.onStart() as been deprecated (though still exists and operates as it used to in previous versions of the platform). It is replaced with a new Service.onStartCommand() callback that allows the service to better control how the system should manage it. The key part here is a new result code returned by the function, telling the system what it should do with the service if its process is killed while it is running:

  • START_STICKY is basically the same as the previous behavior, where the service is left "started" and will later be restarted by the system. The only difference from previous versions of the platform is that it if it gets restarted because its process is killed, onStartCommand() will be called on the next instance of the service with a null Intent instead of not being called at all. Services that use this mode should always check for this case and deal with it appropriately.
  • START_NOT_STICKY says that, after returning from onStartCreated(), if the process is killed with no remaining start commands to deliver, then the service will be stopped instead of restarted. This makes a lot more sense for services that are intended to only run while executing commands sent to them. For example, a service may be started every 15 minutes from an alarm to poll some network state. If it gets killed while doing that work, it would be best to just let it be stopped and get started the next time the alarm fires.
  • START_REDELIVER_INTENT is like START_NOT_STICKY, except if the service's process is killed before it calls stopSelf() for a given intent, that intent will be re-delivered to it until it completes (unless after some number of more tries it still can't complete, at which point the system gives up). This is useful for services that are receiving commands of work to do, and want to make sure they do eventually complete the work for each command sent.

For compatibility with existing applications, the default return code for applications that are targeting an earlier version of the platform is a special START_STICKY_COMPATIBILITY code that provides the old behavior of not calling onStart() with a null intent. Once you start targeting API version 5 or later, the default mode is START_STICKY and you must be prepared to deal with onStart() or onStartCommand() being called with a null Intent.

You can also easily write a Service that uses both the old and new APIs, depending on the platform. All you need to do is compile against the 2.0 SDK with this code:


// This is the old onStart method that will be called on the pre-2.0
// platform. On 2.0 or later we override onStartCommand() so this
// method will not be called.
@Override
public void onStart(Intent intent, int startId) {
handleStart(intent, startId);
}

@Override
public int onStartCommand(Intent intent, int flags, int startId) {
handleStart(intent, startId);
return START_NOT_STICKY;
}

void handleStart(Intent intent, int startId) {
// do work
}

New "running services" user interface

Our final issue to address is the case where there are simply too many service running in the amount of memory available on a device. This may be due to bugs or design flaws in installed applications, or the user simply trying to do too much. Historically users have had no visibility into what is going on at this level in the system, but it has become important to expose this, at least for lower-end devices, as the use of services has had an increasing impact on the user experience.

To help address this, Android 2.0 introduces a new "Running Services" activity available from the Application system settings. When brought up, it looks something like this:

Running Services

The main content is a list of all running services that may be of interest to the user, organized by the processes they run in. In the example here, we see three services:

  • GTalkService is part of the standard Google application suit; it is running in Google's "gapps" process, which currently consumes 6.8MB. It has been started for 3 hours 55 minutes, which on this device is the time from when it was first booted.
  • ActivityService is part of the Phonebook app, and its process consumes 4MB. This also has been running since boot.
  • SoftKeyboard is a third party input method. It has been running since I switched to it, about 4 minutes ago.

The user can tap on any of these services to control it; for normal services that are running because they were explicitly started, this will present a dialog allowing the user to explicitly stop it:

Stop Service

Some other services, like the input method, are running for other reasons. For these, tapping on the service will go to the corresponding UI to manage it (in this case the system's input settings).

Finally, along the bottom of the screen are some obscure numbers. If you know how to interpret them, this gives you a lot of information on the memory status of your device:

  • Avail: 38MB+114MB in 25 says that the device has 38MB of completely free (or likely used for unrequired caches) memory, and has another 114MB of available memory in 25 background processes it can kill at any time.
  • Other: 32MB in 3 says that the device has 32MB of unavailable memory in 3 unkillable processes (that is, processes that are currently considered to be foreground and must be kept running)

For most users, this new user interface should be a much more effective way to manage the background applications on their device than the existing "task killer" applications. In the vast majority of cases the reason for a slow running device is too many services trying to run. This prevents the system from being able to run any background processes (which speed up app switching), and ultimately can result in thrashing through the services when not even they can all be kept running. The Running Services UI is intended to provide very specific information about the services that are running, to help make a good decision about what should be stopped. It also does not use the API to force stop an application, which can unintentionally break applications in numerous ways.

For developers, this is an important tool to ensure your services are well behaved. As you develop your app, be sure to keep an eye on Running Services to ensure that you are not accidentally leaving your services running when they shouldn't be. You should also now keep in mind that users may freely stop any of your services as they wish, without your control, and account for that.

Android's Services are a very powerful tool, but one of the main and subtle ways that application developers can harm the overall experience a user has with their phone.

Tuesday, February 9, 2010

Mobile World Congress 2010 Agenda Planning in Barcelona














BARCELONA -The coming week in Barcelona is set to be as buzzing and intense as ever during Mobile World Congress time, with an agenda packed chock-full of seminars, development days, meetings, parties, PR stunts and more.

The key to success as always will be to pre-select and prioritise carefully which events to attend (there are simply too many good ones to attend, unless you happen to have a body clone out there!) . This will depend on personal and company preferences and your specific objectives for the event. I recommend jotting down between 3-5 things you want to take away from the show (and side-events) and then matching that to your planned timetable. Is your key objective to learn about open development environments but have no time booked in to learn about Android? It could be worth re-jigging your agenda.

A few events on my agenda so far:

Innovation Exchange 2010

I've been invited to take part in a Panel Discussion at the Innovation Exchange 2010 (Applications & Monetization) event hosted by Qtel with support from the GSMA and MEF on the 13th\14th of February at the Hotel Skipper.

Social Media Round Table

I'll also be taking part in a Social Media Round Table discussion on Monday 15th February hosted by ACS at the Gran Marina to talk about "Capturing the Power of Social Media to Revolutionize the Customer Experience"

App Planet

I'm looking forward to the App Planet event in Hall 7 at the Mobile World Congress on Weds February 17th where SonyEricsson will have a 'Creation Day' for developers. The Xperia X10 Android device has had some rave reviews, so I'm interested to see whether developers are excited about generating content for it.

WIP Jam

The WIP Jam session at the Congress (registration now closed) on the 18th will feature a discussion panel on Augmented Reality applications and will help answer the question of whether the hype is justified. As AR is a hot topic, this is an unmissable session (more info here).

TechCrunch Europe

Finally, there is the Techcrunch event on the 17th Feb (offsite from the Congress) featuring Ilja Laurs of GetJar amongst others, and bringing investors and start-ups together (more info here).

I'll also be exhibiting in the Innovation Zone of the MWC at the GeoMe Stand: if you're a blog reader and you're at the fair or one of the other events, come and say hello! If you can't find me, send me a tweet @ricferraro.

Friday, February 5, 2010

Live wallpapers

With the introduction of live wallpapers in Android 2.1, users can now enjoy richer, animated, interactive backgrounds on their home screen. A live wallpaper is very similar to a normal Android application and has access to all the facilities of the platform: SGL (2D drawing), OpenGL (3D drawing), GPS, accelerometers, network access, etc. The live wallpapers included on Nexus One demonstrate the use of some of these APIs to create fun and interesting user experiences. For instance, the Grass wallpaper uses the phone's location to compute sunrise and sunset times in order to display the appropriate sky.

Creating your own live wallpaper is easy, especially if you have had previous experience with SurfaceView or Canvas. To learn how to create a live wallpaper, you should check out the CubeLiveWallpaper sample provided with the Android 2.1 SDK; you will find it in the directory platforms/android-2.1/samples/CubeLiveWallpaper.

A live wallpaper is very similar to a regular Android service. The only difference is the addition of a new method, onCreateEngine() whose goal is to create a WallpaperService.Engine. The engine is responsible for handling the lifecycle and the drawing of a wallpaper. The system provides you with a surface on which you can draw, just like you would with a SurfaceView. Drawing a wallpaper can be very expensive so you should optimize your code as much as possible to avoid using too much CPU, not only for battery life but also to avoid slowing down the rest of the system. That is also why the most important part of the lifecycle of a wallpaper is when it becomes invisible. When invisible, for instance because the user launched an application that covers the home screen, a wallpaper must stop all activity.

The engine can also implement several methods to interact with the user or the home application. For instance, if you want your wallpaper to scroll along when the user swipes from one home screen to another, you can use onOffsetsChanged(). To react to touch events, simply implement onTouchEvent(MotionEvent). Finally, applications can send arbitrary commands to the live wallpaper. Currently, only the standard home application sends commands to the onCommand() method of the live wallpaper:

  • android.wallpaper.tap: When the user taps an empty space on the workspace. This command is interpreted by the Nexus and Water live wallpapers to make the wallpaper react to user interaction. For instance, if you tap an empty space on the Water live wallpaper, new ripples appear under your finger.
  • android.home.drop: When the user drops an icon or a widget on the workspace. This command is also interpreted by the Nexus and Water live wallpapers.

Please note that live wallpaper is an Android 2.1 feature. To ensure that only users with devices that support this feature can download your live wallpaper, remember to add the following to your manifest before releasing to Android Market:

  • <uses-sdk android:minSdkVersion="7" />, which lets Android Market and the platform know that your application is using the Android 2.1 version.
  • <uses-feature android:name="android.software.live_wallpaper" />, which lets the Android Market and the platform know that your application is a live wallpaper.

Many great live wallpapers are already available on Android Market and we can't wait to see more!

Related Posts Plugin for WordPress, Blogger...