So I have an Android app that is running in a TabActivity that separates 3 different activities through this tabs. I've set a DatabaseHandler class with SQLite and all, fine.
The thing is, so far I don't really know how to deal with the database since it will be receiving data from one of the activities and I need to be showing that data in a different one. I don't know if I should declare the db in the main TabActivity or where, I've never worked with SQL in Android before and I'm pretty lost at the moment.
I tried to picture it so it is more understandable: Explanatory Graph (Sorry, I don't have enough reputation yet to post the image into the post directly)
Thanks in advance.
Although using your DatabaseHandler is posssible within each activity in the long term I think most non-trivial apps would benefit from using a ContentProvider
ContentProvider provides an abstraction over your data. It becomes really powerful when you combine it with a CursorLoader and LoaderManager available back to Android 1.6 by using the support library.
These concepts require a bit of study but will make sharing data across multiple Fragment or Activities simpler and less error prone.
Mobile Tuts has a couple of good tutorials that are worth reading on top of the official Android documentation and examples:
http://mobile.tutsplus.com/tutorials/android/android-sdk_content-providers/
http://mobile.tutsplus.com/tutorials/android/android-sdk_loading-data_cursorloader/
You should be okay, as long as you close your connection with the database as soon as you're done reading/writing to the database.
Each activity should be able to have their own DatabaseHandler.
Related
I am a bit confused as I am new to android development. Let me put a scenario:
My app has 2 activities
SQL Lite DB related
List view
How should I use Android studio to combine both of the above? I cannot find a conclusive answer on the internet so that's why I am asking all the professionals out there.
Are you looking to have both in one page? In that case I would consider using Fragments, in which multiple to could housed into one activity and can run there. Could you elaborate more on what you are trying to do?
If you want to connect a ListView to some SQL database, there are many ways you can display that, but it depends on how the database is laid out.
I'm reading the official documentation from android's content providers and I've seen this:
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.
I'm developing an app that syncs data on background when the position changes through an IntentService.
What I've seen is that with ContentProvider you could observe when data changes which I really want without user noticing it. It changes in IntentService and MainActivity observes this changes and when it's notificated, layout content change
Is it a great idea to use a ContentProvider although they don't even mention this?
Thanks
Personally, I have been using ContentProviders in all my projects for the last year and a half. They provide good, database independent, data abstraction to access your data. They are very flexible, I even had a play project where one URI pointed to a SharedPreference while all others where for accessing database tables. ContentProviders also allow you to use already built framework infrastructure such as CursorLoaders, for example. Implementing your own from interfaces and abstract classes is not that hard, but it may be time consuming and error prone, being able to just leverage work that's already been tried and tested is a great advantage.
By the way, I remember the same exact question on a post in google+ about 2 weeks ago where Cyril Mottier gave a very good answer. You can read it here.
My project is a visitor app for a University, that basically displays places and events on a map, and allows the users to interact with one another by making posts with advice/recommendations/questions and so on.
So far I've been trying out bits of code seperately (lists, tabs, the basics), following the android tutorials and trying things for myself. My problem is that I'm not sure how to combine all the bits of code into one project.
I know that I need to make a database, and a map (using OSM rather than google).
The database will store information on places, events, and posts that users have made. With co-ordinate information because they need to go on the map. This information is also displayed in seperate tabs - e.g. a list of places.
My problem is that I don't know how this will all fit together.
Will I need seperate classes for the database, populating the lists, and displaying on the map? Or can they all be in a single class?
I'm a little hazy on how the classes and activities are going to communicate, too. At the moment I'm thinking the database object is going to get passed to the listviews and mapview, which then take and display some of the information?
Any advice on how to cobble these elements together would be much appreciated. :D
I think I will need to subclass SQLiteOpenHelper for my database, so it'll need to be its own class?
I'm thinking of using OSMdroid for the map, which I'm not sure how to do yet.
And everything needs to be inside a tabview.
Welcome to StackOverflow!
Your question is very vague and broad, and likely to get closed as "not a real question" - I suggest you take problems one by one and ask specific questions as you go along and run into problems. Try to think about your problem in these terms: what's the minimal thing I need to get it to do the thing I want. Keep in mind that ANYTHING you want to do is possible, the main question to ask yourself is: what do you want your application to do exactly? Think about the number of different screens (activities), and how they would communicate to each other (when you click XXX, that will lead you to YYY, and so on). One advice: start simple, it's very easy to get buried in too much complexity, especially since it's your first project. It can quickly become very complex, even with a simple concept.
As you didn't specify your level of expertise in coding, it's difficult to give precise advices: but coding an android application is not very different from a "regular" application, with a web or Swing or C# user interface. So I would advise you to learn about OO programming in general, things like composition, inheritance, encapsulation, dependency injection, unit-testing, etc.
Then start writing a base Activity for your main view, write its layout, and add views and graphical elements to it. Then add the listener code for your widgets, that will generate Intents to other Activity.
Then add a DatabaseHelper when you want to save stuff in a database (that can come later, to begin with, you can just "stub" the interactions to a database, by writing what you would save to db on screen using Toast for example).
All objects can be injected into other objects by passing a reference to them, either at construction time or through setters.
Sorry not to be more precise, as I said it's a very vague question.
Are there any advantages of Loaders over Async task? Also, how to make loaders compatible for phones with Android froyo.
Edit:
The primary problem here is that I'm not using the native DB(SqlLite). Using the DB on development server. Obviously, I can't use CursorLoader any more. AsyncTaskLoader has no examples at all. If any, please do link.
Is it a better idea to load the data required onto the local DB and then query it using CursorLoader?
Yes, Loaders are more advantageous than AsyncTask as they take care of a lot of things that AsyncTask falls short of, miserably.
Screen Orientation changes are difficult in AsyncTask. I used to have such a problem, till I used an Activity Control class, which I used to retain while configuration changed. I can give you some code if you want to know how. The app used to crash, though, when you changed the orientation multiples times even before the entire data loaded. The secret here is not load a lot of data with your first thread and and finish your threading tasks as soon as possible. Even if it happens in the background, Android has a shabby way of dealing with threads. You never know when one of your tasks would be killed.
Even if you use a AsyncTaskLoader, makes sure that you use an Activity manager. This will help you in getting more control over the activites and AsyncTask.
Yes, it is compatible in all the old version of Android. You need to include the support library(Most of the times, this is included by default but its always nice to double check.)
For one, loaders are easier to code (they're almost built-in in Fragments).
Loaders (specifically CursorLoader) also handles your cursor for you (like the deprecated manageQuery).
Check out this link to read on how to use Loaders pre-Honeycomb.
There simpler to implement and take care of a lot of the life cycle management which previously had to be done "by hand" with AsyncTasks. See the answer to this question for further detail.
With regards to using them with Froyo, they're available via the compatibility library.
It seems no one is talking about the disadvantages of loaders! I'm currently working on a system that runs other services in the background.
What I have noticed is that as soon as a screen with a loader is resumed. The cursor used by the loader locks up the DB.
It may not be open to most people but getDatabaseWriter from sqlite is actually a synchronized method and hence the cursor used by the loader is never closed until the loader is reset or terminated thus locking up access to the DB.
I cannot recommend using a loader under these circumstances nor can I advice using a loader when your result set consists of less than 100 items which are static and never seem to change.
Another advantage with loaders is that they handle screen turn event gracefully whereas asynctask can give you trouble.
Biggest diff:
CursorLoader will update your UI's content as soon as its related ContentProvider changes its content(say through a Service), while AsyncTask will only update your UI when you tell it.
I've already written some small Android Applications, most of them in one Activity and nearly no data that should be persistent on the device.
Now I'm writing an application that needs more Activities and I'm a bit puzzled about how to organize all this. My app will download some data parse it show it to the user and then show other activities depending on the data and the user interaction. Some of that data could be cached, some of it has to be downloaded every time. Some of that data should not be downloaded freshly at the moment the orientation changes, but it should on the moment the activity is created...
Another thing I'm confused about are things like a httpClient. I now for example create a new httpclient for every activity, the same thing for locationlisteners.
Are there books, a blogs or documentations with patterns, examples and advice on organizing larger apps build on android? Everything I found until now are get startet tutorials leaving me alone after 60 lines of code...
I would be very happy if some of you could provide some good resources.
Check out the Application Fundamentals if you haven't already. It's got a wealth of in-depth information. Then you can branch out to the more specific guides like Designing for Performance or Supporting Multiple Screens, which a large app would certainly have to deal with.
Also, here are some deeper specifics on Activity Design.
Google actually has a ton of awesome doc on this stuff.
I'd suggest taking a look at existing open-source Android applications and learn from how they solved the problems you are facing.
For instance, I learned quite a few tricks from reading Foursquare Android App source code. I'd highly recommend reading source-code like reading a tutorial/book.