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 ...
For most users the primary function of a smart phone is as a phone, followed by receiving text messages, and receiving e-mails. The designers of a smart phone OS must ensure that no application can interfere with these primary functions.
The other constraint of mobile is battery life, any app which "spins" in the background it will consume current and ...
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 ...
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 ...
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 ...
The key attributes of a RESTful applications are:
All communication is via http GET,POST,PUT,DELETE AND all items are addressed via a standard URL of the form http://your.site.com/salesapp/salesperson/0000001/details i.e. only a pure URL with no parameters etc. the URL identifies the thing the GET,POST,PUT,DELETE identifies what you want to do to it.
For starters, the vast majority of apps, of the million out there, do not sell well, whether open or closed source. So don't expect any app to sell well unless it is a stand-out app and well marketed.
For iOS apps, someone would need to have paid Apple $99/annum for an iOS Developer program enrollment, plus have a Mac, in order to be able to download your ...
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.
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...
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....
Battery life - many applications running in the background will drain your battery really fast.
Did I mention Battery life? :)
Here is an article about this feature on the Windows Phone Platform. It starts by explaining the reason why this it is a "necessary evil":
Mobile Matters - Windows Phone 7 Tombstoning
They might want to see the schema so that they can replicate it on the mobile device. That will save them some work. Additionally, seeing the schema might prevent them from making wrong assumptions about how their data should be structured based on potentially-incomplete information about the database.
However, they should really come up with their own ...
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 ...
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:
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
If the webpage is really that simple, you shouldn't make it into an app.
I can give you one reason, but it's a very good one:
Simple applications usually don't pass through appstore reviewers.
2.12 Apps that are not very useful, unique, are simply web sites bundled as Apps, or ...