Mixi’s new platform feature: "Apps for Touch"

We are happy to announce that a smart-phone platform has been launched on mixi Platform.

mixi Platform supports OpenSocial v0.8.1 and have executed applications for two devices “PC desktop” and “Japanese feature-phones” last year. The specification of our feature-phone platform has been proposed as the “OpenSocial WAP extension”, and this specification has been adopted by other platforms in Japan. If you would like to know more, please check the link below:

Recently, we have launched a new feature to mixi Platform. We call it “mixi apps for Touch”. The saturation level of smart-phones is currently increasing in Japan as many people already use the iPhone, and there are many release plans of smart-phones based on Android. Currently, 17 applications have already been launched as mixi apps for Touch, and these developers have attracted many users. The below image is the screenshot of one mixi application executed on the smart-phone. A single mixi application can support three devices — PCs, feature-phones and smrt-phones at same time.

Figure 1. Screenshots of mixi apps for Touch

Basically, mixi apps for Touch is a Web browser based application and is not a native iPhone/Android application which you download from an application market/store. Technically, the view name of mixi apps for Touch is “touch”, and the value of the type attribute is specified as “url”. This definition is written in gadget spec file with definitions for other devices. The below image is the architecture to describe mixi apps for Touch.

Figure 2. Architecture of mixi apps for Touch

The application is executed in the iframe placed on mixi’s page. One of mixi app’s features is that the domain in the iframe is not mixi’s domain, and is of the developer’s server. Therefore, application developers can generate the contents on his/her server similarly to developing a general web site.

Developers need the OpenSocial RESTful API to use social data, and a 2-legged OAuth is adopted to the authorization mechanism. On the other hand, when developers want to use APIs (invitation, posting activity, and etc) with a user-flow (need to show Popup window), a JavaScript file provided by mixi Platform is loaded by using a script tag. The function written in the script file calls the function which exists on the parent frame, and the user-flow will be executed. Of course, Payment and Ad programs are available for monetization (the Payment API is based on OpenSocial Virtual Currency API).

We believe that our platform will be able to bring OpenSocial more scaling to many devices. For more information, please visit our developer’s site “mixi Developer Center”.

For more information, please visit the mixi Developer Center.

Posted on behalf of Yoichiro Tanaka, mixi, Inc., by Mark Weitzel, President, OpenSocial Foundation

Stability in a dynamic world

Technology is not unlike fashion. What was once considered hip and trendy falls out of fashion, only to returned in a retro-improved way after a period of time. I never realized this until I hosted a group of Dutch Waterboards at the ESRI Headquarters in Redlands, CA…

Seeing some of my former clients after some 5 years was a pleasant distraction from the day-to-day business of projects and product development. It provided an opportunity to recollect some of the work we did on creating a common data model for water boards in the Netherlands ten years ago and look at how the goals of that project were doing: share application development to reduce redundant investment, less dependency on a particular application vendor, bridge the information gap between organizational units and business processes, and others.

Although the data model has changed name, its contents are still very much alive. Over the years, the Waterboards have developed several client-server applications that connect to a single data store, thus integrating the various business processes within a Waterboard. All organizational units have the same definition and information for the objects they manage, including but not limited to waterways, hydraulic structures, permits, and numerous other aspects of water management. This would lead you to think: mission accomplished!

But the group of visitors expressed new desires that have come up in this past period that have lead to their study trip to the United States: further separate the layers of the application architecture or the use of new features in supporting software components, to name a few. Over time the client-server pattern has been followed by thin-client and other application architectures. More recently service oriented architectures and the enterprise services bus (or is it services-buzz?) are in-vogue. The accepted styles for user interfaces have changed with those technologies as well. Not that the current application wasn’t meeting the initial needs, but the needs have changed with the advent of new technologies and capabilities: how did we ever do without AJAX?

People trade in their cellphones, not because the old one is broken, but because the new ones have more cool features, and the availability of those features creates the need for them. This is the old supply-demand principle of a market economy.

This principle also applies to software technologies as well. Where a couple years ago the use of HTTP GET/POST protocols for the Open Geospatial Consortium (OGC) services specifications was well accepted, there now is a growing need to add support for SOAP/WSDL to these specifications. Not because HTTP GET/POST doesn’t work, but because the context in which the OGC services are being used is changing to use Service Oriented Architectures (SOA) that require the use of specific standards such as SOAP. Note that the data or the data model that is made accessible through these changing protocols is not affected by the particular choice of protocol.

Well, ever noticed what happens if you use SOAP (most noticable in the shower)? It dissolves and you have to buy new soap! New technologies will come for messaging, information exchange, presentation, aggregation, central versus distributed data management, and what not. Acknowledging this is half the victory of the technology battle: do what makes sense for the foreseeable future, follow the general trends of IT, and assess what and when new technology fits your business needs.

For the Dutch Waterboards, the constact factor in this 10 year period has been the data model, confirming one of the assumptions that lead to the definition of the data model to begin with. The tremendous effort that was put in analysing entity-relationship-diagrams, class-diagrams, data dictionaries, and other exciting materials, proved its value in a world of ever changing technologies.

Appeared in GeoInformatics Magazine (www.geoinformatics.com) in October 2006