I am developing a site using PHP, and I was a bit mislead by how Appcache works; it turns out that it also caches the current page. Which, in the case of a PHP app, is a problem. :)
I'd still like to cache my javascript, css and images on the client, but not my actual generated page. What is a good alternative for that? Just the plain old cache headers? The problem I see with them is, that they still produce requests. I am trying to mimize the amount of requests a client needs to make - this includes 304s.
As you might have found out by now, appCache is in the process of being deprecated and will sometimes disappear. It was a good solution for offline applications (static pages with variable data), but not as a cache for static files in dynamic pages.
You could try to include a blank page with a manifest in a hidden iframe in your dynamic pages, but still only pages present in the appCache would use the static resources downloaded from the manifest; the other pages would check the live static resources from the server anyway (the only part of the manifest which is valid everywhere is the "fallback" part).
So your best option is to check your cache headers as suggested by Marged, as it IS possible to avoid server access indefinitely for a static resource.
You could dig what the ServiceWorkers cache does, but I'm not an expert in the field (for now).
Related
I'm developing a SPA web app and it will support various languages. It is build with AngularJS and I am using angular-translate to provide i18n.
But I am struggling a little bit with how the URL structure should be. I do no plan on using either gTLDs nor ccTLDs, so that leaves me with three options.
Use query params: ?locale=en-us
Use url paths: /en-us/page
Store the chosen locale in localStorage or a cookie
The first option is a no-go according to Google's guidelines for web apps SEO. So that leaves me with the last two options.
I have a hard time deciding which is more beneficial, though I am inclined to believe that using url paths would probably be more crawler friendly.
P.S: Not sure if this is the best place to ask such a question either.
The second option is your safest bet as according to https://webmasters.stackexchange.com/questions/59652/what-happens-if-i-try-to-set-a-cookie-on-a-bot cookies are ignored. You can test this yourself by going to the Google Console and fetching your website.
As of now most crawlers ignore cookies and DO NOT execute JavaScript. This means that they usually just download the html and make their judgements from there.
Some developers get around the no javascript problem by pre-rendering parts of their content. I haven't done it personally but you might want to check out https://prerender.io/
Edit
As rolandjitsu mentioned google crawls and executes javascript content.
You should go with second option: provide the language tag (and, optionally, region subtags) in the URL path as first segment.
For the simple reason that it allows you, visitors, and bots to link to specific translations.
I want to be able to download the entire contents of a website and use the data in my app. I've used NSURLConnection to download files in the past, but I don't believe it is capable of downloading all files from an entire website. I'm aware of the app Site Sucker, but don't think there is a way to integrate it's functionality into my app. I looked into AFNetworking & ASIHttpRequest, but didn't see anything useful to me. Any ideas / thoughts? Thanks.
I doubt there is anything out of the box that you can use, but existing libraries that you mentioned (AFNetworking & ASIHttpRequest) will get you pretty far.
The way this works is, you load the main website. Then you go through the source and find any resources that that page uses to display its contents and link to other pages. You then need to recursively download the contents of those resources, as well as its resources.
As you can imagine, there are few caveats to this approach:
You will only be able to download files that are mentioned in the source codes. Hidden files or files that aren't used by any page will not be downloaded as the app doesn't know of their existence.
Be aware of relative and absolute paths: ./image.jpg, /image.jpg, http://website.com/image.jpg, www.website.com/image.jpg, etc. could all link to the same image.
Keep in mind that page1.html could link to page2.html and vice versa. If you don't put any checks in place, this could lead to an infinite loop.
Check for pages that link to external websites--you probably don't want to download those as many websites have links to the outside and here you downloading the entire Internet to an iPhone with 8GB of storage.
Any dynamic pages (the ones that use a server side scripting language, such as PHP) will become static because they lose their server backend to provide them with dynamic data.
Those are the ones I could come up with, but I'm sure that there's more.
The title says (quite) all: I would like to distribute an app with some HTML pages preloaded into the local Documents folder (they reflect the content of a mini mobile site available on the internet); then, when the contents of the pages are updated, the local HTML files into the app should be updated, so that the user can browse the updated informations also when not connected to the internet.
The app has to work since the first start, thanks to the preloaded pages, and then update itself periodically (I didn't need to check the modify date/time of the single files, it's enough to check and update them when the local copies are older than x days).
The problem: I think I can do it all, but I was asking to myself if is there some framework/class that does it automatically, because it sounds to be a pain :)
Consider using ASIHTTPRequest. Check out this SO question.
Specifically, you might want to look into ASIWebPageRequest:
download complete webpages, including external resources like images
and stylesheets. Pages of any size can be indefinitely cached, and
displayed in a UIWebview / WebView even when you have no network
connection.
I've also used AFNetworking for my own personal projects and it's made my life 10x easier. On the AFNetworking FAQ page, there's a question regarding caching mechanisms for offline viewing. It mentions that NSURLCache in iOS 5 introduced support for caching to disk for offline use - but only for http. If you need to cache https, consider using SDURLCache.
Here's a short additional resource in regards to network caching for iOS.
Read the section titled iOS network caching
If you are looking at pre popping your iOS app with the equivalent of a browser cache then
https://github.com/rs/SDURLCache might be something to look into.
It hooks in with existing NSURLConnection frameworks such as AFNetworking and you just need to set the correct cache policy in your NSURLRequest.
Given its open source you should be able to figure out how where to place your data so it loads it without fetching from the server the first time then just specify when you want the cache to purge itself so it fetches it from the server?
Could anyone please tell how the site http://www.outsharked.com/imagemapster/default.aspx?what.html is working in such way? Modifying the url without loading/reloading the page. I think this is not done by html5. Because it works in IE6 which doesn't support html5.
I created that site. The commenter is correct, it uses Javascript to change the URL. There's nothing about how that navigation works that is different for IE6 - that browser supports the necessary client-side functionality to do this kind of thing. The basic functionality involves:
capturing click events on the nav, and loading the inner content via AJAX
update the URL to reflect a working direct URL to target.
The links also are valid anchor links that, in the absence of Javascript, would go to the same page (but load the whole thing). This is your basic AJAX web site setup with one minor difference. It's common practice to use a URLs like this in AJAX/single page web sites:
http://mysite.com/home#somepage
or even just
http://mysite.com/#somepage
Where the hashtag part represents the actual page a user has navigated to. If someone accessed that url directly, e.g. from outside the site, the site would use Javascript to load the correct content based on the hashtag, after the page had loaded. This means that there might be a little delay for the inner content to reflect the correct page, since it has to run another request after the initial page has loaded from the browser to get the inner content via AJAX.
I was trying to avoid that by creating a setup that worked completely with and without Javascript. If you go directly to a URL within the site such as http://www.outsharked.com/imagemapster/default.aspx?faq.html you will notice it loads the content directly. This URL will work even if Javascript is disabled. You can't actually do this using hashtags, since hashtag content is not sent to the server. Only the client knows what's after the hashtag in a URL. That's why I was using query strings to represent inner pages.
This site architecture was sort of an experiment at the time. It works pretty well but the code isn't fantastic, I didn't really do anything else with it, and I'm sure there are other better-fleshed-out/tested/full-featured frameworks out there to do much the same thing.
But it might not be a bad example of the nuts and bolts of creating a basic AJAX navigation setup, as a learning tool, since it's pretty concise, and also does HTML5 history navigation (e.g. so the back button works on modern browsers).
I have a website http://www.domain.com and I am creating a separate section just for the iPad. I will be putting that in its own directory, http://www.domain.com/ipad/ is there a way for it to pull the contents of the /ipad/ folder but only show www.domain.com?
Hope that makes sense.
Thanks!
Do you have any example of a website doing this? Isn't a better option to serve this content from a specific mobile version, something like "m.domain.com"?
Added:
You can also do this. Use browser sniffing to serve a different stylesheet for the content if it is an HTTP request from an iPad. However, browser sniffing hardly works and it create good web-dev #fail joke memes. So, IMHO, using m.domain.com is the safest bet.
aHave your website serve iPad-specific contents if incoming request has user agent string set to iPad's (see this question).
PArticular implementation of serving content based on browser user-agents depends on which webserver / application container etc. you use.
I would not recommend doing this unless the content is significantly different for the iPad. This has SEO ramifications as well.
If the content is the same, a better approach is to use CSS media queries and serve a iPad styled version of the same website.