I'm trying to implement part of app with PWA approach, that works fine on Android, but not for iOS. We need to have
offline content availability
option to update content dynamically (like special offers or so). With service worker we show prompt to update web content.
As were mentioned here service workers are not supported within WKWebView (or UIWebView). So is there analog or alternative solution like smart cache control?
Seems like it is possible to store some web content from app and be able to update it if something changes. May there is already a framework/library/approach for that purpose?
EDIT
Service Workers unavailable in WKWebView in iOS 11.3 - this question explains the status of ServiceWorkers in WKWebView, but no alternative is given. I would like to discuss any alternative solutions.
One thing I discovered is https://github.com/xtools-at/iOS-PWA-Wrapper. It looks like working based on AppCache, but https://developer.mozilla.org/en-US/docs/Web/HTML/Using_the_application_cache#Browser_compatibility says it is deprecated and adviced to use SW instead (which is not an option for PWA).
So before WKWebView get service-workers to work, you can use AppCache (not yet fully deprecated).
You can use this and take a look at source page at https://leasingrechnen.at
What they do? In case if there is no service worker in browser, they load iframe that points to a page with manifest.appcache file implemented, so the page is cached.
Related
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 am looking for a replace to UIImagePickerController that allows custom extensibility for local pictures, public API's like Facebook/Flickr/Tumblr/Picasa/SmugMug, and custom proprietary picture collections (local or abroad).
Solutions I have found so far, and problems with them:
http://picture.io/photopickerplus
This is almost perfect, except I am forced to use the 3rd party service from getchute.com - what happens if this site goes dark, permanently? And all permissions dialogs list "Chute" as the application name. My app uses the Facebook SDK elsewhere, so I would like to use my existing APP id/key. When I add it via the chute app control panel, I get the Facebook API error "Invalid redirect_uri:Given URL is not allowed by the Application configuration". Which I can fix with the Facebook API, however if A. I knew what the URL was (I don't), and B. I really was OK with having a middle man with the API requests (I'm not).
It is also very ARC hostile which is a PITA to get running.
https://github.com/arturgrigor/AGImagePickerController
Very nice replacement for UIImagePickerController, that includes multi select. No built modularity to support Facebook or other API's.
https://github.com/jeena/JPImagePickerController
Simple replacement for just UIImagePickerController - doesn't seem to have navigable views. No apparent modularity.
https://github.com/facebook/three20/
Looks complicated. For obvious reasons won't play well with non-Facebook services.
https://github.com/mrdavenz/CaptureSessionManager has example code of to create your own photo picker with AVCamera. You could use this as a starting point. See the blog at http://www.musicalgeometry.com/?p=1297
Can you tell me if Apple accepts an application that opens an embedded browser with most of the functionality living on a web application on the internet?
I have read contradicting opinions on this, and I have even seen several apps that seem to use an embedded browser for the main functionality of the app. Still I couldn't confirm this.
This way we could correct problems on the application functionality on the server with no need to submit another version of the app, while keeping the ease of release through the app store and the home screen shortcut.
Thanks!
I can't get the exact quote from the guidelines, but I know that Cordova apps are allowed, and updating the web files dynamically without going through a new native app version is also allowed, as long as:
* The updated code runs with the Safari Webkit engine (true for Cordova)
* The main functionality of the app is not changed
You say this is a bad idea because the user can save a bookmark on their home screen. This doesn't seem to me like a reason for something being a bad idea to me. If this is the only drawback then I would say go ahead and do it. Why should I care if someone wants to bookmark to my site? The app will not work very well outside the app anyway. If you have an actual logical reason why this is a bad idea instead of some emotional response then please bring it up.
I am doing this too in my application. I am under the impression that as long as you are pointing to a secure site then it should be okay. Please enlighten me: is there some good reason why Apple forces people to develop applications the hard way? A web application is hard enough without having to deal with some monolithic organisation imposing ridiculous rules on you.
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.
I've read that its bad (not advised) to use User Agent Sniffing to send down the correct content for a mobile browser, so I'm wondering what IS the best way to do this?
I'm using ASP.NET MVC, and I've built my site and it works well on desktop browsers, so I'm looking to begin building a mobile version. When a mobile browser comes to my site, I'd like to use a different set of Views, which ideally posses the following attributes:
Link to pre-scaled images
Use minimal javascript
Remove all but essential content
My first thought was to sniff the user agent, and then send down a different .CSS file, but as stated above I've read that this is a bad way to do this, so I'm asking you for your thoughts.
The user agent is really all you have in a HTTP GET request, but you should let someone else maintain the list. We use the Microsoft Mobile Device Browser File with a custom view engine in a manner roughly similar to this Scott Hanselman post.
The best way to detect a mobile browser is to use this wonderful codeplex project:
http://mdbf.codeplex.com/
For background on how you could create targeted views read here:
http://www.hanselman.com/blog/MixMobileWebSitesWithASPNETMVCAndTheMobileBrowserDefinitionFile.aspx
The simplest approach could be use a separate domain "m.yourdomain.com" or "yourdomain.mobi" (Source) that way you can assume that the user is on a mobile device.
While I believe it's frowned upon to sniff for browser to determine capability and you should use capability sniffing, such as JQuery.support. When it comes to actually presenting significantly different layouts then I think you have to sniff for the browser ID and act accordingly.