The "Good For Enterprise" solution from good.com is a very very difficult thing to google for!
It comes with a secure browser that... well, if you don't know by all means read all about it, but you probably can't answer my question :-)
Which is: does the secure browser (on the iPad specifically) support the SQLite database (or similar), and if so does that data get persisted when the Good "session" ends? From what I can tell, the browser clears its cache when the session is ended - but I'm not sure if that would include stuff like this.
I'm trying to figure out whether I can create an offline-capable web application that will be a front-end to a CRM system. The web app would have to cache CRM data locally, and that would need to persist between sessions. The browser does not currently fully support HTML5 - and so I'm not even sure that SQLite or similar will be available, but it does have some support for HTML5 features. I'm just not sure of the extent of that support...
Here is the document which lists out the secure browser's HTML5 compatibility.
http://media.www1.good.com/documents/SecureBrowser.pdf
As for your question, I don't think you can do this right now because all cached data will be removed once the Good session ends.
See Good Mobile Access (Secure Browser): Support for HTML5 and CSS3 for a much more thorough list of supported features.
Acccording to this document, SQLite databases are not supported by the Secure Browser.
Related
I am developing an iOS application (to be deployed on the App Store) that requires content updates on a weekly basis.
I understand that the best way to achieve this would be to use a server, where the app would query for new data and download responses in JSON. However I am not knowledgeable when it comes to HTML, PHP or MySQL and therefore am endeavoring to find an alternative.
Here's an idea: using Dropbox to substitute for a server backend. My app connects to one central Dropbox account, checks for new files, and downloads them if present.
Is this idea feasible? If not, are there any alternatives?
Dropbox cannot be a dependable substitute for your server/backend for following reasons:
Dropbox uses OAuth for authentication, which needs user interaction. You do not want your app users to go through Dropbox authentication with your 'common' credentials.
Users who have a Dropbox account or the app installed, will most likely use their own credentials to login which completely breaks your flow.
Drobox, although a good way of sharing and syncing files is not meant for more meaningful data like web services etc or user/database interaction etc. Just syncing JSON file may suffice your app's needs for now but from a long term perspective you want a proper back end.
As suggested in the comment by #tkanzakic you can use one of the substitution services if you don't want to get too technical on the backend.
I am pretty late to the party, but this is possible and not necessarily a stupid idea (though this depends on what you need). You might want to have a look at remote storage for example, which allows you to use Dropbox among other providers as backend.
For sure, you can use the Dropbox Sync API to achieve this (https://www.dropbox.com/developers/sync).
I have been using Cookies for authentication and session control in my web apps, and am content with its functionalities.
I was introduced by an iOS app developer that the new hot thing is JWT (JSON Web Token). He told me that JWT is the way of doing authentication and sessions for native mobile apps, and without giving specific examples, he suggested that both iOS and Android apps have various problems with Cookies.
So I looked up JWT, e.g. http://angular-tips.com/blog/2014/05/json-web-tokens-introduction/ and https://auth0.com/blog/2014/01/07/angularjs-authentication-with-cookies-vs-token/, and I failed to see why it is significant better (or even that different) than Cookies, and more specifically, why it does better in native mobile apps. It seems that, at least iOS, handles Cookies just fine (Persisting Cookies In An iOS Application?).
So my question is, for a native mobile app that interacts with a server-side API, what are the specific advantages and associated use cases for using JWT over Cookies for authentication and sessions? Please highlight the ones that Cookies simply cannot do or does it much worse.
We software developers (sometimes) have the tendency to apply the new hot thing everywhere we look; it's possibly a variation of the saying if all we have is an hammer, everything looks like a nail where in this case we just feel a desperate urge to use this new thing we learned about.
One interesting point about this comparison is that neither JWT or Cookies are in fact authentication mechanisms on their own; the first just defines a token format and the second is an HTTP state management mechanism. Only this is sufficient to give us an indication that advocating that one is better than the other is wrong.
It's true however that both are vastly used in authentication systems.
Traditional server-side web application have used cookies to keep track of an authenticated user so that they were not forced to provide their credentials at every request. Normally, the content of the cookie would be an (hopefully) random generated unique identifier that the server would use to find session data stored on the server.
However, for a new type of web application - the API - it's more much more common to accept a token (in JWT format most of the times) as a way for the server to decide if it should grant access to who's making the request. The reason for this is possibly because while a traditional web application had one major type of client, the web browser, which has full support for cookies, the API's are generally used by much simpler HTTP clients that don't natively support cookies.
I think this is also why we could possibly argue that token based authentication makes more sense for native mobile applications. These applications generally depend on a server-side Web API and we've seen that if the API supports tokens it will increase the range of clients that can use it, so it's just the most practical thing to do.
In conclusion and to try to answer your concrete question, I would say JWT's do have an advantage over cookies on native mobile applications just because of the fact they are currently in very common use, this means more learning resources, SDK's, known pitfalls (mostly because someone else already did it and failed), etc.
Nonetheless, only use them if they give you the security assurances you need and end up simplifying your scenario. If you haven't gone through it already, I think you'll also appreciate Cookies vs Tokens: The Definitive Guide.
I cannot speak for Android but on iOS cookies work with URLSession as good as headers. Once you can utilize the (standard) API right (e.g. dedicated, properly configured session with cookie storage per web app...), iOS should be a rather negligible factor to this decision.
I am currently in the process of writing a static iOS framework that connects developers to my API and returns to them objectified information at their user's requests. However, in order for this framework to be worthwhile, one of the requirements is that this framework must be able to cache the information locally and return an offline copy when a network connection is unavailable. I am aware that I can store this information in NSUserDefaults but there may be a case where the information that is cached may be private and the local developer should not be able to have access by guessing the proper key. I believe that best approach will involve some sort of encryption but I wanted to see if there were any other storage options available to a static framework other than NSUserDefaults.
I would like to keep my data in an objectified format if possible. Two solutions I would be interested in exploring would be to save my offline data in either SQLite or CoreData. However, with both of these approaches I am concerned about how these files would be stored in the framework (I already have an embedded framework) and the security issues of having the schema for these files available in the bundle for the developer to see.
Another solution that I am looking into would be to see if iOS supports any tools such as gzip that could be used to password protect my files until they are used by the framework.
Has anyone successfully overcome any of these issues? Is there anything else I should be looking into besides the previously mentioned possible solutions? Any advice will be warmly welcomed.
Thanks.
P.S. Does anyone know of any resources I could go read relating to iOS Security or static frameworks? Either would be very helpful.
I have recently started playing around with iOS development and have got most of the basics down. I would however like to know about some best practices and what you guys think is the best in coding practice and application architecture.
What I have in mind is a simple application that gets information from a web server, displays the data to the user, and allows the user to edit the data which must then be updated on the web server.
What I would like to know is:
1) What type of web server / architecture is best suited for something like this? For example, data passing / updating similar to something like the facebook or twitter etc. applications where data is retrieved, potentially updated, and sent back for updating.
2) What type of authentication / security can be built into an application like this? I was thinking something in the line of username / password being stored on the server. Obviously the data should be secure when being transfered.
3) Are there any "free" web servers out there to play around with. I'm not building anything enterprise size, just need somewhere to play. Would the Google App Engine be suitable for something like this? What I have thought up to now is that you would probably need to implement a web service or something. Is this correct? Or are there better ways?
4) Are there any good tutorials around? I have started looking at the ones in the apple.com developer center, but I would like to get other people's point of views too.
I realise these are not really programming questions, but I would appreciate any insight that some more experienced iOS developers have. I would like to get the best practices down by incorporating the above into an app.
Thanks!
This doesn't sound like you need an iOS app, more like just a browser based app that works on the iPhone. If you need features like the GPS, Camera, Gyroscope, taking offline things that are native to the phone, then yes build it on iOS.
But if it's a simple web application that performs the operations you mentioned, then you can look at building a mobile web application. The nice thing is that it will work across iPhone, Droid, WiMo 7, really anything that can host a browser.
1) You can pick almost anything you're comfortable with. I program in both ASP.NET and Python for web apps. Personally, I'm building a web app on Django with Python. It's cheap (free) and there are lots of resources for learning as well as an active community.
2) Security is a rather large topic, there are many things beyond authentication and authorization, like cross-site scripting, sql injection, etc that need to be taken into consideration. Django has some things that help with this. But at the simplest you can secure your site with SSL encryption when performing authentication. You should also consider OpenID as an alternative for authentication, like how StackOverflow gives you the option.
3) I do all my "play" on my macbook pro or pc at home. You can do all of this for free on your own machine, and when you're ready to deploy pick a host, like Amazon or something like Media Temple.
I'm trying to create a ruby on rails ecommerce application, where potential customers will be able to place an order and the store owner will be able to receive the order in real-time.
The finalized order will be recorded into the database (at the moment SQLite), and the storeowner will have a browser window open, where the new orders will appear just after the order is finalized.
(Application info: I'm using the HOBO rails framework, and planning to host the app in Heroku)
I'm now considering the best technology to implement this, as the application is expected to have a lot of users sending in a lot of orders:
1) Each browser window refreshes the page every X minutes, polling the server continuously for new records (new orders). Of course, this puts a heavy load on the server.
2) As above, but poll the server with some kind of AJAX framework.
3) Use some kind of server push technology, like 'comet' asynchronous messaging. Found Juggernaut, only problem is that it is using Flash and custom ports, and this could be a problem as my app should be accessible behind corporate firewalls and NAT.
4) I'm also checking node.js framework, seems to be efficient for this kind of asynchronous messaging, though it is not supported in Heroku.
Which is the most efficient way to implement this kind of functionality? Is there perhaps another method that I have not thought of?
Thank you for your time and help!
Node.js would probably be a nice fit - it's fast, loves realtime and has great comet support. Only downside is that you are introducing another technology into your solution. It's pretty fun to program in tho and a lot of the libraries have been inspired by rails and sinatra.
I know heroku has been running a node.js beta for a while and people were using it as part of the recent nodeknockout competition. See this blog post. If that's not an option, you could definitely host it elsewhere. If you host it at heroku, you might be able to proxy requests. Otherwise, you could happily run it off a sub domain so you can share cookies.
Also checkout socket.io. It does a great job of choosing the best way to do comet based on the browser's capabilities.
To share data between node and rails, you could share cookies and then store the session data in your database where both applications can get to it. A more involved architecture might involve using Redis to publish messages between them. Or you might be able to get away with passing everything you need in the http requests.
In HTTP, requests can only come from the client. Thus the best options are what you already mentioned (polling and HTTP streaming).
Polling is the easier to implement option; it will use quite a bit of bandwidth though. That's why you should keep the requests and responses as small as possible, so you should definitely use XHR (Ajax) for this.
Your other option is HTTP streaming (Comet); it will require more work on the set up, but you might find it worth the effort. You can give Realtime on Rails a shot. For more information and tips on how to reduce bandwidth usage, see:
http://ajaxpatterns.org/Periodic_Refresh
http://ajaxpatterns.org/HTTP_Streaming
Actually, if you have your storeowner run Chrome (other browsers will follow soon), you can use WebSockets (just for the storeowner's notification though), which allows you to have a constant connection open, and you can send data to the browser without the browser requesting anything.
There are a few websocket libraries for node.js, but i believe you can do it easily yourself using just a regular tcp connection.