The html + css standards difficulties of supporting IE as a browser translate into using it as part of the WebView control where there are further limitations on functionality.
Other difficulties include:
It renders on top of the XAML
- Using the recommended approach of WebViewBrush isn't a valid scenario if your pages have dynamic content on them.
It doesn't support HTML5
You can't access the content
You can't access the content
- Trying to debug issues with it is nigh on impossible.
Are there any alternative embeddable browsers available or in the works?
To answer your question, I think Jim is correct that there are no other embeddable browsers available, and it's not something I'd expect to see.
I would also recommend that you review the Windows Store Certification requirements, as many may be applicable in this case, including:
2.4 "The primary experiences your app provides must take place within the app" (as opposed to coming from the web)
3.6 "Your app must fully support touch input, and fully support keyboard and mouse input" which covers requirements for touch, including the need for your app's touch support to be consistent with the Windows 8 touch language.
While it's obviously appealing to re-use content across platforms, it's also important to keep in mind that this may lead to degraded experiences for end-users. If those experiences are too far afield of the established behaviors for Windows Store apps, they could also result in your app failing store certification.
For more info on Windows Store app development, register for Generation App.
Related
Good day, I've been using ServiceStack for many years, I currently designing and planning a rewrite of an ASP MVC (Razor) project. #Script seems to be an almost perfect fit, without hands-on experience of the technology I have some doubts and questions.
My question is how relevant is #Script today and what is the future plans of this technology. I ask these questions because when I looked at GitHub example I noticed that there is not a lot of activity, and searching the internet I am also not finding a community around it.
As #Script's author I would say that #Script is a complete library for what it's designed for as an embeddable sandboxed .NET scripting and templating language that's ideal for exploratory programming with seamless integration into .NET APIs (including Win32 APIs) that includes a vast built-in library (1000+) of filters that's easily and highly extensible to the point that it's even able to natively support multiple languages (inc. built-in LISP Repl) within the same page that's been a joy to develop with thanks to its built-in Hot Reloading support where changes are instantly visible upon save - so technology-wise IMO it's pretty great.
If we were to compare it to comparable libraries in other languages like the Ruby's Liquid it should be pretty clear that #Script is vastly more capable where it scales from a user-friendly templating language to a powerful scripting language where it's capable of developing entire Windows Desktop Apps that fits in a Gist.
On the activity front, Liquid is also an established library with low activity with only a handful of commits in 2021, the difference is that it's vastly more popular and used in popular products like Jekyll as used in GitHub Pages which ensures it will always have a rich, vibrant ecosystem which is the most important indicator for assessing a technology's longevity.
Technology not as important as ecosystem
However in the end the technology doesn't matter nearly as much as its user base, community and ecosystem behind it which is where #Script is sorely lacking. Unfortunately this is the reality of libraries that compete Microsoft's defaults like Razor which are exclusively promoted for .NET and will always retain the majority of adoption in .NET.
#Script is a "complete" library in that I've added all the features I planned for it and there's basically nothing I can think of to add to it to make it more appealing, but facing the realization of its indefinite lack of adoption I wouldn't recommend using it for large living (i.e. multi-year) Websites, given it will never have the community and adoption enjoyed by other ecosystems since the benefits of a community and ecosystem are ultimately the most important attributes in order to continue investing in a technology.
Continue to be actively supported
Like all of ServiceStack, #Script is still an actively supported library with no outstanding issues so it's safe to use in that any issues will be promptly resolved should you wish to.
Website Development Recommendations
I'd say it's still a fine option for smaller definitively-scoped projects since its compile-time-free and Hot-Reload makes for a very productive Dev UX for server-generated dynamic pages. However even then I'd first evaluate if a static generated framework like Jekyll, Hugo or other popular static generators would be more appropriate since they enjoy a vibrant community and a statically generated site results in a more performant, resilient and cheaper to host and deploy website.
Static Site Generators
Having recently redeveloped the servicestack.net website to split it out into using Jekyll for static content and ServiceStack.Razor for dynamic content, my recommendation for large websites with large static and dynamic components is to use a static site generator for its static content which yields several benefits:
Although it does require a fair bit of overhead to setup as you're effectively maintaining 2 different websites however it greatly benefits if the static content is actively updated as there's a lot less friction to change and update content on a static generated site then a dynamic one and it results in a superior end user UX thanks to CDN Edge caches that's also cheaper to host from free sites like GitHub Pages and Netlify.
In order to preserve existing URLs we needed extra functionality not possible from a static host so our static content is deployed to a S3 bucket where we use CloudFront for CDN edge caching, CF Behaviors for proxying "external static" routes to our .NET5 dynamic website and a CF Function for supporting pretty URLs. For internally deployed websites you'll be able to accomplish similar functionality with reverse proxy and redirect rules.
SPA or Razor
For small websites or mostly dynamic websites that wont benefit from a content site split I'd recommend either an SPA Project Template if you prefer TypeScript and an established SPA FX like Vue, React, Svelte or Angular or Razor or MVC if you instead prefer C# server generated websites.
Progressive Enhancement
My personal preference is for read-heavy dynamic sites to use ServiceStack Razor utilizing API First Development approach so that all writes are made to the same clean ServiceStack APIs that Mobile and Desktop Apps would also call. This typically involves using some kind of progressive enhancement like our Client TypeScript Validation example which utilizes the Form & Validation Binding in #servicestack/client to take over <form> submissions to perform TypeScript API calls and apply any validation errors back to the Form's UI.
The Client jQuery example accomplishes the same thing without the tsc -w watched build step whose form & validation binding utilizes the older jQuery ss-utils.js library but it does mean you'd need to author logic in an older broadly ECMAScript 5 supported version of JS.
Future of #Script
As I don't expect #Script Pages will ever achieve any meaningful adoption required for self-sustained active development, it's unlikely we'll continue in investing in further development for usage in dynamic websites (i.e. the script project template), it's a complete and extensible library so further development isn't strictly necessary as it can be easily extended with your own local Plugins, Methods, Transformers and Blocks. But it does mean we're unlikely to be creating and including new methods/plugins designed for dynamic websites in the library OOB.
Still a critical ServiceStack component
#Script is still a critical component of ServiceStack where it's used to provide integrated SPA templates since it's able to render dynamic websites from static *.html pages in npm dev hot-reload servers which can't use Razor's *.cshtml pages. It's also what makes ServiceStack's Declarative Validation possible where validation rules can be defined on dependency-free DTOs as it allows defining binary-decoupled logic in dep-free attributes. It's also what makes vuedesktop.com Desktop Apps like ServiceStack Studio possible as well as command tools like Post Command - HTTP API Command Line Utils and cross-platform dotnet scripts which makes usage of its internal functionality, so it's going to continue on as a actively developed & supported library.
Good future use-cases of #Script
However I'd limit any #Script usage to where it excels, e.g. as an embeddable scripting .NET sandbox given it's more versatile & flexible than Razor for tasks like Rendering Emails, authoring & rendering Live Documents (e.g. if needing to maintain live user-generated reports in an RDBMS) or as an embeddable Template, JS or LISP DSL or for evaluating adhoc JS/LISP Expressions or .NET logic.
Future replacement project templates
For developing server-generated websites with ServiceStack we're looking at shipping a couple of new templates which encompasses our latest recommendations (e.g. embracing an API First Development style), if they result in a great Dev UX we're looking at:
An Integrated Static generated (e.g. Hugo/Jekyll) + Dynamic Project template
An API First MVC Pages + ServiceStack template with integrated progressive enhancement
Please follow #ServiceStack to get notified as soon as they become available.
I need to build a web based application that can list available ssid in the area.
From my understanding, these probably can do what i want
Java applet
Adobe Flash
However, Im not sure whether these can do or not
HTML5/JavaScript
Java Web Start
I'm a .NET developer and I'm not familiar with these web technologies.
Are there any other method to get a list of SSID that i have not mentioned?
Thanks.
You'll never be able to list available SSID's with HTML5, Javascript, or any other strictly web-based technology. That's a very low-level task and won't be natively possible in any browser for security reasons. That being said, you may be able to draw on some technology like Java Applets, ActiveX, or even Silverlight 5 if I remember correctly. I don't know your project requirements, but you're better off creating a native application for this type of feature. If this application is being used by/sold to the general public, you're setting yourself up for a lot of headache by going with Applets/ActiveX/etc.
I've found this nice article about the "injected Way", but the author never finished it :
http://hightechstartups.blogspot.ch/2012/05/different-way-of-developing-browser.html
I would like a bare bone cross browser extension, without any 3rd party extensions or framework (to be as light as possible and not dependant on a 3rd party) that would load Jquery and a JS from a distant server and the ability to load it before or after the page is fully loaded.
I've read a lot of topics about the subject, but since IE10, Chrome 26 and FF20 are out with their new cross-link limitations, i was wondering if somebody had ressources, source code or tutorial about the following requirements :
I need :
Cross browser extension supporting (IE 8+ or 9+ worse case, Chrome
26+, FF20+, Safari)
Ability to inject a single JS hosted on another server. Inserts a script tag that references a javascript file in the head of the HTML
page and then be executed
Not be dependant on a third party extension (greasmonkey) or framework (Kango, Crossrider)
Ability to load before or after the page is fully loaded
This method allows me to customise the browser extension depending on the user's location and it also avoid having updates as the JS is updated on each page refresh.
I'm aware of the downsides, but i would like to achieve this.
I'm aware of cross browser framework like Kango or crossrider, but both don't fit me needs.
The closest example i could find is this How can I run a <script> tag that I just inserted dynamically from a BHO
but it only covers IE and as i got very little Csharp experience, i would like to see a full example to understand it properly and learn from example.
I would LOVE to have a few examples, even if it's not cross-browser (IE being the worst part for me).
Thanks a lot for your support !
Update1:
About Kango and Crossrider, Kango is 2000$ if you want to use IE and for Crossrider you're required to be distributed and monetized by them.
I've managed to code for IE and Chrome, but i was looking for an "elegant" way and figured it was the best place to ask given the level of knowledge of people on this site.
For the installer i currently use NSIS, but i'll test Wix too.
Finally i guess the only way for me would be to learn C++ and .net to get it to work with IE, but if anyone could provide more source code it would be great to test speed and compatibility and discuss here what's the best solution.
Why do Kango or Crossrider not fit your needs? Both frameworks allow you to manipulate the page's DOM (which is what you want):
Kango: Adding content script
Crossrider: documentation, example code
If you want to code your own solution, take a look at the relevant documentation:
Content scripts (Chrome)
The Page mod Jetpack API (Firefox)
Injected scrips (Safari)
Injected scripts (Opera)
Internet Explorer does not natively support extensions. It took me about 80 hours to create a stable and reliable IE extension which supports cross-site AJAX, a (preference) storage method and injection of scripts as early as possible in any frames based on its URL. I developed and tested the extension with Visual Express 2010 on Windows XP and Windows 7, for IE 8-10 (the extension might work on IE6/7, but I decided to not support these ancient and rarely used browsers).
First, I wrote an extension in C# based on LiveReloadIEExtension (a sample IE extension, which in turn is based on this Stack Overflow answer - see also this blog post). It was functional, but it required .NET 4, lacked support of frames, and it's relatively slow.
So, I decided to write an IE extension from scratch in C++. A good starting point is available at http://www.wischik.com/lu/programmer/bho.html: Sample code for C++ BHO, which changes the document's background based on key/mouse events. I've also learned a lot by looking at other code samples on CodeProject, topics on the MSDN forums, questions and answers on Stack Overflow, lots of other blogs, and the MSDN documentation:
DWebBrowserEvents2 interface lists several events which you use to find an appropriate injection point.
Scripting Object Interfaces (MSHTML) lists even more interfaces. You'll be mainly interested in the iHTMLDocument, iHTMLDocument2, ... interfaces.
After creating the IE extension, you want to deploy it of course. I used Wix toolset to create a MSI.
we are in process of developing google chrome extension, in which we need to store all the video information from a particular website. so we are considering the option of webdb.
and now we are getting confused between to use webdb or indexdb..
As of now i think that, indexdb is still experimental, is that correct?
and, if we use indexdb, the db even will not show up in dev. tools db section, where as webdb will show up, so that we can do query stuff in there..
please shed some light and put us in correct direction
Use IndexedDB. WebSQL has been officially deprecated and will be removed from Chrome in the future. The dev channel of Chrome has experimental dev tools support for viewing IndexedDB databases.
It's been a few months since I checked, but based on the work I did then, I would suggest WebSQL. The primary reason is that support is complete (it's basically SQLite). Here's what I wrote at the time:
If you're doing web app development and need to utilize a local
(client-side) database, you should be using either localStorage
(assuming you can live with the limitations of size and limited
queries/indexing) or WebSQL. IndexedDB is not a contender yet, as
essential functionality such as deleteDatabase is missing from for
instance Chrome. WebSQL doesn't give you schemaless functionality
without any glue, but on the other hand it works great (has a lot of
uses outside of browsers as well), has full features functionality and
probably limited or no practical size limitations.
In addition, the debug console (at that time) had WebSQL support, and no IndexedDB support. Things may have changed and YMMV, but at least you should be aware.
I have an application that will need to better support tablets in the future. I have seen some apps already created with UP1 and ExtLib Mobile Controls but I was wondering if anyone knows of specific functionality that simply is too challenging to even consider bringing to a mobile device?
For example, are there partial refresh issues on specific devices? Can managed beans still be used behind the scenes? Is dynamic content totally viable on mobile?
I'd be interested in hearing what big challenges/functions people had to give up when they mobilized their existing XPage apps.
There isn't really anything in XPages that would prevent building mobile web apps as with other web app dev models. In other words: Everything you can do with web apps on mobile you should be able to do with XPages.
XPages 8.5.3 UP1 comes with Dojo Mobile 1.6.1. However that does not prevent developers from using other frameworks like JQuery or anything else.
There are some advantages in general for native apps and hybrid apps. But personally I think most of the typically rather simple business apps can be built with mobile web apps. If you need local data/offline that might be different though.
You can use Xpages to do anything that is possible with mobile web developement. Dynamic content may not be the way to go for everything, but it will run just fine. In ITANA available for free on openntf.org, i created a simple replication engine to replicate notes tasks from the local device using sqlite to the domino server. This makes it run very fast and allows the app to run offline as well.
So i believe anything you want to try will work, you can make the Xpage output anything you want, from html, to xml, or json, to accomplish your tasks.
I know that XPages was totally incompatible with older Blackberry's. I assume that's not the case these days but back at OS 5.0 I think even buttons wouldn't work. So if you're doing anything with BB make sure it's modern and tested.
We're not really getting tablet support in ext. library until the next dojo rev I think. But there is a preview of tablet support somewhere that you can get. I've not looked yet but it was mentioned at Lotusphere. so if you want to hit tablets you might want to roll your own right now until that comes available.
Tablets are a little more challenging as the mobile controls are designed for the mobile phone size devices. That said with a little trial and error you can get a nice navigator split screen and still use the one page app mobile controls to streamline it, with records opening in their own page just like the phone version. Type ahead as I'm discovering should be handled differently if you are using the iPhone themes from oneui2.1
The oneui2.1 gives your navs and views nice styling. The forms may need a bit of custom styling.
Split your design into custom controls then you can use a server ate xpage for mobile devices and straight web. Or if you forgo the use of mobile single page controls you can always just have a seperate style sheet to accommodate the iPad. Really depends on the functionality needed. Good luck
My suggestion for anyone wanting to do tablet specific development using XPages is to move to Notes 9.0 and dojo 1.8 asap. Dojo 1.8 has an experimental control called ScreenSizeAware. This is miles ahead of anything else either the Extension Library Mobile controls or Dojo provides for Tablet development.