Could you point out or recommend reading on pros of using Loader regarding network/sqlite requests?
The only implementation - CursorLoader says it uses a ContentResolver. ContentResolvers as I read are used in conjunction with ContentProviders, which purpose is to expose inner-application data. It seems a bit messed up to me since I only intend to load data for internal usage. I cant see any point/benefits of using Loaders - what's bad with using ORM tool like greenDao in conjunction with plain AsyncTasks?
Are there design benefits? easy DI?
The CursorLoader is a very convinient method for querying because it takes care of the thread in an asyncronously manner. There is a lot of info here about it, you just have to search it. Here are two links that might help you to understand them.
Check inside Stackoverflow and full explanation on an expert blog.
Good luck!
Related
I am creating an android application, which i have load URL in to webView.
What exactly i want
I want to store website data which entered by users and store it in to Database.
The answer to this is it depends on your requirements. All have their benefits and trade offs around speed of different operations and simplicity.
I suggest you do some reading before making a choice. An article like this one will be a good start.
https://notes.devlabs.bg/realm-objectbox-or-room-which-one-is-for-you-3a552234fd6e
Personally I've been using Realm for over 2 years and it is fast for stuff like querying, however there are some technical caveats so make sure you read the documentation before you commit to it. I'm saying this because I didn't read it all, and although I don't regret using Realm, there is certainly some things that would have been useful to know before committing to it.
If Realm does interest you take a look at this documentation.
https://realm.io/docs/java/latest/
Suppose you have multiple activities in an app and need to share data. A pretty common pattern for Android developers it seems is to have some sort of singleton object (optionally attached to the Application singleton), and share data globally using that. That's bad enough in Java, but looks really ugly in Scala.
For message passing you can use Intents if your data consists of primitives. But what about your main domain model? I'd like to be able pass very complex objects. It seems I might be able to do that using Parcelable serialization, but I'm not sure how fast that is (my objects are data-heavy) and if it works well with Scala? Has anybody tried this?
Another idea would be to use the "HashMap of WeakReferences to Objects" strategy where the passed messages are references -- you've still got global data but access is guarded. Maybe I can get some opinions on that too, not just from Android folk but also some Scala folk.
The way I solved this was to include the Akka library in my app, and turn the global objects into messages that are passed between activities.
It seems to work OK, but not a lot of people are using Akka on Android so far and it's difficult to find best practices. If people have any comments about this strategy, let me know.
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.
I write an Android app and asking myself how to manage cursors. I know how to get data through a cursor back from the database. I don’t want to handle the lifecycle of these cursors by myself.
For Android 2.x and below I used, according to the Android API, methods like managedQuery and startManagingCursor. These methods are now deprecated. Instead of these methods I should use the Loader class for example (CursorLoader). As far as I know CursorLoader must be backed by a ContentProvider. The Android SDK recommends ContentProvider only if I want to share my data. But I just want to write a simple app, where no data should be shared.
In all my research I just find tutorials about Loaders in combination with ContentProvider. The SDK says that I can also write my own Loader over the class AsyncTaskLoader. Does someone already have some experience how to implement such a Loader? Are there any best practices? Are there any good tuturials how to implement such a Loader?
Or is it just better to implement a ContentProvider, so I can use the CursorLoader (this means a lot of work for just having a managed cursor)?
To make the ContentProvider private use android:exported="false" in your manifest.
ContentProviders are easier than you think and are the suggested way by the Android team. See http://responsiveandroid.com/2012/03/19/using-an-android-cursor-loader-with-a-content-provider.html for a good example of creating a ContentProvider.
Is it possible to successfully use Sqlite on Android without also having to use a ContentProvider?
Can someone show me a sample that doesn't use ContentProvider?
And if it is indeed true that Sqlite can be successfully used without it, what are examples of cases where ContentProvider would be necessary?
This site does an excellent job describing how to use SQLite in Android without managing to ever once use the term 'ContentProvider.'
A simple Google search such as Android SQLite tutorial -"ContentProvider" will show many many more examples.
Google is your friend.
You need to be aware that SQLite database isn't thread safe, so if you intend to have more than the one thread running at any time accessing the database, you'll definitely run into more problems than in implementing a ContentProvider.
I strongly recommend having a ContentProvider as you can bake all the difficult SQL that cannot be mapped to ContentProvider queries into URIs instead.