I am finding it difficult how to implement adapters or loaders to efficiently load data from an SQL database and showing it into an application.
I store accounts and users in a SQLite database:
An account has its own data like the name, the payment information, dates, etc
Users have their name, picture filename, and some other information.
Data is accessed via a ContentProvider that exposes account and user elements.
I would like to retrieve the list of accounts from the database, and display them using a custom layout that should contain the users of each. Each user has its own layout (basically a picto).
My problem is that I don't know how to structure the adapters and loaders so that each account displays the dynamic amount of users (some may have one, some three, five... etc).
The application has a listener service that receives network connections and creates, deletes and modifies users depending on the command it receives.
So, would it be possible to implement this structure in such a way that data is loaded in the background and displayed without interfering with the UI? Also, it would be phenomenal if every time the underlying data is modifed the UI reflects this (modifying, creating or deleting an user from an account, etc)
In my head this sounds like nesting two adapters but I don't know if this is possible or I am missing something.
Thank you very much in advance.
Related
I've written for the beginning basic, very simple app in Android Studio which just fetches data from various REST methods and presents them in a table.
However, I would like to extend the functionality and offer user possibility of filtering data, for example, to get data from a different time. Let's assume, the user clicks and chooses data from Monday to Tuesday, fast SQL and data are refreshed, then user chooses data only from the previous week, fast SQL and data are refreshed.
I would like to ask first - is it better to load sometimes very huge amount of data and then somehow just filtering them or to execute every time REST method and just refresh grid?
For the time being, the user chooses an option from the menu, I call the REST method and present data in the second activity. Now I would like to execute almost the same SQL, but with different WHERE clause, depending on the user what he wants to see.
Should I call the whole mechanism to execute the REST method or is there some library which allows me to modify SQL and "in the fly" execute REST method with different parameters?
It depends on how large the original data is.
If the data is really big then the best option is to add filtering in the request and receive the filtered data from your backend.
In case your data is pretty much static and would probably stay the same you can fetch it all and save it to your local DB and then query it locally
but if the data is not that big you should just request it all
Anyway you should read about Pagination
The Android team also created a paging library as part of the architecture components
I'm trying to learn the best way to control the data a user sees within an application.
As an example I've set up a database that has a table for a bunch of parks that each have separate fields
DBSchema
Now I will have multiple users using this application
I don't want them to be able to see all of the parks available
I will manually create users and select which fields they see, this
will be the only way to get an account.
What is best practice when dealing with this situation? How should I set up the users table in the database in a way I can control what parks are visible to them?
I am currently exploring some possible solutions
Send a pre packaged SQLite DB with the application, and use HTTP Post
calls to alter the DB depending on which user signs in.
Store the entire SQLite DB on the server and make a call to it when a user first signs in.
I am somewhat stuck with my development at the moment because I don't know how to handle this.
The applications functionality is complete in its current state, having multiple users see something different from the same database is something I have never done and should really know.
Any tips on what I should be researching or general guidelines for this would be great.
I am coming from a Sencha Touch background into Android/ Java programming.
For a simple List based application (say a Note, that has a Note Title, Note Text, Note Author, Note Date Created, Note Comments),you could define a Note model with Title, Text, Author, Date Created and a Comments model, that has the Comments Text and Linked Note object/instance. (the basic way to make a database design)
You can then define a Data Store (a local database) that knows which endpoint to fetch the serialized Notes data from (essential a JSON array of Note objects, with embedded comments objects inside them), and define functions to draw out useful info out of the JSON array and put it into the Notes object
The View (the actual list display of notes) then accesses the Notes Stores and anytime the Store is changed the ListView is updated automatically.
Is there such an elegant mechanism in Android? I experimented with ORMLite (which is somewhat similar to stores), but is there a way to achieve this tight external endpoint -- local store -- list view binding in Android?
Out of the box, Android offers but one type of database, SQLite. While there are other storage options (file system, preferences, etc) it sounds like you def want a DB. Android has a nice write up for all storage options, and here's the SQLite section.
To bind that data with a ListView, you'll need to use a CursorAdapter. If you don't want to handle the view generation part, you can instead use the SimpleCursorAdapter. However they are more or less the same thing. As the name implies, these adapters work with Cursors. Cursors just expose the results of running a query on a database.
To achieve the automatic updates, you'll need to use a CursorLoader. Basically this guy handles querying for data on a background thread, then feed you the results on the UI thread. When there is a relevant change in the DB, it'll re-run the query and return you the latest data. Android has a nice write up explaining how to do this.
I currently have an Android app which uses 3 SQLite database tables and I want to store this data on the cloud in my Java-based GAE app. It will be used as backup and also, the user will be able to view it in their browser upon logging in. The user is entering data into the Android app so all the data in the 3 tables belongs to that user. Is there a recommended way of storing this type of user-specific data? Should I store user email with each entity in order to identify it or have a User entity as the parent and all the entities belonging to this user as the children? Are there any advantages of using a parent in this case?
It all depends on how many records you have for a single user, how frequently these records are updated, and how you access this data (what kind of queries you need, etc.) So there is no simple and definitive answer to your question.
Most likely, you will be fine with either approach unless you have thousands of records per user and they update them every few minutes, at which point you may run into some limitations.
Note that you don't need to include an email address to identify each record. Typically, you create a user entity first, and then you use an id of this user entity (a Long) to identify all other entities that are related to this user.
My two cents.Unlike Sqlite,Google App Engine is not a relational database so saving your SQlite data to GAE won't be a straightforward task.However, you could create an app on GAE where you use the useremail from ur app as the Entity key.You can then retrieve the user specific info based on this key.All(well,the most important thing)you need to do in this case is find a way to send that data from your app to GAE.
I recently started using Kinvey as a backend for my Android app. The documentation doesn't have a lot of info about Collections. I want to know if it's possible to create Collections using the same concepts applied to MySQL tables for example:
A Collection called Users will hold a User ID, Username, User Email
And another Collection called Items corresponding to users -> Item ID, Item Name, User ID.
Has anyone successfully created Collections like this using Kinvey?
kinvey.com
I have also contacted their support team about this bu no reply yet.
I'm an engineer at Kinvey and can help you at this. Kinvey uses a NoSQL store on the back end, so the concepts are a little different than those of a relational database system like MySql, but in general the same thought process can apply. A Collection is similar to a table, although it is Schema-less. This means that attributes (columns in MySql terms) can be added dynamically as needed. You simply create the collection, and then start saving data objects to it. For more info on our Android library specifically, take a look at our Data Store User Guide.