Am working on one of my requirement, halfway through am stuck on an issue. As per my requirement I need to know if any calendar event has been updated, say like any new participant is added or any event fields has been updated say Title,Description or location. As of now am able to know precisely if any event is added or deleted from system, but unfortunately am not able to detect out any update.
The same scenario goes to media, i need to know if any fields related to a media is changed, say name,title or parent folder/path etc.
to summaries my requirement is to know if any filed in Media or Calendar db is updated. to detect Insert or Delete am using Content Observers, as it only tells me something is changed by through onChange() call back, but it never tells you which rows was updated.
regards,
techfist
I had a similar problem with the browser. I made use of shared preferences.
When I read the DB, I know that I have read all the entries until the time stored in shared preferences. So each time I read DB, I need to check for all the changes after the time that was stored in shared preferences and update the time in the shared preferences to current time. For code and my implementation can can look to my solution in Android History Content Observer
Related
So I am wondering about how necessary it is to store variables in the realtime firebase database if I want all Users at access the same dynamic variable.
So for instance, I have a arraylist that stores the list of open games, and if I want this list to update in realtime for every user should this List in firebase realtime database?
Sorry for the simplicity of the question
Yes, it may be a simple question, but it surely pops in head of everyone, once.
I think for updating any list dynamically in real time, would require you to access any kind of database.
It is not necessary to have it on Firebase database, but any database online, that can tell every open instance of your app that the list has to be updated at a particular instant.
The main reason of why you need it to be on database is updating it in real time and that too dynamically.
If it's not dynamic, meaning the content that you need, can be hardcoded then one way would be placing everything you need in your code and using timer or something like that to fire at particular moments to update things in your app.
Also that aside, sorting, storing and changing data is much simpler using a database, which also becomes one more reason for you to use a database like Firebase to keep content of your app that has to be updated frequently in real time.
You can know more about database in this Google link, I found.
I have enabled the Firebase Persistance in my application. If I am setting a value to a child such as
child.setValue("XYZ");
I am not adding value to the parent tree. I am just updating the value of one child. So here, the value will be updated again and again by the user as he uses the application like many times a day. So, my question is, if user do not have inter-net connection for days, will this thing generate bug as Firebase is storing these things in cache. Does all the data get stored offline with mechanism something like commits in git or just the latest value is stored. I am asking this thing because it's kind of cache so if firebase stores data with all the logs and values the child gets then it can make my application buggy and slow as it will carry all the cache all the time.
If you are getting offline and you are updating a single record than, when your getting back online, only your last update will be updated on the server. Let's take an example. You have a product in which you store a timestamp. Every time you make an update, you change that timestamp with the current timestamp. If you are offline and you edit that product several times, when you'll be back online, only the last timpstamp will be added on the server.
But remember, this not happening when you add new data. When you do this, all the new data is added on the server accordingly to time you have added. This happening also when you delete.
Hope it helps.
I am using ews-java-api and having a lot of problems
I create appointments and also listen for appointments created elsewhere.
My problem is I create the appointment with
new Appointment(exchangeService).save(notificationMode)
I also save the appointment details including uniqueId, lets call it x, to my db
I see the appointment appear in exchange no problem, I then see a notification that it has been autoaccepted (I can turn off auto accept for the room and still get the same problem below.
Then I see my exchange subscriber kick off as it receives the notification events from exchange that a new appointment has been created. I seem to get 4 events each time, a created event, two modified events and move event.
The problem is each of these events have a uniqueId of y not x as I would expect.
This means that I cant check to see if this is an appointment I have already created.
I never get an event with the original uniqueId x as I would expect. I know that unique ids can change, and that sucks, but there does not seem to be any other field I can use.
Any ideas what I can do to work around / fix this?
A given id for an item will change when the active directory in which it resides changes. It sounds like your auto accept is moving the item. I have not tested this scenario.
If you do a simple .save() you will get a create and a modify event back from exchange on your next push/pull. There doesn't appear to be a way to prevent this. They should have the same id as the one that you got from your save. You just need to check to see if you already have the item for the create. For the modify, well I can't speak for Microsoft as to why we get a modify but it should be exactly the same as the create.
You are then getting a modify, and a move event when the item changed directories. These 2 items will have different ids than the one that you received during the original save. The ItemEvent has an oldItemId that I believe you can use. It's also possible to parse out the GUID from these ids which doesn't change but no real need to do that I think. Best approach might be to use the OldItemId and process the move event.
Let's say you have a database table name table1 with columns name and surname. Two different clients open the same view from the java application and get the data for same person at the same time.
1) First client changed the name and pressed save button to update database record.
2) Client2 still sees the old record on the screen and then pressed to save button to change the surname.
It actually overwrite the record by old name. I think to check and get the latest data before updating the database when I click button but I do not like this solution because of making a second query before update.
So how can we solve this problem by using Hibernate and without using Hibarnete. Any idea?
Of course if you do not want that something will be overridden, then you have to check the data before an update. But it will be not always a real query with a good caching strategy. You could also use a timestamp with last update to compare it easier. Another strategy would be to lock the entities when the first user will read them. But that is normally not a good design for web applications or you have to integrate a messaging service, which will all user inform for an update who actually have open that entity. But I think that is not so easy to implement and a more advanced feature.
In short, compare the timestamp of an entity and if already updated, then compare the changes and show them for the user who wanted update that entity.
I have implement a grid which displays document metadata and the user is able to edit the document on right click. I wanted to implement a locking mechanism for this. What would be the best way to put a lock on the document when one user has opened the editor ? These documents do reside in the database.
Just add a column that specifies who currently has the file checked out. When a person tries to check out a file, if that column is set, they will not be able to check it out, and will be notified of who has it checked out. Unless you have thousands of requests per second for a single document, this method will work fine.
In addition to adding a column to say who has the file checked out and preventing access using that. You can add a timestamp for when the lock was requested.
This way, if someone requests it and the lock is, for example, 30 mins old with no changes made, they can take the lock. (If the original user didn't quit gracefully or something).
If the documents are in a database, the database itself should have support for preventing inconsistent access.
http://docs.oracle.com/javase/6/docs/api/java/sql/Connection.html#setTransactionIsolation%28int%29
If the editor does not keep database transactions/connections open for the duration of file editing, however, and the java application runs client-side rather than server-side (as you could simply create a lock in the editor for concurrency on the server side), then things get a bit trickier and I haven't yet had enough database experience to say how you would resolve that, as using a field in the database to indicate editing status would have concurrency problems with that type of setup (unless the database itself supports locking on records, but that would depend on the DB engine in use).
Oh, one possibility would be to use file modification times (have a timestamp field in the database and update it each time a file is modified) and keep a no-dirty-reads-allowed transaction in use while checking the timestamp and determining if the file was modified by another user after the user attempting to save last accessed it; if so, it won't save the file to the database and will instead alert the user that the server-side file was changed and ask if they want to view the changes (similar to how version control systems work). By disallowing dirty reads for all such transactions, that should prevent other users from changing the file's record while the first transaction is open (to mark a record as "dirty", you could perhaps use a dummy field that would be updated at the start of each transaction with some random value). (Note: aglassman's answer would work similarly to this.)