If you have Steam installed, following links such as steam://link will result in Chrome suggesting to launch Steam:
How can I achieve the same effect for a custom app with a custom handle? Where is this behavior documented?
Are you referring to an external mobile app or an external desktop app?
Here most likely your Steam App supports deep linking via URI Schemes, which is a common flow for being able to open apps from the mobile web.
If you wish to develop an app that supports that, you need to refer to the deep linking documentation for the platform where you develop your app.
Basically deep linking with URI schemes means that the browser tries to redirect to the steam://link scheme, and if there's an installed app which declared that this scheme can open it - deep link occurs.
The scenario to support that really depends on the platform you are targeting.
Related
Have you already developed a Xamarin app whose views are generated from a Json recovered when launching the application?
I met a client with this kind of need:
they are developing a web app to prototype the screens by adding and positioning some controls (TextBox, Label, ...)
this generates a Json that must be interpreted by the Xamarin app: this will build the different views dynamically
in a first version, the user's data would be stored locally (through a file or SQLite) and synchronized "manually" when the device is connected to a computer
the app will work on Android only in a first time, and then on WPF
The client has not yet decided between Xamarin.Forms or Xamarin native, but it's probably more interesting to do it through Xamarin.Forms, even if iOS is not required: this should make porting on WPF easier.
Have worked on similar cases? Have you some recommendations? Are there plugins or patterns that could be used to simplify this development?
I've found this one, but it doesn't seem to be the same use.
There is also this article on iOS, but there is not the same thing on Android.
This would in theory be possible using a massive code behind builder for a page but should NOT be done for a production app. Mobile apps have very specific requirements that need to be thought of before attempting.
Xamarin is great for simplifying code reuse, and if you use Xamarin Forms you can reuse the UI components for Enterprise apps.(the less fancy and pixel perfect the layouts need to be the better. )
Your client would be better served by making it a mobile compatible web page instead from the details you have shared.
When looking up Electron and Offline HTML5, I have found it difficult to make a decision between which one to use for a project.
Assuming that a user will have to go to a certain website to download the Electron application, and would have to go to the same website to get the Offline HTML5 loaded, what are the pros and cons between using one over the other?
Some that I could think of:
Offline HTML5 can be updated without the user consciously updating their application by just making the user go to the online page again.
Electron would eliminate the need to code around multiple browser/browser version dependencies and quirks
It really depends on your exact requirements. The following is a list of everything that I came up with:
electron supports module system (i.e. require) both in main and renderer processes.
electron provides you access to OS APIs (e.g. fs). Without such many node modules will not work in the JS runtime of the browser (e.g. ip).
updating your app with electron is as easy as sending an http request. (or even better as described here)
an HTML 5 offline app requires a browser and the user might just give it IE6.
electron integrates with native desktop environment (see dialog, power-save-blocker, shell or even app for some examples)
electron enhances some of HTML5 APIs such as file API
electron lets you modify the default behavior of underlying chromium. For example you could intercept all URLs with file scheme and modify them on the fly*.
In short if you want your app to have a good native integration and act deterministic (i.e. no browser quirks) I suggest choosing electron.
*electron-jade for example takes use of protocol API to compile all files ending with .jade on the fly without the need to prior compilation.
DISCLAIMER: I am the developer of electron-jade.
I would like to create a new Chrome extension which will be distributed via Chrome store. I also would like to port some code parts of this extension to native code and to use Chrome's native client for it.
So my questions - is it possible to create solution which
comprises of two components - Chrome extension (e.g. can embed content scripts to third party sites like google.com) and native client (e.g. run some native code).
should have these two components be able to interact with each other e.g. via message passing (https://developer.chrome.com/extensions/messaging)
is distributed via Chrome Store as a single unit.
Thanks in advance.
There are two similarly named but quite different technologies.
Native Hosts. Those are separate programs, that cannot be distributed in the Web Store, and talk to your JavaScript with Native Messaging, a variant of standard Messaging API.
Native Client modules (NaCl/PNaCl). Those work like browser plugins, and they can be bundled with the extension.
Note that they are sandboxed from the system - the idea here is performance gain or non-trivial non-HTML UI inside the browser.
Inside your extension, you create an <embed> element that creates an instance of your native code module. JavaScript code can interact with (P)NaCl code with DOM events.
This page contains a guide on using NaCl in Chrome Apps, and mentions that the same applies to extensions. I haven't seen any better documentation, so you'll need to experiment and search around a bit.
I thought PhoneGap was a simple wrapper for HTML5, but it looks like it does in fact compile into native in some way.
I have a Cloud based, HTML5 Single Page Web application that I just want to run full screen, and distribute via an app store.
Should I just create a PhoneGap App with an InAppBrowser?
If you intend to publish an HTML5-based app in a "native" app store sucha s Google Play or Apple Store, you have 2 options:
1- Implement your own native application using a webview to show your web-based app.
2- Use some existing framework like Phonegap/Cordova even you do not use the native API. The framework will already setup everything for you to just deploy your HTML5 code.
However, if your web app is meant to be hosted remotely (i.e. not run from local files), you may encounter problems when trying to publish in the Apple Store. They have some strict rules about remote content, and about publishing apps that may not provide much more value and/or functionality than a simple web-app can.
Best.
Need to understand what are the basic technical differences between chrome and firefox packages apps & other html5 apps in blackberry,tizen.
All of them support apps in Html,Css,Js but where and how are they technically different
1.Can One app created for one platform be used for another without changes
2.If they cannot be used across then how easily can they be migrated
3.Are the differences only in manifest and main browser/os specific
I don't think there is an easy answer for this one. You'd have to probably study each platform's api layer and then do a comparison. Start with chrome.* and then research all the other platforms. If you do end up doing this, please publish your results as I'm sure many future HTML5 app developers would love to read your findings!
There are 2 type of web apps.
Hosted Apps : It can be publicly accessible Web server, just like any other website.
Packaged Apps : It can be packaged sucg as a zip,wgt and so on, instead of hosting it on a web server. The apps file extension is depends on the plaform. (chrome, firefox, bbx, tizen...)
Both kinds of Web Apps are support all of HTML, CSS, JavaScript, and so on.
One difference from a hosted app is that, a packaged app must specify a platform dependant metadata such as mainfest file. And there are different device apis. For example, firefox os provides their own web api for firefox app. Tizen also provides their own web device api for tizen application.
If one application is only standard API (HTML5), then all web platform supports it (Pacakaing may be differnet.). But if application also use non-standard api(like device api which is mentioned above), it couldn't reuse.