Looking for some information and advice on the best way to go about using and integrating MongoDb for an Android App I am trying to develop. Last I looked around there was not an actual Android-MongoDb API that I am aware of so I am curious how this could be implemented. One of the biggest issues I am thinking about is connectivity while out in the field without network access since the app will be collecting data and I am wondering what is the best way to store the data locally on the device in cache until either service becomes available, or at the end of the day, the user can then upload the data. Thanks.
Related
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 used to use Google Analytics for tracking of my application's different features on my users device but since I need to get more information, I'd rather create this analytics on my own so that I can have many other features like how often my users are using the app and other stuff.
The solution I have in my mind is to add a jar file to my application where it retreives the data whenever user is using the app and stores the in the SQLite database of phone and when user is connected to the internet, the data are sent to my webservices on my server-side.
I need to know have a feedback, that what drawbacks this method has. Does it affect the quality of the app in terms of its speed etc ?
Anyone has any other suggestions for solving this issue?
Basically my android project is around making a form to be filled up by the user of the app. And send this data to the php server. The data may be collected offline so the app should also save the datas unless its in the reach of wifi or gprs network. I'm early beginner to android and got stuck in between. Can any one suggest me a similar project sample so tat I could make a study and learn the stuff.
Sounds to me like a good use case for a hybrid client-server app. Use the mobile device to collect forms and store their results in a SQLite database. Whenever an appropriate wireless network is available, connect up with the server-based app and upload all the data. There are many good ways to do this, but for starters, consider making the server app implement a RESTful API and have the mobile device use this API to send in the data. If messing around with a server sounds like fun, I've had good luck with MySQL + CakePHP. One of the cool aspects of CakePHP is it gives you RESTful access to your database almost for free. Or, you can use something like Google App Engine and let someone else worry about administering the server.
I have been developing a web application in PHP that provides contact and calendar management. This application needs to sync its contact and calendar data with mobile devices (specifically Android, Apple, and Windows phones).
I have no experience in mobile development, so I am mostly looking for guidance. It is difficult to know what to even search for because of this lack of experience. I am mostly looking to know what is possible and what is not.
The overall goal is to be able to edit contact/calendar data from anywhere, whether that be from the web application itself or a mobile device. These changes will then be reflected no matter what tool you are using to view it. A very loose comparison is an IMAP server. One central data source where any app can hop in and view/manage e-mails.
My web application can currently handle HTTP requests using XML data. So it can send out data and have data POSTed into it.
This is where my knowledge ends. I have little insight as to what would be required of the device itself to be able to sync. If a user adds contacts to a mobile device's default contact/calendar application, how can it be told to sync with my web application? Does this mean developing an app for each mobile device in order to act as a medium between my application and the mobile device's default contact/calendar data?
Is it possible to access the internal contact/calendar data of a mobile device? Can that data be pushed to an external server or be modified by that same server? What is required on the web application's side? The mobile device's side?
These are the sort of questions I am looking to be answered. There might be questions that I haven't even thought of that I would also love to be discussed. If my question is too general, please specify anything to be clarified.
In case of iphone you have to write your own app. I would recommend to use a database (sql) on your server, then every time the application opens you can check if there are new entries on the server and load them if needed.
I think it will take you some time to get the basic knowledge about ios programming but it isn't a hard job at all.
Things you should check:
requests
uitableview(/delegate)
Event kit
There are good tutorials to learn this stuff.
One good site:
http://www.raywenderlich.com/
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