Porting PHP to Android

There is already an open-source project called “PHP for Android”(PFA), and its official site is: www.phpforandroid.net/. The source code for porting PHP is available at: http://code.google.com/p/php-for-android/.

However, there are some major limitations of the PFA project. First, the PFA project is based on the SL4A project (Scripting Layer for Android
, official site: http://code.google.com/p/android-scripting/), whose major goal is aimed at providing support for quickly prototype applications for Android on the device itself using high-level scripting languages. To speak more simply, the PFA project, or the SL4A project, are helping you develop Android applications with PHP scripts. But our need is, using PHP to produce dynamic web pages on Android devices, and using web browsers on Android devices to render these web pages. So there will be many differences in the porting architecture.
Seond, the PFA is deployed as a standard Android application. But we simply need a PHP runtime. The PHP runtime will be run as a standalone service by the web server, like CGI. It will be built into the Android system, so we don’t have to wrap it as an Android application.

In the following articles, I will write about how to make a standalone PHP runtime on Android. Some of the work are borrowed from the PFA project, and I will mainly discuss the special work needed for our goal.

A tiny cloud in Android

When I read the article in IBM Developer Network someday in 2010.

The title was so amazing, and I was attracted. Why not realized a web server into Android?

If we had a web server in Android, we had everything, script language, micro database, HTML5 and so on.

The logic became simple, accessible and elegant.

So  I decided to develop a tiny web server in Android, to port script language, in order to make a new development environment in Android.

Bill, Thanx a lot.

A Tiny Cloud = A Big Idea

——————————————-

A tiny cloud in Android

Exploring the Android file system from your browser

Bill Zimmerly, Freelance Writer and Knowledge Engineer, Author

 

Summary:  Cloud computing minimally requires two components: the client software that runs on the portable device and the server software that normally runs on a network server. This article proposes creating an Android-based service that emulates a network server that enhances the value of the local machine in unique and unexpected ways. Put a tiny cloud in your Android handset and experience the usefulness of a local Web server.

Tags for this article:  android, cloud, cloud_computing, open_source, sqlite

 

 

Tag this!Update My dW interests (Log inWhat’s this?)

Skip to help for Update My dW interests

 

Date: 17 Nov 2009
Level: Intermediate
Also available in: Russian Japanese Portuguese

Activity: 30944 views
Comments: 0 (ViewAdd comment – Sign in)

Average rating from 10 votes

(You rated this 5 stars)

 

Android is a special distribution of the Linux® operating system, designed to manage the kind of functionality you expect in the smartest of smart phones. To a programmer, everything in Linux — a device, a spreadsheet, or a favorite song — appears as a file. That is, there is a common set of ways to open, extract, manipulate, and save the information content of these diverse and abstract entities. And this commonality forms the core principle of the UNIX® philosophy: Everything is a file.

Frequently used acronyms

  • MIME: Multipurpose Internet Mail Extension
  • HTML: Hypertext Markup Language
  • SDK: Software development kit
  • WWW: World Wide Web

Files are grouped into useful hierarchies called file systems. An Android cell phone typically has two file systems: the non-volatile memory of the cell phone and the SD card plugged into it. Both appear as branches off the root directory (/). A tool that enabled you to browse these file systems conveniently from your browser could prove useful. This project defines a small program, written in the native language of C, that communicates as a Web server and enables you to browse the Android cell phone’s file systems from your workstation or straight from the built-in browser of the cell phone itself. It provides pages with hyperlinks that enable you to move up and down the hierarchical tree. By clicking various file types listed, you can view the individual items.

Setting up the development environment

First, make sure that you have a “rooted” Android cell phone so you can do things like run Terminal and execute the su command to obtain root privileges. If you don’t know how to “root” your Android phone and obtain these privileges, a quick Internet search should give you what you need. (Note that this process is sometimes called jail-breaking your phone. See Resources for links on how to do this.)

The Android community primarily uses two SDKs. The most familiar one is the high-level Android SDK, which enables you to write application code in the Java™ language and commonly uses Eclipse for writing, testing, and debugging code. Another, less commonly known SDK is the Android kernel source, which is stored in what is known as a git repository. (For links to this repository, see Resources.)

Since this article focuses on creating a low-level Web server that will typically reside in the system/bin directory of your cell phone, it is important to download and install the entire Android kernel source code and the GNU tools used for building it. The home page of the Android Kernel Source project (see Resources) provides simple instructions for downloading the entire platform with a script called repo.

The tiny cloud software will be cross-compiled to the ARM platform on your workstation, so make sure all the necessary tools are installed. Using apt-get, install these tools as shown in Listing 1.

 

Listing 1. Installing cross-compiling tools

 

$ sudo apt-get install git-core gnupg \

sun-java5-jdk flex bison gperf libsdl-dev \

libesd0-dev libwxgtk2.6-dev build-essential \

zip curl libncurses5-dev zlib1g-dev

 

 

 

 


Development directory structure

Use the directory name mydroid to install the Android kernel source. This name makes an effective root directory to work off of, so go to your home directory and issue a mkdir mydroid command. Then use cd mydroid and issue the repo sync command there.

After the repo sync command has downloaded all of the Android source code to your mydriod directory, a few noteworthy subdirectories that were created include:

  • You will be creating the cloud directory inside mydroid/external. The source code for this project (cloud.c) will reside there.
  • After the long-running make command builds the Android system, you will find the binary file cloud inside the out/target/product/generic/system/bin directory.

 


The Android cloud project

When the cloud program starts, it immediately checks to see whether any command-line parameters have been passed to it. The two parameters that are optionally expected are the port to monitor and the home directory to start in. If neither parameter is specified, the program defaults to using the standard port 80, and the default home directory is whatever the current working directory was when the program was started.

After startup, the program initializes the TCP/IP socket to “listen” for calls to it through the aforementioned port, then turns itself into a daemon process, waiting for browser calls and servicing them. When a browser calls the default “page” of this tiny cloud server, the code responds by returning a directory listing of the aforementioned “home” directory. File names are listed with or without a hyperlink, depending on whether they are a known file type or a directory. To be a known file type means (in the WWW world) that the file has a corresponding MIME type. For example, deep in the heart of the Android cell phone, audio ringtones are stored as .ogg files. The MIME type audio/ogg tells the browser to play the file on the loudspeaker, assuming that your browser was configured correctly to do this.

Another hyperlink that appears at the top of the file listings is Parent Directory. Clicking this link allows you to move up the file system hierarchy until you eventually get as high as you can possibly go: the root directory. Along the way, other subdirectory names appear as hyperlinks; if you click them, you will go down into that subdirectory to explore the files contained therein.

So, the cloud application is a useful program for conveniently exploring the file system of the cell phone, and the source code (see Download) provides you with a good template of functionality you can modify as you see fit. Suggested ways to modify the code appear at the end of this article. (You can also compile the code and run it on your workstation, enabling you to browse the workstation’s file systems, too. For instructions on how to do this, see Resources.)

 


The C source code

Every program’s source code should show at minimum the program’s name and author. Listing 2 shows the attribution, the include files from which you’ll be using definitions, and some useful constants.

 

Listing 2. Attribution, includes, and useful constants

// Android Cloud Application by Bill Zimmerly. 

// Based on “NWEB” by Nigel Griffiths.

 

#include <dirent.h>

#include <stdio.h>

#include <stdlib.h>

#include <unistd.h>

#include <errno.h>

#include <string.h>

#include <fcntl.h>

#include <signal.h>

#include <sys/types.h>

#include <sys/socket.h>

#include <netinet/in.h>

#include <arpa/inet.h>

 

#define TRUE      -1

#define FALSE     0

#define SBUF      1048576

#define LBUF      4096

#define LAPN      64

#define ERROR     1

#define LOG       2

#define LOGGING   FALSE

 

 

 

Listing 3 provides the global working storage that is accessible by all functions defined in this program. Most of the buffer pointers are allocated storage when a browser calls the tiny cloud. After returning the content to the browser, the memory allocated is returned to the cell phone. In computers with limited resources, this practice becomes more important than many other considerations.

 

Listing 3. Global working storage

char* about=”</pre>Cloud is a simple application that enables “ 

“web-based browsing of the Android file system ”

“and is intended for use by people who like to ”

“explore the lowest levels of their device. It ”

“runs on a rooted Android phone and is only for ”

“browsing the file system. See the IBM ”

“developerWorks article for a full description ”

“of this application.<pre>”;

 

char* mainbuf;

char* theDir;

char* thePort[8];

char* theList;

char* fstr;

 

char logDir[LBUF];

 

int ret;

 

 

 

In this program, a simple table of file extensions map into the MIME types that browsers need to know to properly handle the file’s content. The structure in Listing 4 is used by the mimeokay function for one purpose: to set the global string pointer fstr to the appropriate MIME type string matching the file’s extension: fext. With this information, the tiny cloud can display the file name with a hyperlink or as plain text without a link. It also serves the dual purpose of providing the MIME type when a file’s content is being sent to the browser.

 

Listing 4. Determining MIME types

struct 

{

char *ext;

char *mimetype;

}

 

mimes [] =

{

{“.htm”,  “text/html”  },

{“.html”, “text/html”  },

{“.xml”,  “text/xml”   },

{“.gif”,  “image/gif”  },

{“.jpg”,  “image/jpeg” },

{“.jpeg”, “image/jpeg” },

{“.png”,  “image/png”  },

{“.log”,  “text/plain” },

{“.conf”, “text/plain” },

{“.rc”,   “text/plain” },

{“.sh”,   “text/plain” },

{“.prop”, “text/plain” },

{“.txt”,  “text/plain” },

{“.TXT”,  “text/plain” },

{“.cpp”,  “text/plain” },

{“.c”,    “text/plain” },

{“.h”,    “text/plain” },

{“.ogg”,  “audio/ogg” },

{0,0}

};

 

void mimeokay(char* fext)

{

int buflen;

int len;

long i;

 

buflen=strlen(fext);

fstr = (char*) 0;

 

for(i=0; mimes[i].ext != 0; i++)

{

len = strlen(mimes[i].ext);

 

if(!strncmp(&fext[buflen-len], mimes[i].ext, len))

{

fstr=mimes[i].mimetype;

break;

}

}

}

 

 

 

Listing 5 shows the optional code that will log Android cloud activity to a cloud.log file during development and testing. Because the cloud runs on relatively slow hardware, it is good to leave this functionality shut off unless you really need to see what’s happening in the code while you’re modifying it. The LOGGING constant in Listing 1 should be TRUE if you want this logging to work, but leave it FALSE when it is running on the cell phone, as the performance hit can be significant.

 

Listing 5. Logging activity

void aclog(int type, char *s1, char *s2, int num) 

{

int fd ;

char aclogbuffer[LBUF];

char logFile[LBUF];

 

if(!LOGGING)

return;

 

switch(type)

{

case ERROR:

sprintf(aclogbuffer, “ERROR: %s:%s Error Number=%d, PID=%d”,

s1, s2,

errno, getpid());

break;

case LOG:

sprintf(aclogbuffer, “INFO: %s:%s:%d”, s1, s2, num);

break;

}

 

strcpy(logFile, logDir);

strcat(logFile, “/cloud.log”);

 

if((fd = open(logFile, O_CREAT | O_WRONLY | O_APPEND,

0644)) >= 0)

{

ret=write(fd, aclogbuffer, strlen(aclogbuffer));

ret=write(fd, “\n”, 1);

close(fd);

}

 

if(type == ERROR)

exit(3);

}

 

 

 

Listing 6 provides several functions defined for the purpose of creating the HTML output of the tiny cloud. Note that every page of a well-designed Web site should maintain a common look, and the buildbuf function is where this overall look is defined.

 

Listing 6. Generating HTML output

void apname(void) 

{

strcat(mainbuf, “Android Cloud Application”);

}

 

void buildbuf(char* data)

{

mainbuf[0]=0;

strcat(mainbuf, “<html>\n<head>\n<title>”);

apname();

strcat(mainbuf, “</title>\n</head>\n”);

strcat(mainbuf, “<body>\n<h3>”);

apname();

strcat(mainbuf, “</h3>\n”);

strcat(mainbuf, “<a href=\”/About_\”>About</a><br>\n”);

strcat(mainbuf, “<a href=\”/Home_\”>Home</a><br>\n”);

strcat(mainbuf, “<hr>\n”);

strcat(mainbuf, “Dir: “);

strcat(mainbuf, theDir);

strcat(mainbuf, “<br>\n<hr>\n<pre>\n”);

strcat(mainbuf, data);

strcat(mainbuf, “\n</pre>\n”);

strcat(mainbuf, “</body>\n</html>\n”);

}

 

void htmlout(int fd, char* data)

{

fstr=mimes[0].mimetype;

sprintf(mainbuf, “HTTP/1.0 200 OK\r\nContent-Type: %s\r\n\r\n”, fstr);

ret=write(fd, mainbuf, strlen(mainbuf));

buildbuf(data);

ret=write(fd, mainbuf, strlen(mainbuf));

}

 

void error404(int fd)

{

fstr=mimes[0].mimetype;

sprintf(mainbuf, “HTTP/1.0 404 OK\r\nContent-Type: %s\r\n\r\n”, fstr);

ret=write(fd, mainbuf, strlen(mainbuf));

buildbuf(“404 Error – File not found!”);

ret=write(fd, mainbuf, strlen(mainbuf));

}

 

 

 

Listing 7 shows how the tiny cloud returns the content of a file with a defined MIME type. Notice how the browser expects the MIME type to be sent from the server as a Content-Type: string. By just clicking the cloud-generated links, this function is called upon to return the content of that file. If, however, a creative and mischievous soul edits a bad file name in his browser’s address bar, the error404 function (defined above) will inform the user of it.

 

Listing 7. Returning file contents

void retfile(int fd, int hit) 

{

int file_fd;

long ret;

 

mimeokay(mainbuf);

 

if(fstr == 0)

{

error404(fd);

return;

}

 

if((file_fd = open(&mainbuf[4], O_RDONLY)) == -1)

{

error404(fd);

}

else

{

aclog(LOG, “SEND”, &mainbuf[4], hit);

 

sprintf(mainbuf, “HTTP/1.0 200 OK\r\nContent-Type: %s\r\n\r\n”, fstr);

ret=write(fd, mainbuf, strlen(mainbuf));

 

while((ret=read(file_fd, mainbuf, SBUF)) > 0 )

{

ret=write(fd, mainbuf, ret);

}

}

}

 

 

 

Listing 8 shows how the tiny cloud builds the main file listing with hyperlinks. The hyper function is used several times, so it is prudent to factor it out into its own function. The isDir value prepends the /CD_ text before the full path to the file name so that the tiny cloud knows that it must display the contents of that directory. The fileList function is truly the heart and soul of this application.

 

Listing 8. Directory listing functions

void hyper(int isDir, char* name) 

{

strcat(theList, “<a href=\”");

 

if(isDir)

strcat(theList, “/CD_”);

 

strcat(theList, (char*) theDir);

 

if(strcmp(theDir, “/”))

strcat(theList, “/”);

 

strcat(theList, name);

strcat(theList, “\”>”);

strcat(theList, name);

strcat(theList, “</a>”);

strcat(theList, “\n”);

}

 

char* fileList(void)

{

struct dirent **namelist;

int n;

long i;

long j;

 

theList[0]=0;

 

n=scandir(“.”, &namelist, 0, (void*) alphasort);

 

if (n < 0)

perror(“scandir”);

else

{

for(i=0; i<n; i++)

{

if(namelist[i]->d_type == DT_DIR)

{

if(!strcmp(namelist[i]->d_name, “.”))

{

// strcat(theList, namelist[i]->d_name);

}

else if(!strcmp(namelist[i]->d_name, “..”))

{

if(strcmp(theDir, “/”))

{

strcat(theList, “<a href=\”");

strcat(theList, “/CD_”);

strcat(theList, (char*) theDir);

 

j=strlen(theList);

 

while(j–)

{

if(theList[j] == ‘/’)

{

theList[j]=0;

j=1;

}

}

 

if(!strcmp(&theList[strlen(theList)-4], “/CD_”))

{

strcat(theList, “/”);

}

 

strcat(theList, “\”>Parent Directory</a>”);

strcat(theList, “\n”);

}

}

else

hyper(TRUE, namelist[i]->d_name);

}

else

{

mimeokay(namelist[i]->d_name);

 

if(fstr == 0)

{

strcat(theList, namelist[i]->d_name);

strcat(theList, “\n”);

}

else

hyper(FALSE, namelist[i]->d_name);

}

 

free(namelist[i]);

}

 

free(namelist);

}

 

return theList;

}

 

 

 

In Listing 9, the child functionality of the tiny cloud server is defined. This functionality runs every time the server receives a browser request, and it has a simple function: allocate the buffers necessary for satisfying the request, process them, then free them so the allocated system memory is kept low when not needed. On a cell phone, memory is a scarce and precious resource, and should be released back to the system when your program is done servicing a request.

 

Listing 9. Daemon child functionality

 

void child(int fd, int hit)

{

long i;

long ret;

char* cret;

 

mainbuf=malloc(SBUF+1);

theList=malloc(SBUF+1);

theDir=malloc(LBUF+1);

cret=getcwd(theDir, LBUF);

 

ret=read(fd, mainbuf, SBUF);

 

if(ret == 0 || ret == -1)

{

error404(fd);

}

else

{

if(ret > 0 && ret < SBUF)

mainbuf[ret]=0;

else

mainbuf[0]=0;

 

for(i=0; i<ret; i++)

if(mainbuf[i] == ‘\r’ || mainbuf[i] == ‘\n’)

mainbuf[i]=’*';

 

aclog(LOG, “request”, mainbuf, hit);

 

for(i=4; i < SBUF; i++)

{

if(mainbuf[i] == ‘ ‘)

{

mainbuf[i]=0;

break;

}

}

 

if(!strncmp(&mainbuf[0], “GET /\0″, 6) ||

!strncmp(&mainbuf[0], “get /\0″, 6))

{

htmlout(fd, fileList());

}

else

{

if(!strncmp(&mainbuf[5], “About_”, 6))

{

htmlout(fd, about);

}

else if(!strncmp(&mainbuf[5], “Home_”, 5))

{

htmlout(fd, fileList());

}

else if(!strncmp(&mainbuf[5], “CD_”, 3))

{

if(chdir(&mainbuf[8]) == -1)

{

error404(fd);

}

else

{

if(strcmp(theDir, &mainbuf[8]))

strcpy(theDir, &mainbuf[8]);

 

htmlout(fd, fileList());

}

}

else

{

retfile(fd, hit);

}

}

}

 

free(theDir);

free(theList);

free(mainbuf);

sleep(1);

exit(1);

}

 

 

 

The main (parent) functionality of the tiny cloud is defined in Listing 10. It allocates the TCP/IP socket on which it will be listening for browser request calls. Then it initializes a few global variables like theDir, where the tiny cloud was started. And finally, it makes itself into a resident program (known as a daemon) so it can quietly process browser requests in the background while other processes are running.

 

Listing 10. Main functionality

 

int main(int argc, char **argv)

{

char* str;

char* cret;

 

static struct sockaddr_in cli_addr;

static struct sockaddr_in serv_addr;

 

socklen_t length;

 

int i;

int port;

int pid;

int listenfd;

int socketfd;

int hit;

 

cret=getcwd(logDir, LBUF);

 

if(argc < 2)

{

strcpy((char*) thePort, “80″);

port=atoi((char*) thePort);

}

else

{

if(!strcmp(argv[1], “-?”))

{

printf(“Usage: cloud [Port Directory]\n”);

exit(0);

}

strcpy((char*) thePort, argv[1]);

port=atoi((char*) thePort);

 

if(port < 0 || port > 60000)

aclog(ERROR, “Invalid port number (try 1 –> 60000)”, argv[1], 0);

 

if(chdir(argv[2]) == -1)

{

printf(“ERROR: Invalid directory %s\n”, argv[2]);

exit(4);

}

}

 

if(fork() != 0)

return 0;

 

signal(SIGCHLD, SIG_IGN);

signal(SIGHUP, SIG_IGN);

 

for(i=0; i<32; i++)

close(i);

 

setpgrp();

 

aclog(LOG, “Cloud Port/PID=”, (char*) thePort, getpid());

 

if((listenfd=socket(AF_INET, SOCK_STREAM, 0)) < 0)

aclog(ERROR, “syscall”, “socket”, 0);

 

serv_addr.sin_family      = AF_INET;

serv_addr.sin_addr.s_addr = htonl(INADDR_ANY);

serv_addr.sin_port        = htons(port);

 

if(bind(listenfd, (struct sockaddr*) &serv_addr,

sizeof(serv_addr)) < 0)

aclog(ERROR, “syscall”, “bind”, 0);

 

if(listen(listenfd, 64) <0)

aclog(ERROR, “syscall”, “listen”, 0);

 

for(hit=1; ;hit++)

{

length=sizeof(cli_addr);

 

if((socketfd=accept(listenfd,

(struct sockaddr*) &cli_addr,

(socklen_t*) &length)) < 0)

aclog(ERROR, “syscall”, “accept”, 0);

 

if((pid=fork()) < 0)

{

aclog(ERROR, “syscall”, “fork”, 0);

}

else

{

if(pid == 0)

{

close(listenfd);

child(socketfd, hit);

}

else

{

close(socketfd);

}

}

}

}

 

 

 

 

Compiling, deploying, and testing the application

You need to create one more file to properly build the cloud application using the Android kernel source makefile. Create a file called Android.mk, and paste what you see in Listing 11 into it. (This file is also included in the source available in Download.)

 

Listing 11. Android.mk

ifneq ($(TARGET_SIMULATOR),true) 

 

LOCAL_PATH:= $(call my-dir)

 

include $(CLEAR_VARS)

LOCAL_SRC_FILES:= cloud.c

LOCAL_MODULE := cloud

LOCAL_STATIC_LIBRARIES := libcutils libc

include $(BUILD_EXECUTABLE)

 

endif  # TARGET_SIMULATOR != true

 

 

 

Navigate to the external directory of the Android kernel source, create a subdirectory named cloud, and put both the cloud.c and the Android.mk files into it. You’re now ready to build a new Android kernel system with the tiny cloud application in it.

Move up to the root directory of the Android kernel source, type make, then go get some coffee. This process will take a while, so relax and let the system do its job.

If all goes well and the system has completed the make, you should find the tiny cloud binary in the out/target/product/generic/system/bin directory. You don’t really need to go through all the trouble of installing the entire distribution into your rooted Android cell phone: Just copy the cloud binary to the SD card. Listing 12 shows how you can do this on your host computer (assuming that the mydroid directory contains all the Android source kernel code).

 

Listing 12. Making the kernel and the cloud

$ cd mydroid/external 

$ mkdir cloud

$ cd cloud

$ cp ~/src/tinycloud/cloud.c .

$ cp ~/src/tinycloud/Android.mk .

$ cd ../..

$ make

 

— Android system “make” messages scroll up the screen for a long time. —

 

$ cd out/target/product/generic/system/bin

$ cp cloud /media/ANDROIDSDCARD/.

 

 

 

Notice that /media/ANDROIDSDCARD assumes you have the cell phone plugged in and mounted. Also, the name of your SD card may be different. Look around in the /media subdirectory (if running under Ubuntu Linux) for the correct name.

Running one of the freely available Terminal programs found in the Android Market allows you to run a shell session on the Android phone itself. The Android cloud would normally reside in the system/bin directory, but it doesn’t have to. For the sake of testing, it’s good to experiment with it in another directory. Create a directory under /data and call it cloud. Copy the cloud binary from the /sdcard directory to /data/cloud. Then run a chmod command to make the cloud program executable, and run it by typingcloud. Listing 13 shows you what these steps look like.

 

Listing 13. Testing the cloud on your Android cell phone

$ su 

# cd data

# mkdir cloud

# cd cloud

# cp /sdcard/cloud .

# chmod 777 cloud

# ./cloud

# ps

 

— Listing of resident daemons, and “./cloud” should be one of them. —

 

 

 

Press the Home key, start the browser, and go to the URL http://localhost. You should see the output of the tiny cloud on Android’s browser. You can move around the file system of your handset by clicking the links displayed.

Next, if your Android phone Wi-Fi is running on your network, you can use your computer to call up the tiny cloud. To do this, you need to know the Wi-Fi IP address of your cell phone. There are various ways to determine this address, including checking your Wi-Fi router’s logs. Another way is to go back to the Terminal program and type netstat -r; you should see an entry similar to that in Listing 14.

 

Listing 14. Using Netstat to obtain a cell phone’s IP address

 

# netstat -r

Proto Recv-Q Send-Q  Local Address    Foreign Address    …

.

.

.

tcp        0      0  192.168.0.3:80   192.168.0.5:58744  …

.

.

.

 

 

 

Type http://192.168.0.3/ (your cell phone’s IP address) in your browser’s address bar. In a moment, you should be looking into your Android cell phone’s file system listing, presented by the tiny cloud.

To use the tiny cloud in your cell phone to browse a Web page you are creating at the same time, simply swap the application you’re using by pressing and holding the Home key and clicking the browser or the editor. If you click the browser, do a menu refresh to see your edited changes. By repeating the edit/test/edit/test cycle until it looks how you want it to, you can be Web-mastering while waiting at the dentist’s office.

 


Enhancing the project

There are as many ways to enhance the project as there are people with ideas, but here are a few suggestions that you may want to try:

  • Add a specific menu item called Java that automatically navigates to the directory in which the Java class files reside, allowing you to click any of them for exploratory purposes. (Class files are actually compressed directories and will qualify for hyperlinks.) You can do this for any other specific directory that contains code that interests you.
  • Add a top-like page that refreshes itself every minute or so and displays choice information that can be read from the information in the /proc directory.
  • Write code that allows you to query SQLite databases from a Web page.
  • Whole HTML-based presentations can be hosted on the SD card, and the portability of the cell phone is great, so by using the Web browser built into most modern presentation stages, you can display your slide show presentation on your cell phone.

When you have decided on an idea for improving the tiny cloud, follow these three generic steps to add that functionality:

  1. Modify the buildbuf function in Listing 6 by entering a new menu choice that represents the new functionality you want to add.
  2. Modify the child function in Listing 9 so it can service the new functionality. For example, study how the About_ menu item works in both of these functions (buildbuf and child), and you’ll see how easy it is to add new functionality to the tiny cloud.
  3. Write the function that will service the menu item and be sure to insert a call to the new function in the child.

 

Conclusion

It’s always a good thing to know as much as you can about the devices you use. Furthermore, writing tools that can help you learn more can be a lot of fun. Putting a tiny cloud computing application into the heart of your Android cell phone is a fun and educational activity that will force you to learn a lot about what actually resides “under the hood” of these amazing devices.

 

 

Download

Description Name Size Download method
Source code for the tiny cloud app os-tinycloud-source.zip 9KB HTTP

Information about download methods

 

Resources

Learn

Get products and technologies

Discuss

About the author

 

Bill Zimmerly is a knowledge engineer, a low-level systems programmer with expertise in various versions of UNIX and Microsoft Windows, and a free thinker who worships at the altar of Logic. Creating new technologies and writing about them are his passions. He resides in rural Hillsboro, Missouri, where the air is fresh, the views are inspiring, and good wineries are all around. You can reach him at bill@zimmerly.com.

 

 

THE PSYCHOLOGIST’S VIEW OF UX DESIGN

It is great !

From http://uxmag.com/design/the-psychologists-view-of-ux-design

————————————————————————————-

You may have heard this story about an elephant:

A king brings six men into a dark building. They cannot see anything. The king says to them, “I have bought this animal from the wild lands to the East. It is called an elephant.” “What is an elephant?” the men ask. The king says, “Feel the elephant and describe it to me.” The man who feels a leg says the elephant is like a pillar, the one who feels the tail says the elephant is like a rope, the one who feels the trunk says the elephant is like a tree branch, the one who feels the ear says the elephant is like a hand fan, the one who feels the belly says the elephant is like a wall, and the one who feels the tusk says the elephant is like a solid pipe. “You are all correct”, says the king, “You are each feeling just a part of the elephant.”

The story of the elephant reminds me of the different view of design that people of different backgrounds, education, and experience have. A visual designer approaches UX design from one point of view, the interaction designer from another, and the programmer from yet another. It can be helpful to understand and even experience the part of the elephant that others are experiencing.

I’m a psychologist by training and education. So the part of the elephant I experience applies what we know about people and how we apply that to UX design. I take research and knowledge about the brain, the visual system, memory, and motivation and extrapolate UX design principles from that.

This article is a snapshot of the psychologist’s view of the elephant.

1. People Don’t Want to Work or Think More Than They Have To

  • People will do the least amount of work possible to get a task done.
  • It is better to show people a little bit of information and let them choose if they want more details. The fancy term for this isprogressive disclosure, which I wrote a blog post about recently.
  • Instead of just describing things, show people an example.
  • Pay attention to the affordance of objects on the screen, page, or device you are designing. If something is clickable make sure it looks like it is clickable.
  • Only provide the features that people really need. Don’t rely on your opinion of what you think they need; do user research to actually find out. Giving people more than they need just clutters up the experience.
  • Provide defaults. Defaults let people do less work to get the job done.

2. People Have Limitations

  • People can only look at so much information or read so much text on a screen without losing interest. Only provide the information that’s needed at the moment (see progressive disclosure above).
  • Make the information easy to scan.
  • Use headers and short blocks of info or text.
  • People can’t multi-taskThe research is very clear on this, so don’t expect them to.
  • People prefer short line lengths, but they read better with longer ones! It’s a conundrum, so decide whether preference or performance is more important in your case, but know that people are going to ask for things that actually aren’t best for them.

3. People Make Mistakes

  • Assume people will make mistakes. Anticipate what they will be and try to prevent them.
  • If the results of an error are severe then use a confirmation before acting on the user’s action.
  • Make it easy to “undo.”
  • Preventing errors from occurring is always better than helping people correct them once they occur. The best error message is no message at all.
  • If a task is error-prone, break it up into smaller chunks.
  • If the user makes and error and you can correct it, then do so and show what you did.
  • Whoever is designing the UX makes errors too, so make sure that there is time and energy for iteration, user feedback, and testing.

4. Human Memory Is Complicated

  • People reconstruct memories, which means they are always changing. You can trust what users say as the truth only a little bit. It is better toobserve them in action than to take their word for it.
  • Memory is fragile. It degrades quickly and is subject to lots of errors.Don’t make people remember things from one task to another or one page to another.
  • People can only remember about 3-4 items at a time. The “7 plus or minus 2” rule is an urban legend. Research shows the real number is 3-4.

5. People are Social

  • People will always try to use technology to be social. This has been true for thousands of years.
  • People look to others for guidance on what they should do, especially if they are uncertain. This is called social validation. This is why, for example, ratings and reviews are so powerful on websites.
  • If people do something together at the same time (synchronous behaviorit bonds them together—there are actually chemical reactions in the brain. Laughter also bonds people.
  • If you do a favor for me then I will feel indebted to give you a favor back (reciprocity). Research shows that if you want people to fill out a form, give them something they want and then ask for them to fill out the form, not vice versa.
  • When you watch someone do something, the same parts in your brain light up as though you were doing it yourself (called mirror neurons). We are programmed with our biology to imitate. If you want people to do something then show someone else doing it.
  • You can only have strong ties to 150 people. Strong ties are defined as ties that with people you are in close physical proximity to. But weak ties can be in the thousands and are very influential (à la Facebook).

6. Attention

  • I am beginning to think that the whole idea of attention is a key to designing an engaging UI. I’ll write more in future articles about that. Grabbing and holding onto attention, and not distracting someone when they are paying attention to something, are key concerns.
  • People are programmed to pay attention to anything that is different or novel. If you make something different it will stand out.
  • Having said that, people can actually miss changes in their visual field. This is called change blindness. There are some quite humorous videos of people who start talking to someone on the street (who has stopped them and asked for directions) and then don’t notice when the person actually changes!
  • You can use the senses to grab attention. Bright colors, large fonts, beeps, and tones will capture attention.
  • People are easily distracted. If you don’t want them to be distracted, don’t flash things on the page or start videos playing. If, however, you do want to grab their attention, do those things.

7. People Crave Information

  • Dopamine is a chemical that makes people seek… food, sex,information. Learning is dopaminergic—we can’t help but want more information.
  • People will often want more information than they can actually process. Having more information makes people feel that they have more choices. Having more choices makes people feel in control. Feeling in control makes people feel they will survive better.
  • People need feedback. The computer doesn’t need to tell the human that it is loading the file. The human needs to know what is going on.

8. Unconscious Processing

  • Most mental processing occurs unconsciously.
  • If you can get people to commit to a small action (sign up for a free membership), then it is much more likely that they will later commit to a larger action (e.g., upgrade to a premium account).
  • The old brain makes or at least has input into most of our decisions. The old brain cares about survival and propagation: food, sex, and danger. That is why these three messages can grab our attention.
  • The emotional brain is affected by pictures, especially pictures of people, as well as by stories. The emotional brain has a huge impact on our decisions.
  • People’s behavior is greatly affected by factors that they aren’t even aware of. The words “retired”, “Florida,” and “tired” can make even young people walk down the hall slower (called framing).
  • Both the old brain and the emotional brain act without our conscious knowledge. We will always ascribe a rational, conscious-brain reason to our decision, but it’s never the whole reason why we take an action, and often the rational reason isn’t even part of the reason.

9. People Create Mental Models

  • >People always have a mental model in place about a certain object or task (paying my bills, reading a book, using a remote control).
  • The mental model that people have about a particular task may make it easy or hard to use an interface that you have designed.
  • In order to create a positive UX, you can either match the conceptual model of your product or website to the users’ mental model, or you can figure out how to “teach” the users to have a different mental model.
  • Metaphors help users “get” a conceptual model. For example, “This is just like reading a book.”
  • The most important reason to do user research is to get information about users’ mental models.

10. Visual System

  • If pages are cluttered people can’t find information. Use grouping to help focus where the eye should look.
  • Things that are close together are believed to “go” together.
  • Make fonts large enough. Use fonts that are not too decorative so they are easy to read.
  • Research shows that people use peripheral vision to get the “gist” of what they are looking atEye tracking studies are interesting, but just because someone is looking at something straight on doesn’t mean they are paying attention to it.
  • The hardest colors to look at together are red and blue. Try to avoid red text on a blue background or vice versa.
  • People can recognize objects on a screen best when they are slightly angled and have the perspective of being slightly above (canonical perspective).
  • Color can be used to show whether things go together. Be sure to use another way to show the same info since some people are colorblind.

So, what’s your description of the elephant?

 

The ‘IxD Bauhaus’ – What happens next?

The ‘IxD Bauhaus’ – what happens next?

 

Rahul Sen on April 18th, 2011
The Great article about UX. I like it !
——————————————————————————————

IXD Bauhaus
Occasionally, amidst the rapid rise and fall of trends, fashion and fancy, we are faced with true revolution: paradigm shifts that throw out excess baggage of some kind and usher in new ways of thinking and seeing altogether. The catch is that you need to have the benefit of hindsight to truly measure their effectiveness. With this in mind, I believe that the interaction design community is witnessing an important revolution — an ‘IxD Bauhaus’ of sorts.

 

I’d like to start with architecture and its recent history, and then compare it with current changes in the way interaction design is being conceived and made. Lastly I’d like to discuss the effects of such a revolution in architecture, and provoke thought on what the implications might be for the design of user experience.

Remembering the Bauhaus:  a call to end ornamentation in the built environment

The Bauhaus Movement (1918-1933) was based on a German revival of a purer, honest design representation in architecture, art, typography and product design. Its philosophy celebrated an austere functionalism with little or no ornamentation. It advocated a use of industrial materials and inter-disciplinary methods and techniques. The  Bauhaus aesthetic and beliefs were influenced by and derived from techniques and materials employed especially in industrial fabrication and manufacture. Artists included Paul Klee, Wassilli Kandinsky, and Feininger. Architects and designers included Mies Van der Rohe, Phillip Johnson, Walter Gropius, Lazlso Moholy-Nagy and several others.

Walter Gropius who at Columbia University (March, 1961) clarified the intention of the Bauhaus saying -

“The Bauhaus was not concerned with the formulation of timebound, stylistic concepts, and its technical methods were not ends in themselves. It was created to show how a multitude of individuals, willing to work concertedly but without losing their identity, could evolve a kinship of expression in their response to the challenges of the day. Its aim was to give a basic demonstration of how to maintain unity in diversity, and it did this with the materials, techniques, and form concepts germane to its time. It was this method of approach that was revolutionary…”

This movement was a true revolution because prior to its time, the built environment had bloated in stimuli, caused by an excess of decor and ‘pastry-work’. As early as 1908, the Austrian architect Adolf Loos had said that architectural ornament was criminal, and his essay on that topic would become foundational to Modernism and eventually trigger the careers of Le CorbusierWalter GropiusAlvar Aalto,Mies van der Rohe and Gerrit Rietveld and other Bauhaus masters. The Modernists embraced these equations—form follows function, ornament is crime—as moral principles, and they celebrated industrial artifacts like steel water towers and other ‘Machine Age’ construction as brilliant and beautiful examples of plain, simple design integrity.

The Bauhaus liberated construction from the excessive need for ornamentation as a means of expression, be it in art, typography, graphic design or architecture. One of the main objectives of the Bauhaus was to unify art, craft, and technology. It freed itself from the shackles of historical ’styling’ and attempted to create a fresh order of primary principles. Such radical thinking enabled a celebration of the purity and honesty of structure and looking for truth in things be it on a 2-dimensional canvas or a building. Anyone who’s marvelled at the Barcelona Pavillion or the Barcelona Chair (both designed by Van der Rohe) has experienced the essence of what the movement stood for.

The Bauhaus’s philosophy was that form should follow function and all other distractions and decoration should be avoided. It wanted space to be experience for its purity, stripped off all the ‘dirt’ and clutter of decor. This is something that’s been happening recently in the field of visual interaction design.

Cantilevered chair by Marcel Breuer

What’s the ‘IxD Bauhaus’ about?

If you’re the kind of interaction designer who starts getting a gradient-itch or delights in making buttons look like glass – think again. The times they are a-changin’.

There was a time when our sense of ‘modern’ in the user-interface was driven by concepts like these -

Concepts for the Windows Media Player by frog

Examine the words used to describe such a concept – “… a rich palette of visual surfaces for the media player and taskbars, giving XP a unique, consistent design language that challenges the traditional digital media experience.Analog-style“rubberized” buttons on the skin of Windows Media Player offer classic, intuitive navigation and avoid the hyper-technical feel of other online players. Brushed aluminum textures, rich colors, and dimensional lightingadd a satisfying tactile quality to the user’s online interactions, lending the experience a sense of the real.” The term often used to describe this kind of UI is skeumorphic. If pre-industrial revolution construction suffered from ‘nature-envy’, skeumorphic visual user experiences suffer from ‘object-envy’.

To quote an explanation from FastCompany’s article on it – Skeuomorphic apps take pains to reference or mimic physical, real-world features in their user interfaces. Apple is the current king of this design style, enshrining skeuomorphics in its Human Interface Guidelines: “Whenever possible, add a realistic, physical dimension to your application. The more true to life your application looks and behaves, the easier it is for people to understand how it works and the more they enjoy using it.”

Skeumorphic UISkeumorphic UI

It’s tough to compete with a force as dominant as Apple, in the realm of beautiful user-experiences, but the release of the Windows Phone 7 design guideline (codenamed: Metro), an impending revolution has been made official. The new IxD Bauhaus’ basic principle is that ‘Form follows Data’.

The Windows Phone ‘Metro’ Design Language

Windows Phone’s new design language is inspired by print in the digital age. Let’s examine the words used by their team (extracted from Mike Kruzeniski’s blog) to describe their UI design principles -

  • Clean, Light, Open and Fast
  • Alive in Motion
  • Celebrate Typography
  • Content, Not Chrome
  • Authentically Digital

One could almost use these words to describe Mies van der Rohe’s Barcelona Pavillion, for example -

  • Clean, Light, Open and Fast (Open space, pure exposed beautiful material)
  • Alive in Motion (through albeit static sweeping horizontal lines in the design language)
  • Celebrate Typography (celebrating structure – making it boldly present)
  • Content, Not Chrome (no decor, just beautiful clean spaces)
  • Authentically Digital (authentically physical)

Visual motion in the Barcelona Pavillion

There are so many examples that are beginning to exemplify this philosophy, some better than others. Examples of this ‘IxD Bauhaus’ (to name a few) are -

Flipboard for iPadThe Puma Phone,

Flipboard and Puma

The Fluid App for iPad and iPhoneWired app for iPad

Fluid/Wired Apps

Some design their visual interaction with fiercely reductionist vigor. Others still show hints of a gradient itch. The revolution however, is definitely underway. Increasingly, our apps and OS’s hint on letting us focus on our lives and tasks and ‘getting the job done’ by focussing on ‘content rather than chrome’.

Increasingly, our apps and OS’s hint on letting us focus on our lives and tasks and ‘getting the job done’ by focussing on ‘content rather than chrome’.

This is an exciting and most welcome change in visual interaction design. It is also a huge challenge for designers, content-providers and business groups.  Inorder to see the revolution thrive and prosper – all these interest groups need to work even more closely. We need to learn lessons from history and not make the same mistakes.

The Good, the Bad, and the Boxy: What can visual interaction designers learn from the Bauhaus?

The point of this article is not to acknowledge revolution. That’s been done already and perhaps more eloquently. This stream of thought would like to probe the consequences of such a ‘reductivist’ philosophy and draw parallel lessons from history.

The Bauhaus movement had immeasurable value in shaping modern architecture and design to what it is today, but it also faced severe criticism. After living in them, or owning Bauhaus furniture – several found them to be too impersonal, sterile and devoid of any emotional value. All houses started to look vaguely similar, offices became cubicle graveyards while Bauhaus masterpiece-inspired furniture design knock-offs looked tacky and boring. Since the moved was fuelled by World War II and an industrial wave of mass production it killed ‘craft’ and ensured a sameness in the objects we started seeing around us. This was both good and bad.

Jacques Tati’s ‘Playtime’ (1967) was a brilliant cinematic critique of the ‘glass and steel’ forest that modern life had become as a result of the Bauhaus.

Jacques Tati’s Playtime

Lets quickly summarize why the Bauhaus was important for design history, but was frequently criticized in people’s lives -

  • Not all material is worthy of celebration, not all content is beautiful too.
    The Bauhaus movement was a huge challenge not only to designers but also to the people providing engineering, construction and material services. Everyone needed to up their game in order to make a beautiful chair, poster or building. Any compromise in quality ensured that material/content was revealed as poor in quality and tacky in appearance.In today’s times business owners, content-providers and other interest groups need to do some serious soul searching to ensure that their content alone will carry their online experience through? Just like in the Bauhaus movement, bad quality wood looked tolerable when it was decorated or concealed. The moment one stripped them off decor – it exposed nothing but ugliness.
  • Beauty is in the details, construction, and structure.Barcelona pavilion column detailA bad visual experience will now be judged, not by the beautiful ‘glassiness’ of its buttons, but by its inherent structure and little details that are made to manifest from inside out. Interaction designers and developers alike need to collaborate more closely to ensure that experiences are built inside-out, rather than designers applying ’skins’ to a detached user-experience development platform. Wireframing experiences in close collaboration with developers and content-providers, detailing points of interaction without applying visual clutter will suddenly become a bottom-line in interaction design.
  • Ensuring familiarity without losing brand value and character.
    Visual interaction designers will now be faced with the stiff challenge of creating identity, character and uniqueness without the easier palette of ‘decor’. A failure to create differences could lead to familiar ‘Bauhaus problems’ of sameness and monotony.
  • Industrial processes drove the Bauhaus, software development processes are driving the ‘IxD Bauhaus’.
    Mass production, industrial fabrication, pre-cast components and material technology spurred the Bauhaus movement to fruition in its time. Today, we need to acknowledge that the reductionist IxD revolution is being caused by a larger understanding that ‘apps’ might be the way forward in a ‘Cloud’ computing world. Designers, engineers and developers would need to ensure that pre-cast components were designed well, almost as ‘toolboxes’ in the design of user experiences so that parts were repetitive without being too rigid. Visual interaction designers would need to think big and small simultaneously – keeping overall architecture in mind while resolving smaller details.
  • When all facades are glass, its hard to know where the door is
    Mind the Glass DoorKnowing when and how to provide cues for interaction becomes even more crucial for the design of a good user experience. Windows Phone does this through minimal, yet intuitive animations that delight and inform users. Other app-experiences and platforms need to think of their own ways of solving this problem. Since buttons need no longer look like buttons, designers need to ensure clarity in design language using color, typography, or other material to differentiate interactive elements from static ones.

Conclusion: How much of less is more?

The main question here is not when or where the ‘IxD Bauhaus’ movement began. Or if it exists at all.

It is more important to recognize this reductionist behavior as a refreshingly welcome change in how we plan and design our visual interactive experiences. While we can no longer conceal mediocre interaction design behind the facade of decoration and fluff, several questions remain unanswered. How much can we reduce, without compromising on usability , cognition and emotion? How much can we strip experiences of cues (formerly done through decor) without making them sterile?

Even though the movement is in its early days in mobile, table and desktop visual interaction design, its implications will be broad and deep, regardless of commercial performance. A lot of the movement’s success depends on how users accept such a reductionist approach to visual interactive experiences where there are many hidden cues and authentic digital behavior. It remains to be seen how users respond to the lack of familiarity in the new UX metaphors that were formerly mimicking the physical world.

We all like personalization, customization and a feeling of ownership of the objects and services that we interact with and consume. The Windows Phone Design Team has done a great job of showing the user their relevant content on an interactive start-screen experience. How will others respond, without setting off another clone assembly line that mimics rather than acts authentic? While personally praying for the success of such a school of  thought and action, there are hurdles that we need to be clear about and prepare ourselves for that would rush to quash the revolution at the first signs of duress.

If the Bauhaus movement in the early part of last century failed to resonate with users for reasons that we’ve discussed – can we as designers prepare ourselves to meet the challenges ahead?

——-

Marcel Breuer chair from Wikipedia
Skeumorphic UI from Fastcodesign
Concept sketches from frogdesign
Barcelona Pavillion from Travel with Frank Gehry
Barcelon Pavillion details from Sketchucation

 

Porting Mongoose Web Server to Android

About the Mongoose Web Server
Mongoose (project’s homepage: http://code.google.com/p/mongoose/) is a very tiny web server. Its source code only contains a library header (mongoose.h), a library source (mongoose.c) and an application main file (main.c), which makes it very easy for understanding, maintaining and modifying. Also, Mongoose executable does not depend on any external library or configuration, so it is very easy for porting. It has a very tiny footprint: only 40 kB of executable size, and requires very small amount of system resources. So it is perfect for acting as a simple web server for Android.
There are some features listed from Mongoose’s project homepage:
•    Crossplatform – works on Windows, MacOS and most flavors of UNIX
•    CGI, SSL, SSI, Digest (MD5) authorization, resumed download, aliases
•    IP-based ACL, Windows service, GET, POST, HEAD, PUT, DELETE methods
•    Small footprint: executable size is 40 kB on Linux 2.6 i386 system
•    Embeddable with simple and clean API. Source is in single .c file to make things easy
•    Python bindings

Porting Mongoose to Android

Mongoose is born to suitable for Android. Just check out its source code, and build it with Android’s NDK (requires r5 or later, which supports toolchain compiling).

Here is a sample makefile for building:

NDK_HOME=/Developer/android-

ndk-r5
TOOLCHAIN_HOME=$(NDK_HOME)/toolchains/arm-linux-androideabi-4.4.3/prebuilt/darwin-x86
CROSS_COMPILE=$(TOOLCHAIN_HOME)/bin/arm-linux-androideabi-
SYSROOT=$(NDK_HOME)/platforms/android-3/arch-arm
CC=$(CROSS_COMPILE)gcc
NDK_LIB=$(SYSROOT)/usr/lib 

CCFLAGS=-MMD -MP -fpic -ffunction-sections -funwind-tables -D__ARM_ARCH_5__ -D__ARM_ARCH_5T__ -D__ARM_ARCH_5E__ -D__ARM_ARCH_5TE__  -Wno-psabi -march=armv5te -mtune=xscale -msoft-float -mthumb -Os -fomit-frame-pointer -fno-strict-aliasing -finline-limit=64 -DANDROID -Wa,–noexecstack -g
#CCFLAGS=
INCDIRS += -I$(SYSROOT)/usr/include
LDFLAGS += –sysroot=$(SYSROOT) -L$(NDK_LIB)
LDFLAGS += -Wl,–gc-sections -Wl,-z,nocopyreloc -Wl,–no-undefined -Wl,-z,noexecstack -Wl,-rpath-link=$(SYSROOT)/usr/lib
LDFLAGS += -ldl
#LDLIBS += $(TOOLCHAIN_HOME)/lib/gcc/arm-linux-androideabi/4.4.3/libgcc.a
#LDLIBS += $(SYSROOT)/usr/lib/libc.a

OUTPUT = httpd

httpd: mongoose.c main.c
$(CC) $(CCFLAGS) $(INCDIRS) mongoose.c main.c -o $(OUTPUT) $(LDFLAGS)

clean:
rm -f *.o *.d

Web Servers for Android

Since the Android mobile system is derived from the Linux operation system, porting existing Linux-based web servers to Android is relatively simple. There are several web servers ready for porting:

  • Apache HTTP Server
  • nginx
  • Jetty
  • Mongoose

Considering the fact that Android is normally running on cell phones or tablets which only have limited hardware resources, we are mainly focused on the lightweight web server, such as nginx, Jetty and Mongoose.
In the following posts, we will discuss the porting and usage of nginx, Jetty and Mongoose on Android. And, according to our architecture design, we will select one server as our mainstream-supported web service front end.

About Bodudu

Why Bodudu ?

Bodudu – To Weblize the Android

Bodudu Means The Beetle Optimistic Dungeon Uhlans and Droid Users.

In BODUDU workshop some teammates like the game named Dungeons and Dragons, someone wears the glasses, and everyone likes Android.

We are going to carry on with the project about Webdroid in different places, It seems the hard work under the ground – like the dungeons. We are lance knights in the Android development groups.

Goal

First, our goal is very clear as said in the slogan, “To weblize the android” Surprisingly, we may be one of the very few, if not the only, open source groups in the world that insist on providing the open source web development environment and web application infrastructure in Android.

We actually do research on newest web application technology for Android, and collect the open source projects related to web applications.

Our teammates are a bunch of young, creative and enthusiastic people, mostly related or working in IT industry, and living all over the world.

We not only run a webdroid project, we run it as our dream, we rock it. We are android Fans and we want to build web development environment on Android, provide more development tools for Android.

History

Bodudu Workshop (www.bodudu.org)  was set up on March 15th 2011. In the beginning our teammates worked for some standalone projects in Android. When we met together, and talked about the web applications in Android. We decided to merge our projects to one project – Webdroid.

Team

Now we have 7 teammates from USA, England and China. We want to play an important role in the field of smart phone and mobile internet.

Contracts:

 

Join Us

Time To Join Us!If you hope to join the interesting group, and your dream is to build the web development environment for Android.

Please keep in touch with us:  bodudu#hotmail.com.

Wait for your letter.