How would Pac Man be in 2010? This is Hexage answer, a very addictive game with nice colors and a great gameplay.
Run for your life through colorful neon mazes, chased by countless and ever-vigilant security forces.
Be creative - play stealthily to avoid encounters, prepare traps for your enemies or just rush as fast as you can right in front of their eyes. Figure out how to beat the system and destroy your captors in 24 action-packed levels. Steal from your dark adversary and leave his world in ruins!
Break out and take revenge!
* If you get an installation failed error, unmount your SDcard and install again.
settings>SD card & phone storage>unmount SD card
Download This Free Game 4 Android here:
 Talk about it on our Facebook page. |
| FileSonic apk file: 11.24MB |
 |
Enjoy the ultimate makeover of Sally's Salon in the Luxury Edition of the hit game.
Enjoy fantastic features new to mobile, including 5 additional locations with exciting challenges, more customer types, extra trophies, enhanced visual effects and more!
Download This Free Game 4 Android here:
| Talk about it on our Facebook page. |
| FileSonic apk file: 9.64MB |
|
As I discussed in the previous post, JSON now starts to become fashionable, mostly because of its more compact encoding compared to XML. If we are commited to communicate over JSON with the server, the need for the most common client-server communication pattern, Remote Procedure Call (RPC) arise.
JSON has such a solution, called JSON-RPC. JSON-RPC is a lightweight client-server protocol. Beside the usual stuff (remote method identification, parameter and result encoding, exceptions) it has some remarkable properties that make it particularly suitable for mobile communication.
There are two JSON-RPC specifications out there, JSON-RPC 1.0 and 2.0. While 2.0 in most aspects can be seen as a natural extension of 1.0, there are differences too. JSON-RPC 1.0 was designed to be peer-to-peer with the main transport protocol being TCP. HTTP was also supported but with limitations. JSON-RPC 2.0 is explicitly client-server even though the change is only in the terminology used in the specification. The client-server nature of JSON 2.0 ensures, however, that HTTP as a transport is more naturally supported.
Let's start with the basics.
This is a JSON 1.0 request:
{"method":"add","params":[3,4],"id":0}
"method" attribute specifies the remote method, "params" attribute has a value of an array with the RPC arguments. The order matters and has to be the same as the arguments on the remote side. JSON-RPC requests and responses are connected with the "id" attribute because requests and responses does not have to be ordered. The response following a request - or over a full duplex bearer like TCP arriving at any time - does not have to be the response to the request just sent. It may be a response to an earlier request and the "id" parameter guarantees that requests can be coupled with their responses.
This is a JSON 1.0 response:
{"error": null, "result": 5, "id": 0}
"result" is the return value of the RPC call, "id" is the same as the corresponding request and "error" carries the error object if there was an error during the RPC processing. RPC 1.0 does not define the error value beside stating that it is an object.
JSON-RPC 2.0 extends JSON-RPC 1.0 in many important ways.
{"method":"mul","params":[4,5],"id":1,"jsonrpc":"2.0"}]
and the following is a batched response:
[{"error": null, "jsonrpc": "2.0", "result": 5, "id": 0},
{"error": null, "jsonrpc": "2.0", "result": 20, "id": 1}]
The following is a JSON-RPC 2.0 error response:
{"jsonrpc": "2.0","error": {"message": "ServiceRequestNotTranslatable", "code": 1000}, "result": null, "id": 12}
That was a lot of explanations, let's see something that works!
Click here to download the example program.
This is the same client-server batch calculator that you have seen in the previous post. Use the deployment instructions of the previous post to try out the example program. If you want to try the example on a real phone, I recommend deploying the server part on the real Google App Engine infrastructure as described in the previous post.
The example program uses JSON-RPC 2.0 as communication protocol between the client and server instead of our homegrown protocol. The biggest change is on the server side, which is implemented as a Python application for Google App Engine. Instead of obscure parsing code, you see remote methods defined like this:
@ServiceMethod
def add(self, v1,v2):
return v1+v2
and the rest is done by the server-side Python JSON-RPC 2.0 framework which I hacked out of this JSON-RPC 1.0 implementation. The client side does not use any framework at all which is a major problem with this example program. So far I have not been able to find any decent JSON-RPC 2.0 client-side framework suitable for Android. If you have an idea, please comment!
JSON has such a solution, called JSON-RPC. JSON-RPC is a lightweight client-server protocol. Beside the usual stuff (remote method identification, parameter and result encoding, exceptions) it has some remarkable properties that make it particularly suitable for mobile communication.
There are two JSON-RPC specifications out there, JSON-RPC 1.0 and 2.0. While 2.0 in most aspects can be seen as a natural extension of 1.0, there are differences too. JSON-RPC 1.0 was designed to be peer-to-peer with the main transport protocol being TCP. HTTP was also supported but with limitations. JSON-RPC 2.0 is explicitly client-server even though the change is only in the terminology used in the specification. The client-server nature of JSON 2.0 ensures, however, that HTTP as a transport is more naturally supported.
Let's start with the basics.
This is a JSON 1.0 request:
{"method":"add","params":[3,4],"id":0}
"method" attribute specifies the remote method, "params" attribute has a value of an array with the RPC arguments. The order matters and has to be the same as the arguments on the remote side. JSON-RPC requests and responses are connected with the "id" attribute because requests and responses does not have to be ordered. The response following a request - or over a full duplex bearer like TCP arriving at any time - does not have to be the response to the request just sent. It may be a response to an earlier request and the "id" parameter guarantees that requests can be coupled with their responses.
This is a JSON 1.0 response:
{"error": null, "result": 5, "id": 0}
"result" is the return value of the RPC call, "id" is the same as the corresponding request and "error" carries the error object if there was an error during the RPC processing. RPC 1.0 does not define the error value beside stating that it is an object.
JSON-RPC 2.0 extends JSON-RPC 1.0 in many important ways.
- In order to provide backward compatibility, JSON-RPC 2.0 requests and responses must all have "jsonrpc": "2.0" attribute.
- Error object is now specified. It has "code", "message" and "data" attributes (more about that in the specification).
- It specifies oneway messages that JSON-RPC 2.0 calls notifications. Notifications are requests without "id" attribute. No response can be sent to notifications.
- There are batched requests and responses. Batch is formed by having an array as top-level element and adding JSON-RPC request or response objects tothis array. E.g. the following is a batched request:
{"method":"mul","params":[4,5],"id":1,"jsonrpc":"2.0"}]
and the following is a batched response:
[{"error": null, "jsonrpc": "2.0", "result": 5, "id": 0},
{"error": null, "jsonrpc": "2.0", "result": 20, "id": 1}]
The following is a JSON-RPC 2.0 error response:
{"jsonrpc": "2.0","error": {"message": "ServiceRequestNotTranslatable", "code": 1000}, "result": null, "id": 12}
That was a lot of explanations, let's see something that works!
Click here to download the example program.
This is the same client-server batch calculator that you have seen in the previous post. Use the deployment instructions of the previous post to try out the example program. If you want to try the example on a real phone, I recommend deploying the server part on the real Google App Engine infrastructure as described in the previous post.
The example program uses JSON-RPC 2.0 as communication protocol between the client and server instead of our homegrown protocol. The biggest change is on the server side, which is implemented as a Python application for Google App Engine. Instead of obscure parsing code, you see remote methods defined like this:
@ServiceMethod
def add(self, v1,v2):
return v1+v2
and the rest is done by the server-side Python JSON-RPC 2.0 framework which I hacked out of this JSON-RPC 1.0 implementation. The client side does not use any framework at all which is a major problem with this example program. So far I have not been able to find any decent JSON-RPC 2.0 client-side framework suitable for Android. If you have an idea, please comment!
Ringo Pro is a great way to truly personalize your Android phone. Use any MP3 as a ringtone and set individual tones for each of your contacts and groups.
Ringo really powers up your SMS notifications too - set a different tone for each contact's messages, and control LED colors, pop-up notifications and more!
Download This Free App 4 Android here:
| Talk about it on our Facebook page. |
| FileSonic zip file: 1.60MB |
|
Jerusalem, 1191 A.D. Play Altair, an elite Assassin, sent to kill eight men in order to end the Third Crusade, in a game that redefines the action/adventure genre that provides a well-balanced mix of stealth, chaotic action and riddle-solving exploration in the midst of 4 historical environments of the Middle East.
Requirements: Android 2.1 or higher
Download This Free Game 4 Android here:
| Talk about it on our Facebook page. |
| FileSonic zip file: 115.07MB |
|
Musical for Android is a pocket toolkit for musicians, songwriters, singers, recording artists, and people who just love music. It includes everything you need to be musical on the go.
Features:
- Metronome: 40-200bpm, change note value and time signature
- Pitch Pipe: C to C, activate by blowing into the microphone
- Piano: 3 octaves (customizable), scrolling, 128 instruments
- Keyboard: 2 stacked octaves (customizable), 128 instruments
- Drums: 8 pads, multitouch (for some devices)
- Piano Practice: light-up piano, built-in and custom songs
- MIDI over WIFI: wirelessly use as a MIDI input device
Download This Free App 4 Android here:
| Talk about it on our Facebook page. |
| FileSonic zip file: 1.56MB |
|
Are you a complete idiot?
What about your friends, coworkers, and family? Play The Moron Test now and find out!
Point and laugh at everyone when they get stumped!
Download This Free Game 4 Android here:
| Talk about it on our Facebook page. |
| FileSonic apk file: 14.65MB |
|
Enjoy moon phases widget and beautifully animated zodiac circles. Touch-n-turn the moon to change the date.
Browse moon calendar, get automatic GPS location or set any location, date, time. Look at moon azimuth, moonrise time and learn when next moon phase is. Explore unique moon astronomy and astrology with style.
Download This Free App 4 Android here:
| Talk about it on our Facebook page. |
| FileSonic apk file: 3.91MB |
|
Talking Larry the Bird can whistle and talk. Talking Larry the Bird is your whistling and talking bird friend. Play the piano keyboard and make Larry whistle a perfect tune. Say anything and Larry will repeat.
You can also poke him, feed him, strike him with lightning or make him bow and accept applause. You can even record your own videos of Larry and share them on YouTube, Facebook or send them to your friends and family by email.
Features:
- Play on the piano keyboard and Larry will whistle.
- Talk and he will repeat everything you say.
- Poke him and he will not like it.
- Poke him in the head and he will spin.
- Give him seeds to eat.
- Strike him with lightning.
- Record videos of Larry and upload them to YouTube & Facebook or send them by email.
Download This Free App 4 Android here:
| Talk about it on our Facebook page. |
| FileSonic apk file: 11.58MB |
|
Actualización 08/11/2010: un miembro de la OHA (Open HandSet Alliance) ha publicado en su twitter: "Preparen sus Nexus One (Developer version) para la actualización vía OTA de Android 2.3 (Gingerbread) para los próximos días :-D". ¡Esto está al caer!
Actualización: Ya tenemos la figurita del Gingerbread junto al Eclair y las demás. ¿¿Significará esto que se liberará el SDK próximamente??
Android, como ya sabéis, está en constante evolución y después de la llegada de Froyo (versión presente ya en cerca del 35% de los terminales, como podéis ver aquí) sabíamos que vendría Gingerbread.
Actualización: Ya tenemos la figurita del Gingerbread junto al Eclair y las demás. ¿¿Significará esto que se liberará el SDK próximamente??
Android, como ya sabéis, está en constante evolución y después de la llegada de Froyo (versión presente ya en cerca del 35% de los terminales, como podéis ver aquí) sabíamos que vendría Gingerbread.
No podemos confirmar si se denominará Android 3.0, Android 2.5 o Android 2.3. Esta última opción cobra fuerza, pues un ingeniero de Android ha denominado a Android 2.3 como una "major release" (ya sabemos que se trata de Android 2.3). Dando por hecho que hablaba de Gingerbread, sabemos que será una "major release", es decir, supondrá un salto importante en la evolución de Android, comparable quizá con el salto de Donut a Eclair, aunque Froyo está mucho más maduro que Donut.
Así mismo, ya se ha empezado a filtrar información y un primer vídeo que os dejamos a continuación. Como siempre, hay informaciones veraces y otras que no lo son tanto (como que saldría el SDK esta misma semana, y no ha sido así). Desde Android in Spain os dejamos con las informaciones que creemos son las más probables que nos encontremos en Gingerbread (pero ojo, no dejan de ser rumores):
- Supondrá un cambio en la filosofía de actualizaciones para tratar de reducir la fragmentación. De hecho, ya lo hemos empezado a ver con Froyo, en donde se reciben actualizaciones de las aplicaciones de Google vía Android Market (Gmail, Youtube hace escasos días - en donde nos podemos hacer una buena idea de lo que será Gingerbread, espectacular actualización -, etcétera.). Las actualizaciones mayores tendrán lugar cada 6 meses aproximadamente.
- Lavado de cara en la interfaz gráfica con el objetivo de que personalizaciones como HTC Sense no tengan sentido (pues el Android "de serie" resulte igual de atractivo). Estas personalizaciones seguirán existiendo pero, de momento, sabemos que los iconos se han rediseñado ofreciendo un aspecto más uniforme y se han añadido efectos como un "rebote" al llegar al final de una lista. Así mismo, la barra de tareas se ha modificado (ahora es oscura) y parece que se usarán tonalidades más verdosas y no tanto naranja como actualmente.
- Posibilidad de hacer videollamadas desde la aplicación de Google Talk a cualquier otro terminal móvil o persona que use la aplicación en el ordenador.
- Soporte nativo de la VoIP en la aplicación Google Voice (nada novedoso, teniendo en cuenta que hay aplicaciones que ya lo ofrecen como Skype). Además recordamos que Google Voice no está disponible en España (por el momento).
- Posible aparición de Google Music, versión web del Android Market, nuevo teclado virtual... en definitiva, un montón de novedades que esperamos con gran entusiasmo y harán de Android un SO aún mejor.
Como regalo os dejamos el primer vídeo que ha salido a la luz en el que, teóricamente, se muestra un Nexus con Gingerbread y en el que se puede apreciar una animación (entra dentro del lavado de cara en la interfaz gráfica) al bloquear el terminal, como en los televisores antiguos de tubo de rayos catódicos:
¡Os mantendremos informados!
Fuente: Android code forums en donde podemos ver cómo un ingeniero de Google confirma a Android 2.3 como una "major release".
A long time ago, XML was the emerging, fashionable technology. Those times have clearly passed and nowadays XML is just another boring piece of basic technology. If you want to be trendy, you have to go for something else. Luckily, there is a new in thing, JavaScript Object Notation, JSON. In this post, I show you a simple client-server application based on Android, JSON and Google App Engine.
JSON is based on JavaScript object literals and is a textual representation of complex data instances. It has 4 basic types: strings, numbers, booleans and null. Objects and arrays can be constructed out of these 4 types, object is really just the JSON slang for key-value pairs. The entire thing is specified in RFC 4627 so I stick to just some simple examples so that you have that JSON feeling if you don't want to read the RFC.
This is a JSON number: -4.7e12
This is another JSON number: 0
This is NOT a JSON number: 00012 (no leading zeros!)
This is a JSON string: "JSON"
This is another JSON string: "\u005C" (always 4 hexa digits after the \u, just one character, the \)
This is not a JSON string: 'notJSON'
These are JSON literals: true, false, null
This is a JSON array: [1,"hello",null]
This is a JSON array having two other JSON arrays as elements: [[1,"hello"],[2,"hallo"]]
This is a JSON object: {"a":1,"b":"hello"}
This is a JSON object having another object associated with "a" key and an array with "b" key:
{"a":{"aa":1,"bb":2},"b":[3,4]}
I think this is enough for starter because it is evident that JSON has quite powerful data structures. Arrays are equivalent of Lisp lists while objects can be represented as lists of dotted pairs.
How does JSON compare to the incumbent serialization standard, XML? JSON is fashionable in mobile communication because it is somewhat more bandwidth-efficient than XML. E.g. the last example can be written in (ugly) XML like this (XML tag mangling due to blog engine limitations):
[l]
[a]
[aa]1[/aa]
[bb]2[/bb]
[/a]
[b]
[k]3[/k]
[k]4[/k]
[/b]
[/l]
Not counting the white spaces, this is 58 characters while the JSON representation is just 32 characters, about 45% less. The situation is worse if we consider many "well-designed" XMLs out there (like e.g. SOAP documents) which are full of namespace declarations, long tag names, etc. JSON with its simple yet powerful syntax definitely has a space in mobile application design.
Click here to download the example program.
I will demonstrate the power of JSON with a simple client-server example application. This application is a batch-mode calculator. The user first enters operations on the device's UI. These operations are not calculated immediately. When the user selects the "Process list" menu item, the collected operations are sent to the server in one batch. The server calculates the operations that are sent back to the client which displays the results. As you might have guessed, the client and the server communicates with JSON data structures.
The client part needs to be deployed on Android emulator (let's start with the emulator, I will return to this) like usual. The server part, however, requires the Google App Engine SDK for Python. Download the SDK, edit server/ae_jsoncalcserver.sh so that it suits your directory layout then start the shell script (Windows users will have to turn this one-line shell script into a .bat file). If you access localhost:8080 with your browser, you get a short message that GET is not supported. If you get there, you installed the server part properly.
Now you can start the client on the emulator and you can start to play with it. The most interesting part is the process() method in JsonCalc.java. I structured the program so that the generation of JSON request and the parsing of the response is all there. The org.json package has been part of Android from the beginning and this package is really easy to use. For the server part, I used the simplejson JSON parser for Python.
The Android client logs the JSON requests and responses in the Android log (adb logcat). I represented the batch operation and its result as array of objects. Request and response objects have different keys.
Request example:
[{"op":2,"v1":2,"id":1,"v2":3.3},{"op":3,"v1":4,"id":2,"v2":6},{"op":4,"v1":6.6,"id":3,"v2":2.2}]
Response example:
[{"id": 1, "result": -1.2999999999999998}, {"id": 2, "result": 24}, {"id": 3, "result": 2.9999999999999996}]
In case you want to try it out on a real phone, you'd better deploy the server part on Google infrastructure. Then edit Config.java in the client source so that APP_BASE_URI points to your server's address and you are ready to go. When you recompile, make sure that you delete the client/bin/classes directory - chances are that javac will not notice your changes you made to Config.java because of its broken dependency resolution.
JSON is based on JavaScript object literals and is a textual representation of complex data instances. It has 4 basic types: strings, numbers, booleans and null. Objects and arrays can be constructed out of these 4 types, object is really just the JSON slang for key-value pairs. The entire thing is specified in RFC 4627 so I stick to just some simple examples so that you have that JSON feeling if you don't want to read the RFC.
This is a JSON number: -4.7e12
This is another JSON number: 0
This is NOT a JSON number: 00012 (no leading zeros!)
This is a JSON string: "JSON"
This is another JSON string: "\u005C" (always 4 hexa digits after the \u, just one character, the \)
This is not a JSON string: 'notJSON'
These are JSON literals: true, false, null
This is a JSON array: [1,"hello",null]
This is a JSON array having two other JSON arrays as elements: [[1,"hello"],[2,"hallo"]]
This is a JSON object: {"a":1,"b":"hello"}
This is a JSON object having another object associated with "a" key and an array with "b" key:
{"a":{"aa":1,"bb":2},"b":[3,4]}
I think this is enough for starter because it is evident that JSON has quite powerful data structures. Arrays are equivalent of Lisp lists while objects can be represented as lists of dotted pairs.
How does JSON compare to the incumbent serialization standard, XML? JSON is fashionable in mobile communication because it is somewhat more bandwidth-efficient than XML. E.g. the last example can be written in (ugly) XML like this (XML tag mangling due to blog engine limitations):
[l]
[a]
[aa]1[/aa]
[bb]2[/bb]
[/a]
[b]
[k]3[/k]
[k]4[/k]
[/b]
[/l]
Not counting the white spaces, this is 58 characters while the JSON representation is just 32 characters, about 45% less. The situation is worse if we consider many "well-designed" XMLs out there (like e.g. SOAP documents) which are full of namespace declarations, long tag names, etc. JSON with its simple yet powerful syntax definitely has a space in mobile application design.
Click here to download the example program.
I will demonstrate the power of JSON with a simple client-server example application. This application is a batch-mode calculator. The user first enters operations on the device's UI. These operations are not calculated immediately. When the user selects the "Process list" menu item, the collected operations are sent to the server in one batch. The server calculates the operations that are sent back to the client which displays the results. As you might have guessed, the client and the server communicates with JSON data structures.
The client part needs to be deployed on Android emulator (let's start with the emulator, I will return to this) like usual. The server part, however, requires the Google App Engine SDK for Python. Download the SDK, edit server/ae_jsoncalcserver.sh so that it suits your directory layout then start the shell script (Windows users will have to turn this one-line shell script into a .bat file). If you access localhost:8080 with your browser, you get a short message that GET is not supported. If you get there, you installed the server part properly.
Now you can start the client on the emulator and you can start to play with it. The most interesting part is the process() method in JsonCalc.java. I structured the program so that the generation of JSON request and the parsing of the response is all there. The org.json package has been part of Android from the beginning and this package is really easy to use. For the server part, I used the simplejson JSON parser for Python.
The Android client logs the JSON requests and responses in the Android log (adb logcat). I represented the batch operation and its result as array of objects. Request and response objects have different keys.
Request example:
[{"op":2,"v1":2,"id":1,"v2":3.3},{"op":3,"v1":4,"id":2,"v2":6},{"op":4,"v1":6.6,"id":3,"v2":2.2}]
Response example:
[{"id": 1, "result": -1.2999999999999998}, {"id": 2, "result": 24}, {"id": 3, "result": 2.9999999999999996}]
In case you want to try it out on a real phone, you'd better deploy the server part on Google infrastructure. Then edit Config.java in the client source so that APP_BASE_URI points to your server's address and you are ready to go. When you recompile, make sure that you delete the client/bin/classes directory - chances are that javac will not notice your changes you made to Config.java because of its broken dependency resolution.
Classic tank warfare with a modern touch - and extreme firepower!
Get behind the turret and lock your sites on your enemies, this is going to be an epic battle! You will have to use every ounce of your skill to destroy the cunning tank commanders that are out to destroy you. Take refuge behind a tree, radio for supplies, call in air support. Battle human, computer and networked opponents across 9 different terrains with multiple wind conditions.
Features:
- 7 Vehicles
- 31 Weapons
- 9 Terrains
- 3 CPU AIs
- 5 Wind Settings
- 75 Achievements.
- ONLINE PLAY
- Zooming
- In-Game Chat
- Player Rankings and Leaderboard.
Download This Free Game 4 Android here:
| Talk about it on our Facebook page. |
| FileSonic apk file: 4.17MB |
|
Copycat is a Simon clone, a simple and addictive memory game for Android. Watch the pattern and repeat. The sequence will get longer and faster with each round!
Includes four speed settings and monochrome challenge.
Great for kids of all ages!
Download This Free Game 4 Android here:
| Talk about it on our Facebook page. |
| FileSonic zip file: 1.78MB |
|
Guide DynamoKid as he tries to collect as many stars as possible. Platform gaming for the touch-age!
Features:
- Unique tap & swipe control system.
- Cute cartoon-like graphics.
- Very addictive old school platform game.
Download This Free Game 4 Android here:
| Talk about it on our Facebook page. |
| FileSonic apk file: 5.71MB |
|
Update: the first version of this post contained factual errors. Thanks to Tejas for pointing these out, you can find his experiences with C2DM here. The example program was also updated to fix these errors.
Android 2.2's most important improvement is without doubt the significantly faster virtual machine. The API, however, got some new features too. For me, the most intriguing new feature is the access to Google's experimental push services.
I have already posted about push feature in relation to iBus//Mobile asynchronous communication package so push is not new to Android. There are also open source alternatives like MQTT, Deacon or Urban Airship. It has also been present in certain Google applications from the beginning. Whenever Android Gmail application sends a notification when a new mail arrives on the server, you see push in operation. It is pretty fast, according to my experiences, even though time to time it takes longer time for the notification to arrive. 2.2 opened that already existing mechanism to general-purpose applications, even though the push service is still in early beta.
In order to do push, either one has proper push bearer (a network mechanism able to deliver unsolicited messages to the device) or such mechanism is simulated. Currently only two real push bearers are deployed widely on mobile networks, SMS and Blackberry's proprietary push solution. SMS is costly and the Blackberry solution is available only for Blackberry so the push bearer has to be simulated. The most common simulation method relies on the device to open a TCP connection to the push server. As the TCP stream is full-duplex, the server can send the push message to the device, provided that the stream is still alive. And that's the tricky bit whose complexity should not be underestimated. TCP streams time out if there is no communication on them and the other side does not necessarily notice it. A constant ping-pong traffic needs to be generated to prevent this. Frequency, however, is critical. Too frequent ping-pongs and the data cost associated to ping-ponging will be unacceptable and the battery is drawn down quickly. Too rare ping-pongs and the device or the server will not notice that the TCP stream was closed, only after a long timeout. For the user, it means that he did not get his urgent message immediately, only after, say, an hour.
There is no perfect solution to this problem, therefore it is a good feeling that Google made its best to create a simulated push bearer, along with the server that is able to keep that many TCP sockets open and shared that infrastructure with us. The Google push architecture has the following elements.
Cloud to Device Messaging (C2DM) has many tricky aspects but I wanted to create a test program that is as simple as possible. To try it out, you need the following:
If you want to do the same trick from a real phone, you need a server with fix IP address or a fix DNS name and run the App Engine SDK there. Or better, deploy it on the real thing, on Google infrastructure. In any case, make sure that you update the server address in client/src/aexp/push/Config.java (and delete client/bin/classes directory as there are occassionally troubles with javac's dependency resolution).
About the application. The application reuses c2dm utility library from the JumpNote sample application. When the account is selected, the application registers with the push server using the phone user's credentials and the application ID that you registered with Google. Then comes the interesting bit. After the application registers with the push server, it sends the registration ID to the application server. The application server will use the registration ID to talk to the push server when it wants to do push. The server uses the Google account that you selected for push for authentication and therefore it needs the password for this account.
The implementation in the example application server program is a not efficient as it always requests an authentication token before it sends the push message. In an efficient implementation the token can be requested only once and can be used to authenticate many messages. Eventually the token expires and only then should new authentication token requested.
The client application also sends the client account name to the server but it is not used for authentication, it is only needed so that you can select the push target by account name in the web application's drop-down menu.
Android 2.2's most important improvement is without doubt the significantly faster virtual machine. The API, however, got some new features too. For me, the most intriguing new feature is the access to Google's experimental push services.
I have already posted about push feature in relation to iBus//Mobile asynchronous communication package so push is not new to Android. There are also open source alternatives like MQTT, Deacon or Urban Airship. It has also been present in certain Google applications from the beginning. Whenever Android Gmail application sends a notification when a new mail arrives on the server, you see push in operation. It is pretty fast, according to my experiences, even though time to time it takes longer time for the notification to arrive. 2.2 opened that already existing mechanism to general-purpose applications, even though the push service is still in early beta.
In order to do push, either one has proper push bearer (a network mechanism able to deliver unsolicited messages to the device) or such mechanism is simulated. Currently only two real push bearers are deployed widely on mobile networks, SMS and Blackberry's proprietary push solution. SMS is costly and the Blackberry solution is available only for Blackberry so the push bearer has to be simulated. The most common simulation method relies on the device to open a TCP connection to the push server. As the TCP stream is full-duplex, the server can send the push message to the device, provided that the stream is still alive. And that's the tricky bit whose complexity should not be underestimated. TCP streams time out if there is no communication on them and the other side does not necessarily notice it. A constant ping-pong traffic needs to be generated to prevent this. Frequency, however, is critical. Too frequent ping-pongs and the data cost associated to ping-ponging will be unacceptable and the battery is drawn down quickly. Too rare ping-pongs and the device or the server will not notice that the TCP stream was closed, only after a long timeout. For the user, it means that he did not get his urgent message immediately, only after, say, an hour.
There is no perfect solution to this problem, therefore it is a good feeling that Google made its best to create a simulated push bearer, along with the server that is able to keep that many TCP sockets open and shared that infrastructure with us. The Google push architecture has the following elements.
- The device that authenticates and registers with the push server (Cloud to Device Messaging in Google lingo) and provides authentication ticket to the 3rd Party Application Server.
- 3rd Party Application Server that uses the authentication ticket generated by the device to send push requests to the push server.
- Push server provided by Google that authenticates push requests from 3rd Party Application Servers and delivers the messages to the devices.
Cloud to Device Messaging (C2DM) has many tricky aspects but I wanted to create a test program that is as simple as possible. To try it out, you need the following:
- A PC connected to the Internet so that Google C2DM servers can be reached (and C2DM servers can reach us).
- Android emulator with 2.2+Google API AVD created (API level 8).
- Google App Engine SDK for Python.
- A Google account that you register with Google for push. It is better not to use your real e-mail address because you have to insert the password for this account into the server script. Use aexp.push as package name for the application in the registration form.
- Unpack the download package. Start the Android emulator. Create a Google account if no such account exists (Settings/Accounts & sync). This account does not have to be the same that you registered for push, it can be any Google account that you know the password for.
- Enter the "client" directory in the download package, update client/src/aexp/push/Config.java with the Google account you registered for push (C2DM_SENDER)
- Open server/pushserver/pushserver.py and update it with your push Google account (lines 165 and 167). Unfortunately here you have to insert the password for your push Google account into the server script.
- Enter the "server" directory, customize "ae_pushserver.sh" according to your directory layout and start it. Google App Engine SDK starts.
- Start the Push application on the emulator, select the account using the Menu and wait for the "Registered" message to appear. Now the server application is ready to deliver push messages.
- Go to http://localhost:8080 with your browser and type a message. Select the account from the drop-down list that you configured on the device and click the submit button. The message should appear on the emulator screen.
If you want to do the same trick from a real phone, you need a server with fix IP address or a fix DNS name and run the App Engine SDK there. Or better, deploy it on the real thing, on Google infrastructure. In any case, make sure that you update the server address in client/src/aexp/push/Config.java (and delete client/bin/classes directory as there are occassionally troubles with javac's dependency resolution).
About the application. The application reuses c2dm utility library from the JumpNote sample application. When the account is selected, the application registers with the push server using the phone user's credentials and the application ID that you registered with Google. Then comes the interesting bit. After the application registers with the push server, it sends the registration ID to the application server. The application server will use the registration ID to talk to the push server when it wants to do push. The server uses the Google account that you selected for push for authentication and therefore it needs the password for this account.
The implementation in the example application server program is a not efficient as it always requests an authentication token before it sends the push message. In an efficient implementation the token can be requested only once and can be used to authenticate many messages. Eventually the token expires and only then should new authentication token requested.
The client application also sends the client account name to the server but it is not used for authentication, it is only needed so that you can select the push target by account name in the web application's drop-down menu.
Talking Baby Hippo is a fun 3D character suitable for children aged 2-7 and for everyone young at heart. Baby Hippo repeats everything you say with his baby voice.
You can tickle him, poke him, feed him carrots, make him blow a balloon, give him a pacifier or make him play with a butterfly.
You can even record your own videos of Baby Hippo and share them on YouTube, Facebook or send them to your friends and family by email.
Download This Free App 4 Android here:
| Talk about it on our Facebook page. |
| FileSonic apk file: 4.33MB |
|
