I'm looking for suggestions for ways to share Android app data between phones running the same app. For example, lets say I have an app that stores a database of book reviews. If person A has a book review that person B doesn't have, what are the options for getting that information from person A's phone to person B's phone?
Currently, I'm aware of the following options:
- Upload data from person A's phone to a server, then download data from server to Person B's phone.
- Write code to have the phones sync up using bluetooth
- Write code to send SMS messages
I'm wondering if there are any more options besides these, and if there's actually a best-practice for accomplishing this?
Ideally, I want the users to simply click a button in the app to make the sharing take place, so I don't want to go down the bluetooth route because that requires the user to do a bit of setup (or assumes they already have set things up in the form of bluetooth settings).
Since the data can be of variable length and potentially large, I believe that would rule out text messaging.
As far as the server route goes, from what I understand this seems to be an ok way of doing things, but my problem is that I have no experience with having users potentially sign in to a server and then uploading data. I don't know of the cost concerns (if any), or of potential security concerns (allowing just anyone to upload data, I'm not sure if I would have to take steps to ensure someone couldn't bypass the app and upload malicious data).
So, can you guys give me suggestions and point me in the right direction? Thanks.
I'm wondering if there are any more options besides these
You could try generating a QR code and scanning it on the other phone. Beyond that, I think you have it mostly covered.
and if there's actually a best-practice for accomplishing this?
That is impossible to answer in the abstract.
Keep the database server side and interface with it via a web service
I too am looking for a solution to this very problem. I'll throw it out there that a fourth, or rather extension of your first option, is to use the Cloud to Device Messaging Framework, though it still requires (as best I can tell) having your own server, though I suppose you wouldn't need to store the database server-side longer than it takes to send the message, provided you keep it under 1024b (or whatever the actual size is).
I don't believe there is a convenient way to monitor/send email in the background. If I could have my app monitor email messages looking for a key subject, then parsing the body, I could probably accomplish what I'm looking for using email as the transport.
The problem with maintaining a server, is that you probably would need to build in a subscription fee to your app to cover the costs of maintaining a server, as one time sales may not be able to cover the ongoing expense.
Related
I am creating a REST server that will be holding a decent amount of proprietary information. I want users to be able to access the information in only the intended way, which is through a map built into an iPhone/Android app. I require a verified email registration to access the server. I will be rate limiting the amount of information any identity can receive, however I want to take it a step further and prevent (or at least try to prevent) an identity from pretending to be my app and grabbing the information in plain text.
A successful example of this is Spotify, you can download as much music as you want however it is difficult(impossible?) to get at the files unless you are using one of their clients.
I have seen questions like this saying it is impossible: https://stackoverflow.com/questions/32084631/how-can-you-lock-down-so-only-your-android-client-can-interact-with-your-parse-p
However they do not explain techniques that companies like Spotify use to at least obscure the data. I am also ok with only holding one request at a time on the client and requiring that they are online in order to view the information.
tl;dr: What is a good way to ensure REST communication with a verified client(Android/iOS), and decrypt the information so that only my app can use it?
You could encrypt the information, I dont know much about this, but what I do know that there is a book called java with jax-rs which deals with the authentication you are talking about.
I'm here to discuss about different ways to handle an Android application that can point its APIs to a server A (ie. httq://a.myproduct.com/api/...) for the client A, or an other server B (ie. httq.://b.myproduct.com/api/...) for another client B.
What i do actually is to generate different APK of the same app for each client. This solution is okay for one or two client, but will become quite heavy to deal with later..
I'm trying to find a better way to have one unique APK which can work with different server url.
Another constraint is that on a same device, i can have an app that talk to server A and an other app that talk to server B.
Here are the solution I came up with :
Keep going with multiple APK...
Have a "central" server that each app calls the first time to know with which server it has to talk and that store that in shared preferences.
Have a file store somewhere that make the link between an app and a server
for example:
com.mycompany.productA:httq://a.mycloud.com
com.mycompany.productB:httq://b.mycloud.com
But how to handle this file ? What is creating it ?
Use Android account system ? Create an account for each cloud ? I don't really know..
Does anyone, already experienced this ?
Considering you are able to map connecting devices IMEI to clients, I will briefly give you pros and cons of the three methods you mentioned.
Multiple APK's
Fully isolating client from other knowledge - safe
Not scalable and maintainable (issuing updates if needed).
Central Server
Scalable, easy to update information (in case you change a.mycloud.com to a2.mycloud.com)
Not as robust. What if server goes down? Possible attacks, or bugs to worry about.
All URLs embedded into APK
Stable and does not have large overhead in time/resources spent of your team.
Insecure, you should assume people having access to APK will have access to the file mapping IMEI's to companies.
If client's IMEI data or company url's is sensitive data, then a big no-no.
Are you a large company? If yes, then you are probably having production servers already and could go with second method.
I guess you can build a generic app and use some sort of auth system on the client app. For example, if the user identifies himself as "Client A", your web-service can "tell" your app to use the first endpoint. If it's "Client B", then it will be second endpoint. Bottom line is: make your users sign-in and then use credentials to distinguish the users.
I don't know if this is even possible, couldn't find anything usefull on the internet.
I wanted to make an app, that me and some of my friends could send a message trough "my app" and that everyone who has that app, receive the message, without using a phone number.
So basically, same as WhatsApp GroupConversation, but then without using a phone number.
Is this even possible?
If it is possible, could you put me on the right track to start with.
Hope I am clear enough, if not, tell me :)
Edit:
This just pops up in my head (didn't look on internet yet), but what I want, is a kind of a shoutbox.
This is possible, in fact WhatsApp does not use your phone number for this at all.
You simply provide your phone number to asure a unique ID and proof that you are indeed in possession of this phone with the validation SMS.
From there on, your phone number isn't even used anymore.
You can go 2 ways with this;
Create a simple webservice with a database on which you just save and request messages. Maybe make a little difference between get all or get latest message. Anyone, hooking into the group, can just fetch the same data. With the use of GCM push notifications, you can make this pretty instant.
Use XMPP, which is a chat protocol kinda all the chats use. Whatsapp, Google talk, FB messenger... This will provide you with instant messaging just like any other chat app or program you know.
Option 2 is by far the best in final functionality, but be warned that XMPP is quite complex and error prone.
You can look into the asmack and asmackx libraries for Android, which will give you the basic functionality with ease. Going a bit deeper, you'll have to dig into the protocol and really get to know it though.
ps. For both you'll need your own server, however with asmack(x) you are also allowed to use Google's Talk servers for free. Communication will go through your Gmail account. Basically with this you just make your own version of Google Talk.
It is possible by implementing server-client architecture. Your app will use a common database for all the users. whenever an user install your app, he will achieve an unique user ID. if anyone uninstall it, his id will be destroyed. You can track the users from those ID in database. You don't need phone numbers.
I am writing a basic app that interacts with a webservice I'm writing using AppEngine. I was wondering what the repercussions are of using login based authentication and managing users individually on the server side.
I know the business benefits of knowing your users and since I plan to eventually have some user generated content in the service, I realize I will eventually have to add it.
Right now, I'm concerned more about the technical aspects of adding this feature. What are the development and maintenance costs of adding these services right now versus adding them at a later point in time i.e. when the datastore is already populated with some 'anonymous' data and not user histories are kept ?
I know this is a vague question so I'll try to quantize the situation. Let's say we have an app that allows users to search the surrounding area for restaurants. The app only needs to send to the service the type of restaurant, say 'Chinese' ? The app is popular and gets a 100k users. Now we want to add a favorites system. Would we have been better off adding it from the start or is it better to wait to get some user and then add features ?
An underlying concept here is also the value that users attribute to a personalized experience and it would be great to get some insights from experienced App developers.
It seems feasible to build your system from the ground up using an internal unique identifier to segment user data. To start, just use the device's unique identifier to authenticate, then add a login-based scheme later.
I recently rolled my own api-based authentication system using GAE, and one of my biggest regrets has been not biting the bullet and doing it sooner. That said, if the context warrants (ie you want to test out a concept and see how well it resonates), I'd say you are safe going with an extendable approach, like the one I've described.
I'm having trouble understanding the top level of abstraction of this problem.
The Problem:
Users A and B download application X. A wants to send application-specific data to B. How does user A link with B?
My incredibly messy solution:
- User A clicks a button on the application that opens up a list of contacts. user A selects user B from the list. User B's email address was stored in A's address book. Application creates a sort of "share ID" and sends it to user B via that email address. User B's application gets that ID from the mail, then User A and B use the share ID to connect to a server and share between each other via the sserver.
There must be a better way? The two problems are:
1. It shouldn't need a server (should it? could it be free?)
2. There must be better ways of the users connecting to each other than sending ID's or links etc by gmail.
This solution should be so so simple, but I can't get my head round it. If this question is not sufficient to get a good answer, please please tell me what I need to do to get into the way of thinking about how mobile users can interract with each other as simply as possible, with as few clicks as possible, (Mobile 2.0 or whatever the modern day thing is!)
For example: A mother and a child have an android smart phone. They each download the "ChildLeash" app. Child wishes to configure the app to send updates to Mother, so that Mother can keep track of Child's location and so on. The problem is some how Child needs to tell the app what location Mother is at for the data to be sent to. What is a user-friendly way for Child to Identify Mother's phone? (Mother's IP address? Phone number? Email address? OpenIDs? NFC/Bluetooth?) So that it can then communicate?
You could use push notifications, as provided by the Android Cloud to Device Messaging Framework. There's an Android blog post about this. Problem is, this seems beta and not yet available to all developers (you need a specific signup).
Regarding "IP Adresss", P2P and such, this generally won't work. See: Is peer-to-peer communication over 3G/4G possible for smart phones?
If messages are not urgent, then you could use AlarmManager to have your app wake up every hour or so, and check for new messages by connecting to a server. Not sure that would work for your "ChildLeash" example. Another similar solution would be to use a Service to poll the server.
Usually this sort of interaction would require a server. Which you've kind of faked using email as your medium.
It might be worth looking into peer to peer libraries such as JXTA. There's an android port here: http://code.google.com/p/peerdroid/
EDIT: I just came across this: http://android-developers.blogspot.com/2010/05/android-cloud-to-device-messaging.html Which looks like exactly what you're after.