OpenData Feeds - PostRank (PostRank: Best)

Android’s HTTP Clients

Thu, 29 Sep 2011 10:17:00 GMT

[This post is by Jesse Wilson from the Dalvik team. —Tim Bray]

Most network-connected Android apps will use HTTP to send and receive data. Android includes two HTTP clients: HttpURLConnection and Apache HTTP Client. Both support HTTPS, streaming uploads and downloads, configurable timeouts, IPv6 and connection pooling.

Apache HTTP Client

DefaultHttpClient and its sibling AndroidHttpClient are extensible HTTP clients suitable for web browsers. They have large and flexible APIs. Their implementation is stable and they have few bugs.

But the large size of this API makes it difficult for us to improve it without breaking compatibility. The Android team is not actively working on Apache HTTP Client.

HttpURLConnection

HttpURLConnection is a general-purpose, lightweight HTTP client suitable for most applications. This class has humble beginnings, but its focused API has made it easy for us to improve steadily.

Prior to Froyo, HttpURLConnection had some frustrating bugs. In particular, calling close() on a readable InputStream could poison the connection pool. Work around this by disabling connection pooling:

private void disableConnectionReuseIfNecessary() {
    // HTTP connection reuse which was buggy pre-froyo
    if (Integer.parseInt(Build.VERSION.SDK) < Build.VERSION_CODES.FROYO) {
        System.setProperty("http.keepAlive", "false");
    }
}

In Gingerbread, we added transparent response compression. HttpURLConnection will automatically add this header to outgoing requests, and handle the corresponding response:

Accept-Encoding: gzip

Take advantage of this by configuring your Web server to compress responses for clients that can support it. If response compression is problematic, the class documentation shows how to disable it.

Since HTTP’s Content-Length header returns the compressed size, it is an error to use getContentLength() to size buffers for the uncompressed data. Instead, read bytes from the response until InputStream.read() returns -1.

We also made several improvements to HTTPS in Gingerbread. HttpsURLConnection attempts to connect with Server Name Indication (SNI) which allows multiple HTTPS hosts to share an IP address. It also enables compression and session tickets. Should the connection fail, it is automatically retried without these features. This makes HttpsURLConnection efficient when connecting to up-to-date servers, without breaking compatibility with older ones.

In Ice Cream Sandwich, we are adding a response cache. With the cache installed, HTTP requests will be satisfied in one of three ways:

Fully cached responses are served directly from local storage. Because no network connection needs to be made such responses are available immediately.
Conditionally cached responses must have their freshness validated by the webserver. The client sends a request like “Give me /foo.png if it changed since yesterday” and the server replies with either the updated content or a 304 Not Modified status. If the content is unchanged it will not be downloaded!
Uncached responses are served from the web. These responses will get stored in the response cache for later.

Use reflection to enable HTTPS response caching on devices that support it. This sample code will turn on the response cache on Ice Cream Sandwich without affecting earlier releases:

private void enableHttpResponseCache() {
    try {
        long httpCacheSize = 10 * 1024 * 1024; // 10 MiB
        File httpCacheDir = new File(getCacheDir(), "http");
        Class.forName("android.net.http.HttpResponseCache")
            .getMethod("install", File.class, long.class)
            .invoke(null, httpCacheDir, httpCacheSize);
    } catch (Exception httpResponseCacheNotAvailable) {
    }
}

You should also configure your Web server to set cache headers on its HTTP responses.

Which client is best?

Apache HTTP client has fewer bugs on Eclair and Froyo. It is the best choice for these releases.

For Gingerbread and better, HttpURLConnection is the best choice. Its simple API and small size makes it great fit for Android. Transparent compression and response caching reduce network use, improve speed and save battery. New applications should use HttpURLConnection; it is where we will be spending our energy going forward.

A Deep Dive Into Location

Thu, 23 Jun 2011 15:08:00 GMT

[This post is by Reto Meier, Tech Lead for Android Developer Relations, who wrote the book on Android App development. — Tim Bray]

I'm a big fan of location-based apps, but not their seemingly-inevitable startup latency.

Whether it's finding a place to eat or searching for the nearest Boris Bike, I find the delay while waiting for the GPS to get a fix, and then for the results list to populate, to be interminable. Once I’m in a venue and ready to get some tips, check-in, or review the food, I’m frequently thwarted by a lack of data connection.

Rather than shaking my fist at the sky, I’ve written an open-source reference app that incorporates all of the tips, tricks, and cheats I know to reduce the time between opening an app and seeing an up-to-date list of nearby venues - as well as providing a reasonable level of offline support — all while keeping the impact on battery life to a minimum.

Show Me the Code

You can check-out the Android Protips for Location open source project from Google Code. Don’t forget to read the Readme.txt for the steps required to make it compile and run successfully.

What Does it Actually Do?

It uses the Google Places API to implement the core functionality of apps that use location to provide a list of nearby points of interest, drill down into their details, and then check-in/rate/review them.

The code implements many of the best-practices I detailed in my Google I/O 2011 session, Android Protips: Advanced Topics for Expert Android Developers (video), including using Intents to receive location updates, using the Passive Location Provider, using and monitoring device state to vary refresh rates, toggling your manifest Receivers at runtime, and using the Cursor Loader.

The app targets Honeycomb but supports Android platforms from 1.6 and up.

Nothing would make me happier than for you to cut/copy/borrow / steal this code to build better location-based apps. If you do, I’d love it if you told me about it!

Now that you’ve got the code, let’s take a closer look at it

My top priority was freshness: Minimize the latency between opening the app and being able to check in to a desired location, while still minimizing the impact of the app on battery life.

Related requirements:

The current location has to be found as quickly as possible.
The list of venues should update when the location changes.
The list of nearby locations and their details must be available when we’re offline.
Check-ins must be possible while we’re offline.
Location data and other user data must be handled properly (see our prior blog post on best practices).

Freshness means never having to wait

You can significantly reduce the latency for getting your first location fix by retrieving the last known location from the Location Manager each time the app is resumed.

In this snippet taken from the GingerbreadLastLocationFinder, we iterate through each location provider on the device — including those that aren't currently available — to find the most timely and accurate last known location.

List matchingProviders = locationManager.getAllProviders();
for (String provider: matchingProviders) {
  Location location = locationManager.getLastKnownLocation(provider);
  if (location != null) {
    float accuracy = location.getAccuracy();
    long time = location.getTime();
        
    if ((time > minTime && accuracy < bestAccuracy)) {
      bestResult = location;
      bestAccuracy = accuracy;
      bestTime = time;
    }
    else if (time < minTime && 
             bestAccuracy == Float.MAX_VALUE && time > bestTime){
      bestResult = location;
      bestTime = time;
    }
  }
}

If there is one or more locations available from within the allowed latency, we return the most accurate one. If not, we simply return the most recent result.

In the latter case (where it’s determined that the last location update isn't recent enough) this newest result is still returned, but we also request a single location update using that fastest location provider available.

if (locationListener != null &&
   (bestTime < maxTime || bestAccuracy > maxDistance)) { 
  IntentFilter locIntentFilter = new IntentFilter(SINGLE_LOCATION_UPDATE_ACTION);
  context.registerReceiver(singleUpdateReceiver, locIntentFilter);      
  locationManager.requestSingleUpdate(criteria, singleUpatePI);
}

Unfortunately we can’t specify “fastest” when using Criteria to choose a location provider, but in practice we know that coarser providers — particularly the network location provider — tend to return results faster than the more accurate options. In this case I’ve requested coarse accuracy and low power in order to select the Network Provider when it’s available.

Note also that this code snippet shows the GingerbreadLastLocationFinder which uses the requestSingleUpdate method to receive a one-shot location update. This wasn’t available prior to Gingerbread - check out the LegacyLastLocationFinder to see how I have implemented the same functionality for devices running earlier platform versions.

The singleUpdateReceiver passes the received update back to the calling class through a registered Location Listener.

protected BroadcastReceiver singleUpdateReceiver = new BroadcastReceiver() {
  @Override
  public void onReceive(Context context, Intent intent) {
    context.unregisterReceiver(singleUpdateReceiver);
      
    String key = LocationManager.KEY_LOCATION_CHANGED;
    Location location = (Location)intent.getExtras().get(key);
      
    if (locationListener != null && location != null)
      locationListener.onLocationChanged(location);
      
    locationManager.removeUpdates(singleUpatePI);
  }
};

Use Intents to receive location updates

Having obtained the most accurate/timely estimate of our current location, we also want to receive location updates.

The PlacesConstants class includes a number of values that determine the frequency of location updates (and the associated server polling). Tweak them to ensure that updates occur exactly as often as required.

// The default search radius when searching for places nearby.
public static int DEFAULT_RADIUS = 150;
// The maximum distance the user should travel between location updates. 
public static int MAX_DISTANCE = DEFAULT_RADIUS/2;
// The maximum time that should pass before the user gets a location update.
public static long MAX_TIME = AlarmManager.INTERVAL_FIFTEEN_MINUTES;

The next step is to request the location updates from the Location Manager. In this snippet taken from the GingerbreadLocationUpdateRequester we can pass the Criteria used to determine which Location Provider to request updates from directly into the requestLocationUpdates call.

public void requestLocationUpdates(long minTime, long minDistance, 
  Criteria criteria, PendingIntent pendingIntent) {

  locationManager.requestLocationUpdates(minTime, minDistance, 
    criteria, pendingIntent);
}

Note that we're passing in a Pending Intent rather than a Location Listener.

Intent activeIntent = new Intent(PlacesConstants.ACTIVE_LOCATION_UPDATE_ACTION);
locationListenerPendingIntent = PendingIntent.getBroadcast(
  this, 0, activeIntent, PendingIntent.FLAG_UPDATE_CURRENT);

I generally prefer this over using Location Listeners as it offers the flexibility of registering receivers in multiple Activities or Services, or directly in the manifest.

In this app, a new location means an updated list of nearby venues. This happens via a Service that makes a server query and updates the Content Provider that populates the place list.

Because the location change isn’t directly updating the UI, it makes sense to create and register the associated LocationChangedReceiver in the manifest rather than the main Activity.

The Location Changed Receiver extracts the location from each update and starts the PlaceUpdateService to refresh the database of nearby locations.

public void onReceive(Context context, Intent intent) {
  String key = LocationManager.KEY_LOCATION_CHANGED;
  if (intent.hasExtra(key)) {
    Location location = (Location)intent.getExtras().get(key);

    Intent updateServiceIntent = 
      new Intent(PlacesConstants.PLACES_UPDATE_SERVICE_ACTION);
    updateServiceIntent.putExtra(PlacesConstants.EXTRA_KEY_LOCATION, location);
    updateServiceIntent.putExtra(PlacesConstants.EXTRA_KEY_RADIUS,
                                 PlacesConstants.DEFAULT_RADIUS);
    updateServiceIntent.putExtra(PlacesConstants.EXTRA_KEY_FORCEREFRESH, true);
    context.startService(updateServiceIntent);
  }
}

Monitor inactive providers for a better option

The snippet from PlacesActivity below shows how to monitor two important conditions:

The Location Provider we are using being deactivated.
A better Location Provider becoming available.

In either case, we simply re-run the process used to determine the best available provider and request location updates.

// Listens for the provider I'm using being disabled. 
IntentFilter intentFilter = new 
  IntentFilter(PlacesConstants.ACTIVE_LOCATION_UPDATE_ACTION);
registerReceiver(locProviderDisabledReceiver, intentFilter);

// Listen for a better provider becoming available.
String bestProvider = locationManager.getBestProvider(criteria, false);
String bestAvailableProvider = locationManager.getBestProvider(criteria, true);
if (bestProvider != null && !bestProvider.equals(bestAvailableProvider))
  locationManager.requestLocationUpdates(bestProvider, 0, 0, 
    bestInactiveLocationProviderListener, getMainLooper());

Freshness means always being up to date. What if we could reduce startup latency to zero?

You can start the PlacesUpdateService in the background to refresh the list of nearby locations while your app is in the background. Done correctly, a relevant list of venues can be immediately available when you open the app.

Done poorly, your users will never find this out as you’ll have drained their battery too quickly.

Requesting location updates (particularly using the GPS) while your app isn’t in the foreground is poor practice, as it can significantly impact battery life. Instead, you can use the Passive Location Provider to receive location updates alongside other apps that have already requested them.

This extract from the FroyoLocationUpdateRequester enables passive updates on Froyo+ platforms.

public void requestPassiveLocationUpdates(long minTime, long minDistance, PendingIntent pendingIntent) {
  locationManager.requestLocationUpdates(LocationManager.PASSIVE_PROVIDER,
    PlacesConstants.MAX_TIME, PlacesConstants.MAX_DISTANCE, pendingIntent);    
}

As a result receiving background location updates is effectively free! Unfortunately the battery cost of your server downloads aren’t, so you’ll still need to carefully balance how often you act on passive location updates with battery life.

You can achieve a similar effect in pre-Froyo devices using inexact repeating non-wake alarms as shown in the LegacyLocationUpdateRequester.

public void requestPassiveLocationUpdates(long minTime, long minDistance, 
  PendingIntent pendingIntent) {

  alarmManager.setInexactRepeating(AlarmManager.ELAPSED_REALTIME,   
    System.currentTimeMillis()+PlacesConstants.MAX_TIME, 
    PlacesConstants.MAX_TIME, pendingIntent);    
}

Rather than receiving updates from the Location Manager, this technique manually checks the last known location at a frequency determined by the maximum location update latency.

This legacy technique is significantly less efficient, so you may choose to simply disable background updates on pre-Froyo devices.

We handle updates themselves within the PassiveLocationChangedReceiver which determines the current location and starts the PlaceUpdateService.

if (location != null) {
  Intent updateServiceIntent = new 
    Intent(PlacesConstants.PLACES_UPDATE_SERVICE_ACTION);
  
  updateServiceIntent.putExtra(PlacesConstants.EXTRA_KEY_LOCATION, location);
  updateServiceIntent.putExtra(PlacesConstants.EXTRA_KEY_RADIUS, 
    PlacesConstants.DEFAULT_RADIUS);
  updateServiceIntent.putExtra(PlacesConstants.EXTRA_KEY_FORCEREFRESH, false);
  context.startService(updateServiceIntent);   
}

Using Intents to passively receive location updates when your app isn't active

You’ll note that we registered the Passive Location Changed Receiver in the application manifest.

As a result we can continue to receive these background updates even when the application has been killed by the system to free resources.

This offers the significant advantage of allowing the system to reclaim the resources used by your app, while still retaining the advantages of a zero latency startup.

If your app recognizes the concept of “exiting” (typically when the user clicks the back button on your home screen), it’s good form to turn off passive location updates - including disabling your passive manifest Receiver.

Being fresh means working offline

To add offline support we start by caching all our lookup results to the PlacesContentProvider and PlaceDetailsContentProvider.

Under certain circumstances we will also pre-fetch location details. This snippet from the PlacesUpdateService shows how pre-fetching is enabled for a limited number of locations.

Note that pre-fetching is also potentially disabled while on mobile data networks or when the battery is low.

if ((prefetchCount < PlacesConstants.PREFETCH_LIMIT) &&
    (!PlacesConstants.PREFETCH_ON_WIFI_ONLY || !mobileData) &&
    (!PlacesConstants.DISABLE_PREFETCH_ON_LOW_BATTERY || !lowBattery)) {
  prefetchCount++;
      
  // Start the PlaceDetailsUpdateService to prefetch the details for this place.
}

We use a similar technique to provide support for offline checkins. The PlaceCheckinService queues failed checkins, and checkins attempted while offline, to be retried (in order) when the ConnectivityChangedReceiver determines that we’re back online.

Optimizing battery life: Smart Services and using device state to toggle your manifest Receivers

There's no point running update services when we aren’t online, so the PlaceUpdateService checks for connectivity before attempting an update.

NetworkInfo activeNetwork = cm.getActiveNetworkInfo();
boolean isConnected = activeNetwork != null &&
                      activeNetwork.isConnectedOrConnecting();

If we’re not connected, the Passive and Active Location Changed Receivers are disabled and the the ConnectivityChangedReceiver is turned on.

ComponentName connectivityReceiver = 
  new ComponentName(this, ConnectivityChangedReceiver.class);
ComponentName locationReceiver = 
  new ComponentName(this, LocationChangedReceiver.class);
ComponentName passiveLocationReceiver = 
  new ComponentName(this, PassiveLocationChangedReceiver.class);

pm.setComponentEnabledSetting(connectivityReceiver,
  PackageManager.COMPONENT_ENABLED_STATE_ENABLED, 
  PackageManager.DONT_KILL_APP);
            
pm.setComponentEnabledSetting(locationReceiver,
  PackageManager.COMPONENT_ENABLED_STATE_DISABLED, 
  PackageManager.DONT_KILL_APP);
      
pm.setComponentEnabledSetting(passiveLocationReceiver,
  PackageManager.COMPONENT_ENABLED_STATE_DISABLED, 
  PackageManager.DONT_KILL_APP);

The ConnectivityChangedReceiver listens for connectivity changes. When a new connection is made, it simply disables itself and re-enables the location listeners.

Monitoring battery state to reduce functionality and save power

When your phone is on its last 15%, most apps are firmly in the back seat to conserving what watts you have remaining. We can register manifest Receivers to be alerted when the device enters or leaves the low battery state.

This snippet from the PowerStateChangedReceiver disables the PassiveLocationChangedReceiver whenever the device enters a low battery state, and turns it back on once the battery level is okay.

boolean batteryLow = intent.getAction().equals(Intent.ACTION_BATTERY_LOW);
 
pm.setComponentEnabledSetting(passiveLocationReceiver,
  batteryLow ? PackageManager.COMPONENT_ENABLED_STATE_DISABLED :
               PackageManager.COMPONENT_ENABLED_STATE_DEFAULT,  
  PackageManager.DONT_KILL_APP);

You can extend this logic to disable all prefetching or reduce the frequency of your updates during low battery conditions.

What’s Next?

This is already a monster post, so I’m going to leave it there. I’ll follow up in the next week with a post on my personal blog, The Radioactive Yak, that will go in to more detail on the psychic and smooth elements of this app like using the Backup Manager and the Cursor Loader.

I also plan to build a similar reference app for news apps, so that I can spend more time reading and less time wa

53 New APIs: Google+ Hangouts, PicYou, 2009 Recovery Act data

Sun, 25 Sep 2011 09:00:00 GMT

This week we had 53 new APIs added to our API directory including a photo sharing service, web application analytics service, video chat service, Recovery Act 2009 data, web advertising analytics service and a cloud database service. Below are more details on each of these new APIs.

Adigami Web Analytics API: Adigami offers a web analytics monitoring and aggregation tool that lets users view their data in a single dashboard. The REST API is designed to jumpstart developers who need access to all the major web advertising analytics data. Support is included for Google AdWords and Analytics, Microsoft adCenter (Bing and Yahoo search ads), Facebook Ads, Facebook Social (Graph API), DoubleClick (display and search results from ReportCentral), Yahoo APT (display ads),and Twitter. It gives users a few dozen or so standard calls that are applicable across many platforms. Responses are formatted in JSON.

Archimedes Project Donatus API: The Donatus system provides a unified frontend to a variety of morphological analysis software and databases. Morphological services are provided through an XML-RPC interface that can be utilized by specialized user applications. In addition to providing access to pre-existing linguistic data, Donatus allows for the dynamic extension of morphological datasets by a user. The API can be used to abstract the linguistic content of a document from its structure and to add entries to the databases.

Burstly API: Burstly is a monetization platform for application developers. It allows developers to integrate ads into their applications for profit.

The Burstly Download Tracking API allows developers to track downloads of their applications, as well as the ad conversions within the applications.

Chicago Metropulse API: The Metropulse website is a joint project of the Chicago Metropolitan Agency for Planning (CMAP) and The Chicago Community Trust (the Trust). Metropulse makes available data about the regional quality of life over time in metropolitan Chicago. Available data sets include demographic, economic, transportation and related data for the greater Chicago region.

The Metropulse API is a service of CMAP. It uses RESTful and GETful protocols and returns responses in XML, AMF and HTML formats.

Cing API: Cing is a deal service that provides daily emails, as well as search on their website, for available deals in a city. Deals include food and drink, services, events, retail, and other activities.

The Cing API allows developers to access deal information from Cing. The API can be used to search and retrieve all available deals within a 25-mile radius of a zip code. The API returns merchant information and deal information.

CloudSigma API: CloudSigma is an Infrastructure-as-a-Service (IaaS) provider offering high availability, flexible cloud servers and cloud hosting. The API provides access to the full feature set including user management, drives management, servers management and more. The API uses RESTful calls and responses are formatted in TXT.

Curebit API: Curebit is a social marketing campaign platform that enables companies to get their customers to refer their friends from social networking services to purchase their products or services.

The Curebit API allows developers to access the subscribe function in Curebit. As the API is in the initial stage, developers are asked to contact Curebit if they plan on using the API.

Data Translation Web Service (DTWS) API: The Data Translation Web Service (DTWS) is a service of NASA/Goddard Space Flight Center's Space Physics Data Facility (SPDF) to facilitate and promote data exchanges among space scientists. DTWS supports data in Common Data Format (CDF). The API uses the SOAP protocol and allows users to translate one or more local and/or remote files into other data formats.

Demandware Open Commerce API: Demandware offers an on-demand ecommerce platform and is the ecommerce foundation of more than 200 ecommerce websites. The Open Commerce APIs let developers build shopping widgets and experiences – including transactions – external of the native Demandware Commerce platform by allowing outside web applications and enterprise software to interface with all shopping functionality.

Developers can extend enterprise and commerce functionality to Facebook applications, shoppable blogs, mobile and tablet applications, and recommendation widgets. The APIs expose functionality such as product, catalog, search, promotion, customer account, cart and checkout. Full documentation is not publicly available.

Dialogue Bulk SMS API: Dialogue provides interactive services for mobile messaging and mobile billing. Dialogue’s bulk SMS API product lets users send bulk SMS text messages to global networks from their applications using an SMS gateway platform. Users can connect to Dialogue’s SMS gateway platform with one of the following SMS API interfaces: HTTP, SOAP, SMTP, SMPP. Developers must contact Dialogue for API documentation.

Edupedia API: Edupedia bills their service as a social learning platform. Edupedia is designed for teachers and students in primary and secondary schools in Hong Kong. All content is from Wikipedia and classified according to the Hong Kong Curriculum Development Program, to enable teachers and students to more quickly search for and use Wikipedia.

Edupedia provides an API so that schools and other developers can integrate the site content with their applications. Documentation is available to registered members only.

EncoderCloud API: EncoderCloud is a service that allows users to encode video files into compatible formats for web and mobile from any website or application EncoderCloud is integrating into.

The EncoderCloud API allows developers to integrate EncoderCloud functionality into other websites and applications. Some example API methods include accessing encoding job information and status, creating a new encoding job, and retrieving notifications and details about encoding jobs.

ERS/USDA Per Capita Food Availability Data API: The Economic Research Service (ERS) is a primary source of economic information and research in the U.S. Department of Agriculture (USDA). The Food Availability (per capita) Data System provides data series on food and nutrient availability. The API provides access to this data using the SOAP protocol and returns responses in .NET DataTable/DataSet and XML.

FluidVM API: FluidVM is a service that handles systems management, local and iSCSI SAN storage, and network management, along with supporting virtualization technologies, web hosting, and data center environments. For integration into existing products, FluidVM provides an XML-RPC API and a JSON based proxy service. The FluidVM API can handle starting and executing multiple queued tasks, and can later retrieve the status of any tasks. FluidVM also provides two different license options, a permanent license or a monthly license.

Game Jolt API: Game Joltis a web site and community centered on free online video games. The API provides access to site data. Data includes users, sessions, trophies, scores and the data store. The API uses RESTful calls and responses are formatted in XML and JSON.

Google Plus Hangouts API: Google+ Hangouts is a feature of Google Plus that lets users video chat in the same room as their friends while on the web. The Google+ Hangouts JavaScript API allows users to develop collaborative apps that run inside of a Google+ Hangout. Hangout apps are like normal web apps, but with the addition of the rich, real-time functionality provided by the Hangouts APIs. Apps have the ability to control aspects of the user interface, synchronize data between hangout participants, list hangout participants and respond to various events in the hangout.

GroundLink API: GroundLink is a platform that aggregates, manages, and executes ground transportation services. GroundLink works with consumers, travel agents, and travel and transportation providers to offer an engine where users can search for and book ground transportation.

The GroundLink API allows developers to integrate and access GroundLink functionality and data into other applications. The three API methods are converting addresses to geocode, searching for transportation, and booking transportation.

GroupFlier API: GroupFlier is platform to set up group communications. Users can set up groups to share text messages, voicemails, and conference calls.

The GroupFlier API allows developers to integrate the functionality of GroupFlier into other applications. Some example API methods include creating and managing groups, finding and managing group members, managing and creating messages, and accessing account information.

Health Indicators Warehouse API: The Health Indicators Warehouse (HIW) is a collaboration of many agencies and offices within the Department of Health and Human Services. The HIW is maintained by the Center for Disease Control’s National Center for Health Statistics. The purpose of HIW is to "provide a single, user-friendly, source for national, state, and community health indicators; meet the needs of multiple population health initiatives; facilitate harmonization of indicators across initiatives; link indicators with evidence-based interventions; serve as the data hub for the HHS Community Health Data Initiative to release data, encourage innovative application development, and catalyze change to improve community health."

The HIW provides an API which uses both the SOAP and RESTful protocols.

iDirectDebit API: iDirectDebit provides payment processing services in the UK and abroad including paper and paperless Direct Debits, credit cards, debit cards, checks and postal orders. The iDirectDebit API allows service users to integrate sign up functionality into third party applications. The API supports the creation of a customized Direct Debit sign up wizard and allows Direct Debit Instructions (DDIs) to be easily managed and maintained. It provides users with control over branding, payer sign up, Direct Debit collections, edits, confirmation and reports. The API uses RESTful calls and responses are formatted in XML. Full documentation is not publicly available.

IMG to CSS API: IMG to CSS is a conversion tool that converts image files into HTML/CSS. Using IMG to CSS, users can make sure their images will be seen in emails, as email clients won't block CSS.

The IMG to CSS API allows developers to access the functionality of IMG to CSS. The API method is generating CSS from image files.

Inveni API: Inveni is a movie and TV show recommendation service. Inveni uses both an algorithm and recommendations from user's friends to recommend new movies and TV shows based on a user's taste profile. Inveni also integrates with Netflix.

Inveni has an API that is available to business partners, but public documentation and information is not available. Those interested should email bizdev@inveni.com to learn more.

Let's Crate API: Let's Crate is a file sharing service that allows users to create "crates" to upload files to and generate a link to share with others.

The Let's Crate API allows developers to access data from Let's Crate. Some example API methods include listing files, uploading files, deleting files, adding crates, listing crates, and deleting crates.

Loggr API: Loggr is a service that provides web application analytics. Loggr includes event logging, analytics, and notifications. The analytics and information are completely searchable for users.

The Loggr API allows developers to access and integrate Loggr functionality and data into other applications. Some example API methods include searching and listing event logs, listing and creating events, listing and creating alerts, and listing and creating bookmarks of events.

Melissa Data Data Quality Suite API: Melissa Data provides data quality and data integration services to websites and businesses. Their data can be used to standardize, verify and validate a business' contact data. The Data Quality Suite is a toolkit of APIs for postal address verification, phone verification, email validation and name parsing. The APIs use both REST and SOAP protocol and responses are formatted in XML.

Monitro API: Monitro is a website monitoring service. Users can monitor up to three sites for free, and then subscribe to monitor more sites. Monitro will let users know if and when their sites monitored go down.

Monitro's API is in beta stage, and is asking for developers to let them know if they would like to access the API. Interested developers should email support@monitro.net for access. Some example API methods include adding, deleting, and editing URLs to be monitored, turning on and off monitoring services, and accessing account information.

MultiURL API: MultiURL is a tool that lets users combine multiple links into one short link that that can be shared with others. It makes the process of sharing multiple links at once easier, quicker and safer. The links are trackable to see who opens them, as well as customizable.

The MultiURL API allows developers to integrate the functionality of MultiURL into other applications. Some example API methods include creating a new group of links, deleting links, and accessing information about the links.

MyAnimeList API: MyAnimeList.net is an anime and manga community that introduces visitors to people, anime, manga, and helps them organize their collections. The API lets users interact with the site's data programatically. Functionality includes site search, anime and manga listing, and account verification. The API uses RESTful calls and responses are formatted in XML.

NASA Coordinated Data Analysis System (CDAS) API: The Coordinated Data Analysis System (CDAS) supports the plotting of data variables from multiples instruments produced by multiple space physics investigations. Any data that has been produced in Common Data Format (CDF) with the ISTP/IACG Guidelines is accessible. CDAS is a service of NASA/GSFC Space Physics Data Facility (SPDF). There are about 600+ data variables from Geotail, Wind, Interball, Polar, SOHO, ancilliary spacecraft and ground-based investigations accessible in the publicly available database.

The CDAS Web Services API allows developers to access CDAS data services.

Newsfeed Lab API: Newsfeed Lab is a hosted API for adding scalable news feeds and activity streams to web and mobile apps. Users can add single or multiple news feeds to their apps and can have newsfeeds across multiple apps depending on their plan. The API uses RESTful calls and responses are formatted in JSON.

Overpass OpenStreetMap API: OpenStreetMap is a free editable map of the whole world, made by users, that allows users to view, edit and use geographical data in a collaborative way from anywhere on Earth. The OpenStreetMap Overpass API is a read-only API that returns XML encoded OSM map data in response to requests.

PicYou API: PicYou is a photo sharing site that also works with Facebook and Twitter. Users can upload photos, edit and enhance photos, and share with their friends.

The PicYou API allows developers to access and integrate PicYou functionality into other applications. Some example API methods include uploading photos, retrieving recently added photos, and accessing information about photos.

Planbox API: Planbox is a project

Short List of RESTful API Frameworks for PHP

Fri, 23 Sep 2011 01:00:00 GMT

Having a web API is an essential part of doing business online today. We wanted to help get you started. So we took some time to pull together a list of the RESTful or RESTish (however you choose to view it) API frameworks, that can help you deploy your API faster.

Today we are going to take a look at seven RESTful API frameworks for PHP:

Dave - DAVE is a minimalist, multi-node, transactional API framework written in PHP. which contains an end-to-end API test suite for TDD, a Task model, an Active Database Model, and a stand-alone development server to get you started. DAVE is an acronym that stands for Delete, Add, Edit, and View. These 4 methods make up the core functionality of many transactional web applications. The DAVE API aims to simplify and abstract may of the common tasks that these types of APIs require.

Epiphany – A micro PHP framework that's fast, easy, clean and RESTful. The framework does not do a lot of magic under the hood. It is, by design, very simple and very powerful. The documentation provides a few conventions that will lead to well better code, but you're free to use any style you'd like. According to Epiphany, the framework never dictates how you should write or structure your application.

FRAPI - FRAPI is a high-level API framework that powers web apps, mobiles services and legacy systems, enabling a focus on business logic and not the presentation layer. FRAPI handles multiple media types, response codes and generating API documentation. FRAPI was originally built by echolibre to support the needs of their client’s web apps, and now it’s been open-sourced.

Recess - Recess is a RESTful PHP framework that can be used by both beginner and seasoned developers. Recess is fast, light-weight, and has a very small footprint—ideal for LAMP development and drag-and-drop deployment to shared hosts. Recess is a modern framework that uses a loosely-coupled Model-View-Controller architecture designed and optimized specifically for PHP 5.

Slim - What began as a weekend project became a simple yet powerful PHP 5 framework to create RESTful web applications. The Slim micro framework is everything you need and nothing you don't. Slim lets you build a complete PHP web service with only a single PHP file. Features include: RESTful routing, Named routes, Route passing, Route redirects, Route halting, Custom views, HTTP caching, Signed cookies, Custom 404 page, Custom 500 page, Error handling and Logging.

Tonic – Tonic is an open source less is more, RESTful Web application development PHP library, where everything useful is a resource, not a file, not a CGI script, a resource, an abstract concept of something useful that the client wants to grab hold of. Resources are located by URLs, URLs are cheap and form the universal addressing system of the Web. Tonic helps you develop Web applications that embrace the way the Web really works, enabling your applications to scale, extend and work with other systems easily.

Zend Framework – Zend_Rest_Server is intended as a fully-featured REST server. To call a Zend_Rest_Server service, you must supply a GET and POST methods, with a value that is the method you wish to call. You can then follow that up with any number of arguments using either the name of the argument or using arg following by the numeric position of the argument. When returning values, you can return a custom status, you may return an array with each status.

There are a number of Web and MVC frameworks out there that will also deliver a RESTful API, but the above frameworks focus more towards just delivering a RESTful API.

If you know of any RESTful API framework written in PHP that you’d recommend, please let us know.

Early Winners and Losers of the Platform Wars

Thu, 22 Sep 2011 01:00:00 GMT

Delyn Simons is Director of Developer Relations for Mashery (a ProgrammableWeb sponsor). Delyn previously worked in developer community for eBay and still believes that people are basically good.

A long time ago in Internet years, in a galaxy not so far away, a handful of tech titans in Silicon Valley and Seattle began building business platforms and battling for supremacy. The mobile device and app revolution hadn't yet begun. Terms like “social networking” and “wisdom of crowds” were going “viral”. Web services and APIs were still emerging. The Google IPO of late 2004 had effectively slammed shut the Web 1.0 dotbomb era, paving the way for the amazing evolution of Web 2.0 services in 2005 that hit the mainstream in 2006.

Looking back, 2006 was a pivotal year for tech. Amazon Web Services introduced S3 and EC2 in 2006, completely rewriting the conventional cost benchmarks for funding tech startups. MySpace was vying for the most highly trafficked site on the Internet with Google and Yahoo! Facebook was an upstart university and high school social networking site that wouldn’t open its doors to the public until that Fall. Yahoo! was in the Terry Semel era of building its new media empire. TomKat would descend upon campus for Yahoo! employee meetings, Beck would play at its Hack Days, and business models behind newly acquired Flickr, del.icio.us, and Upcoming would happen in time. Google paid over $1B for new video-sharing service YouTube. A ‘microblogging' service called Twitter launched as an extremely open developer platform. Digg was cool. The Zune had potential.

Five years later, it is easier to see now that thinking and acting like a platform was one of the clearest differentiators between winners and losers of these initial platform battles. For these pioneering companies who architected their platforms back in 2006 or earlier, however, the battlefield of today’s full-blown Platform Wars has now changed under their feet. Mobile and location strategies are now as important as social. The app economy has disrupted traditional product channels, enabling independent developers to distribute applications directly to consumers. The product and feature demands of 2011 have evolved, but in many cases the open platforms that developers are using to build applications have not kept pace.

In my recent talk at Salesforce.com's Dreamforce event, “Your API is So 2006”, I shared some top platform trends that companies might consider in order to modernize their services and APIs. Architecting your platform to meet 2011 development standards is one of the best ways you can to enable your company to meet the demands of today’s competitive markets. Thinking like a platform also helps your business prepare for disruptive forces you cannot possibly predict:

1) REST is Best: Particularly for mobile and front end developers, RESTful APIs that include the option of JSON output formats are an increasing trend. Over 70% of all APIs in ProgrammableWeb's API Directory are restful, increasingly at the expense of SOAP. More than 55% of those same APIs support JSON output, with 20% opting not to offer XML at all. Platforms that support modern protocols, formats and outputs enable developers to build great mobile, social, and location-aware experiences for their customers.

2) Chat less, Do more: Chatty protocols are out; push notifications are in. Etsy, Flickr, Salesforce.com, eBay, and Foursquare are just a few of the APIs that allow developers to utilize push notifications instead of constant polling to trigger event-based client notifications for mobile devices. If you don't offer push, you aren’t making it easy enough to build real-time functionality your users crave.

3) Interactive API Documentation: Long form, technical manual documentation is great for reference, but not so great for trying to get started building with an API quickly. APIs including klout, alibris, posterous, wordnik, and fanfeedr are following a trend of combining testing tool functionality with API documentation. The result is interactive documentation that returns live data to developers, so they can explore new APIs, learn the underlying call structures, and debug methods quickly.

4) The Most Value May Come From Within: People hear the word “API” and often assume third party developers will primarily consume the API. More and more companies, including Twitter, netflix, and npr, are architecting their APIs to optimize for internal and partner value. Company executives who treat and fund their API as a science experiment instead of a core business driver are not helping their companies realize the full value potential of their API.

5) Disruption Happens: Myopic, inward focus is a historically dangerous vantage point from which to address disruptive market forces. From the telegraph and railroads of the 19th century to the newspaper, airline travel, and telecommunications industries of today, disruption happens. Businesses who think like a platform can react to disruption more quickly, pivoting entire business models if necessary. The next airbnb, square, spotify, or skype will eventually happen in your industry. In a world of accelerating industry disruption, consolidation and fragmentation, APIs help prepare your company to take advantage.

Look back to 2006 one more time, then fast forward to the business realities of today. Would you rather be Amazon or Borders? Facebook or MySpace? Netflix or Blockbuster? iTunes or any record label you can name? Best Buy or Circuit City? There are already early winners and losers of the Platform Wars. When you think like a platform and meet the needs of mobile and web developers today, your business is more likely to weather the inevitable disruptions of tomorrow. Prepare to be resilient. Market forces that will change your business are already forming and heading your way.

Related ProgrammableWeb Resources

Etsy API Profile, 18 mashups

Flickr API Profile, 583 mashups

Salesforce.com API Profile, 43 mashups

eBay API Profile, 213 mashups

Foursquare API Profile, 51 mashups

Klout API Profile, 3 mashups

Alibris API Profile, 1 mashup

Posterous API Profile, 2 mashups

Wordnik API Profile, 2 mashups

FanFeedr Sports News API Profile, 11 mashups

Twitter API Profile, 618 mashups

Netflix API Profile, 21 mashups

NPR API Profile, 5 mashups

Spotify Metadata API Profile, 15 mashups

Skype API Profile, 28 mashups

Euro Android Developer Labs

Wed, 21 Sep 2011 10:26:00 GMT

This series started last month, and now registration is open for the European leg:

Berlin — September 28 and 29.
London — October 3 and 5.
Paris — TBD (late October), but register now.

Remember, this ADL series isn’t another set of introduction-to-Android sessions, nor any other kind of general overview. It's specifically aimed at optimizing Android apps for tablets, in particular creating high-quality tablet apps with an emphasis on polish and user-experience.

Registration is a two-step process. Anyone can register, but we can only accommodate a relatively small number of attendees from among the registrants, based on whether they already have an Android app with the potential to be a top-tier tablet app in terms of quality, fit, and finish. The goal is to bring your app to the ADL, and leave equipped to make it into one that makes Android tablet users smile.

Preparing for Handsets

Mon, 19 Sep 2011 10:26:00 GMT

[This post is by Scott Main, lead tech writer for developer.android.com. — Tim Bray]

Early this year, Honeycomb (Android 3.0) launched for tablets. Although Honeycomb remains tablets-only, the upcoming Ice Cream Sandwich (ICS) release will support big screens, small screens, and everything in between. This is the way Android will stay from now on: the same version runs on all screen sizes.

Some Honeycomb apps assume that they’ll run only on a large screen, and have baked that into their designs. This assumption is currently true, but will become false with the arrival of ICS, because Android apps are forward-compatible — an app developed for Honeycomb is compatible with a device running ICS, which could be a tablet, a phone, or something else.

So, if you’ve developed a tablet app on Honeycomb, it’s important that your app do one of two things: prevent installation on smaller screens or (preferably) support smaller screens with the same APK.

Making your Honeycomb app for tablets only

If you don’t want your app to be used on handsets (perhaps it truly makes sense only on a large screen) or you need more time to update it, add the following declaration to your manifest:

...

This describes your app’s screen-size support in two different ways:

It declares that the app does not support the screen size buckets “small”, “normal”, and “large”, which are traditionally not tablets
It declares that the app requires a screen size with a minimum usable area that is at least 600dp wide

The first technique is for devices that are running Android 3.1 or older, because those devices declare their size based on generalized screen size buckets. The requiresSmallestWidthDp attribute is for devices running Android 3.2 and newer, which added the capability for apps to specify their size requirements based on a minimum number of density-independent pixels. In this example, the app declares a minimum width requirement of 600dp, which generally implies a 7”-or-greater screen.

Your size choice might be different, of course, based on how well your design works on different screen sizes; for example, if your design works well only on screens that are 9” or larger, you might require a minimum width of 720dp.

The catch is that you must compile your application against Android 3.2 or higher in order to use the requiresSmallestWidthDp attribute. Older versions don’t understand this attribute and will raise a compile-time error. The safest thing to do is develop your app against the platform that matches the API level you’ve set for minSdkVersion. When you’re making final preparations to build your release candidate, change the build target to Android 3.2 and add the requiresSmallestWidthDp attribute. Android versions older than 3.2 simply ignore that XML attribute, so there’s no risk of a runtime failure.

For more information about why the “smallest width” screen size is important for supporting different screen sizes, read New Tools for Managing Screen Sizes (really; it’s got lots of things you need to know).

Making your Honeycomb app work on handsets

On the other hand, if you want to distribute your app to devices of all sizes, we recommend that you update your existing Honeycomb app to work on smaller screens as well, rather than publishing multiple APKs.

Optimizing for handsets can be tricky if your designs currently use all of a large screen to deliver content. It’s worth the effort, though, because Ice Cream Sandwich brings the Honeycomb APIs to handsets and you’ll significantly increase the user-base for your app. Using a single APK for all devices also simplifies your updating and publishing process and makes it easier for users to identify your app.

Here are two guidelines to help make your Honeycomb tablet app work well on handsets:

Build your design around Fragments that you can reuse in different combinations, in single-pane layouts on handsets and multi-pane layouts on tablets
Be conservative with your Action Bar design so the system can adjust its layout based on the screen size

Creating single-pane and multi-pane layouts

The most effective way to optimize your app for both handsets and tablets is to combine fragments in different ways to create “single-pane” layouts for handsets and “multi-pane” layouts for tablets. There are two approaches to doing this:

For any screen in which your tablet version displays multiple fragments, use the same activity for handsets, but show only one fragment at a time — swapping the fragments within the activity when necessary.
Use separate activities to host each fragment on a handset. For example, when the tablet UI uses two fragments in an activity, use the same activity for handsets, but supply an alternative layout that includes just one fragment. When you need to switch fragments (such as when the user selects an item), start another activity that hosts the other fragment.

The approach you choose depends on your app design and personal preferences. The first option (single activity) requires that you dynamically add each fragment to the activity at runtime---rather than declare the fragments in your activity’s layout file — because you cannot remove a fragment from an activity if it’s been declared in the XML layout. You might also need to update the action bar each time the fragments change, depending on what actions or navigation modes are provided for the fragment. In some cases, these factors might not matter to your app, so using one activity and swapping fragments will work well. Other times, however, using just one activity and dynamically swapping fragments can make your code more complicated, because you must manage all the fragment combinations in the activity’s code rather than leveraging alternative layout files.

I’m going to talk about the second option in more detail. It might be a little more up-front work, because each fragment must work well across separate activities, but it usually pays off. It means that you can use alternative layout files that define different fragment combinations, keep fragment code modular, simplify action bar management, and let the system handle all the back stack work.

The following figure demonstrates how an application with two fragments can be arranged for both handsets and tablets when using separate activities for the handset design:

In this app, Activity A is the “main activity” and uses different layouts to display either one or two fragments at a time, depending on the size of the screen. When on a handset-sized screen, the layout contains only Fragment A (the list view); when on a tablet-sized screen, the layout contains both Fragment A and Fragment B.

Here’s res/layout/main.xml for handsets:

And res/layout-large/main.xml for tablets:

How the application responds when a user selects an item from the list depends on whether Fragment B is available in the layout. If Fragment B is there, Activity A notifies Fragment B to update itself. If Fragment B is not in the layout, Activity A starts Activity B (which hosts Fragment B).

To implement this pattern for your application, it's important that you develop your fragments to be highly compartmentalized. Specifically, you should follow two general guidelines:

Do not manipulate one fragment directly from another.
Keep all code that concerns content in a fragment inside that fragment, rather than putting it in the host activity’s code.

To avoid directly calling one fragment from another, declare a callback interface in each fragment class that it can use to deliver events to its host activity, which implements the callback interface. When the activity receives a callback due to an event (such as the user selecting a list item), it acts appropriately based on the current fragment configuration.

For example, Activity A from above handles item selections like this:

/** This is a callback that the list fragment (Fragment A) calls
    when a list item is selected */
public void onItemSelected(int position) {
  DisplayFragment fragB = (DisplayFragment) getFragmentManager()
                              .findFragmentById(R.id.display_frag);
  if (fragB == null) {
      // DisplayFragment (Fragment B) is not in the layout, 
      // start DisplayActivity (Activity B)
      // and pass it the info about the selected item
      Intent intent = new Intent(this, DisplayActivity.class);
      intent.putExtra("position", position);
      startActivity(intent);
  } else {
      // DisplayFragment (Fragment B) is in the layout, tell it to update
      fragB.updateContent(position);
  }
}

When DisplayActivity (Activity B) starts, it reads the data delivered by the Intent and passes it to the DisplayFragment (Fragment B).

If Fragment B needs to deliver a result back to Fragment A, then the process works similarly with a callback interface between Fragment B and Activity B. That is, Activity B implements a callback interface defined by Fragment B. When Activity B gets the callback, it sets the result for the activity and finishes itself. Activity A then receives the result and delivers it to Fragment A.

For a complete demonstration of this technique for creating different fragment combinations for different tablets and handsets, look at the code for this updated version of the Honeycomb Gallery sample (ZIP file).

Making the Action Bar work on handsets

As long as you’ve been using the framework’s implementation of ActionBar for your tablet app (rather than building your own), the conversion from tablets to handsets should be painless. The Android system will do the work for you; all you need to do is ensure that your action bar design is flexible. Here are some important tips:

When setting a menu item to be an action item, avoid using the “always” value. Use “ifRoom” for action items you’d like to add to the action bar. Now, you might need “always” when an action view does not have an alternative action for the overflow menu or when a menu item added by a fragment is low in the menu order and it must jump into the action bar at all times. But you should not use “always” more than once or twice.
When possible, provide icons for all action items and declare showAsAction="ifRoom|withText". This way, if there’s not enough room for the text, but there is enough for the icon, then just the icon may be used.
Avoid using custom navigation modes in the action bar. Use the built-in tab and drop-down navigation modes — they’re designed to be flexible and adapt to different screen sizes. For example, when the width is too narrow for both tabs and other action items, the tabs appear below the action bar. If your app requires a custom navigation mode in the action bar, thoroughly test it on smaller screens when Ice Cream Sandwich becomes available and make any adjustments necessary for a narrow action bar.

For example, the mock ups below demonstrates how the system might adapt an app’s action bar based on the available screen space. On the handset, only two action items fit, so the remaining menu items appear in the traditional menu and the tabs appear in a separate row. On the tablet, more action items can fit in the action bar and so do the tabs.

Some other tips

When working with a ListView, consider how you might provide more or less information in each list item based on the available space. That is, you can create alternative layouts to be used by the items in your list adapter such that a large screen might display more detail for each item.
Create alternative resource files for values such as integers, dimensions, and even booleans. Using size qualifiers for these resources, you can easily apply different layout sizes, font sizes, or enable/disable features based on the current screen size.

Testing your handset support

At this point you might be wondering, “How do I test my layout for smaller screens without a handset that runs Honeycomb?” Well, until Ice Cream Sandwich is available for the SDK, you technically can’t. So don’t publish your changes until you’re able to test on a device or emulator running ICS.

However, you can begin some early testing of your alternative layouts with a little trick: instead of using the “large” configuration qualifier for the tablet layouts, use the “land” qualifier (that is, instead of res/layout-large/main.xml, use res/layout-land/main.xml). This way, a Honeycomb tablet (or emulator) in landscape orientation uses your tablet design and the same device in portrait orientation uses your handset design. Just be certain to switch back to using the size qualifiers once you’re able to test on ICS.

Conclusion

Ice Cream Sandwich is coming, and with it, handsets will be able to install apps built on Honeycomb. We haven’t released the ICS SDK just yet, but you can start preparing your Honeycomb apps by thinking about how they should work on smaller screens.

So if you have a Honeycomb tablet app out there (and by that, I mean an app with minSdkVersion="11" or higher), you should make sure it’s available only on large screen devices for now. We hope that you’ll then follow our advice here and optimize your tablet app to support smaller screens, using the same APK for both tablets and handsets.

If your app supports API levels lower than 11, then there’s probably nothing you need to do right now, because your app is already running on handset devices. When the ICS SDK does arrive, though, it’ll still be important that you verify your app’s performance on the new platform.

Stay tuned to the blog for more information about ICS as it nears release.

40 New APIs: Google Plus, Social Trip Planning, Foodspotting

Sun, 18 Sep 2011 09:00:00 GMT

This week we had 40 new APIs added to our API directory including a social trip planning service, content sharing service, startup financing community, website video recording tool, food review and sharing service, and a mobile marketing service. Below are more details on each of these new APIs.

Add To Trip API: Add to Trip is a centralized white-label, graph-api platform where travelers can collaborate with friends and family on a trip via their website or application.

The Add to Trip API lets users manage a social travel network including user creation/authentication, social notifications, geolocation searches, trip itineraries, travel related objects and more. With the API, developers can create trips; add hotels, flights and more to that trip; invite friends to join the trip via social tools such as Facebook, Twitter and LinkedIn; use geolocation to look up other user's trips and recommendations.

The API also lets users create a social travel graph by relating objects to each other. Users can get information about travel-specific items such as restaurants, hotels, points of interest, activities, shopping, purchase history, and their relationships between each other and people. This functionality allows users to create believable recommendations based on where someone has traveled, their purchase behavior, and their friends. In addition, the Add to Trip API has a messaging mechanism, where any thread of messages can be related to any other API object. The API uses RESTful calls and responses are fomratted in JSON.

Adigami Web Analytics API: Adigami offers an SEO monitoring and aggregation tool that lets users view web analytics data. The REST API gives users access to all the major web advertising analytics data. Support is included for Google AdWords and Analytics Microsoft adCenter (Bing and Yahoo search ads) Facebook Ads Facebook Social (Graph API) DoubleClick (display and search results from ReportCentral) Yahoo APT (display ads) Twitter. It gives users a dozen or so standard calls that are applicable across many platforms. Responses are formatted in JSON.

Amadeus Cruise API: Amadeus is the leading provider of IT solutions and transaction processor to the travel and tourism industry. Amadeus provides processing services including search, pricing, booking and ticketing in real-time to travel providers and travel agencies.

Amadeus Cruise Direct Connect is a worldwide distribution channel and provides a way to book cruises. It enables cruise providers to focus on customer service and reduce call center costs by increasing the automation rate; converting telephone bookings into online bookings.

The API is a connection between the Amadeus system and a user's own reservation system, enabling agencies to view their live, real-time inventory and availability when accessing Amadeus' sales and e-commerce solutions. The API offers the following functionality: distribution via online travel agencies and private-labeled cruise B2B and B2C applications. Full documentation is not publicly available.

AngelList API: AngelList is a community of startups and investors with the goal of making fund raising efficient. Angel investors are listed along with contact information which startups can use to set up introductions. The AngelList API provides developers with a RESTful interface to the AngelList data set. Data includes followers, reviews, startups and more. Responses are formatted in JSON and JSONP.

AudioMicro API: AudioMicro is a stock music and sound effects collection. AudioMicro licenses stock music and sound effects to producers to be included in their media.

The AudioMicro API allows developers to access content and data from AudioMicro to create other applications. Some example API methods include searching the library by category and sub-categories, downloading track URLs, and retrieving the most recent tracks and the most popular tracks.

Automeme API: Automeme is an automated meme generator, churning out random nonsense on demand. The API lets users add memes to their web site or application. It uses RESTful calls and responses are formatted in JSON, HTML and TXT.

CityGroups API: CityGroups is a searchable public directory that allows community organizers and residents to find community groups by location and topic. CityGroups helps connect and publicize these groups by working with local community groups, governments and local technologists to make an open platform for finding and recommending groups working to make cities better.

The directory uses a simple data standard that allows humans and computers to import and export data from the system. Data can be imported using CSV and an API is available that allows for export using JSON. Developers can use this data to build new services on top of the group listings, such as a map, a text-message service, or group-to-group notification system.

Crop PDF for Amazon Kindle API: This API lets users crop their PDF files for maximum readability on Amazon's Kindle. Users can upload a file, crop a single page or crop an entire document. It uses RESTful calls and responses are formatted in JSON.

CS50 HarvardEvents API: HarvardEvents is a calendar app that details events happening around the Harvard campus. The data is also available programaticaly through the RESTful HarvardEvents API in CSV, iCalendar, JSON, JSONP, PHP, RSS, or XML formats. This data can be used to integrate HarvardEvents into a developer's own applications. HarvardEvents is available for Non-Comercial use via a Creative Commons Attribution-Noncommerical 3.0 Unported license. For commercial use, contact the author.

CS50 HarvardMaps API: HarvardMaps is an application that users can use to search and view maps of Harvard and building/hall data for Harvard buildings. The HarvardMaps API allows developers to get data from HarvardMaps programatically in CSV, JSON, PHP, or XML format. This data can be used to integrate HarvardMaps into a developer's own applications. HarvardMaps is available for Non-Comercial use via a Creative Commons Attribution-Noncommerical 3.0 Unported license. For commercial use, contact the author.

DailyTvTorrents API: DailyTvTorrents indexes TV show torrents from the top sites on the web. With the DailyTvTorrents API users can integrate site information into their search engine, site, blog or app. The API also has commands for command-line users to use with curl. Functionality includes getting info about a show, getting episodes of a show including the latest episode, getting info about a torrent and more. It uses RESTful calls and responses are formatted in JSON.

Earth Observing System API: ECHO is the data clearinghouse for the Earth Observing System (EOS), a service provided by NASA's Earth Science Data Information Systems (ESDIS) program. ECHO provides common mechanisms for provider communities to publish their data and service offerings and other mechanisms for consumers to discover, understand, and access those resources.

The API uses the SOAP and REST protocols and returns responses in XML.

Emailloop API: The Emailloop API lets users connect and sync their own databases and applications with their EmailLoop account. Push content and subscribers to EmailLoop or pull campaign reports and updated subscriber lists from EmailLoop. Full documentation is not publicly available.

Erply Inventory API: Erply is a service that offers software as service for retail inventory and e-commerce sites. Erply offers services such as inventory management, point of sale (POS), and sales.

The Erply Inventory API allows developers to access Erply's Inventory functionality and data. Some example API methods include accessing product information, customer information, editing customer information, and sales information.

Exchangery Trading API: The Exchangery is a commodities trading resource. The Exchangery offers users resources for commodity trading, such as technology, infrastructure, regulatory and clearing relationships, and online platforms so exchanges and commodities have a personalized online presence.

The Exchangery API allows developers to access the functionality and data within the Exchangery. Some example API methods include adding and editing information on trades, products, accounts, and screens.

FanBridge API: FanBridge is a customer engagement and reward service. Clients of FanBridge can use their tools to interact with their customers and fans, reward them for being customers and fans, and make new customers and fans.

The FanBridge API allows developers to access the functionality of FanBridge. Some example API methods include creating and sending email campaigns to customers and enabling new customers and fans to join the marketing list.

Fluidinfo API: Fluidinfo is an online information storage and search platform for content publishers. Fluidinfo provides openly writable metadata on all types of items, and also allows data and metadata about web content to be social and searchable. Content owners can publish their content with Fluidinfo, adding metadata and sharing content with others.

The Fluidinfo API allows developers to access the functionality and data of Fluidinfo to build other applications and integrate Fluidinfo into other applications. Some example API methods include searching and retrieving objects, users, and tags and other data included in Fluidinfo. The API uses RESTful calls and responses are formatted in JSON.

Foodspotting API: Foodspotting is a visual food review and sharing site and application. Unlike other food review sites, Foodspotting lets users review dishes, instead of the restaurant. Along with the review, users can upload a photo of the dish, so other users can see what the dish looks like. Within the site and application, users can search by dish, restaurant, or location.

The Foodspotting API allows developers to access and integrate information and images from Foodspotting. Some example API methods include retrieving and uploading images, searching for and retrieving user information, dishes, places, and reviews, and adding reviews and other information.

Framey API: Framey is a JavaScript application that lets users record video on any website. With Framey, users can embed a webcam recorder into their sites. Users can integrate Framey by embedding the recorder, then use a rubygem or provided code snippets to accept updates from the Framey server when new videos are ready. Responses are formatted in JSON.

Google Plus API: Google Plus is a service to share links, photos and other content. The Google Plus API allows developers to access publicly-available Google Plus content, including user information and publicly shared items.

How do you pronounce and use…? API: A multimedia pronunciation dictionary and English word usage API. Search for a word and not only get an audio pronunciation but also tagged and time-stamped videos of real people in real situations speaking and using the word in context.

Ketchup API: Ketchup is a web application for scheduling, planning and taking notes at meetings. The Ketchup API allows users to integrate the service with their own applications. The API exposes functionality that lets users list, show, update and delete meetings, projects, agenda items and notes. It uses RESTful calls and responses are formatted in JSON.

LetsGiftIt API: LetsGiftIt is a service for group gifting. It allows eCommerce and other product and service providers to offer group gifting as an option to buy the goods or services. Users can use LetsGiftIt to buy a gift for someone socially, with other people.

The LetsGiftIt API allows developers to integrate LetsGiftIt functionality into other websites and eCommerce platforms. The main method of the API is creating and adding gifts, listing a title and description of the gift, and other details about the gift.

Memonic API: Memonic is an application that allows users to capture, organize, and share web content. Memonic offers services for personal use, business use, publisher use, and can be used with Evernote.

The Memonic API allows developers to access the functionality and data from Memonic. The API is free for non-commercial use and can be used for commercial use with their approval. Some example API methods include accessing users, sets of users, and groups of users.

Memory Reel API: Memory Reel is an event marketing service. Memory Reel offers clients tools such as event mobile applications, online tools to connect with event attendees, and analytics to measure marketing effectiveness.

The Memory Reel API allows developers to access and integrate Memory Reel functionality and data. Some example API methods include adding and editing events and event information, adding and editing users and their avatars, and listing devices that are available for push notifications.

Mobile Roadie API: Mobile Roadie is a service for musicians to create and manage mobile applications to engage with their fans. Features included with Mobile Roadie include selling tickets to shows, selling music, adding music, and interacting with fans.

The Mobile Roadie API allows developers to access and integrate the functionality and data from Mobile Roadie into other applications such as MySpace. Some example API methods include creating content, adding content, editing content, retrieving comments, and managing users information.

Mobli API: Mobli is a real-time visual media platform social networking service. Through channels, such as people channels, subject channels, event channels, and place channels, users can upload and share media such as photos and videos in real-time.

The Mobli API allows developers to access the data and functionality of Mobli. Public documentation is not available, but interested developers can sign up to request access.

Mogreet API: Mogreet is a mobile marketing service. Mogreet clients can create, manage, and track their mobile marketing campaigns through Mogreet's platform and customer relationship manager (CRM).

The Mogreet API allows developers to access the functionality and service of Mogreet. Some example API methods include sending blasts to lists, managing content, and add and delete users from their mobile marketing lists.

NASDAQ Data-On-Demand API: NASDAQ Data-On-Demand provides historical stock quote data. NASDAQ Data-On-Demand enables users to choose specific symbols and trading time periods for quick and efficient analysis. The data can be used to integrate stock quote data into a developer's application, analyze trends in stock quote data, back test trading strategies and algorithms and build a stock quote book.

An API is provided to pull the data using RESTful or SOAP calls. The API includes calls that let users select historical stock data from the exact trading dates and times, download stock data after the markets close for pre-market analysis and request bulk data downloads. Responses are formatted in XML.

Numote Live API: Numote Live is a platform that allows users to watch TV shows and videos with interactive features. Companies can use the platform to build communities, reward viewers, manage content, and track usage and viewing analytics.

The Numote API allows developers to access and integrate Numote's functionality and data. Public documentation is not available without signing up first. Interested developers or companies should contact support@numnote.com for more information.

OurShelf API: OurShelf is a cataloging site that allows users to list and keep track of their belongings, connect with friends and other users, and sell items that they are no longer using. Users can share information on their belongings, find other people's belongings, and interact with other people.

The OurShelf API allows developers to extend OurShelf into other applications or create new applications based on OurShelf's functionality. The service is in beta and public documentation is not available, but

PayPal and eBay Merge for X.Commerce Innovate Conference

Wed, 14 Sep 2011 10:33:00 GMT

X.Commerce is the new brand for the developer commerce tools that include the eBay API and PayPal API. The first conference under this new brand is coming in October to San Francisco. As a media partner, we have a promo code, as well as a little more information about how the company is looking to create a sum greater than its parts with the X.Commerce platform.

The conference takes place on October 12-13 in San Franscisco. Speakers include eBay CEO John Donahoe; Blake Mycoskie, founder of TOMS Shoes, the company that donates a pair of shoes for each one that you buy; Katie Burke Mitic, Technology Executive at Facebook, and many more. After the days of presentations and strategy discussion you can take part in X DevCamp on Friday the 14th. It will give you a chance to work with seasoned veterans who will guide you through PayPal, eBay, Magento, and X.Commerce implementations. ProgrammableWeb readers will save $100 off the registration fee using promo code “INN2011PW.”

X.Commerce is a platform that combines eBay and PayPal APIs with breadth and depth. PayPal API has options to allow your customers an express checkout option or to schedule recurring payments. EBay opens up just about all its site features to developers, whether its listing, buying or searching for items. Filling out the trio of the X.Commerce platform is Magento, a company which provides a range of solutions from small DIY website design and hosting tools to full-fledged enterprise level e-commerce consultancy services.

The web is still a wide open field for small businesses and X.Commerce is helping them connect to customers online. Even if you aren't selling products yourself, developers can benefit by using the APIs to help those small businesses integrate with eBay, PayPal and Magento.

Related ProgrammableWeb Resources

PayPal API Profile, 30 mashups

eBay API Profile, 213 mashups

Thinking Like a Web Designer

Tue, 13 Sep 2011 10:30:00 GMT

[This post is by Roman Nurik, who is passionate about icons, with input from me and a bunch of the Framework engineers. —Tim Bray]

The number of people working on mobile apps, and specifically Android, is growing fast. Since modern mobile software-development is a relatively new profession, the community is growing by sucking in experts from related domains, one being web design and development.

It turns out that familiarity with web UI development, particularly using modern HTML5 techniques, can be a great primer for Android UI development. The Android framework and SDK have many analogues to tools and techniques in the Web repertoire of HTML, CSS, and JavaScript.

In this blog post, we’ll walk through a few web development features and look for matches in the world of Android UI development.

Device resolutions and physical sizes

One of the most important aspects of both Android UI design and web design is support for multiple screen resolutions and physical sizes. Just as your web app needs to work on any physical display and inside any size browser window, your native app needs to run on a variety of form factors, ranging from 2.5” phones to 10” tablets to (possibly) 50” TVs.

Let’s look at some ways in which CSS and Android allow for flexible and adaptive layouts.

Providing custom layouts for different resolutions

CSS3 media queries allow developers to include additional stylesheets to target different viewport and screen configurations. For example, developers can provide additional style rules or override existing styles for mobile devices. Although the markup (layout hierarchy) remains the same, CSS3 has several sophisticated techniques for completely transforming the placement of elements with different stylesheets.

Android has long offered a similar mechanism in resource directory qualifiers. This extends to many different types of resources (layouts, images or ‘drawables’, styles, dimensions, etc). Thus you can customize the view hierarchy as well as styling depending on device form factor, A base set of layouts for handsets can be extended for tablets by placing additional layouts in res/layout-xlarge or res/layout-sw600dp (smallest width 600 density-independent pixels) directories. Note that the latter syntax requires Android 3.2 or later.

Below is a CSS3 example of how one could hide a ‘left pane’ on smaller devices and show it on screens at least 600 pixels wide:

#leftPane {
  display: none;
}

@media screen and (min-device-width:600px) {
  #leftPane {
    display: block;
  }
}

The same could be accomplished on Android using multiple layout directories:

res/layout/foo.xml:

res/layout-sw600dp/foo.xml:

As a side note, if you plan on creating multi-pane layouts, consider using fragments, which help break up your screens into modular chunks of both layout and code.

There are also other neat ways of using resource directory qualifiers. For example, you could create values/dimens.xml and values-sw600dp/dimens.xml files specifying different font sizes for body text, and reference those values in your layouts by setting android:textSize="@dimen/my_body_text_size". The same could be done for margins, line spacing, or other dimensions to help manage whitespace on larger devices.

‘Holy grail’ layouts

Web developers have long dreamt of an easy way to build a ‘holy grail’ 5-pane layout (header/footer + 3 vertical columns). There are a variety of pre-CSS3 tricks including position:fixed, float:left, negative margins, and so on, to build such layouts but CSS3 introduced the flexible box module, which simplifies this tremendously.

Figure: An archetypal “holy grail” layout

It turns out that grail is pretty holy for Android tablet apps, too, and in particular for tablets held sideways in landscape mode. A good approach involves the use of LinearLayout, one of the simplest and most popular of the Android layouts.

LinearLayout has this neat way to stretch its children to fit the remaining space, or to distribute available space to certain children, using the android:layout_weight attribute. If a LinearLayout has two children with a fixed size, and another child with a nonzero layout_weight, that other child view will stretch to fill the remaining available space. For more on layout_weight and other ways to make layouts more efficient (like switching from nested LinearLayouts to RelativeLayout), check out Layout Tricks: Creating Efficient Layouts.

Let’s take a look at some example code for implementing such a ‘holy grail’ layout on Android and on the web:

Note: Android tablet apps in landscape will generally show an action bar as the top pane and will usually have neither a right nor bottom pane. Also note that the action bar layout is automatically provided by the framework as of Android 3.0, and thus you don’t need to worry about positioning it.

And here’s an example implementation using the CSS3 flexible box model; notice the similarities:

Layered content

In CSS, with position:absolute, you can overlay your UI elements. On Android, you can use FrameLayout to achieve this. The child views in a frame layout are laid out on top of each other, with optional layout_gravity attributes indicating alignment with the parent frame layout.

Below is a contrived example of a FrameLayout with three children.

Figure: Example FrameLayout with three children (2 with top-left and 1 bottom-right alignment)

Figure: Isometric view of the example FrameLayout and its children.

The code for this example is as follows:

Scrollable content

HTML, by default, flows in reading order and scrolls vertically. When content extends beyond the bottom of the browser, scrollbars automatically appear. Content panes can also be made individually scrollable using overflow:scroll or overflow:auto.

Android screen content isn’t scrollable by default. However, many content Views such as ListView and EditText offer scrolling, and any layout can be made scrollable by wrapping it in a ScrollView or HorizontalScrollView.

It’s also possible to add custom scrolling to views by using methods like View.scrollTo and helpers like Scroller in response to touch events. And for horizontal, snap-to-page-bounds scrolling, one can use the excellent new ViewPager class in the support library.

Below is an example of a ScrollView containing a single TextView child and the code needed to implement something like this.

Figure: A TextView inside a ScrollView, scrolled about half way.

Custom layouts

Sometimes the positioning and layout behaviors you can achieve with CSS aren’t enough to achieve your desired layout. In those cases, developers fall back on JavaScript coupled with absolute positioning to place and size elements as needed.

Programmatically defined layouts are also possible on Android. In fact, they’re sometimes the most elegant and/or performant way of implementing a unique or otherwise tricky layout. Not happy with nesting LinearLayouts for implementing a 2x3 grid of navigation icons? Just extend ViewGroup and implement your own layout logic! (see an example DashboardLayout here). All the built-in layouts such as LinearLayout, FrameLayout, and RelativeLayout are implemented this way, so there generally aren’t the same performance implications with custom layouts as there are with scripted layout on the web.

Device densities

Web designers have long dealt with the reality that display densities vary, and that there wasn’t much they could do about it. This meant that for a long time web page graphics and UI elements had different physical sizes across different displays. Your 100px wide logo could be 1” wide on a desktop monitor or ¾” on a netbook. This was mostly OK, given that (a) pointing devices such as mice offered generally good precision in interacting with such elements and (b) browsers allowed visually-impaired users to zoom pages arbitrarily.

However, on touch-enabled mobile devices, designers really need to begin thinking about physical screen size, rather than resolution in pixels. A 100px wide button on a 120dpi (low density) device is ~0.9” wide while on a 320dpi (extra-high density) screen it’s only ~0.3” wide. You need to avoid the fat-finger problem, where a crowded space of small touch targets coupled with an imprecise pointing tool (your finger) leads to accidental touches. The Android framework tries really hard to take your layout and scale elements up or down as necessary to work around device-density differences and get a usable result on a wide range of them. This includes the browser, which scales a 160px at 100% browser zoom up to 240px on a 240dpi screen, such that its physical width is always 1”.

Developers can achieve finer-grained control over this browser scaling by providing custom stylesheets and images for different densities, using CSS3 media query filters such as -webkit-max-device-pixel-ratio and viewport arguments such as target-densitydpi=device-dpi. For an in-depth discussion on how to tame this mobile browser behavior see this blog post: Pixel-perfect Android web UIs.

For native Android apps, developers can use resource directory qualifiers to provide different images per density (such as drawable-hdpi and drawable-mdpi). In addition, Android offers a special dimension unit called ‘density independent pixels’ (dp) which can (and should!) be used in layout definitions to offset the density factors and create UI elements that have consistent physical sizes across screens with different densities.

Features you don’t have out of the box

There are a few features that web designers and developers rely on that aren’t currently available in the Android UI toolkit.

Developers can defer to user-driven browser zooming and two-dimensional panning for content that is too small or too large for its viewport, respectively. Android doesn’t currently provide an out-of-the-box mechanism for two-dimensional layout zooming and panning, but with some extra legwork using existing APIs, these interactions are possible. However, zooming and panning an entire UI is not a good experience on mobile, and is generally more appropriate for individual content views such as lists, photos, and maps.

Additionally, vector graphics (generally implemented with SVG) are gaining in popularity on the Web for a number of reasons: the need for resolution independence, accessibility and ‘indexability’ for text-heavy graphics, tooling for programmatic graphic generation, etc. Although you can’t currently drop an SVG into an Android app and have the framework render it for you, Android’s version of WebKit supports SVG as of Android 3.0. As an alternative, you can use the very robust Canvas drawing methods, similar to HTML5’s canvas APIs, to render vector graphics. There are also community projects such as svg-android that support rendering a subset of the SVG spec.

Conclusion

Web developers have a number of different tools for frontend layout and styling at their disposal, and there are analogues for almost all of these in the world of Android UI engineering. If you’re wondering about analogues to other web- or CSS-isms, start a conversation out there in the Android community; you’ll find you’re not alone.