We have a web application and we've built phone applications (iPhone, Android, BlackBerry) to be companions to the site. The usual workflow is that an existing user of the site gets a phone app and then plugs their existing credentials into the phone app and they are off and running, but more often now we are seeing folks who are downloading the app and then (and this should not surprise anyone) don't read the help screen that explains they need to go and get credentials at the web site and therefore cannot connect to the application which does require registration to manage their content. This is a giant usability fail condition.
So we know that we need to put user registration workflows on the phone app.
Other than the obvious solution of duplicating our registration page on the mobile, does anyone know of a better identity solution for the phone? For example, on the desktop we also use Facebook Connect as an identity server and the users love it. I'm looking for something that simple that we can implement across the major smartphone platforms.
Clarifying note:
I should add here that this registration mechanism is likely to; and it would be desirable if it did, go hand in hand with a general identity/authorization mechanism such as the Facebook mechanism mentioned below.
One other place I'm poking around is to see whether there's an openId solution that does not require a browser to pop up.
Restful service might be the e asiest way for you to achieve this, you can use it on any device that can make http requests, so you can make your own login screens and talk to the s ervice that way...
Facebook has a Connect API for the iPhone. Integrating it into your iPhone app is very smooth.
http://developers.facebook.com/connect_iphone.php
On the BlackBerry we were able to build a fairly robust REST pipeline between the client apps in the field and our servers. We primary use the framework for updates, but the device API is generic enough to be able to build almost anything you need via standard HTTP/HTTPS GET/POST calls.
On the RIM platform, look into the HttpConnection API as a starting point. There is also an example on the BlackBerry Developer's site which will help. Finally, I believe there are several examples inside the sample package that comes with every BlackBerry JDE (IDE + API download).
Related
Where can I find list of PWA features that are supported and under development for each browser?
This will greatly help to determine if I shall develop a native app or go directly for PWA. And also know upfront what to expect in the foreseeable future in terms of browser support so that I can enhance my app with newer features.
Thanks
Actually you can try
https://whatwebcando.today/
for test your browser first
Web App Manifest, and
Service Worker API
seem to be the key technologies to watch. Google's Progressive Web App Checklist mentions both of these technologies.
However, other technologies such as BeforeInstallPromptEvent, or PWA installation notifications, are explicitly discouraged by Mozilla Developer Network, MDN:
Do not use it [BeforeInstallPromptEvent] on production sites facing the Web
Also, as an aside, commercial incentives for PWA's appear to exist:
The Supreme Court signaled Apple could face a revived antitrust
lawsuit over its price control [...and 30% take] of the iPhone and
iPad App Store. -Fortune
Google indicates that a progressive web app, PWA, is:
Progressive - Works for every user, regardless of browser choice because it's built with progressive enhancement as a core tenet.
Responsive - Fits any form factor: desktop, mobile, tablet, or whatever is next. Connectivity independent - Enhanced with service
workers to work offline or on low-quality networks.
App-like - Feels like an app, because the app shell model separates the application functionality from application content .
Fresh - Always up-to-date thanks to the service worker update process.
Safe - Served via HTTPS to prevent snooping and to ensure content hasn't been tampered with.
Discoverable - Is identifiable as an "application" thanks to W3C manifest and service worker registration scope, allowing search
engines to find it.
Re-engageable - Makes re-engagement easy through features like push notifications.
Installable - Allows users to add apps they find most useful to their home screen without the hassle of an app store.
Linkable - Easily share the application via URL, does not require complex installation.
You can check this blog about the features of PWA. Also based from this documentation, Chrome, Opera and Firefox have all implemented support for service worker with Edge having positive public signals about interest in the feature. Safari briefly mentioned interest in it via one engineer's proposed five year plan. You can also check this related thread for more information.
Preview:
I am using juggernaut chat server.I am having redis and juggernaut server running on machine. I am able to do chats within my local network on vaious web browsers. Everything is working smoothly. As juggernaut is a server driven chat server so i am quite sure about the scalability thing. Now here is the thing:--
Whats the problem:
I want to have a iphone native app too where user can login and chat with his friends. Now the thing i want to know is how do I push on iphone app, cause for juggernaut client registration a javascript code is needed. Something like this:
var jug = new Juggernaut;
jug.subscribe("channel1", function(data){
alert(data);
});
Basically how do i push new notifications to Iphone chat window. I don't know much about iphone as I am web developer. Still from google search etc I came to know some possible ( may be) ways:-
We can embed a url in iphone window. Is this a good approach?
Other thing we can do is using UrbanAirship kind of services we can do push notifications. Will push notification works for chat? I don't know about that even.
Third option can be polling. Iphone chat client keeps on hitting my rails app for new notifications. But i think this will be a very bad approach.
What are the other possible solutions?
Can any iPhone/Android developer guide me what should i do. I will eventually hire a Iphone developer to do all the coding part. But I want to have a big picture in my mind so that I can provide a complete docs of all the things, and have a clear picture how I want to discuss things with him before writing down the code.
PS: I am looking for a solution which works for android/nokia devices too. Cause later on I will be developing an application for that too. Basically it will be good to have a same solution. if not then compatibility factor should be there atleast.
Apparently there is WebSocket support in MobileSafari on 4.2 (source). You could probably write up a client that uses an embedded UIWebView to marshall the events to/from the Juggernaut server and deliver them to your app via shouldOpenURL and custom handlers.
You might also look at libPusher by Luke Redpath for interacting with push communication via the Pusher web service.
Check out this library: https://github.com/fpotter/juggernaut-cocoa
It's really easy to use.
I want to give web applications running on foreign servers access to smartphone sensors and address book data. The W3C is working on a spec for that, called the Device APIs. However, it is not finished yet, and it will probably take quite some time until browser vendors provide working implementations.
But I need this functionality NOW (for a proof of concept). I do not care about portability, Android would be enough. Requiring the user to install special software first would also be OK.
Two solutions come to my mind:
Hack the APIs into the browser myself. Maybe I could take Phonegap and easily write a browser wrapper with it? That is, build a browser with Phonegap that exposes the Phonegap JS APIs to arbitrary sites (don't care about security for now)?
Write a server and run it on the smartphone localhost. This server would provide access to the resources via HTTPS and OAUTH2 (for example). Web applications could then reference this localhost server in their code (HACK HACK .. are there security mechanisms that prevent an arbitrary site from accessing a server running on localhost?).
Suggestions welcome.
Use a WebView:
http://developer.android.com/reference/android/webkit/WebView.html
This class is the basis upon which you can roll your own web browser
A WebView has several customization points where you can add your own behavior. These are:
Adding JavaScript-to-Java interfaces
with the
addJavascriptInterface(Object, String)
method. This lets you bind Java
objects into the WebView so they can
be controlled from the web pages
JavaScript.
You'd need to create an application that acts as the browser, (by implementing a custom WebView). Then in that application, create a java object for the web view that will fetch the sensor information. In the server output, write javascript that tests for and accesses this object.
For android, I believe you can expose custom local functionality to javascript either by wrapping a webview in your own lightweight "browser" application or by building a plugin for the supplied browser. As pointed out in this question How to develop plugins for the native Android browser there is an example in the sdk samples.
But I for one would be rather upset if you enabled a website to access my device's contacts, and would probably refuse to install your application on my device.
When I implement OAuth in iPhone, I have a dilemma to choose Safari or UIWebView to open the Twitter pages for user authentication?
I write some advantage and disadvantage of both case:
Using UIWebWeb. The disadvantage is users have to enter their credentials in our application. It's maybe risky phishing. The advantage is this approach will not quit our app.
Using Safari for user to authenticate (this approach automatically callbacks to our application) Addvantage: less risky. Disadvantage: have to quit our app
A good reference link about this: http://fireeagle.yahoo.net/developer/documentation/oauth_best_practice
Which approach do you prefer?
Any response is appreciate. Thanks.
The vast, vast majority of users will not understand or care about the distinction. Do whatever makes their lives easier, or--all else being equal--your life easier. And so long as you are trustworthy (you're not phishing or peeking at their credentials, right?), you'll be providing a good experience and not screwing them over. In this case, I'd use the UIWebView.
The guy who did the Pownce iPhone app a couple of years ago sort of publicly debated with himself about this.
His blog doesn't seem to be up anymore, but basically he implemented it the "right" way as far as OAuth is concerned. Instead of entering credentials inside of the app, Safari was launched and they were entered in there, and then a custom iPhone URL was used as the callback to relaunch the Pownce app. Pretty neat, eh?
Some time later, the developer followed up with a comment that a lot of people were downloading the app but not actually using it. His conclusion? That his brilliant OAuth scheme was to blame. Users were confused by Safari launching and being taken out of the app.
To be honest though? I think the fact that the app was for Pownce, a service that nobody used, was to blame.
I have an app in the app store right now that uses the Foursquare API, which supports both Basic HTTP auth and OAuth. I decided to "do the right thing" and use OAuth. The user enters their credentials directly inside of my app. Am I saving their username and password in plain text anywhere? Nope. But could I be? Sure.
It might sound like I'm arguing for both sides here, but what it really comes down to is that it's very unlikely that your users will know or even care about what OAuth is. It's probably just as unlikely that they will even think twice about putting their credentials into your app. OAuth is great (a hell of a lot better than OpenID) but wasn't designed with the iPhone in mind. It's built to work inside of a web browser. I think the Foursquare API docs put it best when talking about their Mobile/Desktop client OAuth scheme (different from what they want you to do for a web app) - "We provide this mechanism under the assumption that if a user has installed your application on their hardware they, trust it enough to pass through their authentication information to foursquare."
I've already implemented this as a drop-in set of classes (open source). Feel free to take a look: http://github.com/bengottlieb/Twitter-OAuth-iPhone
For the best user experience with destop and mobile application, we should use xAuth:
http://docs.google.com/View?id=ddkz8b2q_76d95356mz
As of May 31st, 2017 and onwards, there is no option left. We MUST use Safari, since google now does not support OAuth via UIWebView. Refer this link for more details.
I've been doing mobile app development for a long time (2001?), but the systems we worked with back then were dedicated mobile development environments (Symbian, J2ME, BREW). iPhone SDK is a curious hybrid of Mac OS X and Apple's take on mobile (Cocoa Touch).
But it is missing some stuff that other mobile systems have, IMO. Specifically:
Application background processing
SMS/MMS application routing (send an SMS to my application in the background)
API for accessing phone functions/call history/call interception
I realize that Apple has perfectly valid reasons for releasing the SDK the way they did. I am curious what people on SO think the SDK is missing and how would they go about fixing/adding it, were they an Engineering Product Manager at Apple.
The biggest shortcoming in my opinion is support for separating licensing from distribution.
What I mean by this is that it should be possible to download a trial version of an application and later purchase a license for that application (from an API call inside the application or from the app store). This would make it much easier to try-before-you-buy and get rid of the current duplicates of many applications with 'lite' versions.
I think lack of push notifications for apps is the big thing we're missing right now. With push, you can register your application to perform a task (like getting the most recent data from a web service) even when it's not running, at a time and frequency the OS decides is best. In an ideal world, along with the existing concept of iPhone apps loading quickly and resuming where you last left off, this solves the problem of not running in the background. I know some tasks will be more difficult or maybe impossible with this strategy, but it's still a pretty good compromise between third party applications and the iPhone's limited hardware.
Originally push was scheduled for last September, but it was removed from the beta SDK and not spoken of since then.
API's I'm personally looking for:
Apple80211 as a public API (private, current API is fine if documented)
Access to Volume buttons (semi-accessible via Celestial, private, needs new API)
Access to Calendar (private, API status unknown)
Access to Bluetooth + SPP profile (status unknown)
Access to Camera (directly, API status unknown)
Access to JavaScript runtime (directly, not through UIWebView, API status unknown)
WebKit access that's lower-level than UIWebView (private, current API is fine)
Access to Music Library (private, current API is fine)
Garbage Collection.
CoreData is missing.
You've mentioned some of the big ones - copy & paste (or in fact any way for apps to collaborate) is another huge omission.
It also seems to lack a desktop synch framework (at least if it exists I can't find it).
Language independence and especially lack of scripting is another pet peeve - objective-c is all very well but more languages to choose from would be good.
Inability to dynamically extend apps, via scripts or otherwise, is another big omission. This is partly an SDK/OS issue, partly licensing.
My list ordered by priority:
Mapping abstraction (the MapKit looks awesome), but that would require a new Google Maps TOS
Music library
Camera (photo + video) Access to more
UIViews, Apple designed some pretty nice custom ones for their apps
Better UIWebKit abstraction
The features I see missing that it should have is
Access to SMS
Direct Access to Google Maps App. You should be able have access to this so you could extend your application to use the built in features provided by Google Maps.
Access to the Bluetooth functionality of the phone.
Access to the Calendar. Why not allow access to simply post a calendar event for the user.
Access to Active Sync. It would great if we could directly access this and communicate back to the Exchange Server.
Core Image. They provide Core Animation but Core Image is missing. I hope that this is added to the API soon.
These are some of the features that my clients have access for in the past and are supprised when they are not available.
We definitely miss a Calendar API and SMS access. So many applications could leverage such APIs. The iPhone allows users to have everything in their pocket, but it's almost useless as long as developers cannot leverage this integration in their apps.
A language with proper namespaces.
A limitation that bugs me is lack of access to system features that require root or setuid. For example: opening privileged IP ports.
I'm not sure there is a good solution to this, as long as Apple's policy is to keep the device locked-down.
Allow program to set some kind of local timed event for your application to bring up an alert and launch your app if the user agrees (like any calendar app). You could do that with push notifications but there are many cases I'd hate to have to rely on a whole server infrastructure and network connectivity just to basically do some timed thing.
Some idea of what direction the user is facing. I cannot believe the GPS chip the newer iPhones use are not capable of reporting direction.
I would personally love to see
Access to the CoreTelephony Framework (Currently private). Which allows access to all the phone functions (Especially sending MMS / SMS).
Some sort of ability to run stuff in the background. While push notifications is ok for most things, but it is a bit hard to leverage CoreLocation (i.e. have the app show a notification at a certain location). Of course this would probably need an on/off button or app specific like push is.
animation view which will be reduce developer to make a cool app , of course the core business local still need consider more , but the view layer could more easy to use ....