I am generally very pleased with Composite C1.
However, I find the web interface a bit unreliable. Even if running locally I have to frequently re-open pages because I can no longer type into the editor - or when I click save it doesn't work (re-opening always fixes the issue).
This happens both in Chrome on Windows & Mac.
Is this a common issue? Why is it so unreliable & is there anything I can do to fix it?
Related
So, I know it's possible to specify a specific javascript engine with react for server side rendering. I just can't seem to find any info on it. Here's a blurb from one of their Github issues that confirms that it's possible:
Have you tried running it with the V8 engine instead? The MS one can be flakey (we had similar issues with it but much early on in our dev cycle). The fact it works on 3 other enviros means there has to be a difference between those and the 4th one. Could be its got a different version IE on the production server for instance? Tricky one to track down hence switching to V8 might be a quicker option.
https://github.com/reactjs/React.NET/issues/188
Anyone know how to do this? I'm seeing inconsistencies between different machines and I think (like, 90%) the cause is different JS engines being used. I'd like to lock it down so only v8 gets used so things are consistent.
You need to call .SetAllowMsieEngine(false) on your ReactJS.NET configuration. For ASP.NET 4, that's in App_Start\ReactConfig.cs by default. For ASP.NET Core, it's in the UseReact call in Startup.cs.
This will force it to use V8, or throw an exception if it fails to load V8 (rather than falling back to MSIE). The most common issues is the ClearScript.V8 directory missing from bin. This should be automatically copied across for ASP.NET 4 sites, but for ASP.NET Core you need to manually modify your build to do it (see http://reactjs.net/2016/08/protected-memory-exceptions-and-dotnet-core.html)
We are in the middle of choosing our headless browser driver solution that will be some implementation of Selenium WebDriver.
There is the GhostDriver, which leverages the PhantomJS in the backend on the one side and HtmlUnitDriver which based on HtmlUnit on the other.
PhantomJS uses WebKit, the rendering engine of Safari, to render the pages while HtmlUnitDriver uses the Rhino engine which no other browsers use (it's just "simulating" browser behaviour. The last fact considered as a con, because the rendering behavior can differ significantly from the popular browsers.
In our opinion, PhantomJS is a much stronger candidate. But, we don't know everything :) Is there other considerations and trade-offs we should take into account with our decision? other scenarios where HtmlUnitDriver can be a better solution?
From my experience with a number of headless browsers, I'd say:
HtmlUnitDriver: the fastest of all implementations I've come across, and perfect for simple, static pages, especially those without JavaScript. Any remotely complex page seems to produce problems - that's my practical experience even if I can't justify in detail. Perfect for testing Selenium features on demo pages, scraping status pages etc.
PhantomJSDriver (PhantomJS + GhostDriver): not as much faster as you might hope vs the desktop browsers, however, much easier to set up than Firefox + xvfb. By default screenshots can look a bit odd, but that usually turns out to be because PhantomJS defaults to a narrow window unless explicitly set (read below for why).
Update: a bit more detail on PhantomJS versions, from my other answer.
Like Safari, PhantomJS uses WebKit for rendering (e.g. Firefox uses Gecko)
Different PhantomJS versions are built against different WebKit versions. PhantomJS 2.x uses WebKit 538.x, which makes it equivalent to Safari 7 or 8. whereas PhantomJS 1.9.8 uses WebKit 534.34, which is equivalent to Safari 5.
This may be an issue for you, since Google determines Safari 5 to be an "old" browser and will therefore potentially render its search pages differently.
So ensuring you use PhantomJS 2.x can reduce the rendering differences that a lot of people report vs. desktop browsers.
Another interesting possibility is SlimerJS. However, I've not got it to work reliably enough yet.
I've never had reliability issues with either HtmlUnitDriver or PhantomJSDriver (the only annoyance one was a HttpClient 4.5 / HtmlUnit 2.17 incompatibility issue).
(In answer to the comment about modifying HTTP requests, I'd personally recommend sticking to the WebDriver API and use a proxy like BrowserMob to mutate requests and responses rather than taking advantage of browser-specific features.)
All in all, I'd advise against creating a tool or process that forces users to choose one browser over another. If possible, allow them to configure or override. For the majority of cases I'd plump for PhantomJS, as it won't let you down. However, the performance of HtmlUnit should be considered for the simplest pages.
See also (perhaps): http://www.guru99.com/selenium-with-htmlunit-driver-phantomjs.html and https://www.quora.com/Software-Testing/How-does-PhantomJS-compare-to-Selenium
I've used phantomJS in a few projects over the last couple of years, but have often had issues with it. For example javascript on pages behaving different to chrome, firefox, internet explorer. Some pages simply not loading, possibly due to redirects but I'm not positive (e.g. keycloak log in pages).
I've not used HtmlUnit as much, but as I type this it is avoiding some of the above phantom issues for me on tests with keycloak login pages.
PhantomJS development has been suspended as of March 3rd 2018 while headless mode has been added to Chrome and Firefox
This means that if you want to receive updates you should either use HtmlUnit, Chrome or Firefox for a headless driver.
My current default browser is Chrome (dev). I'm using VS2010 and Silverlight4, with ASP.NET MVC3. I don't seem to have the problems with debugging that I've seen others have. My main complaint is that I regularly have to clear my browser cache to get the latest version of my app to show up. Sometimes I have to clear it two or three times. I've taken to changing the background color of certain elements just to be sure whether I've got the actual latest changes.
Are Firefox or IE better in this regard? Is there are trick to make my latest version always appear?
Too lazy to do fiddler.
Seems I hadn't googled very well before, this article seems to be precisely what I wanted
http://codeblog.larsholm.net/2010/02/avoid-incorrect-caching-of-silverlight-xap-file
via this discussion which has other options and some useful discussion https://betaforums.silverlight.net/forums/p/11995/449355.aspx
Unfortunately, that part of my project has been on hold for a bit, so I haven't tried it out yet.
Like you, I use Chrome for my main browser, and I don't use IE for any regular browsing. But I do use IE for Silverlight development, for this reason and others. I rarely if ever have trouble with the IE cache holding onto outdated versions of my XAP file, but this happens pretty regularly with FireFox and Chrome. In addition, depending on how I closed my previous debug session, when I start up a new one, FireFox and Chrome frequently open up my previous tab(s) in addition to the one that I'm actually trying to debug. Consequently, IE is (for me) the cleanest browser to actually debug with.
This isn't really an answer -- just an observation. Sorry :-).
Have you tried investigating why this is happening using Fiddler or a similar HTTP debugging tool? Personally I've never been able to debug Silverlight in Chrome so I usually have to force IE when debugging. But I never have the problem of a stale application. I'd check Fiddler to see if you can isolate the issue. It's probably not directly related to Silverlight.
Your probleme looks like a lot like a cache configuration issue. The web server is often configurated rather aggressively concerning caching of static files, as the XAP.
So the response header are probably set in a way that maximize browser caching.
You could change the webserver configuration to prevent client side caching of the XAP file.
Don't forget to remove these setting in production, however.
Apart from the fact people get to view the app in a browser which may be familiar. Is there any actual compelling reason to use the XBAP model in WPF rather than a straightfoward stand alone WPF app.
All I can see are potential security issues and restrictions but no benefits. Am I missing something?
I have used an XBAP, once.
We needed full-trust, and we needed the application to act as if it were browser hosted. XBAP was the only real option we had, and I'm glad it was there.
Outside of this tiny nitch, Silverlight & Click Once are better all around options.
In practice No and No would be the answers to your questions. I have never actually seen them used in production nor is there ever really a justified reason to use them.
As Kent mentioned Silverlight or Click Once is almost always a better option.
One could argue, in a full trust Windows only environment, XBAPS gives you the ability to leverage the full WPF framework with the flexibility of web deployment. Of course that is what Click once is for. However, in my experience ClickOnce is a nightmare for anything more then a simple, single application install so you might argue in favor of XBAP to avoid ClickOnce headaches.
But again, my response would be, Silverlight is likely a better choice.
We use it to have a single sourced solution for an application that can run in a browser but also as a desktop application. Both full trust.
Actually a modular designed app consisting of xbap(s) communicating via webservice is very efficient. This type of scenario would allow for execution of the modular pieces to run concurrent and in separate memory spaces. This benefits the user and the application's developer(s).
The app would not run in an ie but rather a custom browser shell to control the flow and execution of the application itself. It does seem like a lot of work when everything could simply run with in a single or multiple projects but this type of solution would be pertinent in large enterprise app(s). The application Programmer(s) will be able to work on segments or distinct parts of the app which contain distinct functions, utilities, and capabilities. The user never knows or realizes that each part is actually running independently because it appears seamless. The partial trust issue is eliminated because the shell is not an xbap and has full permission. Now to the good stuff ... if there happens to be a fault (that never happens right?) other parts of the application continue to execute without failure. Try-catch-finally work great until you miss one... Last but not least no more complicate background thread processing it's in a browser and by default is async. Most systems will have multiple windows open at a time each window simply contains a browser running an xbap. Unique...Yes...Useful...Yes... It is a different approach but it is clean and simple.
Life is a race ... When you reach the finish line who will be there cheering for you and will you be proud of the race that was run?
XBAPs using Partial Trust are useful if you have a requirement that the WPF client should be run without requiring admin privileges and without installing anything on the clients machine (disregarding the user's profile cache that is)
I was thinking the same thing, here is my takeaway.
The main reason is the user experience, WPF apps are more powerful and easier to write than Silverlight. People will click on a web site, but will think twice about installing an application. An XBAP is very close to a website experience, and can out perform Click Once and Silverlight.
However since it only works for a very narrow user base, it would probably be best for intranet applications.
WPF, XBAP, Silverlight - What do I use?
I tested that it is possible for Android to pass newVersion < oldVersion to SQLiteOpenHelper.onUpgrade() method, ie. it wants the application to downgrade its database.
I don't want to handle this case, though I would like to notify the user somehow that there exists a newer version of my application (which she apparently had installed previously) and that's the one she should be using.
Any ideas what would be the best way to achieve this? Toast? AlertDialog (but in what context)?
Indeed, you can call that method with a "new" version smaller than the "old" version, but when would it ever happen?
Unless you expect your users to manually reinstall your app, overwriting it with an earlier APK, there's no need to think about this.
We have multiple active branches of our app (e.g. v1.x and v2.x), and we deliver releases internally for testing. This means a tester occasionally installs the older version over the top of the newer one.
It is a good idea to cope gracefully in this scenario (a helpful error popup, blow the database away, etc), otherwise the tester see a "Force quit" message, and then we have to look at the adb logcat logs to confirm that this was due to a version mismatch.
Initially I worried that there were other reasonable scenarios where this could happen, e.g. when Reactivating an older version in the Android Market (e.g. due to a catastrophic bug in a new version).
However, the Android docs seem to say that you can't Activate an older release:
You cannot activate a new APK that has a version code lower than that of the APK it's replacing.
So to hit this scenario you would need to rebuild the older version with a new version number before you can Activate it. IMO it is still worth coping with this scenario, as somebody could easily make this mistake at 4am while trying to backout a bad release!