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.
Related
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.
I'm starting to learn Android development, and also have been trying to follow the DDD design patterns. One thing that has me confused is where application logic goes with respect to ContentProviders.
ContentProviders look a lot like repositories to me, but a lot of times I don't want to expose my repositories directly. There may be some additional application logic inside a Service which the repositories/database.
Most of the examples of ContentProviders I find show them accessing the database directly. Is it wrong to have a Service or Application object in between the ContentProviders and database?
For example I'm trying to create a personal finance/budget app (e.g Mint/Quicken etc..). I'm going to have a database of transactions and a corresponding TransactionProvider. In most cases transactions are independent from one another. Yet if two transactions are marked as part of the same "Transfer" there there will be some fields that I will want to keep in sync between the two transactions. If someone changes the category or amount of one transaction, I want to make sure the same values are updated for the transaction for the other account of the transfer.
A ContentProvider can execute arbitrary code on its insert(), update(), delete() and query() methods. They are not necessarily mapped one-to-one with the corresponding database operations, and neither do the structure definitions (i.e. fields) themselves. You could, for example:
Update more than one table when you insert, update or delete.
Keep normalized tables in SQLite, but present a non-normalized interface for querying.
Not store data in a database at all (for example to expose/manipulate the files available in your application's private storage).
&c.
So you can, indeed, include whatever business logic you want in the "backend" of the ContentProvider. In your case that would mean updating associated records to keep them in sync.
Just to clarify, since you're starting Android development, it's not necessary to build a ContentProvider if you just want to store data in SQLite -- you can use SQLiteDatabase directly for that. A ContentProvider is generally to expose your own data to other applications, or for specialized cases such as search suggestions.
From Creating a Content Provider:
Decide if you need a content provider. You need to build a content
provider if you want to provide one or more of the following features:
You want to offer complex data or files to other applications.
You want to allow users to copy complex data from your app into other apps.
You want to provide custom search suggestions using the search framework.
You don't need a provider to use an SQLite database if the use is
entirely within your own application.
If you're building a financial data app, you probably don't need one. Do you want other applications to be able to access that data?
I'm working on an Android app for homework management. I'm a senior in college, so my experience on larger projects is very limited, but I'd like to design all parts of this app well instead of just throwing something together. This includes the way data is stored.
We have two main objects/entities: Task and Subject. Even if someone uses the app for the whole time they're in college and never deletes anything, I'm guessing there would be a maximum of a few thousand tasks and a couple hundred subjects (not all subjects would be shown at once). The initial version of the app won't sync data with a server, but this is a definite possibility in the future, so I'd like to design with that in mind. We might also have an option for users to send tasks to each other.
Here are my questions:
Would a SQLite database be the best option for storing the amount of data we're likely to have, or would something like serializing it to XML or JSON then loading it into memory when the app starts work?
I'm used to thinking in terms of objects. This means that if I use a database and it has a Task table and a Subject table, my first instinct is to convert each database table row into a corresponding object for viewing/editing. (The objects' setters would contain validation logic.) Is this a good/helpful/necessary way to think? If not, what is the alternative?
Thanks for your help!
This question is broad so may comments below may not be 100% correct as I don't have all the information about your system.
SQLite is better suited for storing thousands of records than files (be it JSON or XML). This is especially true if your data is not static, i.e. will be changed during the usage of your app (which is the case for you, I believe). You can take advantage of existing functionality for records inserts, updates, deletions, using indexes, etc.
Yes, you generally create objects similar to your database. But you don't usually need to convert each and every record from the database into your objects. You usually query the database for a limited number of objects, depending on what you want to show in the UI. Of course, if you need to show all, let's say, tasks, you need to get them all.
1. Would a SQLite database be the best option for storing the amount of data we're likely to have, or would something like serializing it to XML or JSON then loading it into memory when the app starts work?
Yes SQlite will be the option for you.It will give you a structured format and in future if you want to access data from remote end the same structure of tables can be used without much change in the code.
2. I'm used to thinking in terms of objects. This means that if I use a database and it has a Task table and a Subject table, my first instinct is to convert each database table row into a corresponding object for viewing/editing. (The objects' setters would contain validation logic.) Is this a good/helpful/necessary way to think? If not, what is the alternative?
you can simply execute queries to manipulate data.
But dont forget to encryt your database if you storing it in mobile itself.
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.
I'm new to both db4o and Lucene.
Currently I'm using db4o to persist my data on an Android app. I need the capability to perform quick searches, as well as provide suggestions to the user (e.g., auto complete suggestions).
An SO poster mentioned using Lucene to index data and db4o to store it.
Has anyone implemented this approach ? If yes, I would appreciate if they share the overall approach? What are the alternatives?
I used Lucene to extract keywords from items to be stored in the database and store what I call 'keyword extension' objects that point to the corresponding domain objects. This made the domain objects findable by keyword (also allowing for stemming), and separated the keywords concerns. The database was built from a large static dataset (the USDA food nutrient database), so I didn't need to worry about changes during runtime. Thus this solution is limited in its current form ...
The first part of the solution was to write a small chunk of code that takes some text and extracts both the keywords and corresponding stems (using Lucene's 'Snowball' stemming) into a map. You use this to extract the keywords/stems from some domain objects that you are storing in the database. I kept the original keywords around so that I could create some sort of statistics on the searches made.
The second part was to construct objects I called 'keyword extensions' that store the stems as an array and the corresponding keywords as another array and have a pointer to the corresponding domain objects that had the keywords (I used arrays because they work more easily with DB4O). I also subclassed my KeywordExtension class to correspond to the particular domain objects's type - so for example I was storing a 'Nutrient' domain object and a corresponding 'NutrientKeywordExtension' object.
The third part is to collect the user's entered search text, again use the stemmer to extract the stems, and search for the NutrientKeywordExtension objects with those stems. You can then grab the Nutrient objects that those extensions point to, and finally present them as search results.
As I said, my database was static - it's created the first time the application runs. In a dynamic database, you would need to worry about keeping the nutrients and corresponding keyword extensions in sync. One solution would be to merge the nutrient and nutrient keyword extension into one class if you don't mind having that stuff inside your domain objects (I don't like this). Otherwise, you need to account for keyword extensions every time your create/edit/delete your domain objects.
I hope this limited example helps.