Création des Logiciels de gestion d'Entreprise, Création et référencement des sites web, Réseaux et Maintenance, Conception
Seo Master present to you: This post is part of the Who's @ Google I/O, a series of blog posts that give a closer look at developers who'll be speaking or demoing at Google I/O. This guest post is written by Aloqa’s Head of Client Development Matthias Schicker who will be demoing as part of the Developer Sandbox.
In the last few years, the mobile industry has overcome several infrastructure hurdles that location-based services (LBS) have historically faced -- cheap, small GPS receivers have become ubiquitous, CellID / Wifi positioning has become available on platforms like Android and iPhone, and some carriers have even started to make location information available. Not surprisingly, a wave of LBSs has been unleashed in the market. Yet LBS has still not lived up to its much vaunted promise.
The reason, we believe, is that most location services are still "reactive" -- they treat the phone like a PC. The user is required to launch an application that returns information based on the user's location. While these "finder" services are certainly useful, with Aloqa, we believe we are striking at the core of three things that are fundamentally wrong with mobile LBS today:
1. Mobile phones shouldn't have to be used as browsers. A phone is an interrupt-based device that is intended to alert you - ring when someone calls or buzz when an SMS comes in. It should "proactively notify" you, as obtrusively or unobtrusively as you'd like, of content, people, and places in your surroundings. So you never miss an opportunity to socialize, play, work, shop, watch a show, or just grab a coffee with a friend.
2. Location is only one part of a user's current "context". Historically, "location" has been used a little too simplistically by mobile apps. The canonical LBS example is to walk by a Starbucks and get a coupon sent to your phone. Even ignoring the fact that Starbucks doesn't even have coupons, if all we got all day from mobile apps is aggressive ads of various kinds, of course we would hate "LBS" too.
Location is just one component of a user's context. Who the user is, what they like, the time of day, their social graph - these are all important inputs to context as well. Your phone can be trained in a much smarter way to know you and therefore is a perfect device to give you "Context Based Services".
3. Point applications are good but it's getting beaten to death by a thousand apps. Restaurants, toilets, bars, music, events, even friend finders - why have separate apps for them? This information should just be available to users at their fingertips and at once, and without having to launch individual applications and type into them.
Aloqa is a mobile service that proactively notifies you of a variety of interesting opportunities around you: places, events, bargains, friends and activities. A kind of universal "context based inbox" for all the world's location relevant content and services.
If you have an Android phone, you can download Aloqa through the Android Market or scan this QR code to the left. To try our dev tools, go to http://dev.aloqa.com. We’d love to hear your feedback, and if you’re going to I/O, be sure to stop by the Developer Sandbox to see our demo!
posted by Matthias Schicker, Head of Client Development at Aloqa2013, By: Seo Master
In the last few years, the mobile industry has overcome several infrastructure hurdles that location-based services (LBS) have historically faced -- cheap, small GPS receivers have become ubiquitous, CellID / Wifi positioning has become available on platforms like Android and iPhone, and some carriers have even started to make location information available. Not surprisingly, a wave of LBSs has been unleashed in the market. Yet LBS has still not lived up to its much vaunted promise.
The reason, we believe, is that most location services are still "reactive" -- they treat the phone like a PC. The user is required to launch an application that returns information based on the user's location. While these "finder" services are certainly useful, with Aloqa, we believe we are striking at the core of three things that are fundamentally wrong with mobile LBS today:
1. Mobile phones shouldn't have to be used as browsers. A phone is an interrupt-based device that is intended to alert you - ring when someone calls or buzz when an SMS comes in. It should "proactively notify" you, as obtrusively or unobtrusively as you'd like, of content, people, and places in your surroundings. So you never miss an opportunity to socialize, play, work, shop, watch a show, or just grab a coffee with a friend.
2. Location is only one part of a user's current "context". Historically, "location" has been used a little too simplistically by mobile apps. The canonical LBS example is to walk by a Starbucks and get a coupon sent to your phone. Even ignoring the fact that Starbucks doesn't even have coupons, if all we got all day from mobile apps is aggressive ads of various kinds, of course we would hate "LBS" too.
Location is just one component of a user's context. Who the user is, what they like, the time of day, their social graph - these are all important inputs to context as well. Your phone can be trained in a much smarter way to know you and therefore is a perfect device to give you "Context Based Services".
3. Point applications are good but it's getting beaten to death by a thousand apps. Restaurants, toilets, bars, music, events, even friend finders - why have separate apps for them? This information should just be available to users at their fingertips and at once, and without having to launch individual applications and type into them.
Aloqa is a mobile service that proactively notifies you of a variety of interesting opportunities around you: places, events, bargains, friends and activities. A kind of universal "context based inbox" for all the world's location relevant content and services.- Instead of having to search, you can just look at your phone and see your local hotspots, events of interest, and recommended bargains.
- Users can customize Aloqa and decide which Aloqa "channels" they want from our "channel store".
- Using our API, publishers can create a channel and use our universal inbox for context relevant notifications, be it for biking trails, or popular bars where Pittsburgh Steelers fans congregate.
If you have an Android phone, you can download Aloqa through the Android Market or scan this QR code to the left. To try our dev tools, go to http://dev.aloqa.com. We’d love to hear your feedback, and if you’re going to I/O, be sure to stop by the Developer Sandbox to see our demo!posted by Matthias Schicker, Head of Client Development at Aloqa2013, By: Seo Master
Seo Master present to you: On April 7th, Google launched a new version of Gmail for mobile for iPhone and Android-powered devices built on HTML5. We shared the behind-the-scenes story through this blog and decided to share more of our learnings in a brief series of follow up blog posts. In the last two posts, we covered everything you need to know in order to make effective use of AppCache. This week, we'll be having some fun and trying to disect the inner workings of AppCache by looking at the database it uses to store its resources. Before we start though, I'd like to point out one tip that can be useful while debugging AppCache related problems on the iPhone: how to clear your Application Cache.
There are two steps involved here:
Now onto the fun stuff! There is no way to inspect the application cache from within the browser. However, if you are using the iPhone Simulator to develop your webapp, you can find all of the Application Cache resources and metadata in a SQLite3 database located at:
Let's have a look at what is contained within this database.
The CacheGroups table holds an overview of what manifests exist. A manifest is identified by its URL and the manifestHostHash is used to track when the contents of a manifest changes.
Here you can see that I have only one cache in my database. If the Application Cache was in the middle of updating the cache, there would be a second entry listed here for the cache currently being downloaded.
The CacheEntries table holds a one-to-many relationship between a cache and resources within it.
This shows what information is stored for each resources listed in a manifest. As you can see the CacheResources and CacheResourceData tables contain everything that is needed in order to simulate a network response to a request for a resource. Let's see exactly what is stored in the database for Mobile Gmail's database.
From this list, it is fairly easy to see what the meaning of the type field is. A host page has type 1, a manifest has type 2, and a normal resource has type 4. In order to know whether or not to load a page using AppCache, the browser checks this list to see if there is a URL of type 1 within it.
This concudes our three-part series on HTML5's Application Cache. Stay tuned for the next post where we will explore other areas of how we use HTML5 in Gmail. And just another reminder that we'll be at Google I/O, May 27-28 in San Francisco presenting a session on how we use HTML5. We'll also be available at the Developer Sandbox, looking forward to meeting you in person.
References
The HTML5 working draft: http://dev.w3.org/html5/spec/Overview.html
Apple's MobileSafari documentation: http://developer.apple.com/webapps/docs/documentation/AppleApplications/Reference/SafariJSRef/DOMApplicationCache/DOMApplicationCache.html
Webkit Source Code: http://trac.webkit.org/browser/trunk/WebCore/loader/appcache
2013, By: Seo Master
There are two steps involved here:
- Go to Settings->Safari and tap "Clear Cache".
- Open Safari and terminate it by holding down the home screen button for 10 seconds.
Now onto the fun stuff! There is no way to inspect the application cache from within the browser. However, if you are using the iPhone Simulator to develop your webapp, you can find all of the Application Cache resources and metadata in a SQLite3 database located at:
~/Library/Application Support/iPhone Simulator/User/Library/Caches/com.apple.WebAppCache/ApplicationCache.db
Let's have a look at what is contained within this database.
$ sqlite3 ApplicationCache.db
SQLite version 3.4.0
Enter ".help" for instructions
sqlite> .mode column
sqlite> .headers on
sqlite> .tables
CacheEntries CacheResourceData CacheWhitelistURLs FallbackURLs
CacheGroups CacheResources Caches SchemaVersion
sqlite> select * from CacheGroups;
id manifestHostHash manifestURL newestCache
---------- ---------------- ------------------------------------------------- -----------
1 906983082 http://mail.google.com/mail/s/?v=ma&name=sm 1
The CacheGroups table holds an overview of what manifests exist. A manifest is identified by its URL and the manifestHostHash is used to track when the contents of a manifest changes.
sqlite> select * from Caches;
id cacheGroup
---------- ----------
1 1
Here you can see that I have only one cache in my database. If the Application Cache was in the middle of updating the cache, there would be a second entry listed here for the cache currently being downloaded.
sqlite> select * from CacheEntries limit 1;
cache type resource
---------- ---------- ----------
1 2 1
The CacheEntries table holds a one-to-many relationship between a cache and resources within it.
sqlite> select * from CacheResources where id=1;
id url statusCode responseURL
---------- ------------------------------------------- ---------- -----------------------
1 http://mail.google.com/mail/s/?v=ma&name=sm 200 http://mail.google.c...
mimeType textEncodingName headers data
------------------- ---------------- --------------
text/cache-manifest utf-8
This shows what information is stored for each resources listed in a manifest. As you can see the CacheResources and CacheResourceData tables contain everything that is needed in order to simulate a network response to a request for a resource. Let's see exactly what is stored in the database for Mobile Gmail's database.
sqlite> select type,url,mimeType,statusCode from CacheEntries,CacheResources where resource=id;
type url mimeType statusCode
---------- ---------------------------------------------- ------------------- ----------
2 http://mail.google.com/mail/s/?v=ma&name=sm text/cache-manifest 200
4 http://mail.google.com/mail/images/xls.gif image/gif 200
4 http://mail.google.com/mail/images/pdf.gif image/gif 200
4 http://mail.google.com/mail/images/ppt.gif image/gif 200
4 http://mail.google.com/mail/images/sound.gif image/gif 200
4 http://mail.google.com/mail/images/doc.gif image/gif 200
4 http://mail.google.com/mail/images/graphic.gif image/gif 200
1 http://mail.google.com/mail/s text/html 200
4 http://mail.google.com/mail/images/generic.gif image/gif 200
4 http://mail.google.com/mail/images/zip.gif image/gif 200
4 http://mail.google.com/mail/images/html2.gif image/gif 200
4 http://mail.google.com/mail/images/txt.gif image/gif 200
From this list, it is fairly easy to see what the meaning of the type field is. A host page has type 1, a manifest has type 2, and a normal resource has type 4. In order to know whether or not to load a page using AppCache, the browser checks this list to see if there is a URL of type 1 within it.
This concudes our three-part series on HTML5's Application Cache. Stay tuned for the next post where we will explore other areas of how we use HTML5 in Gmail. And just another reminder that we'll be at Google I/O, May 27-28 in San Francisco presenting a session on how we use HTML5. We'll also be available at the Developer Sandbox, looking forward to meeting you in person.
References
The HTML5 working draft: http://dev.w3.org/html5/spec/Overview.html
Apple's MobileSafari documentation: http://developer.apple.com/webapps/docs/documentation/AppleApplications/Reference/SafariJSRef/DOMApplicationCache/DOMApplicationCache.html
Webkit Source Code: http://trac.webkit.org/browser/trunk/WebCore/loader/appcache
2013, By: Seo Master
Seo Master present to you: 
By Ricardo Cabello (aka Mr.doob), Google Data Arts Team
Last August, we released “The Wilderness Downtown”, a music experience that brought together HTML5 and JavaScript, as well as the Google Maps and Street View APIs. Today, we’re excited to introduce our newest project, “3 Dreams of Black”, made with WebGL, HTML5 and JavaScript, and designed for modern browsers like Google Chrome. We previewed this music experience yesterday with web developers at Day 2 of the Google I/O keynote.
“3 Dreams of Black” takes you on a journey through three dream worlds constructed through a combination of rich 2D drawings and animations interwoven with interactive 3D sequences. Throughout various points in these dream worlds, you can grab your mouse and guide the protagonist’s point of view through the experience. This music experience also includes a 3D model creator that allows you to create your own relics and contribute to the shared collective dream. “3 Dreams of Black” is written and directed by Chris Milk, and developed with a few folks here at Google.
In creating “3 Dreams of Black”, we’ve had the opportunity to build many tools, libraries, and models. We’ve fully opened up the source code and made it available for web developers to tinker with us at www.ro.me/tech. In addition to the code, a few other highlights include eight WebGL demos, a fun model viewer for interacting with some of the animals from the web experience, and the Three.js 3D library used for building the experience. In addition, a big part of the project was to define a good pipeline for getting all the animals and environment models right in WebGL -- for this, we extended Blender with custom plugins so we could manipulate and export the data with ease.
“3 Dreams of Black” is set to the song “Black” off the album ROME, presented by Danger Mouse & Daniele Luppi, featuring Jack White and Norah Jones on vocals, to be released soon on the record label EMI. Because it’s built in WebGL, it requires a WebGL-supported browser like Chrome, and Windows Vista / Mac OS X 10.6 and above to help ensure that your computer has the necessary and up-to-date graphics drivers. We hope you’ll take a moment to dive into the experience and the developer resources at www.ro.me
Ricardo Cabello is a designer/developer in the Google Data Arts Team. He is the creator of several popular Chrome Experiments, including Google Gravity, Ball Pool, and Harmony.
Posted by Scott Knaster, Editor
2013, By: Seo Master
By Ricardo Cabello (aka Mr.doob), Google Data Arts Team
Last August, we released “The Wilderness Downtown”, a music experience that brought together HTML5 and JavaScript, as well as the Google Maps and Street View APIs. Today, we’re excited to introduce our newest project, “3 Dreams of Black”, made with WebGL, HTML5 and JavaScript, and designed for modern browsers like Google Chrome. We previewed this music experience yesterday with web developers at Day 2 of the Google I/O keynote.
“3 Dreams of Black” takes you on a journey through three dream worlds constructed through a combination of rich 2D drawings and animations interwoven with interactive 3D sequences. Throughout various points in these dream worlds, you can grab your mouse and guide the protagonist’s point of view through the experience. This music experience also includes a 3D model creator that allows you to create your own relics and contribute to the shared collective dream. “3 Dreams of Black” is written and directed by Chris Milk, and developed with a few folks here at Google.
In creating “3 Dreams of Black”, we’ve had the opportunity to build many tools, libraries, and models. We’ve fully opened up the source code and made it available for web developers to tinker with us at www.ro.me/tech. In addition to the code, a few other highlights include eight WebGL demos, a fun model viewer for interacting with some of the animals from the web experience, and the Three.js 3D library used for building the experience. In addition, a big part of the project was to define a good pipeline for getting all the animals and environment models right in WebGL -- for this, we extended Blender with custom plugins so we could manipulate and export the data with ease.
“3 Dreams of Black” is set to the song “Black” off the album ROME, presented by Danger Mouse & Daniele Luppi, featuring Jack White and Norah Jones on vocals, to be released soon on the record label EMI. Because it’s built in WebGL, it requires a WebGL-supported browser like Chrome, and Windows Vista / Mac OS X 10.6 and above to help ensure that your computer has the necessary and up-to-date graphics drivers. We hope you’ll take a moment to dive into the experience and the developer resources at www.ro.me
Ricardo Cabello is a designer/developer in the Google Data Arts Team. He is the creator of several popular Chrome Experiments, including Google Gravity, Ball Pool, and Harmony.
Posted by Scott Knaster, Editor
2013, By: Seo Master