I have three classes,
Activity - displays the listview with my single_list_item.xml
SQLiteOpenHelper - I'm currently running my queries here.
My activities and my SQLiteOpenHelper talks together well. However I'm not sure how to run a query from my third class
BaseAdapter - This one is not in my manifest, and with my current skills I can't access the db from this one - as I normally do from activity classes.
I want to hide a textview in my single_list_item.xml depending on the value from my query(the query only returns 0 or 1). I can easily hide it or show it statically by defining tv.setVisibility(View.GONE) etc. - But I want this one to be active or not depending of the usersettings.
Any help is greatly appreciated.
A common approach is to create a singleton, that is first initialized with a Context. That holds the SQLiteDatabase, and has all the data specific methods that you use from your application.
Thus, from your BaseAdapter, you call MyDBSingleton.getInstance().getData()
Be sure, that the singleton class keeps an ApplicationContext, and not a reference to an Activity/Service, as that could cause leaks...
Related
I have two questions.
Suppose I'm creating an android app with three types of screens:
first, a series of 3 tabs that display information in a list. The type of information determines which tab(s) it's displayed in.
Second, a screen with in-depth detail about a selected list item.
And third, a screen where you can add a list item, which will populate the appropriate list.
What would be a good structure for this program? Right now what I have is a Global class (extends Application) that keeps track of the lists and imports them from a JSON file, an Activity (and accompanying Fragment) for each of the three screens above, and a separate Fragment for the individual tabs.
However, I'm finding that importing the JSON file in the Globals class requires Context that I can't figure out how to get. Before I go any farther, is this a good structure?
And if so, how can I get context in a Global class?
I'm working in Android Studio 3.
Application is a Context. That is, you can just use the current instance – this – wherever you need a Context. (There's no need to call getApplicationContext().)
However, the backing Context will not be properly initialized and attached yet in an Application's constructor. An Application is actually a ContextWrapper, which is a Context subclass that delegates all method calls to a Context field that is created and set by the system upon launch. This means that you cannot call any Context methods in the constructor, as it will still be null there.
As with the Activity and Service classes, though, Applications generally should not have any explicitly defined constructors anyway. Any initialization that needs to be done can be performed in its onCreate() method. The Context field will have been set by then.
I have one Activity, I created class called DatabaseHelper that extends SQLiteOpenHelper,
now when I want to use it (has I see in many simple examples) I need to have new SQLiteDatabase Object & implement insert, update, delete... in my Activity code.
What is the right design if I want to work through database with number of activities and to create DatabaseHelper just once, for all the activities will work with it.(and not have duplicate code.
simply: what is the right classes SQLite structure for number of Activities
Thank you!!
Just use one DatabaseHelper throughout your application, there's no profit in repeating yourself.
Make your DatabaseHelper a singleton across your entire application's lifecycle. Check out my blog post on the topic:
Correctly Managing Your SQLite Database
I have a class which extends Application in an Android tabHost app. In the App class, I've been placing methods and variables which I would otherwise need to re-create in every class. One method reads from a DB and stores results in an ArrayList (first name, last name for instance). Rather than re-reading this database and re-creating the code for every tab view which needs the info, I've stuck the method and ArrayList in a class extending Application (myAppClass). This way, by setting up mAC = (myAppClass) getApplicationContext() from any tab view in onCreate() I can reference all the get..() and set..() methods in myAppClass.
My original plan was to use a shared class with static methods and variables but I read a lot of "don't do that" threads so decided to go the Application route. Now, I've run into a situation where I'm trying to use myAppClass in a Project Library but getting errors about android.app.Application cannot be cast to... If I change myAppClass back to static methods/variables (and do not extend Application) things work, but this is supposed to be a big no-no. Is there another way to do this? Not sure if Android passes everything by reference but Would I be better off to re-implement the entire application by passing huge (thousands of objects/members) ArrayLists back-and-forth between methods/classes?
My original plan was to use a shared class with static methods and variables but I read a lot of "don't do that" threads so decided to go the Application route.
The "don't do that" is generally a recommendation against anything in global scope and therefore would cover static data members as well as a custom Application. Both are likely sources of memory leaks.
Now, I've run into a situation where I'm trying to use myAppClass in a Project Library but getting errors about android.app.Application cannot be cast to...
Your manifest in the hosting project probably does not state to use the library's Application implementation.
this is supposed to be a big no-no
Again, static data members are no worse than a custom Application, and in many cases are better.
Is there another way to do this?
Don't use either an Application or static data members.
Would I be better off to re-implement the entire application by passing huge (thousands of objects/members) ArrayLists back-and-forth between methods/classes?
You would be better off having a persistent data model, such as a database. Using static data members as a cache for a persistent data model is OK, so long as you are very careful about your memory management.
I have an application which has several screens. Lets say A B C D and D might open some external application as well.
All this activities share data, an arraylist with one another and I have created a reference to it in my Application class. (I have created a class which extends Application and referred to it manifest.) So all these are using single instance of arraylist. A initializes the arraylist since its first screen and others might modify it.
The problem is when I test this on emulator nothing gets broken. But on 'some' phones after 3+ screens of navigation arraylist just clears from the heap. No matter how small size is.
Use a singleton class for your ArrayList
Use singleton design pattern or make your object static
With the Singleton design pattern you can:
Ensure that only one instance of a class is created
Provide a global point of access to the object
Allow multiple instances in the future without affecting a singleton class's clients
Declare ArrayList as static in your first Activity then use it from any it will not broke up.
I have a ListView with a custom ArrayAdapter, that shows orders from an ArrayList. These orders are supposed to be synced with my server. There I have an API, which I am requesting for new orders, and if there are any, I get an XML of the order back. What is the best approach to dynamically update the listView? I do not want to use SQLite to store the orders, because only last ten are supposed to be displayed. With a ContentProvider I am not able to store my custom Order object. And if I wrap the ArrayList into a singleton class and use it in the service as well as in the Activity class for the ArrayAdapter, the ListView is not dynamically updated (probably, because the arrayAdapter makes a copy of the arraylist?). Thank you very much.
Filip
use Intent or Bundle
i'm no sure what you mean regarding the ArrayAdapter not being updated, but i can give you a solution we used in my company.
I have a DataMaanger which is a bridge between the Activities and the Networking or SQLite.
The dataMaanger keeps it's data in memory so it's not in DB or on disk. the disadvantage of it is if your app gets killed for lack of memory and reconstructs itself, the dataManager will be empty, which leaves you with two options, either on every Activitie's death or you main task's activities death you serialize your DataManager's data, or if you are not dependant on any previous data, just make arequest again and update the data manager.
I use broadcasts to notify my activities.
To get an access to the DataManager i don't use a sigletone. i use the Application object, you can extend it and in the Manifest.xml give it's name in the tag, then it will be used instead of the regualr Application object.
You can access it later by using getApplication() method in Activity class.