i know that the index.html page (the PhoneGap startup page) needs to reside on the device. but if we want to create an app who uses third party user authentication before proceeding to core application, so then what we have to do?
Thanks in advance
On android you can change the starting page in the main activity or you can make a redirect in index.html
Well, you don't say if you are platform specific..
And there are lots of third party auth options..
But I can offer two solutions (admittedly my own code etc),
both of them use PhoneGap for Android and PhoneGap Plugins. The key piece of code for me has been the onLocationChange callback feature of the ChildBrowser plugin. Your app can take the user to other sites for auth or whatever, but still get control back.
Tutorial on Using Twitter REST API (OAuth 1, ChildBrowser, jsOAuth plugin)
Free Android App + Source on github : AppLaud App (OpenID, ChildBrowser, custom server)
For authentication, you can have a form in your index.html (maybe under login div) to do a post to an actual webserver.
Then, fetch the data returned from the webserver to let your user access the functionality of your native phonegap application.
You can have the functionality disabled until you receive the successful login from the webserver. If you post via ajax, the webview won't even blink, but you will still get the successful login response from webserver and simply enable functionality on your app after this.
Let me know if this is confusing and I'll try to explain more clearly and
I hope this helps.
Related
I have a web app developed using..(PHP,MYSQL,HTML,CSS,JS,AJAX,Datatables, bootstrapjs)
Now, I want to make a desktop version of the same app, and I came across electronjs.
The problem is I dont know whether ELECTRONJS will support all my requirements.
A breif of my requirements:
My app is responsive using datatables.net library including EDITOR for displaying the data .
the datatable plugin requires ajax calls to some API (Which I developed with PHP and hosted on a server)..
but now I want to even do all the DB Operations with electronjs so that my app can work offline.
I am not sure if I can do that with electron
- calling an API (created by same app) from HTML/frontJS
- the API Returns Json data
- the Front JS displays that data on front.
Kindly let me know if this can be done with electronjs,
Well, basically yes. You can build a desktop app like this.
But you wont be able to run it offline if it depends on a server sided API. If you can rewrite your backend Code in JavaScript and use a SQLite DB instead of a MySQL you can run this as electron App.
Keep in mind that your business logic in the frontend can always be abused because it’s not hidden from the user.
FYI: Electron only runs a browser inside it’s own App container. So there is actually no crucial difference between Browser or electron App.
When building a tvOS app using TVML, the logic, written in Javascript is downloaded from your server, hosting the files. Does that mean that you could change the Javascript, modifying your app, without having to submit an update to Apple for review?
The tutorial I have been following is
Beginning tvOS Development with TVML Tutorial.
Following the steps in the tutorial, I have successfully started a server locally that is hosting the Javascript files. I can then change part of the Javascript files and then see the change reflected in the app (after I relaunch it). This seems like evidence to me that you could make changes to the app without submitting an update to Apple for review.
Any externally hosted files can be updated. I have personally tested this by adding content and descriptions to my tvml files.
Apple TV will obey any cache headers on the JS script that's served. Additionally, it will only completely reload the app (and the JS with it) if the app has been terminated by TVOS or the user.
Once these criteria are met, it's technically possible to deliver 'OTA' updates to your app without going through App Review again. This is fine with the App Review Guidelines for Apple TV, as long as you're not making 'significant changes' without going through review.
I am writing a Chrome App that communicate with a web page. For that I have added something similar in my manifest file.
"externally_connectable": {
"matches": ["*://*.example.com/*"]
}
But the "example.com" has to be dynamic as individual customers has their one web server.
Is there any possibility, user(who install the app) can change the externally_connectable site/s.
There is an alternative way a web page can communicate with extension through content script. This approach can be used if both web page and extension are done by you.
E.g.
web page <--> content script of extension <--> background script of
extension <--> native application
For web page to content script of extension communication use window.postMessage and window.addEventListener
For Google Chrome browser,
For content script of extension to background script of extension communication use chrome.runtime.sendMessage and chrome.runtime.onMessage.addListener
For background script of extension to native application communication use chrome.runtime.sendNativeMessage
Please make sure your code has necessary security in place.
As far as I know the "externally_connectable" is the only official way to send messages (With data) from a web page as mentioned here
This requires a predefined values for every single domain. But what if you want to make only one extension to accept messages from any web page?
If you just want to notify the other side about some thing, you can use the native JS Event dispatching it on the document from one side and listening to it at document also from the other side as the document is shared between the extension content script pages and the web page.
You can't use JS CustomEvent to send data as every time you send data, you receive it empty as a result of sandbox effect of any extension.
If you want to share data so the only workaround I know so far - after spending about one month developing an extension - is to have a combination between some sort of a storage and the JS native Event mechanism.
The solution in steps (suppose you need the web page to send some data to the extension):
Make an event on document from the web page.
Save the data temporarily inside any storage technology you prefer
(localStorage, the DOM itself, or what ever..)
Receive the event at the other side (extension) by listening on the
document.
Read data and remove it.
Hope this helps someone or open a door for a discussion on a better way doing this.
I am building a packaged chrome app (It is needed as I want to access chrome.socket). I have a website from which I would like to call my app (if installed or ask the user to install it) by clicking a link. Is this possible ? Not able to find any easy way for this workflow.
The url_handlers might be the best way to achieve this.
You can also use the externally_connectable manifest property to declare that your website can connect to your app, then call chrome.runtime.sendMessage or chrome.runtime.connect from your webpage and handle it in an chrome.runtime.onMessage handler in the app.
Which one is better suited depends on your needs. The url_handlers is an easier way, but it will permanently assign the URL on your link to your app, so you won't be able to use it for anything else if the app is installed. The externally_connectable is a harder way, but it enables a much more elaborate bidirectional communication between your website and the app.
You can even use a combination of the two approaches, if you need: launch the app using the url_handlers feature, then establish a communication channel back to the website once the app is up and running.
Apps can now (as of Chrome 31 I believe) register to handle urls by adding url_handlers in their manifest and detecting the url causing the app to launch in the chrome.app.runtime.onLaunched event. If the app doesn't launch, your hosted web site will be loaded an can present an inline installation with chrome.webstore.install.
I'm adding Box support to an iPad app. I tried the official SDK and I don't want to use it for the following reasons:
Login page is too wide for a modal controller with UIModalPresentationFormSheet style on iPad. The SDK hosts UIWebView which loads content of https://m.box.net/api/1.0/auth/, which perhaps returns HTML with min width set to 768px (although I didn't check the HTML, speculating here).
HTML in login page doesn't show Google Apps authentication option. The full desktop version of the page does.
Because the login page is hosted in UIWebView the user cannot be sure that he's supplying the credentials to Box, and not to an app author.
I don't need the whole SDK functionality, just authentication, folder/file listing and content download. Since my app also uses other cloud storage providers I'd prefer to provide uniform file browsing experience.
Here's what I'm going to do:
Add a custom URL scheme for my app, let's say "myapp".
In Box's Application settings for my app set Redirect URL to myapp://RedirFromBoxAuth.
When the user chooses to browse Box from inside my app, I'm going to:
Get a ticket by calling GET https://www.box.com/api/1.0/rest?action=get_ticket&api_key={API_KEY}
Extract the ticket, then call openUrl with https://www.box.com/api/1.0/auth/{TICKET} This will open Safari and let the user enter his credentials. This is the full, desktop version of the login page.
On successful login Box's server will tell Safari to redirect to myapp://RedirFromBoxAuth?ticket={TICKET}&auth_token={TOKEN}, which in turn will tell iOS to yield control to my app.
My app receives handleOpenURL notification and I can extract the authentication token and use REST API from now on.
Please comment, is it a good plan? I created a quick prototype and it seems to work, but maybe I'm missing something?
Box team, could you please tell us will an app using this authentication model be eligible for inclusion in OneCloud?
This seems like a good strategy and will probably make for a better UX/easier implementation than the normal redirect. Please let us know if you run into any weird edge cases by implementing it this way.