It seems like facebook has this mastered, I've checked a bit into WURFL but this seems like an extremely expensive process. I've also checked out: url link. While it has a good list of user agents, I'm trying to identify which are smart phones and which are not.
facebook pushes the non-smart phones to a different site than their smart phones. Trying to see if there was an easy way to do this.
You should look into Tera-WURFL which is basically WURFL serialized data in a MySQL database. Much better performance than XML WURFL.
There is also another mobile device db out there: Device Atlas.
What you could do is find the lowest common denominator for smartphones, then create your own stripped down version of WURFL / Device Atlas which would be far less resource intensive and faster to check, and go from there.
Screen size should be a somewhat reliable indicator. Non-smarts tend to have less than 320x240 resolution, though I'd check some older smartphone models to be sure.
Try wurfl-php-1.4.2.0
$isPhone = $device->getCapability("can_assign_phone_number");
$isSmarty = $device->getCapability("device_claims_web_support");
If it is a phone and smart, it is a smartphone.
If it is a phone and it is not smart, it is a non-smartphone
Related
TLDR; Is it possible to get an approximation of whether user hardware is arbitrarily "good" or "bad" in order to serve them more or less resource intensive content using PHP NOT serving javascript first and relaying info?
I can't find anything online about it, but is there any way to get some basic information about the user's hardware using only the information PHP has access to? i.e. request headers likes user-agent string etc?
I don't mean detailed information like RAM, HDD Capacity, CPU, GPU etc, just an approximation to plug into a boolean value $good_hardware = true for example
Why? Javascript and CSS effects and animations can massively improve user engagement if not overused and properly placed, but some effects and scripts in particular can be extremely resource intensive.
It would nice to be able to have an idea of the user's hardware so that users with high performance machines can benefit from the increased engagement, but users with low-end machines can be served slightly different content with effects/scripts simplified or turned off altogether in order to improve the page speed
I am NOT looking for javascript solutions, as this should work from the landing page and not delay the user's first engagement with the site
There is a Browser Capabilities Project for PHP that will give you all kinds of info about the Browser and a little bit about the machine. See PHP's get_browser().
These guys that say you can spoof the UA are not the sharpest knives in the drawer. 99.99% of the population does not know what a UA is. And, so what if someone does?
The bigger question is Why? Why do you want to rank visitors? That would give us some insight and possible have a solution. Basically you have our hands tied.
Obviously javascript is the correct tool for this job. Why no javascript? And I'm not talking extensive analyzation, based on javascript's ability to tell you about the visitor's screen size, and etc.
It's very simple. At the top of the HTML you have a simple javascript that simply stores the time. At onload, you write the time again. The difference between the two times gives you an excellent indicator of the user's machine performance. But for whatever reason you want to avoid Javascript, you can get some very limited info from the user agent. You can get the OS, whether the machine is 16, 32, or 64 bit, and mobile or desktop. I cannot help you because I have no idea why you are doing this.
I'm currently building a facebook alike chatbox, and I have encounter several considerations and problems along the way.
I had been googling useful resources all the time,like simple chatbox example or tutorial online.
My goal is to build one just like facebook/gmail chatbox and CometChat, I know it's hard and too much thing to scale behind the scene, but all I want to do is building it as simple as possible, and figuring out how facebook/gmail chatbox implement their chat functionality.
Progress:
I have finished facebook-like chatbox structure where I have sidebar at the right displaying online friends i can chat with, and popup chatbox at the bottom, and it is able to expand and minimize it.
I also have finished simple chatting based on MySQL database.
There's a table with 4 columns 'sender', 'receiver', 'message', 'time' for storing conversation.
My chatbox works this way:
1.The user send a message, and my front-end javascript will fetch the message the user type in and send the message to php file on the server via Ajax.
2. backend php file will store this message to MySQL.
3. The front-end will call the update function every 3 seconds to update the chatbox content if receiver send message to the sender, and show it out in frontend's chat.
I'm not sure this is a good way and long way to do, and I'm really concerned about it.
If users grow and grow, I have to think of ways to scale it well or my database and server will explode and frontend users might feel high latency in updating conversation.
Is BigTable a right way to do this if you have millions of users online?
How does facebook store their customer's text message or chat history in the backend well??
How does chat app like Whatapp store their text message?
Is it able to let the users chat directly to another user without storing state in server?
If I want to implement the chat history functionality in my chatbox, what is a good way to do ??
I am thinking server can create .txt file for each conversation in their file system, and it has a database table column to store the file path. Is this a good way and right way to do with chat history, I know its possible to do it this way, but im not sure if its a right way or good way.
I know this could be a huge, detailed application.
I'm asking not a detailed implementation but a big picture, concept of building it!
thank you!.
That's a good question and here's an attempt at answering it.
I believe you are thinking about scalability a bit too early. Your IM app might not reach the projected number of users for it to stop performing well. Consider enhancing your small product and scale as you go as much as is needed.
Disk I/O is one of the issues that you will face scaling your web application. Storing communication directly onto the disk with txt file might not be a reliable solution.
Push your technology stack to its limits before considering changing it or switching to something else. I assume you are using a relational database for your storage (since you mentioned columns and rows, which is not an ultimate indicator but still), there are other options out there that have good benchmarking results at the expense of multiple other compromises. (NoSQL: which you referred to as BigTable) is one option. Relational databases are great, they have been for quite a long time the industry standard but currently there are alternative solutions that are quite promising.
Look into NoSQL document based datastorage solutions such as MongoDB, CoucheDB or even Casandra and there are many others. There is a considerable amount of information about the performance of each, under specific circumstances and situations. Choose what is best for the problem at hand and not what is most fashionable or hipped.
Another option would be to outsource your scalability problems to a 3rd Party provider such as Firebase. In this situation all you have to worry about is your product and not what's happening under the hood.
Store only the data that you need and archive or dismiss what you don't.
With scalability there are generally 2 broad categories: Horizontal and Vertical scaling.
Horizontal: means adding more nodes to your system i.e. adding more server instances to handle the extra load. There are many cloud solution providers out there that make this genre of scaling very cheap and instantaneous.
Vertical: means adding more resources to the node you are currently running your app from in addition to use specific technologies that allow you to take full advantages of your resources. This optimization happens on the level of the instance resources (i.e. CPU, RAM, Disk Space etc...) and your data storage, programming language of choice, algorithms you are using etc... You might realize that php and mysql aren't the tools for this job, but that's arguable.
Read More about it here
Distributed Systems architects / programmers also take advantage of other (faster) programming languages at runtime (such as C, C++ or even Java) to speed up certain tasks. Look into how you can dissect your application into smaller decoupled modules / components that can run independently. (But i'm not sure if you will ever reach this stage with an IM client unless it becomes as popular as Whatsapp or Facebook chat).
I advise you to grab and read a couple of books about scaling web applications and leveraging cloud computing. Study scalable architectures and design your application depending on your business logic based on them.
This is a very broad and complex topic, I'm sure others might have additional interesting insight on the matter.
I am currently looking at some code for PHP detection of mobiles, which is probably quite easy.
Now I just have got one problem - I want to make it possible to make unique view-files in my MVC-framework for tablets, mobiles and web pages. So I need to split the tablet from the rest of the mobile devices.
Currently this is the code, that I am using:
public function isMobile()
{
if(preg_match('/(alcatel|amoi|android|avantgo|blackberry|benq|cell|cricket|docomo|elaine|htc|iemobile|iphone|ipad|ipaq|ipod|j2me|java|midp|mini|mmp|mobi|motorola|nec-|nokia|palm|panasonic|philips|phone|sagem|sharp|sie-|smartphone|sony|symbian|t-mobile|telus|up\.browser|up\.link|vodafone|wap|webos|wireless|xda|xoom|zte)/i', $_SERVER['HTTP_USER_AGENT']))
return true;
else
return false;
}
But this is not enough - the only check is wheter the device is a mobile device - if not it is as standard telling the framework, that we're on a computer. The last part is ok - but I want to make a split of the mobile devices in actual mobiles - and in a secound group, which should be tablets.
I hope, that I have made my wish clear, and I hope, that you have some input in a good way to achieve this.
Thanks in advance.
Here is a class with methods for detecting each platform individually.
https://github.com/serbanghita/mobile-detect
Old question, but here goes my opinion regarding mobile detection.
You state in your question that you want unique files for mobile devices, so I can assume the reason for this is to present a different version of the website for mobile clients and desktop clients.
This approach is OK until a certain point. And that point is called Android. There are ~1.5 million Android devices activated each day with resolutions from 320*240 to 2560*1600, which makes it hard to if {} else for each of them. Even if you try to make a list with most used devices and you try to target only those, it will be hard to support a new device in the future.
My approach a while back was to forget about old method of splitting devices into "mobile" and "desktop" categories and create a new method. And that method consist in "good" and "bad" browsers which is based on browser capabilities. For example, if the browser supports local storage, it will be in "good" category.
Starting from this, I had the possibility to create a "base" version of the website, very basic from a UI standpoint but which will work cross-browser. This base version of the website will present the same content (because that matters at the end of the day) on all devices, will be very small in size (less assets, smaller html) and based on browser capabilities will be enriched on the client side.
So in the end you will end up with a website that has very small footprint (html size and assets), that looks OK cross browser and it will support any new device that comes up on the market without any changes, will load fast even on poor connections and that can be enriched on client side based on browser capabilities.
You can even enrich the webpage based on devices size: if the browser reports a large screen, you can bring in more assets, more ads and make the webpage more beautiful ; if the browser reports is on a small screen, you leave it as is.
Mobile_Detect is a lightweight PHP class for detecting mobile devices (including tablets). It uses the User-Agent string combined with specific HTTP headers to detect the mobile environment. — Read more
http://mobiledetect.net
You can also use a more comprehensive solution like WURFL Cloud, which is a service that detects the capabilities of mobile devices, like is_mobile and is_tablet. There is a free plan for low traffic sites: http://www.scientiamobile.com/cloud
Facebook has the feature to show instant auto-suggestion result in-various situations such as : searching , message sending etc.
i think I have been correct in terming the functionality as 'auto-suggestion'.
If a user has 1000 friends and s/he wishes to send message to a friend , then facebook will suggest his/her name on typing a few characters.
My question is: While pulling the data out of database to find friends (or for any such situation) and then handling with it, which technique does FB use to maintain the speed in auto-suggestion?
Is it caching the variable or what? I wish to know in details as i am planning to build a social networking site. My scripting language is php
I think a good chunk of it is not so much PHP, although facebook are known to use hiphop to compile the PHP.
A more important factor IMO would be the database side of things. The query is probably as optimised as it can be, only getting back what it needs, caching will probably also come into play, i.e. the user's friends have been already retrieved, quite likely getting back the most frequently contacted friends. Also facebook have tons and tons of database servers, which can only help speed really.
Hope that helps
Probably a data structure like patricia-trie or ternary search tree.
A suggesttree like: suggesttree.
Auto-suggesting with 1000 or even 5000 entries is not that hard. You have to retrieve the whole friend list, and to store it in indexed javascript array (for example we did it using the first letter as index, so friends['a'] = [andrey, albert] ) and then you are actually searching in memory from a small subset.
The invite window is build in similar fashion - you build an index of names -> dom elements, you perform the dom manipulation offline - and you are attaching the results with only people that match the searched term.
The friendlist is most likely cached in memcached, and facebook warm up caches as early as it can - it does not wait to use the friend list in any way in order to put it in memcache. So - it's retrieven in memcached, stored in local storage and uses efficient JavaScript. No DB involved here.
P.S. I'm not speaking for facebook, but for a similar solution we've designed to handle fast auto-suggest / invite dialog on 5000+ entries.
I'm in need of a way to detect mobile browsers server-side. I'd like a way that requires me to do little to set up and little to maintain, yet still provide me with accurate detection of (at the VERY least) Android, Mobile Safari and Blackberry browsers, along with alternatives like Opera.
I'd like to have at least the majority of the mobile market covered, and I'd really prefer virtually all of the market if it doesn't take much.
WURLF is the ultimate way for mobile browser detection and a PHP API is available.
I found this one to be very easy to use php-mobile-detect
(edit: for now the Browser Capability Project is closed, i.e. atm this answer is not an option)
All you need is get_browser() and a recent browscap.ini that maps the user-agent string to a browser/version and its capabilities.
You can get a usually very up-to-date browscap.ini version from http://browsers.garykeith.com/downloads.asp
Its just a matter of reading the headers ( How do I read any request header in PHP ) and parsing / interpreting this to read the "user-agent", you may be able to find an existing PHP script or maybe just plain regex that will help in figuring out which user-agents are mobile and which are regular pc's / laptops.
There are a lot of different headers, as it indicates the operating system, so as many different mobile OS'es as there are there would be user-agent headers so the script needs to have a list of all valid ones.
http://en.wikipedia.org/wiki/List_of_user_agents_for_mobile_phones
Found this library a little while back:
http://code.google.com/p/mobileesp/
Has PHP, Java, JavaScript, and C# versions. I see it as a "lightweight" smartphone/tablet detection tool without dependencies and is regularly updated. I have mixed feelings about it though as some aspects of the code quality are a bit shaky.
If you need something even lighter-weight, the WP Super Cache plugin for WordPress contains some long regex strings you could probably swipe.
Browser sniffing based on user agent strings is always going to be flaky. I looked at WURFL and it is several MB compressed. Using that is overkill. A better approach is to detect the top devices in use on the website, design for those devices, and then call it a day.
A quick Google search picks up these:
http://mobiforge.com/developing/story/lightweight-device-detection-php
http://code.google.com/p/php-mobile-detect/
Zend Framework introduced Zend_Http_UserAgent lately.
It can determine the Mobile Device and it's capabilities by detecting the UserAgent through Wurfl, TeraWurfl and DeviceAtlas API.
How about http://code.google.com/p/hdapi/ ? Server side mobile detection in PHP.
Unfortunately WURFL is not free anymore for commercial projects.
But there is OpenDDR with its experimental PHP implementation.
I once used to store temporarily visitors' ip-addresses and csrf-session values (meant to count current visitors).
And I noticed that I had a side-gain of being able to see if the visitor used a mobile or a PC: The csrf of a mobile changes with every new page load, a PC doesn't; and the ip-addresses remain in both cases.
Sure, you only detect a mobile if a visitor clicks twice and I have not checked how reliable this is (as I do not really need it), but it is php/server-side only.