I still haven't really wrapped my head around synchronization. I know it's there, I know why it's used and what the idea is behind it, but Im lacking the practical skill and real world examples to understand exactly how it works and how it's implemented when several activies are trying to read/write to the database at the same time. Do you share your objects through Application, or is the system intelligent enough to synchronize various objects of the same type?
Perhaps a Content Provider is a better way to go as I understand that has built in sync.
I digress though.
Im still confused over database activity. Remember that I have a service running every 60 seconds in the background reading the same table an update function is writing to. Yes Im looking to change this, but right now I want to understand database handling in Android more and work out what's happening.
If I have a loop such as:
db = provider.getReadableDatabase();
while(theres_still_work_today) {
do_some_calculations;
update_database;
}
provider.close();
this works fine as a standalone. If I try and place this in a thread, I get errors galore about locking. But when run like this:
while(theres_still_work_today) {
do_some_calculations;
db = provider.getReadableDatabase();
provider.close();
update_database;
}
I find that bizarrely, this actually seems faster, and gives no locking issues.
Am I just being incredibly lucky that I don't get two events triggering at the same time causing a lock? Is there some kind of timeout built into database handling in Android/SQLite?
I don't understand why the last bit of code should work OK, and why it should work faster?
Im not entirely confident about the Android Emulator though. If I use the first option with a single open/close outside the loop, sometimes I can get through a long long loop fine even though the service triggers in the background.
Other times it crashes on a whim.
I also don't know why "isDatabaseLockedByOtherThreads()" does not report that it is locked by other threads.
Any advice?
Thanks
Simon
Related
This question already has answers here:
Meaning of Choreographer messages in Logcat [duplicate]
(5 answers)
Closed 8 years ago.
I am building a new game with andengine and for some reason i keep getting this debug statement in the logcat:
01-31 21:29:50.503: I/Choreographer(697): Skipped 152 frames! The application may be doing too much work on its main thread.
Im not really sure what is causing this error exactly during my game. I am checking a lot of collisions, but they arent initiated until after the game play scene has started.
I also noticed on my galaxy S3 the game causes my phone to "flicker" when swiping changing home screens and pulling down the task bar at the top.
I think this error has something to do with it, but i am not sure. What do you guys think?
Also each time the user goes to another level i initialized the collision detectors all over again. But i dont unregister or stop the last collisions that were started. I thought they would be automatically cleaned up when the new one is initialized.
What do you guys think?
It sounds like you're aware of what the message is telling you, i.e., your frame rate is lagging. Your follow up question, "why?" is going to be impossible to answer without more information. You've provided some possibilities: is it the collision handling? Is it processing of unnecessary collisions? Is it some problem in the scene transitions? The answer is, maybe. Maybe it's any of those things. Maybe it's something else. At the moment all we can do is guess, because we're not looking at the code.
But the good news is, you're not without recourse! What you need to do is test your code and find where the bottlenecks are. A good place to start is to throw in some calls to clock the milliseconds between blocks of your code that you suspect are the problem. You may discover that things you'd assume we're slow are actually happening pretty quickly, and conversely, things you thought were fast are happening slowly. Focus on the latter! Put more calls in there to see where exactly things are taking longer. And look at your code to see why it might be running slowly there. Are a lot of objects being instantiated there? Is it reading from disk? Etc.
When you're ready for them, there are some great third party tools to get deeper into the testing, but it's worth spending some time to clock and review your own code first. You have the advantage as the author of suspecting where the problems may be. Start investigating!
Side note, I'd provide some links to third party tools, but I'm writing this from a jacuzzi. I'll update later.
I keep adding data to a List as my app runs. When I close it and run the app again, the old list is somehow still there and the new data is added to the end of it. I don't want this to happen and I don't know why it's happening... I think I'm initializing it properly and closing things with onPause() and onDestroy().
I'm not quite sure what's going on or where, and maybe the problem is from elsewhere in the code... All I know is that the app is not working right (on the first run it doesn't work like its supposed to, but when I close it and run it again it works just fine). And this was the only fishy, seemingly related problem (?) I could find in several hours. I don't even know what part of my code to post so I'm not looking for any specific answers, but any insights, ideas, or tips would be greatly appreciated.
EDIT: Okay, I fixed the specific issue with the List, by initializing it in OnResume(), as suggested. However, the problem remains that on the first run, things are derpy, but closing and reopening it fixes everything. It seems like there's still something going on that transfers over...
Read these...
Application Fundamentals
Activity
In particular learn that the concept of an app is not the same as any individual application component such as an Activity. Also understanding the Activity life-cycle (creation, starting, resuming, pausing, stopping, destruction) is paramount to understanding where and when to perform various actions.
Sorry - a bit of a generic answer but as you haven't provided any code it's not possible to give anything definitive.
One thing I will say though is both of those links above when combined would probably solve 50% of all the common Android questions I see here on SO.
Currently I'm receiving a JSON from a server with updated information on a contact. Currently, I iterate through the JSON and do an update on my app on the phone, but for 2000 contacts, it takes up to 50 seconds(I used transactions too, b4 that it took 70 seconds). Is there a faster way to speed this up?
Well, just remember that it's 2,000 row updates, and on a handheld phone/tablet. It's not a high-powered server with an in-memory database. This stuff takes time. Unless you're doing something more than what you're saying, it doesn't sound like you're taking more steps than required (i.e. there's nothing to cut out in order to save time)
Often performance is just as much perception, as it is optimization. One way to deal with this reality is to simply return control of the UI to the user, making your app look snappy and responsive, while doing the contact updates in another thread in the background. That would give your app the appearance of being very fast, even though it still takes 50 seconds to complete all the updates.
Are you using Android's built-in JSON objects? If so, that may be the source of the performance problem. The first time I profiled my app, I was surprised to find that JSON parsing was causing the biggest performance hit (see also this post in the Android Developers Blog).
You should profile your code to find exactly what is taking the most processing power then perhaps you may be able to find a more efficient solution to your problem
Profiling on Android is done making a tracefile on view, then viewing it with Traceview.
See here for detailed information
Hey,
So I've pretty much got my applications code down, but I'm having an issue with one of my classes. The Layout for my game board is pretty extensive and takes a long time(as far as android is concerned) to build. To make the game playable there is a large amount of input from a bunch of buttons and a lot of code that takes a long time. Although my layout by itself loads without an issue, when I throw the running code into the class's onCreate() the application dies. How could I keep my application from timing out? Would making another class that does all of the game actions or would it still time out?
Make that second class and turn it into an AsyncTask. This will allow you to do the heavy lifting in the background while showing a friendly spinner to the user. The official tutorial can be found here.
i have a (perhaps stupid) question:
im using 2 threads, one is writing floats and one is reading this floats permanently. my question is, what could happen worse when i dont synchronize them? it would be no problem if some of the values would not be correct because they switch just a little every write operation. im running the application this way at the moment and dont have any problems so i want to know what could happen worse?
a read/write conflict would cause a number like 12345 which is written to 54321 and red at the same time appear for example as 54345 ? or could happen something worse?
(i dont want to use synchronization to keep the code as fast as possible)
The worst that could happen is that your reader thread never sees anything your writer thread has written. There is no guarantee that memory written to by one thread will ever be seen by another thread without some form of synchronization.
If one thread is writing to a particular float and changes the value from 'a' to 'b', another thread reading the same float will only see either 'a' or 'b', never a third value.
As for any other potential logic problems your app may experience, it is impossible to answer this without knowing more about your app.
Worst case is that your users find you application is errant because it does not behave properly due to concurrency issues.
Uncontested locks do not add much overhead. You should always write an application correctly first and then optimize only after running metrics which indicate where you're problem areas are. I'd wager that a lot of your application code is likely to be the source of performance issues rather than some basic synchronization.