I'm currently developing my first Android application and still in the designing stage trying to come up with a solid model.
My application will use the GCal data from a users Google calendar and sync it up with one or more other users to determine common meeting times between all without the tedious back and forth of scheduling over email.
I vision this working by storing each user and their calendar data in a database that will be refreshed daily. When a query to determine the optimal meeting times between a group is issued, I want to select the calendar data of each user from the database, perform the computation to find optimal times, and display the results back to the user who made the query.
The AWS SDK for Android supports Amazon SimpleDB and S3, in which case I would use SimpleDB for my database. Where I am getting lost is using the Amazon EC2 web service in concert with the SimpleDB to perform the computation.
First off, any feedback on my approach and/or design is appreciated.
Second, how does using non-Android, but Java based APIs/SDKs effect applications, or is it even possible to do so?
The API typica for Java looks interesting and useful if it is possible to use with Android for instance.
Thanks!
So, I think its important to note a couple of things.
What you are describing is not an 'android application'. Its a web service application with an android client. The reason I'm being pedantic is that many of the design decisions you need to make are completely besides the fact that your primary client will run on android.
I'm concerned about the viability of storing the users calendar in a non-relation database. I don't know if you've already looked through this, but the problem you are trying to solve (calendaring) seems like it would benefit from the relational benefits of a relational database. For instance, i'm not sure how you would structure for storage the data of past, present and future events/meetings in a non-relational. Its probably possible, but i'm not sure if its optimal. Depending on the amount of data you may also need to consider the maximum record size.
While its true that AWS SDK for android supports writing to S3 or SimpleDB, I think there is a lot to consider. The reason you are confused about the interaction with EC2 is that normally, your EC2 web service will be interacting with S3 or SimpleDB. By using the AWS SDK you can, in theory, remove the requirement for a web service. My main issue with that is that you're now forced to do lots more on each client because there is no common access pattern. Your ios client or web client needs to have all the same logic that your android client has to make sure its accessing your s3 and simple db data the same. If that doesn't make sense i can elaborate.
Using non-android api's and sdks is a mixed bag. Sometimes it works fine if the classes compile to Davlik. If they don't it doesn't work.
One thing I might point out, since you'll already possibly be tied to a Google technology is Google App Engine. The nice part about it is that there is a free level of service which lets you get your app up and running without cost. Based on the technologies you are suggesting, it might be something for you to look into. Other than that, my other strong suggestion is that you focus on building out the web service first and independently of the android client. Take the time to model what the client server interaction would be and move as much of the 'logic' to the server as is possible. Thats what I felt like was missing from your initial description. Where the crunching would be.
my solution is that you use O-O principles. store your db on amazon dynamoDB and then sync user data with the mobile app. then you do processing of the data/computation on the device before displaying the results
Related
The Goal: I'm working on a simple project with Android Studio and Google App Engine. The App is just a Proof of Concept, so nothing spectacular. In a sentence, it is an app that counts the number of times a button was clicked in a six hour interval. Specifically, when a button is hit, the app needs to send a request to the backend. The backend then needs to load a number from cloud storage, increment it, and write it back. Every six hours, I need to reset the counter to zero.
The Current Progress: I have the app UI written, I have an App Engine Project set up, and I have the two connected via endpoints. For now, I have a method to send two numbers to be added in the backend and return it. I'll scrap that and go with the incrementor code when the time comes, but I can say I understand how App Engine and Android are connected.
The Problem: How do I access Google Cloud Storage programatically from here? Do I write backend code? Do I write code in the App itself? Do I do some more endpoints wizardry?
I keep seeing code excerpts, however, I don't know how everything fits together. I can access cloud storage from the online manager, however, that doesn't do much good I don't think. I understand how buckets and entities are broken down as well, if that helps.
Thanks in advance, I've been wandering through the desert of Documentation for weeks.
It's a little unclear exactly what you're trying to accomplish, but I'll take a crack at hopefully nudging you a bit more in the right direction.
First off, if you're just needing to load and increment a number, in my opinion, you may be far better served using a database, such as Google's Cloud Datastore, rather than Cloud Storage.
There are numerous options for connecting, whether you end up on Cloud Datastore or Cloud Storage. You may find it easiest to implement your Storage/Datastore operations on App Engine, but that really depends on what else you're doing.
If you app just needs to do basic database or storage operations, I wonder if you might not be far better served by a more managed solution like Firebase. With Firebase, you get many of Google's cloud services, nicely wrapped in an API that is very easy to implement, thereby negating the need to manage a separate App Engine instance and your endpoints. Firebase also gives you offline and caching functionality.
Is it possible that I store my SQLite table over a dropbox account and have all my users sync their tables with the stored table? Also be able to make changes to that table?
Your approach could work in theory, but there are so many issues involved, that you're better off not doing it. If you wish to store and make data available across all devices belonging to a user, I strongly recommend looking into Datastore API by Dropbox. The API will take care of storing data locally as well as synchronize it over connected Dropbox accounts.
If you want a bit modular approach, you can use Windows Azure Mobile Services. These give you REST APIs to store your data in cloud. However, synchronization has to be handled by the developer - you. I have written a small library to do that here: http://bit.ly/ProjectMirror It's for Windows Phone, but Android version is already in a sister repo there. You could extend it. Let us know how that goes.
In addition to these services, Parse SDK is a good option. It requires you to pay after a while, though. In addition to what you want to do, it also provides other things like user management and so on. But, be aware that some of those operations may require you a live Internet connection.
So, in essence, if you want seamless data storage and sync, use Datastore. Be aware that you'll have no control over the server side. Also, your data will be restricted to the Dropbox ecosystem forever. If you plan on further expanding your app to other platforms, go with Azure and handle the sync. If you want lots of features, go with the Parse.
I would suggest looking into Google Play Game Services using the Cloud Save feature. Even if you are not building a game this feature lets you sync sqlite data in the cloud and Google will handle most of the work for you.
OR you could use a cloud based database which supports both push and pull. That means:
Scenario 1:
Your users change something on their phones. Changes are uploaded to the database. The database then pushes these changes to all other users.
Scenario 2:
Your users change something and upload this to the database. But instead of the cloud based server pushing the changes to all users, the users phones can ask the database for new data at intervals.
All this is very easy to set up. It took me about five, ten minutes. Just follow this easy tutorial:
https://parse.com/docs/android_guide
and for push:
https://parse.com/tutorials/android-push-notifications
We now use this for our company app, storing statistics for example.
Bear in mind that syncing can become complex. Try to keep it very simple, especially if you are new at programming.
I have recently started working with Android. I decided to create a small personal android app for myself and my friends (anyone who wish to use it.) It’s a fitness tracking app where it’ll store number of sets and repetitions that you do for the day. Then, you can view your daily, weekly, or monthly progress. I have a WCF Web service that is communicating with SQL server database. However, I was wondering if will be better to use SQL Lite. I was thinking the app will be lighter using the web service, I could control the database, and I could even add more features that would allow folks to share their report with other friends. However, I have to host the web service, it will cost money, and if the service is down, the entire app is down.
Since I am a novice, I’d like to know what other cost/benefit that I should take into consideration?
If you don't want to host the database on your own server via a web service.
I think the easiest and cheapest method would be store the data in the embedded sqlite database which is local to the device. Then to ensure it is available on multiple devices, export the data from the database in some way, xml file, csv etc and upload this file to a cloud service such as drop box or Google Drive.
Then the app can use the file from Drive or Dropbox to sync the data into the local device database.
Start small and go big.
First implement it using sqlite on the phone and release it with adds or a paid version.
Once you see enough growth in fame and popularity and start seeing income, you can switch to the server, and go big.
I do not see any need to spend money on something which you yourself are not sure will be popular.
Also as you grow servers will start getting more expensive, and you will have to take into consideration emergency measures and such. That is why it is better to have something small and working and build upon it, rather than try something big and stop due to it taking up too much time or being costly.
I am planing to implement an app and I have come to a point where I don't know what is the best approach.
Scenario:
I have an app where I am making a todo list and I am adding 3 items. I use my phone for this.
Then I take my tablet and want to continue adding another task. Then after a while I take my wife's phone and want to add 2 new tasks.
Basically I want to have a very simple way of storing the tasks online and be able to sync it with the app.
I am seeing two possible ways:
have a web server with a database + web service calls. This has the disadvantage of having a host paid, learn some extra mysql + web service techniques.
store somehow the data on cloud and allow the app by login to access an account which stores the file. I am thinking here at something like Google Drive / Dropbox. But I don't know how I would be able to sync only the updated values, not the whole file. Because I am thinking, if I store all the tasks into one file, each time I update the file, I'll need to upload it fully, which is not the best approach.
I am open to any advices. What approach would you recommend ?
There's also Google Drive's "Application Data" folder.
https://developers.google.com/drive/android/appfolder
This has the advantage of using the user's storage space.
I would look into either Google App Engine or Amazon Web Services. They both give you free allotment of usage per month and if you go over then you start paying, chances are you wont get past the free tier for a while.
AWS is a bit more mature than GAE currently and seemed to be a bit easier to implement that GAE was when I was researching them
Take a look at the new training class for sync adapters:
http://developer.android.com/training/sync-adapters/index.html for the basics of sending data from your device to a server.
On the Android device, I suggest you store your tasks in a content provider. This helps you keep track of updates since the last time you synced. You can then query the provider during your sync, send only the data that's been updated, and store the data on the server.
You should probably store the last update time on the device, so you can tell if the server contains data that isn't yet on the device. Remember that you'll have to download tasks as well if you want all devices to be in sync.
You can try Google's Firebase. Firebase provides SDK for Android and iOS devices. And also, firebase supports offline and syncing. Firebase also provides object storage service. It easier to create firebase app than you think. Have look at this firebase's firestore service.
You can take a look at our Rethync framework (freeware with source) . Using it you can simplify the task of detecting modifications and sync only updated data. Next, Rethync provides both client- and server-side API so you can create your own service (and host it on the web side) or you can write your own transport for the cloud service of your choice (we will provide some transports in future, they are under development now).
I have an Android game and I want it to store data - say a high score for example - against each user on a server backend.
Here's a list of outrageously demanding requirements! It's unlikely any solution can meet all these demands, so I've changed/prioritised them:
Minimum/very easy server and client code
Free/cheap
Automatically scalable and no/little server maintenance
As secure as possible with minimum code
Seamless - no user action required to authorise/choose anything
I know about Parse, and that seems the easiest option but I'm concerned about the future cost and would prefer more control so I'd like some alternatives.
AWS seems a lot of effort, although it handles secure anonymous authentication fairly easily and well.
App Engine would be great if there was an easy way to secure requests without requiring the user to login or authorise app engine.
So... I want the seamlessness of Parse, the security of AWS, and the auto-scaling of App Engine. Also the ease of use/coding of Parse. Fingers Crossed. :)
Thanks
My advice: use Parse, but create enough abstraction/encapsulation in your models so that swapping Parse out for another service won't be so painful. But seriously, I don't think Parse will get expensive (or even not-free) until your app is seeing very high demand. Furthermore, the Parse guys seems pretty committed to openness: you can export your data as a CSV and they have a REST API so any type of program you write can access the data.
If you're determined to roll your own, I'd recommend creating a Rails back-end with Heroku. Piggyback SSL is free, HTTP Basic Auth is really easy in Rails, and the entire stack will play nicely with whatever db you'd want to use (I'm assuming NoSQL since you want flexibility).
Any PaaS that supports SSL and a dataabse will probably do. Estimate your traffic, data storage and processing needs and pick one that is cheap enough to get started. App Engine is going out of beta soon, and the pricing model will be changed, so if you want autoscaling you'll have to pay for it.
What exactly is 'secure anonymous authentication' and how does AWS support it?