I need to have a Graph(or some equivalent data structure) in memory which should hold a set of IDS(numbers) and the requirement would be that the graph(or some datastructure) might have about 10000 nodes.The scenario is explained below. Should I choose any API or my own custom implementation.Please consider memory and speed (Please feel free to tell me any suggestions.)
Eg:
I would get all the leaf nodes at every instance. ie
In the figure below I would need only 6,7,8.
If the program removes 6 from the graph then the output would be 4,5,7,8
Sorry to stress it again.Please consider memory and speed as it should run on android.
Thanks
You might also want to have a look at the following post: Is there a Directed Acyclic Graph (DAG) data type in Java, and should I use it?
What you want is a DAG (Directed Acyclig Graph) library.
What API implementation are you considering? I can't think of any Java collection that suits your needs.
If you just implement your own, you can keep track of the leaves as you build and modify the tree, so whenever you need to get the leaves, you already have a list of them. If you use a a HashSet to keep track of the leaves, I think you should be able to do all tree operations without incurring an extra time-complexity hit because of the HashSet.
Of course, you'll be using extra memory, but it's up to you to determine if that will be an issue. I'd say that even with 10k possible leaves and running on android, it should not be of any concern.
Related
I'm a newbie to Android, however I'm not entirely new to Java. From what I can tell, the ArrayMap should be used over the HashMap due to less memory used/performance increase. I'm not entirely sure when I should use one over the other beyond that, however while attempting to send an ArrayMap over a Bundle/Intent, I noticed that I was unable to do so, yet I could with a HashMap.
So, I thought, instead of just succumbing to using HashMap, especially when it's not necessary to, I'll create my own Serializable ArrayMap, however I'm unsure as to how to go about it.
All I know is that I implement three methods, readObject, writeObject, and readObjectNoData, all which have a Stream as an argument. I'm assuming I have to go through each item in the ArrayMap, then write it to the output stream and read from the input stream to recreate the ArrayMap. What I want to know is... how I should go about doing so.
I'm sorry if there is a duplicate question, but I can't really find any at all. So I'll start off with an example to fend off any "YAGNI" (You Aren't Gonna Need It). For one of my projects, I maintained a nested ArrayMap of objects, with said objects being in the thousands, with nested key-values to reduce collision greatly. I can't go too far into it, as it was for a recent school project. I wanted to be able to preserve the data structure over the life cycle of the application, including onDestroy of MainActivity, without having to parse everything all over again.
My solution ended up being to create a constant (static final) ArrayMap and access that, which worked, but it feels like I'm going against the philosophy of Android Development. Also I'm assuming that when MainActivity is destroyed the constant is also destroyed as well, yet with a saved bundle, it will be preserved, which is what I want.
I'm getting off topic... anyway, I want to create a Serializable ArrayMap, but I have a lot of questions regarding it. For one, what would be the best format to represent the objects nested inside of an ArrayMap? JSON would be my guess, although I've never actually done anything with it before. Then, how do I get the information from the objects nested inside? Do I enforce that only certain objects that implement an interface I declare may be added to the map? Then HashMap doesn't have this requirement. Do I use reflection to obtain each field and value, but then isn't that super slow?
I cannot use any third-party libraries, however I would love to do this from scratch regardless as it feels like a good way to learn more, does anyone have any tips/ideas on how to properly approach this? Thank you in advance!
I've got a question more about a strategy to use in order to implement the following requirement.
I need to develop a functionality where a user can perform some actions in the application like posting photos, commenting on photos etc. Every of this actions should leave a log somewhere and after entering one of the screens in my app, all the logs should be visible chronologically (the latest first). I've used a TreeSet sorted by item date and it works pretty fine. The problem is to keep this data persistently so that there's a never ending history of logs. I'm reluctant to migrate my code to SQLite unless it's necessary.. I like quite a lot my TreeSet structure thanks to its methods I managed to keep the logic simple. The problem starts when I'm to save this object across different launches of my app....
Has any one any idea how to solve it? Maybe TreeSet is a wrong decision though?
Putting the Logs in SQLite isn't a bad idea. Your other options is to put them in a file, and keep writing to it. You could then write a class to handle sorting it which shouldn't be too bad. The added benefit of using SQLite would be that sorting by Date would be a breeze. But then then exporting it would require the extra work, while having it already in a file makes it easy. So its really just a preference.
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.
I am going through a bit of a design dilemma, I have been targeting Android 2.3.3 and have a custom implementation of a ContentProvider. I then have a class of static methods to abstract the Content provider - providing me with objects representing each entity (row) based upon my query. For a while I was very comfortable with working like this, until I started wanting to use the whole collection in a number of places, for performing "hit tests" and drawing to the screen. I then had the headache of keeping my object representations up to date, and at this point have decided I need to step back and reconsider where to take this.
As I say, I am presently using 2.3.3, and realise that in 3.0 CursorLoader overcomes a lot of the problems I have encountered. I still need to support smart phones though, so unless there will be a backport I cannot do this.
As an interim solution I started to register notifyChange listeners so that I can rebuild a collection with my original query, but this strikes me as very CPU intensive and potentially slow. I haven't yet decided whether I should roll back from using my static facade and instead use the now obsolete managedQuery call from Activity.
I therefore have two questions:
1) Is there a preferrable way to avoid the issues with working against a collection based around a contentProvider?
2) Have you any advice on working with raw cursors in an activity? Should I be making objects out of them or working with the cursor as-is? I certainly feel they should be in an AsynTask while performing the query, but after that can I use them anywhere?
Ok, well I came to a decision and it works reliably.
1) Is there a preferable way to avoid
the issues with working against a
collection based around a
ContentProvider?
I have decided that the approach I took was correct; In my situation it is preferred to make a cache rather than maintain a cursor (managed or not) to the ContentProvider; this allows me to reuse methods and reduce the amount of code that requires testing. NotifyChange listeners are important until working on 3.0+ and that means I should guarantee the NotifyChange is called - another argument for centralising all of this code, so that it indeed triggers the changes when expected.
2) Have you any advice on working with
raw cursors in an activity? Should I
be making objects out of them or
working with the cursor as-is? I
certainly feel they should be in an
AsyncTask while performing the query,
but after that can I use them
anywhere?
In my use case I have decided it is a matter of thinking about what it is I am planning to create - avoid unnecessary work, with respect to returning unnecessary rows & fields and potentially creating unnecessary objects. If I am looking to create a map of entry names and entry IDs then I shouldn't be getting all of the other fields too. Abstracting from the collection is good but it must be lightweight and take in to account how the data is used - whether it is a one-off or may be used repeatedly. It is important that it is written for performance rather than completeness.
I am a complete noob to android but I have been programing c# for a long time. I am writing an android application and have gotten to a point where the c# programmer in me wants to start creating a loosely coupled design and and moving code into different layers, using interfaces, etc.
But then I stumble upon the Designing for performance guidelines it is telling me to avoid object creation and then it also is saying to optimize judicially.
Do I just build based on good design and then deal with performance issues as they come up?
The last thing I want to do is go through the work of building a application and have it perform poorly. Can someone point me to some examples of application that are designed well and have good performance or just make some recommendations?
Thanks
I've found AndEngine to be fairly well designed and it has to be concerned with performance since it is a game development library -- so you might pull down a copy of it and read the source.
In the "Designing for performance" document, I would point out this statement:
Note that although this document
primarily covers micro-optimizations,
these will almost never make or break
your software. Choosing the right
algorithms and data structures should
always be your priority, but is
outside the scope of this document.
An example of this would be creating a particle system. A good way to model it is to have a ParticleSystem object that holds a collection of Particle objects...maybe those Particles implement a Particle interface...this is not the place to avoid object creation. However, for performance reasons, you will want to optimize the ParticleSystem to recycle Particle objects rather than creating them from scratch every time you spawn one.
Personally, I haven't found performance to be much of a limiting factor but I suppose that will really depend on what type of app you're building.
My opinion is to build a suitable design first, test the performance, and optimize from there.
Pay more attention to Donald Knuth's quote that appear in the same article:
"We should forget about small
efficiencies, say about 97% of the
time: premature optimization is the
root of all evil.root of all evil."
Then if you are dealing with the other 3% you'll see...
As a general rule, the thing to do is keep the data structure as simple and normalized as you can. Like don't just throw in hash table data structures just because they are easy to grab. Know how to do profiling (here's my method) and if you have a real performance problem then fix it. Otherwise, the simpler the better, even if that means simple arrays, lists, and O(N) loops.
The reason to keep the data structure normalized is, if it is not, then it can have inconsistent states, and you will have a strong temptation to write notification-style code to try to keep it consistent. Those can be real performance killers. If you do those, the profiling will tell you it that's what is happening.
If you must have redundant data, I think it's better to be able to tolerate some temporary inconsistency, that you periodically repair by passing through the data. This is better than trying to intensely guarantee consistency at all times by notifications.
Another problem with unnormalized data structure is it can have lots of object creation and destruction. That also can be a real performance killer, although you can ameliorate it with the pool technique.