I don't wish to use authentication with my sync adaptor Since I plan to use it for syncing twitter public timeline for a search query.
Shall I use SyncAdapter or any ordinary Service?
Either would work fine in this use case.
If your application might contain multiple user accounts, then going the SyncAdapter/Account route would be best as it would maintain the standard account management procedures (you can have accounts without authentication).
Using a SyncAdapter will also mean Android automatically syncs your data as needed.
With a standard service you'd need to set up the functionality if you wanted it to sync automatically every X minutes in the background, but apart from that it would be just as easy - though you'd need to do your syncing in a different thread (e.g. use an AsyncTask, I think using a SyncAdapter will do this automatically).
Related
I am very fairly novice to AndroidStudio and want to create a project of my own.
My question is:
Can you update a Database outside of republishing your app?
Say I have published the app and the Database is currently empty. Then later I want to add some data How would I add this data to the DB without having to change fundamental source code, or redevelop the app? I am using SQLite.
I would like to publish this application as a Network app. That is I want all users to view the same information from "empty" Database and whatever is populated. Could you guys give me a direction or a minimally functional example of Network apps / their requirements. I have never used or developed them before.
END_RESULT:
Users should download an app (this app) and be able to be able to collect news added to its feed.
The maintenance crew, should be able to add/populate the app via a database reasonably without having to redeploy the app every time new material is added.
You would have to implement some kind of server backend that your app communicates to in order to download new data. The app must already have logic for how to process that data and store it locally in SQLite, but that can be fairly straightforward. As for how to sync or download new data, there are several possibilities.
Perform a sync when the app starts. You may or may not want to do this if you are using some other (periodic) mechanism.
Schedule periodic syncs with JobScheduler. This is a good practice in that JobScheduler doesn't have to run your task at a specific time, it can run it within a certain time window so that your task coincides with other apps that need to run tasks. Since your task would spin up the radio and make network requests, the system can let other apps that need the radio also run at the same time to reduce the number of radio wakeups (and thus be more battery efficient).
Implement Google Cloud Messaging so that your backend can send a push notification to your app, and your app can receive this as a signal to perform a sync.
Note you aren't limited to only one of these.
Yes you can, if you add Realtime Database.
This is a database hosted on a server instead of directly on the phone, which can push informations to clients to synchronize new data on them.
Otherwise, you need to update the app to get new content.
One wonderful tool to achieve this is Firebase.
https://firebase.google.com/docs/database/
This is a very broad ended question and as such difficult to provide specific answer to. What do you mean by 'updating a database outside of republishing your app' ?
Do you mean update the database schema - YES, it can be done.
Put data into database - Yes, the app owning the database can do it anytime based on it's business logic.Which means the source code to insert the data should already be embedded into your published app. Only thing that should be decided on the fly, is when to execute this code.
Normally for a networked app, it's a norm to refresh the data when the app is launched. This means you can put a network call in your app's main screen launch and download whatever you wanted to download and put it into database. Your maintenance crew can put the data on a server and let the app download it.
Android has a plethora of network libraries and the choice depends on what kind of content you are downloading. Will suggest to try out Volley (Official from Google) and Retrofit (If you want something slicker)
Firstly: This will be implemented for Android using Google App Engine & Google Cloud SQL/Datastore but it's more the over arching strategy that I'm a bit confused about.
I'm creating an Android app that will record an activity. I'd then like to be able to sync this activity to the cloud and have the activities viewable/editable on any other devices registered to the user. The specifics of authentication, device registration and all that I can work out, it's more so the sync strategy that I'm having trouble with.
Requirements will be:
Activity is recorded on a users device
Activity is stored in cloud after being recorded
Devices should check the cloud for an updated list of activities and maintain a local 'cache' of activities (will be a SQLite database) to display to the user.
These are my initial thoughts on how I'll implement this:
Scenario: Recording activity
Record Activity on Device
Once Recorded upload data to cloud
Force sync with cloud to update local cache
Show user locally cached activities (which will include the recently added one because of the previous sync step).
Scenario: Updating activity
User selects cached activity
Makes changes
Uploads change to cloud (and marks it as modified somehow? not sure how this will work)
Force sync with cloud to update local cache
Show user locally cached activities (which will include updated content of the activity because of the previous sync step).
Problem: Sync local cache with cloud data
I'm not exactly sure how to implement the sync (i.e. steps 3 & 4 of the previous scenarios respectively). I don't want to discard the local cache and re-download everything to ensure the latest data as that seems terribly in-efficient. Preferably I'd like to just download activities that aren't in the cache and update activities that are in the cache but have been changed since the last sync.
Are there any best practices / well known sync patterns (that are easyish to understand) that will help me achieve this?
Kind regards.
You will also need to consider connection loss/retries, battery/power efficiency, and possibly apply custom sync algorithms.
Android already has an excellent pattern/API to address these issues and handle background sync with your back-end server in an efficient way.
Follow the official android guide for sync adapter API pattern , you do not have to implement content provider or authenticator if you do not need them, just implement stubs for them.
Here are couple of example projects to help you through...
Basic example, available at above link called BasicSyncAdapter
Look at Google iosched app for more advanced usage, and best practices including the usage of GCM for triggering your sync, among others.
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 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 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