I am new to ngrx, and I would like to ask you a question.
I am currently creating a small game to practice ngrx, and I would like to store the current game state in ngrx.
I have a list of objects that I can drag/drop, and that receive server updates.
I am, at the moment, for each drag/drop and server update updating my item store.
My question is, is it ok to constantly update the store for each element. I don't see big performance issue atm, but I would like to know if the approach is ok.
Related
I am new to android and java and working on an app that has a few remaining problems that I haven't resolved yet.
I have a main activity that is a viewPager, with each page being a fragment. If the 4 fragments 3 are extended from ListFragments and one from PreferencesFragment.
The ListFragments have CursorAdapters to get data to and from SQLite databases through providers.
I am able to get data into the database, insert, modify and query the data correctly and fill the list views ok.
My preference setting are to choose different ways of viewing the data in the database.
Not knowing how to do this, I have implemented a process where I modify the cursorLoader query to the provider with a number of different choices of the "WHERE" clause. I have worked out the logic for the preferences as they exist now, implemented the code but had some difficulty finding what to try to trigger the refresh of the ListView.
Since the "dataset" hasn't really changed, no trigger can come from there, plus that would just use the same cursor as it currently exists to run the query again and return the same results (or be smart enough to know that it doesn't need to run).
On Stack Overflow I did find a couple of references to a similar implementation that suggested reStarting the cursor loader, which would then on the reStart read the current values in the stored Preferences file, create a now modified WHERE clause that will show the sub-set of data as specified in the preference settings.
In testing the app now, even with the reStart of the cursorLoader, the ListView isn't getting refreshed.
The only time I can get it to work right is restarting the app. If I stop the app and restart it, the new values are used and the ListView presents as the preferences dictate.
In looking through Stack Overflow and the Android site, I did find another set of APIs that might have been a more natural fit for what I am trying to do, namely the Filter APIs.
First question then would be, did I go in the wrong direction on how to control the "filtered" view of the datbase. Is filtering a better approach and a recommended way of
doing what I am trying to do?
Second question would be related to the fragment lifecycle of my ListFragments to achieve this CursorLoader update.
Thanks for any input on the topic.
-Dan
Found my problem here.
Two things, the way I am trying filtering is working and from what I have seen in the
Android development site, a reference there indicated that the filtering capability is
already implemented in the CursorAdapter, CursorLoader classes I am using.
When my preference settings changed, I did a reStart of the cursorLoader, but had restarted the wrong one.
Problem solved. Any input on is there a better way would be appreciated.
Regards, Dan
Lets try this explanation again...
I'm new to polymer (and getting back into web dev after a relatively long absence), and I'm wondering what the recommended approach might be to more closely manage object state while employing 2 way databinding. I am currently consuming rest API (json) objects. My question is if polymer keeps a copy of the original object before initiating updates to the bound object's properties/attributes...so one might be able to easily undo the changes? While allowing 2 way databinding to work its magic is often desired, there are cases where I'd like to prevent / delay changes to the object / DOM until the user approves the changes (say via the paper-dialog component for instance). I suppose one could make a temporary copy of the object and bind fields to that version, and then only persist the changes back to the source object upon user approval. In any case, I'd be interested to hear thoughts and see an example or two of recommended approaches (especially if I am off-track with my ideas!)
I suppose one could make a temporary copy of the object and bind
fields to that version, and then only persist the changes back to the
source object upon user approval
This.
Consider that view-models are essentially different from pure data-models (sometimes called business-data). Frequently, the differences are irrelevant and one can use them interchangeably. However, be aware of scenarios where the view-model is distinct (uncommitted user edits are a good example).
The notion of a field editor that requires approval from the user is purely UI/View oriented. Whatever data is managed in that modality is purely in the domain of the view, and fetches/commits to the business-data should be discrete.
I guess I would need some really good explanation on some Model related concepts.
In general does the model, as described by frameworks like Robotlegs play the role of an application state holder, or a domain state holder? I originally thought that models are entirely domain based, i.e UserModel, LocationModel, which play the same role that DAO classes play on the server. The more source code I am looking at though, the more I see stuff like UserAccountModel, ShoppingCartModel, etc, full of properties and methods related to the state of the client application, not the domain state.
I see that the people do not bother to add complex relationships to the VO classes, i.e. if a User has a lot of photos, the photos collection is obviously omitted from the UserVO class. Instead, a bunch of PhotoVO objects are loaded from the server whenever necessary, based on a service call with the user ID. Is that some sort of a rule of thumb - in general keeping VOs as "bare" as possible? Doesn't that increase the possible number of calls that must be made to the server to fetch all the data? Moreover, doesn't that fragment the domain model in general? (an entity User class on the server will always have a photos property)
With so many calls to the server, it is normal to fetch some objects that might be already on the client storage. does it make sense to make a client side cache, and check if the object that is going to be fetched is already there, or in general, the overhead of getting it once again will be paid off by the benefits of getting a fully synced object from the server. Otherwise, every object stored on the client side cache must be cared for when a change occurs. I personally think that the overhead of getting an object from the server, which might have already been picked up before is not as big. Better have fresh and synced data I'd say.
I do not believe your question is answerable, because so many of the answers are "it depends." It depends on the application you're building and the needs of the UI.
I don't really understand your distinction between "Domain State" and "Application State." However, I believe that any "Value Object" style classes implemented in the UI should focus on holding the state of specific views. It is extremely rare that a single view is a one to one relationship to database tables. As such, my UI Data Objects may not be identical to server side data objects. Although, it is very common that I will map UI objects to server side objects using AMF. But, it doesn't mean that every object in the UI is implemented server side and every server object is implemented on the UI.
I see that the people do not bother to add complex relationships to
the VO classes,
I'm not sure where you see that; I will often do exactly this. However, it depends what the view is supposed to display. IF the view is not displaying a lot of photos related to the user, then I won't make a remote call to retrieve the user information with all their photos.
With so many calls to the server, it is normal to fetch some objects
that might be already on the client storage.
It depends. I would say that the apps I write, the calls to the server are done as needed; and attempts are made to limit them as appropriate. If I already fetched data and have it cached on the client, then I am going to try to use that cache instead of retrieving the data again.
I'll restate my original assessment: I think the answers to most of your questions depend on the situation, and depend on the app. You seem to start with overally broad generalizations about how things are done. However, I Do not believe they are universal truths. Developer's fight about application architecture issues all the time.
I created my App with iOS 2.0, first using the C library directly. Then I moved on to using FMDB (much easier on me). But today, it has become too much of a hassle to manage faulting, caching and prefetching of data. I'm pretty sure that using CoreData would make the app more responsive and lighter (memory-wise).
I'm prepared to go through a long and hard work redoing everything in CD, but I need to migrate existing data. I've considered creating a new model with new objects (CDTrack, CDTrackPoint, CDSegment etc) and then move the existing data that's in objects such as Track, TrackPoint Segment to this new store. But is it really a wise idea? Are there better ways to do it than duplicating the old graph one by one?
You're basically on the right track.
What I would probably do is to create an NSOperation for migration that runs when the app starts, if the data needs to be migrated.
Depending on your application, that operation might be able to run in the background (be mindful of Core Data threading rules!), communicating with a main thread NSManagedObjectContext using notifications.
If your app doesn't make any sense without this data migrated, maybe you put up a modal view with a progress indicator while the data is migrating, giving the user a better idea of how long they have left to wait.
Depending on how much data we're talking about, you might be surprised at how quickly Core Data and SQLite can do this sort of thing... The key is to keep the user informed, do it in the minimum amount of time possible and if your application design supports it, do it in the background. Make sure to do the work off the main thread to keep the UI responsive.
Have fun!
We are in the process of designing a web site were users can fill an application form and submit it. Once an application is created, it goes through different departments for review.After each review, the department persons log on to the website and update the status of the application. Once review is completed, the application is said to be 'approved'. Also, communication(email) is sent to the applicants updating them about the status of their application.
I am thinking of using Windows Workflow for this application, but am new to it.
Can anyone tell me if it would make sense to use WF for such an app..or would it be an overkill..I was thinking of using a State machine workflow, as each application created goes through different states. One of my major concerns is, this process also involves manual work such as reviewing the application(this could take days) and then updating the status(say by clicking a button on the website). Can workflow handle this kind of thing?
I have gone through many websites, but they talk about very basic examples where states change automatically.But in my case there is a lot of human interaction.
Any help is appreciated
Thanks!!!
Here is a sample on MSDN that describes a very similar workflow that you've described - although they use a Windows Forms client rather than a web client - but those details shouldn't matter given the use of the Workflow Runtime.
I would say that your situation would be well suited to Workflow - long-running workflows are supported by having the runtime automatically persist workflow details at certain points while it runs, so steps that take days or weeks to fulfill are perfectly fine.
"my case there is a lot of human interaction".
That's the easiest kind of thing to build. It's just transactions.
Each stage in the process is a simple web application.
Fetch all items that are waiting at this state. Display them in a list. User picks one.
Display that piece of work. User makes changes. Saves it. Some change will move it to the next state. It's still just an update.
That's it. Nothing fancy.
You just need to very, very clearly define each state.
You must have a simple query that finds work in this state.
You must have a simple update that moves work on to the next state.
The states must be very, very clear and simple definitions. One column with a state name, for example.
The state transition rules, however, may be complicated. If the work is highly manual, it may be as simple as a drop-down list of available states.
If the state transitions are complex, then, perhaps you need something more sophisticated to embody the transition rules. But since it's manual, you don't need much.
Do I need a separate workflow instance for each application created?
I don't know what this can possibly mean. Each "application" that's moving through the pipeline of manual processing steps has a "state" -- the step of the pipeline where it's waiting, right now.
Each application also has a complete history of each state change. I don't know which of this is a "workflow" that could have an instance. They're just states of being of an object.
It is a web application. So it will have some other logic such as view an appln., navigation etc. do I need to accommodate this in the workflow as well?
Yes and No. Yes, each processing stage which show the application so the user at that stage can do whatever value-add thing they do. They add information or they approve information.
Each stage in the workflow is a place where some human being makes a decision and takes an action. So each stage displays all the information the person needs to make the decision. There's no additional view required.
Navigation isn't terribly interesting. People go to pages to see their queues of unprocessed work. I guess you'll have to build a page with some URL's, but there isn't much to that.
Would it be ok to have just a part of the application based on workflow.
Sure. Why not? I'm not sure I understand the question.
Your web apps just queries a queue of stuff out of the database and present that queue of stuff to a person. The person can request details and make changes to a specific item in the queue. One change the person can make will be to move the stuff out of their queue and into someone else's queue.
This isn't very complex. It shouldn't be. What's hard is defining the allowed state changes.