You can never verify an entity, any entity, be it a person, hardware client or software client. You can only verify that what they are telling you is correct, then assume honesty.
For example, how does Google know it is I'm logging into my Gmail account? They simply ask me for a user name and password, verify that, then assume honesty because ...
I'm currently working on a mobile/desktop/distributed app with exactly the same requirements and issues.
First of all, these requirements are not inherent to mobile apps per se, but to any disconnected/distributed client-server transactions (parallel programming, multithreading, you get the point). As such they are, of course, typical issues to address in ...
I'm sure you're comfortable with dealing with user logins, and with communications over SSL, so I'm going to focus on what I think it the more interesting part of the question: how to ensure that your read-only actions - which do not require the user to be authenticated - are only accepted from your own client apps?
Before anything else, there is the ...
The API being designed follows the Rest style of resources-centric URI and CRUD operations mapped to HTTP verbs.
This is your problem right here.
You have limited your resources to (I'm assuming) the models in your database. As such it is taking ages to load all these resources because your server has no concept of resources that don't have a ...
I'm a mobile developer who has spent a great deal of time considering this issue.
Why do you ask?
Most likely, you hope to reduce app development costs by:
Targetting multiple platforms without writing multiple apps from scratch
Not having to maintain multiple codebases in the future
Reasons may also ...
In layman's words:
Not all users use all of a company's apps
Different users have different needs
Why force an user to buy a full package when he/she needs only a part ? (Ok, Google apps are free, but other software maker's aren't.)
Having those apps separate makes it possible to be updated separately and, most importantly, sold separately.
The fact that ...
To anyone interested, on Android you CAN verify that the request you have gotten was sent from your app.
In short, when you upload your app to google you sign it, with a unique key that known only to you (and google).
The verification process goes(ish) like this:
your app goes to google and ask for auth token
your app sends the token securely to your ...
To understand delegates, you have to understand protocols.
A protocol is like a service contract. When an object (most often a UIViewController subclass, but not always) signs that contract, it is saying "I am interested in providing logic to back the message you send me". This is similar to NSNotificationCenter in regards to signing up for a level of ...
Polling is always acceptable when real-time isn't a necessity. What you have to ask yourself is why would you use one instead of the other?
The purpose of a push service is a couple things; it can be considerably less traffic for you to deal with if your pushes are broadcasts and a 3rd party provider does the broadcast - this allows you to send one message ...
There are several way how to implement authentication in RESTful context, and it is more safe to send only tokens instead of login/password: you could easy make tokens to be invalid by timeout or by some other criteria, and ask user to re-authenticate.
For example authentication REST requests using HMAC. In this approach, client will have public and secret ...
You pass username/password to the login method of your RESTful API and it returns access-token. That access token is just some unique (for the system) string.
Device stores (persists) that access-token. Each time you send RESTful request to the server you put that access-token in header of HTTP request. Server finds the user by access-token and on success ...
You need a Service Oriented Architecture.
Because you are sharing data across all those platforms, Web Services..
Basically rather that calling a "function" you make an HTTP request to a URL, parameters are passed in via the query string or Http header. XML or JSON is returned. Read up on it.
Thing is, your app need to be online at all times...
If something you can take with you, but not really for using on the move, take a look at Raspberry Pi.
You can use it on the move with a USB power pack designed for giving your cellphone extra battery life, but you'll also need to bring some sort of screen / output device with you, and maybe a USB keyboard or something.
The poster boy for HTML5 apps, LinkedIn went native early 2013.
In the interview in VentureBeat they explain why.
I think this is the part most relevant to your question:
Prasad said performance issues weren’t causing crashes or making the
app run slowly. What he did say shows that HTML5 for the mobile web
still has a bright future — but only if ...
Put together a stock "thank you for your interest" letter that covers the possibilities of a) features you will NEVER implement even if I show up on your doorstep with a bag of gold, b) features you don't PLAN to implement but maybe, and c) features you'd like to implement but can't right now. Send that. Because you ALMOST never know when you might find ...
First, you mentioned both an API and a database (MySQL). I very much recommend that you use an API and don't try to communicate directly between the databases. That latter route will not scale well at all.
One good starting point you should consider is using Apache CouchDB. It is schema-less, based on HTTP and JSON, and has a very good replication mechanism....
oAuth is the standard for this but there are more solutions.
Don't try to implement security, tokens etc. all by yourself since that's a difficult and risky topic. Take for example a look here:
When choosing a technology for multi-platform development there are some main issues to consider.
The first issue is the quality of the application. PhoneGap, for example, is probably the most popular option for writing an application that works both for Android and iOS. But, of course, it has it's disadvantages (native languages wouldn't be used otherwise ...
As the co-founder of Codename One which does pretty much that I can answer that pretty easily.
You can cross compile (which is what we do) but you can't have a single binary that will work everywhere because mobile OS vendors don't allow it.
Apple doesn't allow JIT's and limits interpreters. All mobile devices include app isolation which prevents a global ...
There's actually quite a bit you can do to recover something close to the actual time of most of your events.
Android gives you a few useful tools to work with, notably broadcast intents sent when the device completes a boot, when the system clock changes and when a shutdown is imminent. It also gives you a way to check the amount of real time that's ...
I've been in this position. I evaluated a lot of different things, but didn't really find something that suited me. Here are some things I've looked at though and pros/cons
The actual programming work isn't too bad
Fairly easy to write graphically intense applications (since it's designed for it
Ideally, you should use such requests as an opportunity to help you and users better understand the application.
If you think of it, the very reasons why you prefer to ignore these requests are quite important information and you'd rather have them stored and documented than buried and forgotten deep down in your mind.
If a request is ignored because you ...
Basically your mobile phone company is adding your phone number to HTTP headers when you visit certain sites.
So when you visit www.advertiser.com your request goes to your mobile phone operator, via cell towers, through their network, off to the internet
Obviously the cell tower knows your number, as does your phone operator, they configure their router ...
To me, the table on the website you mentioned has a somewhat-naïve representation of these differences. It seems to focus on pushing a native app as the best possible solution because of "browsing speed" and access to device functionality, but this may not always be what you actually want to achieve. They haven't taken into consideration other factors which ...
In your mobile app, you have better control over the code that runs and can avoid XSS vulnerabilities. So storing the token is not so problematic and you can have your code pass it to the API
In your webpage you do have to worry more about injected code, so use the secure cookie to store the token and have the browser pass it automatically
There's little difference, RPC tends to be more binary-protocols than REST, but that doesn't have to be the case. Also RPC tends to be implemented as a single procedure point per call, but again that doesn't have to be - you can implement a single RPC procedure that takes a REST-style verb as the first argument. RPC sometimes has a semi/stateful approach, ...