I have a black box container. I love black boxes, they obfuscate things so well.
This black box is an encrypted zip (sort of) and has inside some html files (this is the short, not so painful to explain, version).
Those files need to be displayed in an UIWebView. Now, the easy way to do it, decrypt, unzip to filesystem, load file from filesystem. That's good, except, the black box contains secret stuff, and can't just lay around on the filesystem, not even a sec, so, I made a C library that actually streams the contents of the box (directly out of the box).
Now, I have this streaming capability and have to somehow make it work with UIWebView. First thing that comes in my mind would be to use a mini local HTTP server where the UIWebView can sent its requests. I would then manage the requests myself and return the contents the UIWebView requires using the streaming lib I've done. That would work I suppose well, but I think a mini HTTP server would somehow, maybe, be a little bit of a overkill.
So, I was wondering, is there another way to interfere between UIWebView and the filesystem? Maybe using a custom schema? Like myschema://? And every time the UIWebView makes a request to myschema://myfile.html I would somehow interfere and return the data it needs?
Is such a idea viable? Where should I look to start from? Maybe NSURLRequest?
EDIT: I found this: iPhone SDK: Loading resources from custom URL scheme. It sounds good, however, how will the browser know the size of the request, the type (xml/binary/xhtml) and all the info HTTP puts in its header?
Create a custom NSURLProtocol subclass and register it so it will handle the HTTP requests. This will allow you to handle the requests that come from the UIWebView however you see fit, including supplying the data from your library. You can examine an implementation of one that performs disk caching of requests to allow offline browsing by looking at RNCachingURLProtocol. I personally use a custom NSURLProtocol subclass that I wrote to handle injecting some javascript code into pages that are loaded in the UIWebView, and it works very well.
Related
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?
I've not written an iOS app and want to know if what I want to do is reasonably easy before I invest all my time in it. The idea is simply to leverage the built-in webkit methods to write my own browser. I've seen tutorials where this is done fairly easily. However, the twist is I want to apply some rewrite/regex rules prior to the page rendering. ie, you load http://example.com which is a page containing the word 'foo'. Prior to displaying the page, the app rewrites 'foo' to 'bar' and renders.
Is this possibly to do easily without actually writing a ground-up browser?
Thanks!
It's doable (assuming you're using the standard UIWebView component to render the page), and there are a few ways you could go about it. Among them:
You could download the HTML and parse it via Objective-C string handlers before loading it into the UIWebView
You coud use load the HTML as-is and use the UIWebview's stringByEvaluatingJavaScriptFromString: message to "inject" javascript onto the page, manipulating the DOM itself
You could go the Opera route, and pre-render the page via a server-side proxy before downloading it to the client.
How far down the rabbit hole you want to go would be up to you, of course. Easy is in the eye of the beholder.
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.
I'm trying to get my Chrome extension working with the Google Calendar API. However, the way Google has set up the extension sandbox makes anything almost impossible.
I can't add the Calendar API using JavaScript because I've tried 200 different ways to include the http://www.google.com/jsapi library. Therefore, I want to try interact with the Calendar API with PHP. Is it even possible to do a POST from a Chrome extension in order to run my PHP file? If not, it's pretty much impossible to interact with any external API that doesn't have a downloadable library, isn't it? If that's the case, I don't see how you can make anything useful with Chrome extensions.
I think you are still having difficulties because you don't completely understand the difference between content scripts and background pages.
Content scripts have certain limits. They can't:
Use chrome.* APIs (except for parts of chrome.extension)
Use variables or functions defined by their extension's pages
Use variables or functions defined by web pages or by other content scripts
Make cross-site XMLHttpRequests
Basically all they can is access DOM of a page where they were injected and communicate with background page (by sending requests).
Background page thankfully doesn't have any of those limits, only it can't access pages user is viewing. Good news is that background page can communicate with content scripts (again through requests).
As you can see background page and content scripts supplement each other. If you use both at the same time you have almost no limitations. All you need is correctly split your logic between those two.
As to your initial question - content scripts can't make cross domain requests, but background pages can. You can read more here.